9. 我們怎樣進行Sprint的展示
Sprint展示(有些叫它Sprint review)是Scrum中重要的一部份，但是人們都低估它。
"哦！ 我們真的需要去展示嗎？ 沒有啥好東西可以展示"
"我們沒有時間去準備&%$#的展示" "我沒有時間去參加其他團隊的展示！"
我無法了解為什麼我會叫它 “sprint 展示”！
我倒底在想什麼？官方名字是叫做”sprint 檢視會議”，這是比較好的名字。展示意味著單向溝通（”來這裡一下，這是我們所建造出來的”）。而檢視則意味這雙向溝通（”這是我們所建造出來的，你認為如何？”）。Sprint 檢視是有關於回饋的事情！所以當你下面看到”展示”時，把它想成”檢視” ，好嗎？
為什麼我們堅持所有的Sprint在結束前都要展示
一次做得不錯的展示，即使可能看起來很一般，也會帶來深遠的影響。
• 團隊因所完成的結果而得到認可，他們會感覺很棒。
• 其他人可以知道你們團隊現在正在做什麼。
• 這個展示可以吸引關係利害人給予重要的回饋。
• 展示是(或應該是)一個社交的活動，不同團隊可以相互交流，和討論各自的工作。這是有價值的。
• 有展示會促使團隊真正完成一些東西，並發行它(即使是在測試環境中)。沒有展示，我們總是會得到一個99%完成的東西。有了展示，或許我們完成的東西變少，但是這些東西是真正的完成。這(以我們的例子來說)會比得到一堆看似完成的東西好的多，而且他們將會影響到下一個Sprint的進行。
如果團隊是有點被半強迫去進行展示，尤其他們沒有太多東西是真正的完成，這樣的展示將會令人感到很尷尬。團隊在展示過程中，可能會結結巴巴的，之後的掌聲也可能是稀稀落落的。人們會對這團隊感到有點難過，也有人感到不太高興，因為他們浪費時間在一場很爛的展示上面。
這會傷害到一些人，但是就像良藥苦口一樣。下一次的Sprint，團隊會真的試圖去完成一些事情。他們會感覺 "好的，也許下個Sprint我們只能展示2件事情，而不是5件。但是這些該死的功能一定會正常運作！" 團隊知道，無論如何他們必須展示。讓一些真正有用的東西被展示的機會，會變得大的很多。這種情況我已經看過很多次了。
對於多個團隊的環境下，這是額外十分重要的。每隔固定一段時間，被邀請的每個人都需要看產品如何被整合在一起。總是會有些整合上的問題，但是你越早發現它們，就越容易被解決。自組織的團隊總是利用透明度和回饋迴圈在運行，而一個運作良好的 sprint 檢視會議，則提供了以上兩個機制在裡面。
Sprint展示的檢查清單
• 確保你已清楚地描述Sprint的目標。在展示中，如果有人對你的產品一無所知，花幾分鐘簡介一下產品。
• 不要花太多時間去準備展示，特別不要去做些花俏的展示。把那些玩意放到一邊，只要集中精神在真正可運作的程式碼上面。
• 保持快速的結奏，也就是集中精神，讓簡報能保持快結奏，而不是好看。
• 讓展示是保持在商業導向的層次，不要有太多技術性的細節。著重於"我們做了什麼"，而不是"我們如何做到它"。
• 如果可能，讓觀眾自己試用一下產品。
• 不要展示一堆小的錯誤修復，或是微不足道的功能。可以提到他們，但不用展示他們，因為通常會花很多時間，並且讓大家不能專注於更重要的故事中。
有些團隊進行兩種檢視：短暫的公開檢視，目標瞄準外在的利害關係人。之後再接著內部的檢視，來看更多細節，像是關鍵的挑戰和技術決策等等。這是很好的做法，可以讓知識在團隊間散播，又避免利害關係人聽到他們不在乎的技術細節。
處理"無法展示"的項目
團隊成員： "我不打算去展示這個項目，因為它無法被展示出來。這個故事是'改進延展性，因此系統可以處理10,000同時上線的使用者' 我拼了老命也無法讓10,000使用者同時上線來展示，不是嗎？"
Scrum master： "那你已經做完了嗎？"
團隊成員： "是的，當然"。
Scrum master： "那你怎麼知道？"
團隊成員： "我在效能測試環境中架設好系統，啟動8個負載伺服器，對系統同時發出請求 "。
Scrum master： "但是你有任何指標能顯示出系統可以處理10,000使用者？"。
團隊成員： "嗯，這個測試機器挺爛的，但是在我的測試過程中，它還是可以處理到50,000使用者同時上線"。
Scrum master： "你怎麼知道？"
團隊成員(快失去耐性)： "好的，我有份報告，你可以自己看啊，上面有如何設定這個測試，以及多少請求被發出！"
Scrum master： "嗯，太棒了，這就是你的"展示"啊。只要給大家看這份報告就可以了，這比什麼都沒有強，對嗎？"。
團隊成員： "哦，這樣就夠了嗎？ 但是這報告有點難看，需要去美化一下"。
Scrum master： OK，"好的，但不要花太多時間。不需要很好看，只要能表達訊息就可以"
全站熱搜
留言列表
