乾貨｜敏捷實踐重構

點選上方“中興開發者社群”，關注我們

每天讀一篇一線開發者原創好文

▎作者介紹

丁一：無線研究院敏捷教練，也是敏捷軟體開發愛好者，致力於讓管理實踐和技術實踐在團隊中紮實落地。

葉衛軍：優秀的團隊Scrum Master，具有敏銳的洞察力，豐富的管理經驗，打造了一隻高效能的團隊。

李會毅：專注於軟體設計和開發，善於思考和總結，致力於通過敏捷軟體開發技術與流程提升團隊績效。

我們接觸敏捷軟體開發也有一段時間了，但這其中的一些實踐，比如“四會”、程式碼走查、結對程式設計等實踐我們真正做“到位”了麼？如果僅僅當成一種形式去開展這些實踐，反而達不到預期的效果。時間長了，團隊成員就會對敏捷開發動搖信心了。

在《重構》一書中，軟體大師Martin Fowler以程式碼壞味道的方式給出重構建議。本文也以敏捷實踐壞味道的方式展開敘述，結合作者們的實戰經驗對問題進行改進。這些實踐在作者們的團隊中都獲得了不錯的效果，在此和大家分享。

▶1.站會

壞味道：

- 拖沓、冗長

- 針對具體問題討論發散

- 彙報會

重構方法：

- 可以買個小鬧鐘掛在看板上，設定好時間，超時就提醒。

- 團隊成員講解的時候，要面向大家，不要看著SM。發言內容僅限站會要求的三件事。

- 不討論具體的細節問題，可以等站會結束後找相關人員單獨討論。

▶2.啟動會

壞味道：

- 任務安排會

- 只評估開發的工作量

- 冗長

重構方法：

- SM首先整理出這個迭代的backlog（優先順序已經和專案確認好）。

- 交付類故事需要在迭代前完成需求研討，輸出設計方案，如果沒有方案，不能進入迭代。

- BA已經初步拆分史詩故事（可以獨立交付、驗收）。

- 啟動會開始時，BA對方案進行講解，大家提問，達成共識後，評估點數，包括開發、驗收測試、自動化測試、UT等全部點數，拆分使用者故事。

- 當全部故事評估完成後，根據總點數，看是否超過了團隊的承受能力，如果超過，需要捨棄低優先順序需求。

- 最後認領故事。

▶ 3.回顧會

壞味道：

- 回顧內容單一

- 改進措施跟蹤不到位

重構方法：

最初的回顧會，就是傳統的敏捷回顧會，討論這個迭代做的well, less well, suggestion的地方。

當然這種方式並沒有問題。但它忽視了軟體交付過程的改進。

因此，除了上述的回顧方式，可以增加如下內容：

- 迭代度量資料解讀。比如特性、史詩故事、使用者故事的交付週期，程式碼覆蓋率等度量指標，從中挖掘需要解決的問題。

- 故障覆盤。這個可以說是我司傳統保留活動，不解釋了。

通過以上三種回顧方式，可以從文化、交付、團隊等角度全面進行回顧。

針對回顧發現的問題，在wiki上建立了專門的backlog，然後把待改進點列印出來，貼在看板上，提醒實施人跟蹤。

下次回顧會時，首先會對上次回顧會的改進內容進行討論，看問題是否解決。

▶4.演示會

壞味道：

- 缺失

- 時有時無

- 提出的問題沒有跟蹤和反饋

重構方法：

- 演示會需要固定時間，比如在迭代完成後的第三天進行。提前確定主持人。

- 主持人提前整理演示的內容，一般從需求系統上匯出交付的功能清單。用專案的整合環境進行演示。

- 主持人發郵件給用服、規劃、開發、測試、專案經理等干係人。

- 演示過程有專人記錄提出的問題。

- 演示後，主持人把演示過程和發現的問題記錄在wiki上。

- 下個迭代，對問題進行改進併合入版本。在後續的演示會上，會對這些改進點進行演示，做到閉環。

5.程式碼走查

壞味道：

- 評審的同事對程式碼不熟悉，發現不了問題。

- 討論發散。

- 只能走查部分同事的程式碼，其他同事的內容沒有覆蓋。

重構方法：

- 程式碼走查時間分兩塊：每天下午16:30--17:30，第二天09:05--09:30。如果當天下午能把全部內容走查完，第二天早上就不再進行走查。如果沒有走查完，第二天早上就要繼續走查。

- 走查前，會統計下幾個人要走查，每個人大概要花多長時間。做好初步計劃。

- 走查時，主講人要對業務背景、程式碼意圖進行介紹，讓大家有整體瞭解。

- 引入主持人機制。主持人要有敏銳的洞察力，一旦發現大家討論發散或者延遲，立即叫停。

