Scrum - 指導原則

時間 2019-12-05

標籤 scrum 指導原則简体版

原文原文鏈接

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

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

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

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

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

＃1。開發團隊規模

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

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

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

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

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

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

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

＃4。活動時間表

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

這是否意味着，對於爲期兩週的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參考

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。