Scrum - 指导原则

栏目: 编程工具 · 发布时间: 5年前

内容简介：雖然這篇文章討論了Scrum中的一些常見指导原则，但重要的是要記住這些指南是靈活的，應根據您團隊的需求進行塑造。當我提到規則時，我指的是那些無法修補以適應特定背景的方面。例如，沒有產品負責人，開發團隊和Scrum Master，您就無法做Scrum。當我提到指南時，我指的是那些可能被改變以適應特定背景的方面; 但是，影響只能在實施後進行驗證。然後我們相應地檢查和調整。

雖然這篇文章討論了Scrum中的一些常見指导原则，但重要的是要記住這些指南是靈活的，應根據您團隊的需求進行塑造。

當我提到規則時，我指的是那些無法修補以適應特定背景的方面。例如，沒有產品負責人，開發團隊和Scrum Master，您就無法做Scrum。

當我提到指南時，我指的是那些可能被改變以適應特定背景的方面; 但是，影響只能在實施後進行驗證。然後我們相應地檢查和調整。

例如，Product Backlog細化消耗不超過團隊容量的10％。容量是小時數，故事點數還是天數？嗯，沒有規則。Scrum團隊自我組織並選擇最適合他們背景的東西; 遵循我們消耗的指導方針，不超過團隊容量的10％。

在這篇文章中，我將探討一些將11個要素綁定在一起的指南，並讓Scrum團隊靈活地將這些方面融入其背景中。

＃1。開發團隊規模

建議開發團隊的規模為3-9名成員。根據具體情況，可能會有更多人或更少。它的影響因團隊環境而異。不到三個開發團隊成員減少了交互，導致生產率降低。較小的開發團隊可能會在Sprint期間遇到技能限制，導致開發團隊無法提供可能可釋放的增量。擁有超過九名成員需要太多的協調。大型開發團隊為實證過程提供了太多的複雜性。

＃2。開發團隊的標題/角色

Scrum無法識別開發團隊中的任何標題/角色。在開發團隊中，每個人都是開發團隊成員。雖然在組織內，團隊成員可能擁有頭銜/角色。根據我的經驗，我沒有遇到任何只有一個頭銜/角色的團隊。

＃3。每日Scrum的三種問題格式

我使用過的大多數團隊都使用了每日Scrum的三個問題的格式：

昨天我做了什麼幫助開發團隊實現Sprint目標？
今天我將做些什麼來幫助開發團隊實現Sprint目標？
我是否看到任何妨礙我或開發團隊滿足Sprint目標的障礙？

這三個問題只是以Scrum開頭的團隊的模板。只要他們專注於Sprint目標的進展，開發團隊就可以按照他們認為合適的方式構建他們的Daily Scrum。

＃4。活動時間表

事件的時間框表示一個月Sprint事件允許的最長時間。指南是：對於較短的Sprint，時間限制通常較短。

這是否意味著，對於為期兩週的Sprint，Sprint Planning的時間限制為四小時，Sprint Review為兩小時，Sprint回顧為一個半小時？沒有。

只要滿足其目的，事件可以根據需要调整短/長，但它們不能超過最大分配時間。例如，Sprint計劃為期兩週的Sprint計劃活動如果達到目的可能會在兩小時內結束，如果不滿足，則可能會持續八個小時。

＃5。進展趨勢

Scrum指南建議使用燒毀圖表和累積流量等實踐來監控進度。但是，團隊可以完全自由選擇他們認為合適的任何練習。根據我的經驗，我見過團隊創建視覺路線圖，基於里程碑的進度，旅程線，釋放燃燒圖表等。我們還需要記住，在復雜的環境中，只有經驗數據才能幫助我們做出正確的決策。

＃6。估計

在 Scrum的指南介紹了需要積壓的產品項目來進行估計。如何估算它們完全取決於Scrum團隊。故事點，理想日，T卹尺碼，狗尺碼是一些方法。

