上周五和本周二，我經歷了兩次教科書一樣的SCRUM會議。

cu_Cbear

轉：redouble

上周五和本周二，我經歷了兩次教科書一樣的SCRUM會議。

背景：
我準備在公司推進敏捷項目管理方法。想辦法得到了軟件開發(fā)部部門經理的支持。于是乎在新立項的G維護項目中進行實驗。

上周五下午，是G維護項目的一次迭代匯報會議。
會議中，我?guī)椭�項目組成員回顧了已經完成的工作，同時分析了工作沒有按照計劃完成的原因。會議的效果如下：

1.下一次迭代的估算時，每個成員每周流出1天的工作量來應付突發(fā)的事件。
2.討論出了若干實際的方法來解決項目中出現的溝通的問題。

本周二上午，是G維護項目的迭代規(guī)劃會議。會議中：

1.先約定了以后會議的一些常態(tài)規(guī)范和約定
2.計算了本次迭代項目組所有可用工作量的小時數
3.請產品經理按照優(yōu)先級的順序給大家講解需求
1.產品經理由于沒有按照部門規(guī)定的用例格式書寫需求條目，被部門經理嚴重批評
2.過程中，我盡量的引導了所有項目組成員對需求條目進行討論和澄清
4.針對每一條需求，項目組成員進行了DELPHI的估算方式
1.估算以小時數為單位，而不是功能點
2.針對每一條的估算分割成了開發(fā)和測試兩部分
5.由于有另外一個產品經理的需求還需要占用項目組的時間，因此要求兩個產品經理對需求條目進行合并，并對優(yōu)先級進行了協(xié)調。
6.項目組成員對本迭代的需求進行了認領
1.開發(fā)經理也會承擔一部分開發(fā)任務。按照原來的計劃方式，開發(fā)經理會承擔很多難度較大的需求條目。工作量過載會導致開發(fā)經理成為瓶頸。采用這樣的計算方式，避免了出現上述的問題。其他的開發(fā)人員幫助開發(fā)經理分擔了工作。
2.測試人員只有一名，但是測試的工作量已經溢出，因此要求開發(fā)人員分擔了一些測試執(zhí)行的工作。
3.最終達到了工作量的大致平衡分布。

當然，規(guī)劃會議中也出現了一些問題：

1.對于某一條需求，分割粒度不夠。有兩個開發(fā)人員估算了40小時，開發(fā)經理估算了20小時。按照一般的約定，應該由產品經理再次分割指16小時之內。但是強勢的部門經理堅持認為該需求不能在分割了�；�于當時的環(huán)境，我沒有堅持。
2.還是針對該條需求，開發(fā)人員的估算存在明顯的分歧（包括部門經理在內），出現了短暫的緊張氣氛。由于我意識到該條需求具有明顯的潛在認領者（開發(fā)經理），因此我也沒有堅持針對他的估算必須達成一致。
3.針對于需求的描述格式。由于部門內部發(fā)布了用例的規(guī)范格式，因此當然要求產品經理進行遵守。但是針對這個特定的項目（用戶的角色非常單一），我們都發(fā)現，描述功能比描述場景可能更加合適。因此，在日后的改進工作中，有必要發(fā)布用戶故事的格式規(guī)范。
4.在瀏覽需求條目時，發(fā)現了不同的需求條目之間存在著依賴關系，即某需求的開發(fā)的開始和估算依賴于另外一條需求。我在本次會議中沒有處理這個情況。我覺得這其實是由于被依賴的需求條目還需要被拆分。但是，我準備在下一次迭代中再處理這種情況。
5.本次規(guī)劃中發(fā)現需求來源于兩個產品經理。這一次雖然協(xié)調的比較順利，但以后還是需要盡量避免。

雖然出現了一些問題，但是我還是對這兩次會議非常滿意了！關于部門經理非常強勢的問題，由于本次實驗部門經理也非常支持，因此我會在以后的私下聊天中，逐步改變部門經理的管理方式。

感謝以下一些圖書的作者：
《SCRUM敏捷項目管理》
《SCRUM敏捷項目管理實戰(zhàn)》
《硝煙中的SCRUM和XP》
《敏捷無敵》
《敏捷估計與規(guī)劃》