兩次教科書一般的SCRUM會議

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

背景：我準備在公司推進敏捷專案管理方法。想辦法得到了軟體開發部部門經理的支援。於是乎在新立項的g維護專案中進行實驗。

上周五下午，是g維護專案的一次迭代匯報會議。

會議中，我幫助專案組成員回顧了已經完成的工作，同時分析了工作沒有按照計畫完成的原因。會議的效果如下：

下一次迭代的估算時，每個成員每週流出1天的工作量來應付突發的事件。

討論出了若干實際的方法來解決專案中出現的溝通的問題。

本周二上午，是g維護專案的迭代規劃會議。會議中：

先約定了以後會議的一些常態規範和約定

計算了本次迭代專案組所有可用工作量的小時數

請產品經理按照優先順序的順序給大家講解需求

產品經理由於沒有按照部門規定的用例格式書寫需求條目，被部門經理嚴重批評

過程中，我盡量的引導了所有專案組成員對需求條目進行討論和澄清

針對每一條需求，專案組成員進行了delphi的估算方式

估算以小時數為單位，而不是功能點

針對每一條的估算分割成了開發和測試兩部分

由於有另外乙個產品經理的需求還需要占用專案組的時間，因此要求兩個產品經理對需求條目進行合併，並對優先順序進行了協調。

專案組成員對本迭代的需求進行了認領

開發經理也會承擔一部分開發任務。按照原來的計畫方式，開發經理會承擔很多難度較大的需求條目。工作量過載會導致開發經理成為瓶頸。採用這樣的計算方式，避免了出現上述的問題。其他的開發人員幫助開發經理分擔了工作。

測試人員只有一名，但是測試的工作量已經溢位，因此要求開發人員分擔了一些測試執行的工作。

最終達到了工作量的大致平衡分布。

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

對於某一條需求，分割粒度不夠。有兩個開發人員估算了40小時，開發經理估算了20小時。按照一般的約定，應該由產品經理再次分割指16小時之內。但是強勢的部門經理堅持認為該需求不能在分割了。基於當時的環境，我沒有堅持。

還是針對該條需求，開發人員的估算存在明顯的分歧（包括部門經理在內），出現了短暫的緊張氣氛。由於我意識到該條需求具有明顯的潛在認領者（開發經理），因此我也沒有堅持針對他的估算必須達成一致。

針對於需求的描述格式。由於部門內部發布了用例的規範格式，因此當然要求產品經理進行遵守。但是針對這個特定的專案（使用者的角色非常單一），我們都發現，描述功能比描述場景可能更加合適。因此，在日後的改進工作中，有必要發布使用者故事的格式規範。

在瀏覽需求條目時，發現了不同的需求條目之間存在著依賴關係，即某需求的開發的開始和估算依賴於另外一條需求。我在本次會議中沒有處理這個情況。我覺得這其實是由於被依賴的需求條目還需要被拆分。但是，我準備在下一次迭代中再處理這種情況。

本次規劃中發現需求**於兩個產品經理。這一次雖然協調的比較順利，但以後還是需要盡量避免。