軟件工程之美7講——大廠都在用哪些敏捷方法？（下）
一個應用敏捷開發的小組日常
分工上
產品經理：寫需求設計文檔，將需求整理成 Ticket，隨時和項目成員溝通確認需求；
開發人員：每天從看板上按照優先級從高到低領取 Ticket，完成日常開發任務；
測試人員：測試已經部署到測試環境的程序，如果發現 Bug，提交 Ticket；
項目經理：保障日常工作流程正常執行，讓團隊成員可以專注工作，提供必要的幫助，解決問題。
如何完成需求和修復 Bug？
這個小組的日常工作，也是圍繞 Ticket 來開展的。所有的需求、Bug、任務都作爲 Ticket 提交到項目的 Backlog，每個 Sprint 的任務都以看板的形式展現出來。每個人手頭事情忙完後，就可以去看板上的“To Do”欄，按照優先級從高到低選取新的 Ticket。選取後移動到“In Progress”欄。
每週一部署生產環境
沒有人願意星期五部署，那意味着如果部署後發現故障，可能週末都沒法好好休息了。所以即使程序早已經測試好了，除非特別緊急，否則都會留在下一週再部署。所以部署放在上半周，這樣後面遇到問題還有足夠的時間去應對。部署很簡單，按照流程執行幾個命令就可以完成生產環境部署。部署完成後，需要對線上監控的圖表進行觀察，如果有問題需要及時甄別，必要的話對部署進行回滾操作。但輕易不會打補丁馬上重新上線，因爲倉促之間的修復可能會導致更大的問題。像敏捷開發這樣一週一個 Sprint 的好處之一就是，即使這一週的部署回滾了，下週再一起部署也不會有太大影響。
每週二開迭代回顧會議，總結上個 Sprint
每週二的早上，這個小組一般還會預留一個小時的時間，因爲常規的站會完成後，還有一個迭代回顧會議 (Sprint Retrospective) 會議，目的是回顧一下在迭代中，團隊有哪些做的好的地方，有哪些做的不好的地方。對於需要後續改進的，需要創建相應的 Ticket，加入到 Backlog 中，在後續迭代中改進完善。例如會議上，測試人員反饋說，上一個 Sprint，開發人員上線前幾個小時還往預部署的分支裏面更新代碼，導致測試需要重新做迴歸測試，但因爲時間不夠了，沒來得及測試完整，導致上線後不穩定，建議以後不要隨意在上線前，在部署分支更新代碼。對於這樣的問題，可能不止一次發生，說明流程上還是存在問題。所以最後大家商定，以後如果不是緊急的修復，就不要在預部署的分支上更新，確實要加，需要和測試先確認。如果會議中要形成涉及項目的決策，最好是通過集體表決的方式決策，儘可能避免獨裁式決策。因爲敏捷的原則之一是要善於激勵項目人員，給他們以所需要的環境和支持，並相信他們能夠完成任務。
每週四迭代規劃會，計劃下週工作
每週四早上，也需要一個小時來組織會議。因爲常規站會完成後，還有一個迭代規劃會（Sprint Planning Meeting）。這個會議是要大家一起討論下一個 Sprint 的內容。在開會之前，產品經理和項目經理會商量好 Ticket 的優先級，會議上，大家一起按優先級從高到低的順序，從 Backlog 中選出下個 Sprint 的內容。團隊每個成員都要對候選的下個 Sprint Backlog 中的 Ticket 從 1-5 分進行打分，1 分表示容易 1 天以內可以完成的工作量，2 分表示 2 天內可以完成的工作，5 分表示非常複雜，需要 5 天以上的工作量。這裏需要注意，打分時，要大家一起亮分，而不是挨個表態，不然結果很容易被前面亮分的人影響。評估每條 Ticket 工作量的大概流程如下：會議組織者閱讀一條 Ticket，可能是用戶故事，可能是 Bug，可能是優化任務。同時會詢問大家對內容有沒有疑問。大家一起討論這個 Ticket，確保充分理解這個 Ticket。每個團隊成員在心中對 Ticket 進行工作量估算。會議組織者確認大家是否都已經確定估算結果，確認後，開始倒數：“3，2，1”，大家一起伸出一隻手，亮出代表分數的手指頭。如果估算結果存在分歧，出分最高的和最低的各自說明理由，討論後達成一致。這種估算工作量的方法有個名字叫估算撲克，因爲亮分時用撲克牌亮分而得名，但並非一定要用撲克牌。用這種方式評估工作量有幾點很明顯的好處：大家積極參與，詳細瞭解需求。相比以前，可能只有當某個功能模塊分配到自己頭上的時候，纔會去詳細瞭解那部分需求，而其他開發人員可能都不瞭解這部分需求。工作量是由實際參與開發的成員作出評估，往往更準確也更容易被接受。以前項目經理代爲估算的模式，很容易不準確，或者讓開發人員牴觸。促進成員的交流和經驗分享。我們知道一般經驗淺的新手估算工作量都會偏樂觀，而經驗豐富的老手則會更準確，通過這種方式，新手可以向老手學習到很多工作量估算甚至技術實現的經驗。所以，在經過幾個 Sprint 的磨合後，一般一個團隊在每個 Sprint 的產出是比較穩定的。比如說這樣一個 7 人的小團隊，一個 Sprint 預計可以完成 20-30 分的 Ticket。
每週五分支切割
週五標誌着一週的工作要結束了，所以下班之前（4 點左右），要做 branch cut（分支切割），也就是要把當前主幹上的代碼，克隆到一個分支（branch）上。爲什麼要做分支切割這一步操作呢？經過一週的開發，master （主幹）已經合併了不少新的 PR（Pull Request，合併請求），但是如果你直接把 master 的代碼部署到生產環境，肯定還是不放心，畢竟自動化測試還是不能完全代替專業測試人員的測試。所以我們需要把 master 上的代碼部署到測試環境進行測試，並且對測試出來的 Bug 進行修復，直到穩定下來爲止。由於 master 還需要一直合併新的功能，所以最好的方式就是每次 Sprint 結束，從 master 創建一個分支版本出來，然後基於這個分支部署和修復 Bug。所以需要基於主幹做一個 branch cut，創建一個預部署的分支，將預部署分支的代碼部署到測試環境，這樣在下週，測試人員就可以測試新的版本。測試驗收通過後，預部署分支的代碼會部署到生產環境。每週輪值小組裏面除了日常開發工作以外，其實還有不少瑣碎的事情，比如每週部署生產環境，每天部署測試環境，每週的 branch cut（分支切割），回答其他小組的問題，主持每日會議（不一定需要項目經理），這些事情如果都是一個人做難免會有些枯燥。在敏捷開發中，鼓勵發揮每個成員的主動性，所以每週輪值是一個不錯的方式，可以讓每個人都有機會去體驗一下，幫助團隊完成這些事情，更有集體榮譽感和責任感。一些問題解答