迭代回顧會議諮詢記錄
每次敏捷迭代都是一次PDCA迴圈， 迭代的回顧會議則是其中的A(adjust)，不斷的覆盤總結可以幫助專案一次比一次做的更好，使團隊形成一個自學習的組織。
近日我旁觀了一個敏捷專案組的迭代回顧會議，專案組成員對本次迭代的經驗教訓進行了總結，我作為外部顧問旁觀了整個過程，並對專案組中存在的問題，本次迴歸會議的優缺點進行了點評，諮詢記錄如下：
|
迭代回顧會議諮詢筆記 |
|||
|
型別 |
相關實踐 |
現象 |
建議措施 |
|
改進點 |
Daily meeting |
在每日站立會議上沒有每個角色通報任務進展，尤其需要不同角色協同的任務。 |
開發完成了什麼，測試測完了什麼都需要在站會上通報。每個角色都要了解其他角色完成了什麼。並且要在看板上將任務狀態視覺化。 |
|
改進點 |
Daily meeting |
在迭代初期發現的測試人力的瓶頸問題，但是沒有采取有效措施。 |
當發現測試人員成為瓶頸資源時，需要增加人手。 |
|
改進點 |
Design |
開發人員做過了過度設計，把需求想複雜了，把設計的通用性想複雜了，並沒有和需求溝通。 |
簡化原則； |
|
改進點 |
Design |
缺少UI設計，導致開發出的軟體不夠美觀，操作不簡便。 |
儘快招聘UI設計人員到位； |
|
改進點 |
Planning |
測試工作量、開發工作量估計不足。 |
策劃會議上要溝通，策劃撲克法； |
|
改進點 |
Planning |
有些任務沒有識別出來，有計劃外任務。 |
估算時要識別可以提供的時間，把一些公司培訓任務等排除在外。 |
|
改進點 |
Requirement |
PO出國2周，開發人員無法及時與PO溝通需求。 |
每週，PO和開發至少1天一起工作。 |
|
改進點 |
Retrospective |
Retro會議詳細回顧每個任務的進展。 |
不需要詳細列出每個任務的完成情況。首先回顧完成的需求； |
|
改進點 |
Retrospective |
SM在會議中很少發言，沒有及時制止跑題。 |
SM要控制會議不要跑題。 |
|
改進點 |
Retrospective |
SM不需要對已發生的問題先分析原因。 |
只列現象即可，不要引導成員的結論，不要限制成員的思考。 |
|
改進點 |
Retrospective |
迭代回顧時，沒有迭代資料的積累與展示。 |
統計某個迭代實際上班時間，投入本專案的時間，%； 統計某個迭代的實際生產率； 統計某個迭代的缺陷個數； 統計缺陷修復類任務的工作量分佈，為以後做缺陷修復工作量的估算提供參考。 |
|
改進點 |
Retrospective |
讓大家自由發言，沒有總結的主線。 |
要採用海星法總結，給大家一個思考的主線。 |
|
改進點 |
Retrospective |
在回顧會上，有同事一直沒有發言。 |
要採用海星法總結，讓所有人都參與進來。 |
|
改進點 |
Retrospective |
有人打斷別人的發言，替他人總結問題 |
在會議紀律中要強調一下； |
|
改進點 |
Retrospective |
問題提的多，措施提的少。 |
每個人在提出現象時，要給出改進建議； |
|
改進點 |
Support |
開發環境，部署環境一致性。 |
環境固化，使用提前通知，安排資源 |
|
優點 |
Design |
後端坐了設計文件，前後端的介面更容易，減少了介面錯誤。 |
堅持。 |
|
優點 |
Requirement |
需求反講很有效。 |
堅持。 |
|
優點 |
Retrospective |
SM先宣佈了會議紀律。 |
會議紀律文件化： 聚焦本次迭代； 每提出一個現象就要提出一個措施； |
|
優點 |
Testing |
在測試之前，開發和測試做了需求溝通，有利於測試效率的提升。 |
堅持。 |
|
優點 |
Testing |
做了UT的培訓，開始做單元測試了。 |
堅持TDD。 |
|
優點 |
Support |
大家都在使用confluence, Jira工具。 |
繼續在JIRA 中維護需求，整合更多的工具進來。 |
|
優點 |
Mindset |
大家都意識到了進度和開發效率提升了，對開發模式建立了信心。 |
繼續堅持敏捷的相關世界，不斷總結經驗教訓，積累度量資料，通過資料客觀刻畫改進效果。 |