本文里會以一個功能π的開發(fā)流程為例，展示公司內(nèi)一個敏捷團隊的軟件開發(fā)實踐捺檬。
項目背景
客戶R是澳洲最大的在線房地產(chǎn)廣告平臺再层。公司團隊是協(xié)助R客戶創(chuàng)建一個針對中國市場的房產(chǎn)信息廣告平臺，用來展示澳洲以及其他海外房產(chǎn)堡纬，方便國內(nèi)投資者聂受。
作為一個全功能的交付團隊，整個團隊的人員一共11人烤镐，成員包括TL * 1蛋济、BA * 1、UX * 1炮叶、QA * 1碗旅、Ops * 1渡处、Dev * 6∷畋伲客戶方面Delivery Lead * 1 和 Product Owner * 1, 兩人均在澳洲医瘫。
客戶負責提供項目的Roadmap，優(yōu)先級以及初步的需求旧困。后續(xù)由公司開發(fā)團隊完成從需求分析醇份、交互設計、功能設計吼具、實現(xiàn)僚纷、測試、以及部署上線的全生命周期的工作馍悟。
功能π的敏捷之旅
下面以一個功能π的開發(fā)流程為例畔濒，展示筆者所在項目的開發(fā)實踐。
計劃
項目的路線圖Roadmap是由Trello來管理的锣咒。Epic需求會由客戶PO記錄在Trello中侵状。Trello board中設置的有不同的列，如Backlog, Planned, Next, In progress, Completed等毅整。每列中卡片由上而下代表優(yōu)先級的遞減趣兄。Trello board作為項目high level需求的管理工具，可以很直觀的了解項目整體的進展狀況悼嫉。
每兩周全團隊會進行一次計劃會議艇潭，類似IPM，但是主要是根據(jù)Roadmap上的優(yōu)先級戏蔑，確定近期的開發(fā)計劃蹋凝。
最終的輸出是一個具體的task列表。其中會包括:
- 當前進行中的任務
- 新加入的功能π
- 需要fix的bug
- 技術卡
計劃會議上會把上述列表中的任務逐個討論总棵，目的是團隊對于近期的優(yōu)先級有一致的認識鳍寂，以及對每個任務的內(nèi)容做澄清。
團隊JIRA作為需求管理工具情龄，并同時使用物理Kanban墻以方便站會時討論迄汛。計劃會議中計劃的任務會在JIRA kanban board中挪至Selected for Dev列。
對于新功能π而言骤视，PO首先會在Trello上創(chuàng)建卡鞍爱，并設置優(yōu)先級。開發(fā)團隊會按照優(yōu)先級將功能π計劃到后續(xù)的開發(fā)中专酗。
需求來了
功能π開發(fā)的第一步就是由BA對客戶提供的需求進行進一步的分析睹逃、細化、澄清和確認祷肯。如果功能π還涉及到用戶交互唯卖，UX也會參與到這一步粱玲。UX會基于BA的分析，對信息流進行梳理拜轨，完成用戶界面和交互設計。最終的輸出結(jié)果為Jira上的用戶故事允青。
用戶故事一般遵從As…I want…so that的格式橄碾。在用戶故事的內(nèi)容上，一般會包含下面信息：
- 描述信息： 關于功能π的描述颠锉，提供更多的上下文信息
- 驗收標準(Acceptance Criteria)
- 完成定義(Definition of Done)
- UI相關設計文檔
另外一些信息會在后續(xù)環(huán)節(jié)持續(xù)補充上去法牲，如分解的子任務，受影響的模塊琼掠，需要部署的模塊等拒垃。
分析完成的用戶故事卡片會被挪至Ready for Dev列，后續(xù)會有開發(fā)著手開發(fā)瓷蛙。
Story Kickoff
開發(fā)人員在開始一個新的任務前悼瓮，會首先進行story kickoff。這個環(huán)節(jié)主要目標是大家對功能有正確的認識艰猬，同時避免技術坑横堡，簡言之就是確保在以正確的方式做正確的事情。kickoff環(huán)節(jié)會有QA冠桃，Dev, BA, UX以及TL共同參與命贴。在kickoff中，Dev會首先介紹當前自己對這個功能的理解食听，用戶如何與系統(tǒng)進行交互胸蛛，如何驗證功能完成、以及技術實現(xiàn)樱报。如果是一對Pair在kickoff葬项，一般會有經(jīng)驗較少的Dev來進行介紹。
Story kickoff成功后肃弟，Dev會對功能π進行任務分解玷室，并按照優(yōu)先級以及依賴關系排列子任務開發(fā)順序。任務分解的結(jié)果也會更新到用戶故事中笤受，一般會在用戶故事卡下建立子任務穷缤，方便追蹤進度。
結(jié)對編程
團隊一般采用結(jié)對編程(Pair programming)的方式進行開發(fā)箩兽。結(jié)對編程的優(yōu)點在于快速的知識傳遞津肛，無論是對于剛進入團隊的新人，還是剛接觸某個模塊的老鳥汗贫，業(yè)務知識還是編程技能身坐。
在功能π的開放中秸脱，這對Pair中的兩個Dev會以TDD的方式，合作完成業(yè)務代碼和測試代碼的實現(xiàn)部蛇。測試部分包括單元測試和自動化驗收測試兩部分摊唇。對于驗收測試的部分，Dev有時也會和QA一起pair完成驗收測試腳本的編寫涯鲁。
團隊中也會周期性的輪換pair巷查，這樣每個人都有機會接觸到不同的模塊，使得業(yè)務知識在團隊內(nèi)更好的傳遞抹腿。
每日站會
團隊每天會使用Always On Video和客戶一起進行站會尸闸，更新項目的進展元扔。
在站會中捷枯，每個人/Pair會更新一下三個方面的內(nèi)容：
- 上一個工作日的工作內(nèi)容
- 遇到哪些技術挑戰(zhàn)晓锻，有沒有風險？
- 今天的工作計劃
同時肩祥，團隊會更新Kanban物理墻上功能π的狀態(tài)后室。
持續(xù)集成
持續(xù)集成目前應該已經(jīng)是軟件開發(fā)的標配實踐了，什么搭幻？你的團隊還沒咧擂？
功能π的新代碼每天都會多次提交到git, 持續(xù)集成工具會自動檢測代碼提交，并觸發(fā)構建流水線檀蹋。流水線中的驗證環(huán)節(jié)會自動執(zhí)行測試松申，驗證系統(tǒng)功能正常與否，將構建物發(fā)布到軟件倉庫, 并最終將最新版本軟件部署至測試環(huán)境俯逾。
Code Review
每個工作日的5點至6點是code review時間贸桶。這個環(huán)節(jié)所有的Dev會集中在大屏幕前，集中review當天提交到git的代碼桌肴。code review可以審查代碼中的瑕疵皇筛，從基本的編碼規(guī)范、代碼壞味坠七、明顯的邏輯錯誤水醋、以及功能實現(xiàn)上的疏漏等。同時彪置，code review也是很好的knowledge transfer的方式拄踪。
Story Signoff
Dev完成功能π的開發(fā)后，會邀請BA拳魁，QA惶桐，UX和TL進行story signoff。Dev會在本地或者測試環(huán)境中準備好測試數(shù)據(jù)，向參與Signoff的各位同事演示功能姚糊。期間贿衍，QA會要求Dev按照多個測試場景進行多次演示，以確保功能基本完整救恨。UX也會按照設計Mockup對功能實現(xiàn)進行比對贸辈，確保在各個屏幕尺寸下顯示符合設計。
Signoff通過后忿薇，Dev會更新kanban墻上功能π對應的故事卡的狀態(tài)至 Ready for QA裙椭。
QA
QA會從看板墻的Ready for QA列中將功能π對應的故事卡更新至 In QA, 并在測試環(huán)境中按照設計的測試用例進行驗證。
如果發(fā)現(xiàn)功能問題署浩，會記錄至功能π的故事卡，并交由Dev修復扫尺，并再次Signoff后筋栋，繼續(xù)QA環(huán)節(jié)。
驗證無誤的話正驻，功能π會被部署到預生產(chǎn)環(huán)境（Staging環(huán)境）弊攘。這樣客戶可以在預生產(chǎn)環(huán)境對功能進行review。
最終姑曙，π的故事卡會被挪至Ready for Release襟交，并在下次上線時部署至生產(chǎn)環(huán)境。
部署上線
團隊的持續(xù)集成流水線中包含了部署上線的階段伤靠。如前所述捣域，每次構建成功，都會將最新的軟件版本部署至測試環(huán)境宴合。發(fā)布到預生產(chǎn)環(huán)境和生產(chǎn)環(huán)境會按照項目和業(yè)務要求焕梅，手動觸發(fā)。
對于暫時不需要發(fā)布上線的功能卦洽，如需要等待銷售或市場部門配合贞言，團隊會使用功能開關(Feature Toggle)，將新版本部署至生成環(huán)境阀蒂，但并不上線新功能该窗。
另外，在部署流水線中蚤霞，也集成了一部分的自動測試酗失。當新版本在預生產(chǎn)環(huán)境和生產(chǎn)環(huán)境部署完成，但并未正式切換前争便，這些自動測試會被執(zhí)行级零，以確保系統(tǒng)功能正常。
至此，功能π就完成了它的敏捷之旅奏纪，成功上線鉴嗤！
