本文里會以一個功能π的開發流程為例，展示公司內一個敏捷團隊的軟件開發實踐。
項目背景
客戶R是澳洲最大的在線房地產廣告平臺。公司團隊是協助R客戶創建一個針對中國市場的房產信息廣告平臺，用來展示澳洲以及其他海外房產，方便國內投資者。
作為一個全功能的交付團隊，整個團隊的人員一共11人，成員包括TL * 1、BA * 1、UX * 1、QA * 1、Ops * 1、Dev * 6?？蛻舴矫鍰elivery Lead * 1 和 Product Owner * 1, 兩人均在澳洲。
客戶負責提供項目的Roadmap，優先級以及初步的需求。后續由公司開發團隊完成從需求分析、交互設計、功能設計、實現、測試、以及部署上線的全生命周期的工作。
功能π的敏捷之旅
下面以一個功能π的開發流程為例，展示筆者所在項目的開發實踐。
計劃
項目的路線圖Roadmap是由Trello來管理的。Epic需求會由客戶PO記錄在Trello中。Trello board中設置的有不同的列，如Backlog, Planned, Next, In progress, Completed等。每列中卡片由上而下代表優先級的遞減。Trello board作為項目high level需求的管理工具，可以很直觀的了解項目整體的進展狀況。
每兩周全團隊會進行一次計劃會議，類似IPM，但是主要是根據Roadmap上的優先級，確定近期的開發計劃。
最終的輸出是一個具體的task列表。其中會包括:
- 當前進行中的任務
- 新加入的功能π
- 需要fix的bug
- 技術卡
計劃會議上會把上述列表中的任務逐個討論，目的是團隊對于近期的優先級有一致的認識，以及對每個任務的內容做澄清。
團隊JIRA作為需求管理工具，并同時使用物理Kanban墻以方便站會時討論。計劃會議中計劃的任務會在JIRA kanban board中挪至Selected for Dev列。
對于新功能π而言，PO首先會在Trello上創建卡，并設置優先級。開發團隊會按照優先級將功能π計劃到后續的開發中。
需求來了
功能π開發的第一步就是由BA對客戶提供的需求進行進一步的分析、細化、澄清和確認。如果功能π還涉及到用戶交互，UX也會參與到這一步。UX會基于BA的分析，對信息流進行梳理，完成用戶界面和交互設計。最終的輸出結果為Jira上的用戶故事。
用戶故事一般遵從As…I want…so that的格式。在用戶故事的內容上，一般會包含下面信息：
- 描述信息： 關于功能π的描述，提供更多的上下文信息
- 驗收標準(Acceptance Criteria)
- 完成定義(Definition of Done)
- UI相關設計文檔
另外一些信息會在后續環節持續補充上去，如分解的子任務，受影響的模塊，需要部署的模塊等。
分析完成的用戶故事卡片會被挪至Ready for Dev列，后續會有開發著手開發。
Story Kickoff
開發人員在開始一個新的任務前，會首先進行story kickoff。這個環節主要目標是大家對功能有正確的認識，同時避免技術坑，簡言之就是確保在以正確的方式做正確的事情。kickoff環節會有QA，Dev, BA, UX以及TL共同參與。在kickoff中，Dev會首先介紹當前自己對這個功能的理解，用戶如何與系統進行交互，如何驗證功能完成、以及技術實現。如果是一對Pair在kickoff，一般會有經驗較少的Dev來進行介紹。
Story kickoff成功后，Dev會對功能π進行任務分解，并按照優先級以及依賴關系排列子任務開發順序。任務分解的結果也會更新到用戶故事中，一般會在用戶故事卡下建立子任務，方便追蹤進度。
結對編程
團隊一般采用結對編程(Pair programming)的方式進行開發。結對編程的優點在于快速的知識傳遞，無論是對于剛進入團隊的新人，還是剛接觸某個模塊的老鳥，業務知識還是編程技能。
在功能π的開放中，這對Pair中的兩個Dev會以TDD的方式，合作完成業務代碼和測試代碼的實現。測試部分包括單元測試和自動化驗收測試兩部分。對于驗收測試的部分，Dev有時也會和QA一起pair完成驗收測試腳本的編寫。
團隊中也會周期性的輪換pair，這樣每個人都有機會接觸到不同的模塊，使得業務知識在團隊內更好的傳遞。
每日站會
團隊每天會使用Always On Video和客戶一起進行站會，更新項目的進展。
在站會中，每個人/Pair會更新一下三個方面的內容：
- 上一個工作日的工作內容
- 遇到哪些技術挑戰，有沒有風險？
- 今天的工作計劃
同時，團隊會更新Kanban物理墻上功能π的狀態。
持續集成
持續集成目前應該已經是軟件開發的標配實踐了，什么？你的團隊還沒？
功能π的新代碼每天都會多次提交到git, 持續集成工具會自動檢測代碼提交，并觸發構建流水線。流水線中的驗證環節會自動執行測試，驗證系統功能正常與否，將構建物發布到軟件倉庫, 并最終將最新版本軟件部署至測試環境。
Code Review
每個工作日的5點至6點是code review時間。這個環節所有的Dev會集中在大屏幕前，集中review當天提交到git的代碼。code review可以審查代碼中的瑕疵，從基本的編碼規范、代碼壞味、明顯的邏輯錯誤、以及功能實現上的疏漏等。同時，code review也是很好的knowledge transfer的方式。
Story Signoff
Dev完成功能π的開發后，會邀請BA，QA，UX和TL進行story signoff。Dev會在本地或者測試環境中準備好測試數據，向參與Signoff的各位同事演示功能。期間，QA會要求Dev按照多個測試場景進行多次演示，以確保功能基本完整。UX也會按照設計Mockup對功能實現進行比對，確保在各個屏幕尺寸下顯示符合設計。
Signoff通過后，Dev會更新kanban墻上功能π對應的故事卡的狀態至 Ready for QA。
QA
QA會從看板墻的Ready for QA列中將功能π對應的故事卡更新至 In QA, 并在測試環境中按照設計的測試用例進行驗證。
如果發現功能問題，會記錄至功能π的故事卡，并交由Dev修復，并再次Signoff后，繼續QA環節。
驗證無誤的話，功能π會被部署到預生產環境（Staging環境）。這樣客戶可以在預生產環境對功能進行review。
最終，π的故事卡會被挪至Ready for Release，并在下次上線時部署至生產環境。
部署上線
團隊的持續集成流水線中包含了部署上線的階段。如前所述，每次構建成功，都會將最新的軟件版本部署至測試環境。發布到預生產環境和生產環境會按照項目和業務要求，手動觸發。
對于暫時不需要發布上線的功能，如需要等待銷售或市場部門配合，團隊會使用功能開關(Feature Toggle)，將新版本部署至生成環境，但并不上線新功能。
另外，在部署流水線中，也集成了一部分的自動測試。當新版本在預生產環境和生產環境部署完成，但并未正式切換前，這些自動測試會被執行，以確保系統功能正常。
至此，功能π就完成了它的敏捷之旅，成功上線！
