Scrum(3) | 敏捷流程項目評審會

項目組向產品負責人展示迭代工作結果，成為評審會。在評審會，產品負責人給出評價和反饋。

1. 評審會

• 小組向產品負責人展示迭代工作結果。
• 產品負責人給出評價和反饋。
• 以用戶故事是否能成功交付來評價任務完成情況。

評審會開展

• 評審標準：整個用戶故事是否已經達到交付標準。

  評審的標準是整個故事是否已經達到交付標準，而不是從其中分解出來的任務完成了多少，因此若一個故事“差一點就完成了”也算沒有完成。

• 評審標準在迭代計劃會上設定。

  一般在迭代計劃會上設定每個故事的完成標準，如是否需要測試，是否需要考慮性能，是否需要說明文檔等等。這些標準一般由項目組提前列好，每個故事只需要選中是否需要即可。

• 單個用戶故事評審

  盡管有正式的評審會，但很多團隊習慣在單個故事完成時，就讓產品負責人進行單個故事評審，以確保交付時不會有“驚喜”。

• 發現的問題被累積到產品待開發項

  評審會上發現的問題或改進將被累積到產品待開發項，也不會馬上或在下一個迭代中開發，而是由優先級排序決定何時開發。

這個活動的關鍵是 檢視與調整 sprint過程中產出的產品增量。

1. 第一步是回顧sprint目標和承諾的特性集，并和實際完成的情況進行對比。
2. 第二步是演示和討論完成的特性，并對產品backlog或者發布計劃做出必要的調整，以反應討論中新的認知，然后重復這個步驟。這個循環直到討論完所有完成的特性之后才結束。

在這個方法中，演示只是sprint評審會議中的一個活動，它不是sprint評審的目的。

sprint評審會議的目標是 檢視與調整 構建的產品。成功的評審結果是雙向的信息流動。不屬于Scrum團隊的人也可以得知開發的成果并幫忙指出方向。

同時，Scrum團隊成員通過頻繁的反饋而加深了對產品的業務和市場認識。所以，sprint評審會議是一個 檢視和調整 產品的預定機會。

2. 評審會問題和改進

1. 問題反饋
2. 改進積累到Product Backlog

3. 評審會示例

1. 計劃會認領的需求（任務）：講解和最初估計時間。
2. 展示一頁紙測試計劃，簡單描述測試方案
   • 關于Tower 日歷的測試場景：
     1. 日歷表中，高亮今天的日期
     2. 創建多個日歷簿，每個日歷簿上創建日程
     3. 在項目日歷簿，創建日程
     4. 在項目中添加任務，到當前日歷中查看
     5. 日歷中的任務，點擊跳轉
     6. 在項目中創建日常，到日歷中查看
     7. 日歷的重復功能
     8. 日歷的提醒功能
     9. iCalendar訂閱
3. 打開禪道，找到指定的迭代和需求。展示需求的測試任務。
4. 在測試模塊，找到用例，簡單講解用例
5. 在Tower中演示測試過程
6. 如果有測出缺陷，描述缺陷。

4. 評審會總結：

• 經驗的積累：分析需求需要更加細致，不可以放過頁面上的任何一個元素

• 測試要注意關聯：模塊之間的關聯容易尋找，但是模塊內部的關聯也是很重要的

• 用例的編寫：需要留意用例的標題，標題不可以有是否這樣的尋求答案的字眼出現，而是應該以預期結果為導向的出現。

  • 例如
    1. 注冊用戶時，輸入過長的團隊名稱，可以注冊成功。（錯誤用例）
    2. 注冊用戶時，輸入過長的團隊名稱，是否可以注冊成功。（錯誤用例）
    3. 注冊用戶時，輸入過長的團隊名稱，不可以注冊成功，提示用戶名稱過長。（正確用例）

• Bug提交：Bug的描述，Bug的重現步驟，截圖等需要認真描述。另外在禪道中學會使用用例的轉Bug功能。

  Snap1.jpg
  
  
  Snap2.jpg
  • 上述用例的執行失敗，會產生Bug。那么bug的標題：注冊用戶時，輸入過長的團隊名稱，用戶可以注冊成功，團隊創建失敗。

• 禪道中，有兩個地方的版本菜單。項目（迭代）中的版本，由開發創建，創建后，關聯該版本的以下內容：

  Snap4.jpg
  • 完成的需求
  • 解決的Bug
  • 遺留的Bug

  然后提測。

  測試中的版本，由測試操作，關聯用例，并執行用例。具體步驟如下

  • 開始測試

    Snap5.jpg
    Snap6.jpg

  • 關聯用例

    Snap3.jpg

  • 執行用例

  • 關閉測試