成長的煩惱(16)
本文摘自《敏捷無敵》一書
阿捷：嗯，還有其他的嗎？
敏捷聖賢：有！採用Delphi方法進行任務工作量的估算。當進行任務細化的時候，每個人的估算是不一樣的，如果最高估算值跟最低估算值相差一半以上，二者就要溝通一下，看看爲什麼二者的理解相差這麼多。溝通明白後，再重新估算。即使這樣，還是會有分歧的，此時採用Delphi估算方法，簡單講就是進行一次加權平均。
阿捷：嗯，我們以前也用過Delphi方法。
敏捷聖賢：爲了提高任務細化的效率，可以將團隊分成兩個小組分別進行。
阿捷：爲什麼還要分組？不是讓大家一起做細化、做估算的嗎？
敏捷聖賢：是這樣的，我曾經帶過一個Team，有10個人。最初，我都是打開投影儀，把Product Backlog投到屏幕上去，大家一邊說，我一邊敲，我是挺忙活的，但是大家卻不一定都能集中注意力。現在回頭看看，這種方法真是有點蠢！當Team成員少的時候，在最初的幾個Sprint，大家在興趣還比較高的時候，這種方法還行。當Team成員超過6個的時候，問題出現了，首先是當討論某一個問題的時候，總會有人問，剛纔你們說什麼來着？很顯然，他走神了。另外，人多的時候，對同一個任務的細化，即使採用Delphi方法，溝通成本也很高，很費時間。
阿捷：那你們具體怎麼做的？
敏捷聖賢：後來我就把Team分成兩個小組，分別對任務進行細化。細化時，不再用投影儀，而是把Sprint Backlog中的內容按大塊張貼在牆上，大家站在牆前，拿着記事帖直接進行細化和估算。當兩個小組都進行完後，互相檢查對方對任務的細化，解決爭議，澄清模糊的地方。這樣一來，就把大家的積極性調動起來，參與程度非常高，效率也高。
阿捷：雖然我們團隊現在只有5個人，估計還用不上，但這個經驗真的值得推廣。
敏捷聖賢：產品負責人（Product Owner）一定要參加。實在不能參加的話，也要指定一個人授權代理。否則，就不要開Sprint計劃會議。
阿捷：嗯，我一定會把他叫過來參加這個會議的。
敏捷聖賢：最後一點，雖然我們採用了Scrum，但即使不再採用Gatt圖，但是傳統的Risk/Dependency分析還是不要丟棄。在Sprint計劃會議結束前，進行Risk/Dependency的分析，還是會幫助我們發現一些問題的，然後再稍微重新調整任務的優先級，更能保證Sprint的成功。
阿捷：好的！有了這些指導原則，我相信我們的第二個Sprint會走得更好的。
敏捷聖賢發過來一個不斷眨眼的笑臉，似乎提醒阿捷不要過於樂觀。
阿捷：還有一個問題就是，我感覺這個Scrum好像只定義了一個項目管理框架，沒有給出具體的編程實踐指導，是你還沒告訴我嗎？
敏捷聖賢：嗯，不是的。Scrum依靠的是經驗管理，所以他沒有定義出很細的工程實踐。這樣才能很好地跟組織原來的工程實踐融合起來，譬如跟CMM、ISO 9000、RUP，甚至XP等都能很好地工作在一起。因爲Scrum主要是想解決項目管理和組織實踐範疇的東西，更多的是關注在敏捷團隊建設上，它的終極目標就是自我管理自我組織的高效團隊。作爲一個敏捷框架，具體的編程實踐，可以靠XP去補充。但我還是建議你們，最初先努力適應這個框架，待成熟後再考慮引入其他敏捷實踐。
阿捷：好的！這次我不會冒進的。?
敏捷聖賢：那就好！凡事預則立，不預則廢。對形勢做出良好的判斷並提前做好準備還是非常有必要的。我要下了，有事咱們再聯繫吧。
阿捷：多謝。886。
敏捷聖賢：886。
今天的收穫太大了，阿捷重拾起了Scrum的信心，準備帶領TD團隊再次快跑。
【敏捷精靈日記】
- Scrum注重的是管理和組織實踐，XP關注的是編程實踐，分別着重解決不同領域的問題。可以組合使用，互相補充。
- 一條可以實行的實踐原則，會比長篇大論的理論有用許多，沒有實踐原則指導的方法論沒有意義。Scrum因爲缺乏有效的編程實踐，必須通過XP或其他方法來補充。
- 使用XP，可以使開發人員成爲更好的Developer，但 Scrum方法能夠迫使那些效率低的developer變得更有效率。
- Nokia的Scrum標準：
* Scrum 團隊必須要有產品負責人(Product Onwer)，而且團隊都清楚這個人是誰。
* 產品負責人必須要有產品的Backlog，其中包括團隊對它進行的估算。
* 團隊必須要有燃盡圖，而且要了解他們自己的生產率。
* 在一個Sprint中，外人不能干涉團隊的工作。
- Scrum雖然強調文檔、流程和管理的輕量化，但並不是意味着沒有控制，沒有計劃，只是要做輕量的短期衝刺計劃。強調的是每時每刻都要根據需求和開發情況對項目進行調整，從而達到提前交付
- ScrumMaster與傳統項目經理相比，必須從傳統的控制者轉變爲引導者。
- Scrum中，對任務細分和時間估計，需要整個開發小組和Product Owner的參與。
- Sprint計劃會議議程：
上午(2 Hours)
1)充實並講解Product Backlog[Product Owner] (50 Minutes)
2)重新調整Product Backlog條目優先級[Product Owner] (10 Minutes)
休息(10 Minutes)
3)設定Sprint目標[Scrum Team] (10 Minutes)
4)選擇Product Backlog條目，組成Sprint Backlog[Scrum Team] (40 Minutes)
下午(3-4 Hours)
1) 分成兩個小組，進行任務細分， 定義"DONE"，給出任務估算. (60 Minutes)
2) 小組間互相評審，解決爭議(20 Minutes)
休息(15 Minutes)
3) 關鍵路徑分析(20 Minutes)
4) 制定資源計劃(20 Minutes)
5) 任務領取(20 Minutes)
6) 風險分析(20 Minutes)
7) 其他事情(10 Minutes)
