敏捷開發生態系統系列之二：敏捷生態系統-計劃跟蹤 I（跨職能團隊-共同估算-每日立會-同行壓力）

這是敏捷生態系統系列的第二篇（之一，之二，之三，之四，之五）。

如果說需求管理中尚有一些團隊無法控制的因素導致實施困難，計劃與跟蹤過程總歸就沒有問題了吧？其實不然，筆者見過領導很放權的全團（很多是因為領導根本管不過來了），但在團隊內部仍然存在很大的問題，一般最為突出的，就是每日立會開得毫無生機。這不完全是因為文化差異問題，而是生態系統出了問題。 

 敏捷開發中的計劃跟蹤生態大致如此（黑體字即圖片中的元素）：

 跨職能團隊的整體思路是“每個人可以做每個工作”。好處是消除了資源分派的瓶頸和造成隊員無法互助的分工壁壘。

 任務應該先估算後分配給個人，以便整個團隊（或至少其中的某個小組）都對其保持興趣，才可能進行真正的共同估算。

共同估算（一般採用撲克牌估算）中人們利用整個團隊的智慧充分討論和確認任務的實現目標和方法，因此PO會統一管理/講解需求，以防止個體理解差異。共同估算是共同跟進的基礎，在每日立會中人們之所以關注別人的進展，就是因為人們關心自己曾經參與的估算結果是否正確，方案是否可行。

 共同估算和每日立會產生了同行壓力，即每個人都希望以好於或至少持平於團隊估算的結果完成任務，從而產生了受激勵的個體。

 共同估算和每日立會還防止個體失誤，前者通過統一了大家對同一個需求的理解和其實現方法的理解，後者則防止了工作中出現需求鍍金、蠻乾等問題，從而產生更好的技能和設計。

 作為自組織團隊，敏捷團隊並非簡單地因為“領導讓我們自我管理”而受到激勵，而是在跨職能團隊、共同估算、個體互動、同行壓力這些實踐的配合下才產生了受激勵的個體和更好的技能和設計，從而產生更好的工作效率。

 

跨職能團隊-共同估算-每日立會-同行壓力是這個生態系統的主線之一。

如果從每日立會的例子看，要解決每日立會問題並不難，可以簡單地：

1. 由Scrum Master監督必須召開每日立會

2. 統計每日立會的執行情況

3. 設立按時完成獎和遲到罰款箱

4. ……

這些方法有很多公司都用過，筆者早期知道這些方法時，還真的以為這樣就可以了呢，直到後來聽說沉悶的每日立會越來越多，才知道存在深層問題。

從生態系統的角度怎樣看待呢？

第一個要懷疑的是是否進行了共同估算。如果大家都對別人的任務不瞭解，也從來沒有參與其中（，那麼自然就像聽天書一樣聽別人講；而如果別人對自己的任務不瞭解，那麼即使遇到困難，告訴他們又有何用？（除了表明自己笨……）最終就形成了沉悶的每日立會。

但如果繼續分析下去，共同估算的根源又在跨職能團隊。這裡之所以只把“先估算後分配”當作一個小跳板，是因為不能簡單地認為“因為大家不知道會分給誰，所以不得不一起估算”，大家遲早會形成習慣性分工的，所有人都會知道哪個任務其實肯定分給別人。只有“每個人都能做每個任務”的跨職能團隊才能解決這個問題。

建立跨職能團隊是個難題，個人感覺不可能強制三四個人無緣無故地就跨職能了，他們私下裡都會自動形成強分工體系的。一個好的方法是利用師徒制度和松結對程式設計建立穩固的團隊關係，責權利統一遠遠易於改變團隊文化。

儘管計劃跟蹤整體上是團隊內部的事情，但是卻可能在計劃的時候被強制多做事情，而在跟蹤途中又被加入變更而時間點不變。怎樣處理這些問題呢？這就是計劃跟蹤生態系統的另一條生態線，將在下一篇文章中描述。

 

點擊下載免費的敏捷開發教材：《火星人敏捷開發手冊》