▶6.看板

壞味道：

- 荒廢了

- 故事卡移動不及時

重構方法：

針對看板，團隊內部做過一次討論。正好當時專案要統計迭代人力投入，為了能更準確、工作量小的完成這件事情，我們做了這樣的約定。

- 迭代開始前，在團隊backlog(excel文件)中更新任務，然後把故事卡列印出來，貼在看板上。故事卡進行分類：設計、開發、測試、故障、文件、溝通等。

- 站會開始前，每人檢查自己的故事卡是否完整？如果不完整，補充故事卡。

- 站會開始時，每人在故事卡上劃道道，最多兩道（每道代表0.5天）。然後移動故事卡。

迭代完成後，SM收集故事卡，結合excel表格和卡上的道道，很容易就能統計出團隊這個迭代的人力投入以及故事交付是否延遲？並且是相對精準的，也節省了大家的時間。

還有一個好處就是：團隊的任務全部視覺化，故事卡也能流轉起來了。

▶7.自組織

自組織是大家為了目標能自發的做事情，檢驗的標準很簡單：如果SM不在，這個團隊的工作能否正常運轉下去？

要實現自組織，一定讓大家達成目標共識。

比如可以做了如下約定：

1. 每天早上8:50，自覺到看板前集合召開晨會。

2. 每天下午16:30，自覺到大電視前集合進行程式碼走查。

剛開始執行的時候，可能有些同學還不太習慣，需要有人叫一下。時間長了，大家養成習慣就按照這種方式自覺開展了。

另外，對於一些敏捷實踐，比如回顧會、啟動會、showcase等也不僅僅是sm的事情，通過認領的方式，讓大家都能參與其中，同時也鍛鍊了個人的組織協調能力，一舉兩得。

▶8.需求研討

壞味道：

- 沒有需求研討

- 計劃會上SM或者BA簡單澄清需求後開始認領故事

重構方法：

- N-1迭代BA組織完成N迭代的開發需求研討；

- 研討過程必須參與角色齊全：BA + TSE + QA + DEV（不一定全員）；

- 形成團隊自己的需求場景清單，並在後續覆盤改進中不斷完善；每個需求研討結束前對照清單逐一分析波及影響；

- 研討完成後，計劃會之前TSE和QA協商輸出測試用例

▶9.無差別團隊

壞味道：

- 團隊一個蘿蔔一個坑，各人只掃自己門前雪

- 計劃會無故事認領環節

- BA拆分好故事後，SM挨個指派任務

重構方法：

- 故事按照優先順序排序，主動認領；

- 如果認領者認領了陌生領域卡片，SM可以安排一個熟悉的同事協助，但一定要認領者負起交付責任；

- 無差別建設過程中，團隊營造一個開放的氛圍，允許犯錯；SM在考核或者語言鼓勵上，給予成員足夠的安全感；

- 如果團隊現狀不適合大規模無差別，建議逐步小範圍開始，但一定要開始做起來。後續收益會超乎想象。

▶10.結對程式設計

壞味道：

- 大部分時間都在閒聊；

- 在結對中濫竽充數、心不在焉、得過且過；

- 都結對程式設計了，就不需要程式碼走查了；

- 結對過程中兩人沒有任何交流；

- 新人和老員工結對時，新員工一直默默的看著；

重構方法：

根據團隊的實踐經驗，結對的方式是非常靈活的，結對程式設計應該是自由選擇，不應是強制性的。

是否使用結對程式設計，需要具體問題具體分析，不可盲目。任何事手都有他的好與壞，結對程式設計也不例外，只有知道了好與壞，才可以更好的利用它。提升開發的程式碼質量和開發的效率，更好的知識共享，更好的團隊氛圍。

- 如果兩個人都喜歡閒聊，就不要在一起結對程式設計，通過分別認領不同的任務。

- 不是所有工作都適合結對完成。架構設計和技術驗證、簡單的任務、已經有成熟的解決方案，這些都不適合結對。對於有挑戰的問題，結對雙方有不同的技術背景，可以通過結對達到技術互補或者碰撞找到更好的解決方法。

- 老練的程式設計師和新程式設計師結對，可以分享業務和技術經驗，使新人更快的成長，同時新老結對也需要給新人獨立完成任務的時間和機會。使新人有自己解決問題的思路和方案。通過結對-獨立開發-結對，不斷的乒乓來發現自己的短板。使團隊人員能力達到提升。

- 結對程式設計不能沒有程式碼走查，兩個人有可能缺少同樣的知識點，導致犯同樣的錯誤。程式碼走查是必須的。

- 結對需要結對雙方都要明白結對的意義，不是為了結對和結對。不能發揮結對的優勢，那麼需要果斷的終止結對。