Scrum儀式：Sprint演示

> Scrum Sprint演示：綜合指南

關鍵要點： Sprint Demo展示完成的Sprint工作，允許產品所有者根據接受標准進行驗證。 它闡明了完成的工作，改進估計並告知團隊的速度。重點是可證明的價值，而不是技術細節或問題（這些細節屬於回顧）。 然後，根據可持續時間表將公認的功能集成（釋放）。

>

（本節基於的新手：戴維·格林（M. David Green）。 在Sprint的結論上舉行的Sprint演示是至關重要的儀式。開發團隊展示了完成的工作，而產品主則根據接受標準，接受或拒絕每個故事評估完成。 這提供了衝刺進展並完善未來估計的清晰圖片。

Sprint演示目標：

>主要目標是了解Sprint的輸出和產品的更新狀態後整合。 公認的故事決定了團隊的速度，改善了未來的衝刺積壓估計。 Sprint演示的客人：

>歡迎客人觀察員，但他們的存在不應破壞演示的目標或時機。 他們是觀察者，而不是參與者，除非有積極徵求反饋。

>

定時箱Sprint演示：

時間分配取決於完整故事的數量和復雜性。 為期兩週的衝刺很常見半天。 Scrum Master確保遵守分配的時間。

結合演示和回顧性：

>通常，團隊在同一天安排回顧性，以最大程度地減少生產力中斷。 但是，這優先考慮Scrum偽像，而不是有形產品開發 - 需要仔細考慮。

準備Sprint演示：

演示展示了所有“完成”故事，無論發行狀態如何。 每個貢獻的團隊成員都應準備解釋他們的工作。 與產品所有者進行的事前會議確保與接受標准保持一致，並為示威做準備。 Scrum Master協調準備並確保演示適合時間表中的演示。

>

>產品所有者驅動的演示：

雖然工程師可以呈現，但讓產品所有者進行實時測試是有益的。 工程師知道“快樂的道路”，但是產品主確定了邊緣案例並確定了接受標準，確保了全面的測試和利益相關者的參與。

演示一個故事：

Scrum Master指導過程，系統地檢查每個故事。 在設置演示時，產品所有者會閱讀故事和接受標準，以確保每個人都了解期望。 該演示重點介紹了產品的功能添加，展示了每個接受標準的實現。 演示期間確定的接受標準不足會導致未來衝刺的新故事。

避免對問題進行詳細討論：

雖然有價值，詳細的關於發展挑戰的討論應推遲到回顧展。 專注於產品可以防止演示在技術細節上陷入困境。

> talling點和速度：

Scrum Master根據分配給公認故事的點來計算Sprint的速度。 跟踪拒絕或不完整的故事並更新其狀態。 總結Sprint進度的報告經常會產生。

>

釋放故事：

>釋放將完整的功能集成到實時產品中。 釋放方法各不相同；一些團隊立即發布，而另一些團隊則將大型版本的故事分組。 連續集成支持立即發布，消除了demo後發布步驟。

連續集成：

>連續整合，工程師在發布並進行了測試之前不應放棄故事。 這可能需要專門維護和改進的時間。

>

>發布調度：

發佈時間表應與團隊的可持續步伐和產品所有者的目標，而不是任意截止日期保持一致。 避免急於以犧牲質量為代價的截止日期； 如有必要，請確定關鍵功能。

常見問題（常見問題解答）

（為簡潔而省略了FAQ部分，因為它在很大程度上重複了主要文本中已經涵蓋的信息。）

以上是Scrum儀式：Sprint演示的詳細內容。更多資訊請關注PHP中文網其他相關文章！