開發管理 CheckLists(17) -靈活開發 SCRUM評估會議

注： 開發管理 CheckLists-系列文章是從本人   Iteye部落格中移植過來.後續會直接在此更新     開發管理 CheckLists   專欄

本文主要是為了檢測你對SCRUM 評估會議的了解和使用程度,

通過本文你可以檢測一下 

    1、你們的SCRUM 評估會議的過程和步驟

    2、SCRUM 評估的輸出結果

一、會議目的 

     1.  确定 Backlog 中各項的大小.

     2.  确定團隊在一個Sprint中能夠完成多少工作。 

     3.  團隊成員可以從會議中知道項目接下來的階段會發生哪些事情。 

     4.  修整Backlog内容：以合理方式分解Backlog各個項目，進而獲得更深入的了解  

     基本要求： 

         隻有團隊才能作估算。Product Owner（産品負責人）需要在場，以幫助判定某些使用者故事能否拆分為更小的故事。

二、會議時間 

       1. 該會議時間限制為不超過 90分鐘。 

       2. 如果 Sprint 持續時間長于一周，那麼每個 Sprint 舉行兩次估算會議比較合适  

三、會議準備 

       1. 邀請與會者：

             産品負責人

             Scrum Master

             團隊所有成員  

       2. 已按優先級排列好産品 Backlog 中的各項問題 

       3. 把産品 Backlog 公開給所有人，保證其可被擷取 

       4. 在用作計劃紙牌的一組卡片上寫上标簽 1，2，3，5，8，13，21，34，89，并發到每個團隊成員的手上  

四、會議程序 

    介紹會議的目标

       1. Product Owner展示她希望得到估算的 Product Backlog條目。 

       2. 團隊使用規劃撲克來估算Backlog條目。  

       3. 如果完全還沒開始着手對 Backlog 中的問題進行評估：

           (1)、選擇 Backlog 中您認為是最小用例的問題，并指派其工作量為 2 個 Story Point對于産品 Backlog 中的各項問題：

           (2)、由産品負責人來解釋 Backlog 中該問題背後的詳細用例。

           (3)、團隊各成員選出其手上的一張計劃卡片，以投票決定他所認為的該問題的工作量大小。

           (4)、所有團隊成員同時亮出他們的卡片如果評估結果有分歧，讓意見分歧最大的成員進行辯論，然後再次投票，直到所有人意見一緻

           (5)、評估結果被添加到 Backlog 項  

       4. 如果某個 Backlog條目過大，需要放到下一個或是後續的 Sprint中，團隊就會将該大 Backlog 條目劃分為較小的幾個 Backlog 條目，并對新的 Backlog條目使用規劃撲克進行估算。 

       5. 重新估算 Backlog中目前沒有完成、但是可能會在接下來三個Sprint中要完成的條目。

       6. 通過簡潔的總結來結束評估會議

           (1)、如果有需要的話，再安排時間另開一個評估會議

       7.  區分出下一次估算會議需要澄清的Backlog條目。 

五、會議結果 

      1. 經過估算的Product Backlog。 

      2. 更小的Backlog條目。 

      3. 需要澄清的問題。   

      4. 公司的所有人員都要獲得這個已經評估的backlog

        <開發管理 CheckLists> by dyllove98 @開發管理 CheckLists 

<script type="text/javascript"> </script><script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>