Scrum團隊可以做“沒有估計”嗎？當然，只要Scrum團隊能夠起草支持經驗主義的計劃，創建透明度，並幫助團隊在Sprint結束時創建可能可釋放的“完成”增量。Scrum團隊自行組織選擇適合其背景的內容。

＃7。工作分解

在“選擇的工作將如何完成？”部分下。對於Sprint計劃，Scrum指南提到：

開發團隊在Sprint的頭幾天計劃的工作在本次會議結束時進行分解，通常分為一天或更短時間。

然而，這通常有助於發展團隊這樣做。根據我的經驗，我看到幾個團隊沒有將他們的工作項目細分到如此細緻的水平。他們了解如何將功能轉換為“完成”增量。

＃8。Sprint評論

這是一項重要的檢查和調整活動，Scrum團隊與主要利益相關方就Sprint期間取得的成果進行合作，以及在下一個Sprint中可以做些什麼來優化產品的價值。

Scrum指南還描述了Sprint Review中的元素：

與會者包括Scrum團隊和產品負責人邀請的主要利益相關者。
產品負責人解釋了產品待辦事項項目已“完成”且未完成的內容。
開發團隊討論Sprint期間的情況，遇到的問題以及這些問題是如何解決的。
開發團隊演示了它“完成”的工作，並回答了有關增量的問題。
產品負責人會討論產品Backlog。他或她根據迄今為止的進展（如果需要）預測可能的目標和交付日期。
整個小組就下一步做什麼進行合作，以便Sprint Review為後續的Sprint Planning提供有價值的信息。
回顧市場或產品的潛在用途如何改變下一步最有價值的事情。
審查下一個預期的產品功能或功能發布的時間表，預算，潛在功能和市場。

對於已經獲得資助一年的Scrum團隊來說，在每兩週一次的Sprint評審中審查其預算是否有意義？也許不吧。

並非所有上面提到的元素都適用於所有Scrum團隊。它們作為指導提供，以便Scrum團隊可以選擇在Sprint審核期間討論和触及產品交付的各個方面，因為他們認為適合他們的上下文。

＃9。發佈到生產

每個Sprint的目的是創建一個可能可釋放的“完成”增量。這意味著增量需要處於可用狀態並滿足Scrum團隊的完成定義（DoD）。

然而，將增量釋放到生產中的選擇由產品負責人決定。根據團隊的上下文及其創建的增量，Scrum團隊可能決定每個Sprint執行多個版本，每個Sprint發布一個版本，或者累積發布多個Sprint; 無論如何優化產品的價值。

＃10。完成的定義

“完成”的定義有助於提高透明度，並對完成工作的含義達成共識。根據Scrum指南，Scrum團隊有望擴大他們的國防部並使其更高質量的更嚴格。

同樣，這不是一個規則。取決於團隊的背景; Scrum團隊可能會在每次回顧中重新審視它的國防部，或者可能繼續使用相同的國防部，除非它學會了新的東西以提高產品的質量。

結論

這些只是Scrum指南中的一些指導原則。我想提出這種區別，因為我經常發現Scrum團隊與Scrum規則和指南混淆。幾乎沒有什麼是常見的 - 將Sprint計劃的時間安排為兩個星期的Sprint或開發團隊花費太多時間和精力將PBI分解為“任務” - 其他人並不常見。我相信這篇文章將幫助團隊確定Scrum的一些方面，他們可以修改這些方面以適應他們的背景。

Scrum参考

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。

码农书籍

数文明

涂子沛 / 中信出版集团 / 2018-9 / 88.00元

从量数、据数、普适记录、人脸识别、以图搜车，到雾计算、城市大脑、单粒度治理、无匿名社会、量子思维……作为中国研究大数据的权威专家，作者在《数文明》一书中，以大数据为核心元素，抽丝剥茧，深入地阐述了这个大数据时代的文明社会——一个全新的数文明时代。将大数据与人类文明融合在一起，这本书提供给我们的不仅是一种全新的叙事结构，它还将突破你的认知边界和思维极限，给你提供一个应对这个世界的全新的认知方......一起来看看《数文明》这本书的介绍吧!

码农工具

在线进制转换器

各进制数互转换器