衝刺計劃
作者 Mitch Lacey。 擁有者 Mitch Lacey & Associates, Inc，是一家致力於 agile 和 scrum 採用及改進的諮詢公司。
2012 年 1 月。
衝刺 (Sprint) 計劃不需要是富有挑戰性的。 對於整個 Scrum 團隊來說，彼此緊密合作，回答「我們能承諾什麼？」這樣的問題，往往是非常有趣的事情。現在也是時候這樣做了，在此過程中，團隊成員之間會建立其感情。在本文中，作者提供可讓衝刺 (Sprint) 計劃專注於目標和產生實際效果的範例和策略，並詳細說明小組規劃衝刺 (Sprint) 時會遇到的常見問題及其可能的解決方法。
套用至
Application Lifecycle Management；Team Foundation Server
本文內容：
簡介
預測與承諾
什麼是衝刺計劃？
我們如何完成它？
常見問題
情境：團隊無法承諾產品擁有者所要求的所有劇本。
情境：產品擁有者尚未準備好。
情境：第 1 部分超出其時間方塊。
情境：第 2 部分超出其時間方塊。
情境：產品擁有者無法出席。
情境：團隊沒有其需要的接受準則。
情境：產品擁有者不知道完成是什麼意思。
情境：ScrumMaster 或產品擁有者評估/影響團隊的評估/工作。
我們不計劃。 我們執行 Scrum，因此我們只是執行。
我一直聽到這樣一種聲音。 人們認為 Scrum 和 Agile 意味著無計劃、無評估、無會議、無任何事情！ 這不是事實。 我們在 Agile 專案的各個層級進行計劃：每日計劃或每日晨會、每週計劃 (衝刺或反覆項目、待處理項目)、發行計劃 (產品待處理項目) 及可能的其他作業。
讓我們重點討論計劃衝刺。
預測與承諾
在 2011 年的夏天，Ken Schwaber 和 Jeff Sutherland 修訂了他們的《Scrum 指南》。 在該指南中，他們移除了 Scrum 眾所皆知的一個建立已久的行為，即團隊對產品擁有者和客戶所做出的承諾。 承諾由「預測」取代。 他們說團隊可能會預測其工作，但不會對其進行承諾。
當我了解他們的邏輯時，我更傾向於使用承諾，原因如下：
承諾某事讓團隊處在不同的思維方式之中，而不僅僅是預測。 如果團隊預測，則隱含的意思是沒有達成他們所說他們能做到的事情是可接受的行為。 雖然團隊可能會從其預測中學到很多，但是最終幾乎沒有什麼評估差異。我發現執行「預測」的團隊與執行「承諾」的團隊相比，要花費較長的時間來減少差異。
預測或評估適用於產品待處理項目。 不過，當團隊將劇本從產品待處理項目移至衝刺待處理項目，並對它們進行細分時，他們即加入另一個細微層級，了解可讓他們自問「我們能承諾這點嗎？」的少量詳細資訊。預測存在失敗後由團隊回到延遲狀態的風險，而不是說說「我們只需要預測，如果我們遺漏部分事項，我們可以稍後找出所有事項。」就好。
輕鬆點說，設想一下，您對您的妻子、丈夫、合作夥伴說「我預測我們將在一起十年」和「我將我自己承諾給你」- 是的，後者將妙不可言。
最後，Scrum 是與常識有關的。 我建議您將承諾方法和預測方法都試一下。 所有的一切都是有關學習，而不是您所使用的文字，因此請明智地體驗這兩種方法，並使用最適合您、您的團隊和您的公司的方法。
什麼是衝刺計劃？
我們會召開衝刺計劃會議，以計劃在即將進行的衝刺中，團隊要建置「什麼」，以及團隊「如何」進行建置。 雖然我們將其稱為衝刺計劃「會議」，但它實際上由兩個非常不同的部分組成。 第 1 部分重點討論要求團隊建置什麼，由產品擁有者和團隊參加。 第 2 部分重點討論團隊計劃如何建置所需的功能。 雖然整個團隊都必須參加第 2 部分，但產品擁有者可以選擇不參加。 如果基於任何原因，產品擁有者不參加第 2 部分，則產品擁有者應該仍可回答問題。
在衝刺計劃會議的第 1 部分，產品擁有者有機會向團隊描述所需的劇本集。 這是劇本的「什麼」部分的深入會議。 產品擁有者呈現劇本、展示事情如何互動，並逐步解說介面。 此外，他們可能會檢閱基礎結構或架構項目。 目標是將團隊成員聚集在一起，讓他們了解足夠的資訊，以便可以開始弄清楚如何建置功能。 團隊將會詢問各種各樣的問題，以收集「如何」進行會議的資訊，問題像是：
「所有這些劇本的接受準則是什麼？」
「您認為我們在使用哪些資料來源？」
「在此元件上，介面應該看起來如何？」
在衝刺計劃會議的第 2 部分期間，團隊會將其注意力轉向建置衝刺待處理項目，即在衝刺期間需要完成的劇本和工作清單。 為了建置待處理項目，團隊會將產品擁有者所要求的每一個劇本細分為工作層級；對每一個工作進行一小時的評估。 到第 2 部分結束為止，團隊會決定哪些劇本他們可以承諾在衝刺期間完成。
衝刺計劃會議的這兩個部分加在一起，短則兩小時，長達八小時。 我所使用的一般經驗規則是每一個部分應該占每一週衝刺長度的一個小時。 這表示如果我執行一週的衝刺，則會議應該總共花費兩個小時 (一個小時用於第 1 部分，一個小時用於第 2 部分)。 另一方面，如果我執行四週的衝刺，則會議應該總共花費八個小時 (四個小時用於第 1 部分，四個小時用於第 2 部分)。
我們如何完成它？
只要團隊離開承諾完成劇本清單的衝刺計劃會議，該團隊即完成衝刺計劃的目標。 讓團隊在每一個團隊成員都處於感到自在做出承諾的位置，但這需要進行一些預先計劃和促進。
產品擁有者在衝刺計劃期間有一項工作：參加能夠描述所需劇本集的會議。 團隊的目標是從產品擁有者的視角了解劇本，以分享產品擁有者的遠見。 ScrumMaster 應該確保團隊詢問足夠的問題，並擷取所有產生的資料，包括接受準則、梗概和任何假設。 ScrumMaster 還應該讓產品擁有者明白在團隊將問題細分為工作時，可能還會有其他問題。 雖然產品擁有者會呈現總分大略對應於團隊歷史速度的劇本，但團隊最終會基於在衝刺計劃會議第 1 部分和第 2 部分所了解到的內容，決定他們實際上是否可以接受給定衝刺中的所有劇本。
在團隊從產品擁有者那裡取得所有資訊之後，他們必須將劇本細分為工作，並建立衝刺待處理項目，這會擷取特定衝刺的所有劇本、附註、接受準則、工作和評估。 雖然有很多種方法可以完成此作業，但我更喜歡下面的方法，即利用所有團隊成員的想法，並在進行工作分解時，向每一個人進行說明。
ScrumMaster 或會議促進者讀完劇本並詢問「每一個人都了解此點了嗎」？團隊應該花費時間與產品擁有者就此問題進行討論。 如果團隊中的某個人不了解，請花費一些時間回來討論此劇本，詢問產品擁有者任何必要問題。
接下來，讓每一個團隊成員手拿一張便利貼。 要求每一個團隊成員在每一張便利貼上寫下單一工作，並將其投到桌子中間。
- 當每一張便利貼都扔進桌子中間時，投擲者宣讀工作。 因此如果寫的是「更新預存程序」，則這句話會被大聲地讀出來。 這一點非常重要，因為這會激發思想的火花，導致其他人說出「對了！對了！我們需要更新資料來源。」這時，某個人會在便利貼上寫出「更新資料來源」，讀出來，然後將其投到桌子中間。 這種腦力激盪活動確實有用，會想出所有相關聯的工作。 此時不要擔心重複作業。 通常每一個劇本會花費大約五到十分鐘以扔出所有工作便列貼。
當所有便利貼都在桌子上時，就要對它們進行排序。 將它們粘到墻上，後退幾步，看！這麼多便利貼！ 從找出重複項目開始；將看上去重複的任何便利貼疊在一起。 然後，尋找看上去可以一起執行的工作，原因是它們很相似或者它們彼此相依。 例如，如果兩個便利貼具有相似關係，請將它們放在一起，並排放置，如下圖所示：
.png "類似的自黏便箋 - 位移")
如果兩個工作關係如此接近，以至於幾乎相同，請將它們幾乎完全疊放在一起，如下所示：
.png "類似的自黏便箋 - 重疊")
透過對便利貼進行排序，團隊可以選出工作清單，並將那些留下來工作之間的關係視覺化。
對工作排序完之後，就要進行評估。 我使用 Planning Poker 技術進行工作評估，但有一點不同：卡片上的數字代表小時而不是點數。 我這樣做是因為人們傾向就小時數，過於擔心不必要的細節，尤其是對大型工作更是如此。 他們的擔心是有原因的。 公司總是拿評估做為武器，來打擊團隊。 「你說會花費 8 小時，但卻花費了 12 小時。 是有什麼問題嗎？」或者「你說會花費 8 小時，但卻只花費了 4 小時。 你的評估過量了。」
同樣地，卡片有助於讓劇本點數評估保持抽象，使用卡片進行工作評估，可讓團隊擁有一定的自由，給他們一組可從中選擇的固定數字，同時強制他們最終做出選擇。 這也可避免工作應該評估為 6 小時，還是 6.5 小時或是 7 小時這樣的熱烈討論。
無論最終的評估是多少小時，請記住這個評估是由團隊完成的，它旨在供團隊用於增加其信心，並基於速度判定是否能夠完成產品擁有者所要求的工作。 工作評估並不是測量，不應該如此使用。 「永遠不要」將評估當作對付團隊的武器。
現在已評估完工作，團隊必須判定其是否有能力承接更多工作。 若要這樣做，您需要了解團隊的產能，即衝刺期間團隊可以使用的總時數。 如果您有完全專用的團隊，則判定產能很容易，但是如果您的團隊由跨多個專案分割的兼職人員組成，則會變得困難。 要求每一個人寫下他們每天 (或每一個衝刺總共) 可以處理專案的時數。 將所有時數加在一起，以取得團隊可用的總時數。 假設團隊產品為 200 小時。 如果劇本的工作總和被評估為耗用 30 小時，詢問團隊「我們還能再多承接一些工作嗎？」在這早期階段，回答當然會是「能」。
因為您有更多的產能可以利用，所以移至下一個劇本，重複步驟一到五。
(如需如何使用 Team Foundation Server 完成此工作的詳細資訊，請參閱 共同作業 [重新導向])。
有時候，您可能很難回答這個問題「我們還能再多承接一些工作嗎？」這是因為您已接近團隊的產能。 當您完成此程序時，請考量您不想將衝刺填滿產能。 如果您將杯子用水填滿至邊緣，它很可能會灑出來。 這對於衝刺是一樣的。 如果評估的時數耗用了所有的可用時間，而稍後在衝刺中識別出新工作，則事情會「溢出」。 您必須為緊急工作留出空間。
當考量衝刺承諾時，它有助於考量來自過去衝刺的追溯性資料。 團隊一直必須帶來更多工作嗎？ 也許在衝刺計劃期間，團隊可以承諾更多工作。 團隊一直無法完成衝刺的所有工作嗎？ 團隊可能需要更保守的做出承諾，直到其解決無法完成衝刺的根本原因。
將數字放在「要將杯子填得多滿」這個問題上的一種方法是考量計劃大小增長。 計劃大小增長會測量與初始評估相比，實際時數是如何花費的。 例如，假設我們的團隊具有 200 個可用小時的產能。 基於評估，團隊承諾可以使用 190 小時。 在衝刺結束時，團隊計算那些劇本實際包含 240 小時的工作，這導致計劃大小增長 20%。
發現此不一致情形的團隊應該在追溯期間，花費一些時間來調查原因：
在執行期間是否發現太多的工作，而在計劃期間卻沒有識別出來？
團隊是否基於其目前技能集，低估了其工作。
團隊是否高估了其產能？
等等。
團隊還應該在判定其是否可以對劇本做出承諾時，在下一次衝刺計劃會議期間，考量其計劃大小增長。 回到我們的範例，如果團隊仍評估產品為 200 小時，則團隊應該基於記錄資料，從最高減少 20%，以補償「預期」計劃大小增長。 換句話說，至少對於此衝刺，為防止溢出，當團隊到達 160 小時時，應該宣告已達到產能。
考量計劃大小增長是量化衝刺應該多滿的一種方法。 不過，請意識到目標不是完全符合產能。 而是讓團隊可以充滿信心地承諾適當數目的劇本，該數字是團隊的動力，而不是負擔。 計劃大小增長只是大概判定下一個衝刺應該多滿 (如果所有其他因素仍相同)。
當所有劇本已評估，或者劇本已耗用所有時間，請回到產品擁有者身邊，分享團隊已承諾交付的衝刺待處理項目。 衝刺會立即啟動，開始工作吧！
常見問題
在我做團隊顧問協助他們採用 Scrum 的那些年，我看到了許多阻礙衝刺計劃成功的相同問題。 雖然衝刺計劃看起來直接明瞭，但剛開始使用 Scrum 的團隊卻是非常辛苦。 本節詳細說明了這些當中的許多問題，及其潛在解決方案。
情境：團隊無法承諾產品擁有者所要求的所有劇本。
您應該預期這是偶然發生的。 只要團隊可以使用本主題稍前步驟四和五中的資料，對承諾做出備份，則產品擁有者應該會滿意。 您要留意以確保要承諾的這個失敗不是過度填充或大型工作的結果。 ScrumMaster 應該質疑哪些看起來是過度保守的評估，以確保它們評估精確。 產品擁有者應該對具有兩位數評估的任何工作提出問題。 評估需要花費長於兩個工作日的任何工作，都應該細分為較小的工作，然後重新進行評估。 所有專案都應該這樣做，但這對於執行一週或兩週衝刺的團隊而言，尤其麻煩。
情境：產品擁有者未準備好。
Scrum 的基本價值是尊重。 未準備就參加會議是失禮的。 因此，如果產品擁有者沒帶來團隊所需要的任何資訊就來參加會議的話，團隊要怎麼辦？ 雖然有一個選擇可以推遲會議，直到產品擁有者準備好，但這樣做只會鼓勵相同的行為，要避免這樣！ 另一個選擇是取消衝刺。 雖然這可能有用，但太過極端。
我找到一個最佳解決方案，包括兩個方面。 首先，產品待處理項目「應該」處於某種優先權順序，這樣一來，如果產品擁有者沒有特定的一組劇本，則團隊和產品擁有者可以按照優先權順序討論劇本，直到他們達到相信這就是他們的產能或超出產能的點。 隨後，團隊可以像往常一樣，在會議的第 2 部分決定確切的承諾。
在會議之後，ScrumMaster 應該去了解產品擁有者未準備好的原因。 如果問題是態度不積極，則 ScrumMaster 可以教育產品擁有者，讓其了解準備好一組劇本來參加會議的重要性。 另一方面，如果問題是產品擁有者「無法」準備，可能是因為團隊無法協助清理，則 ScrumMaster 同樣應該協助解決這些問題。
情境：第 1 部分超出其時間方塊。
另一個基本價值是專注。 如果會議的第 1 部分反覆執行，則根源在於缺乏專注。 有時，產品擁有者因缺乏準備、未設定優先權或嘗試解釋太多劇本而漫無目的。 其他時候，缺乏專注可能來自因為「怎麼做」的細節脫離「需要什麼」對話的團隊。
ScrumMaster 應該協助讓事情順利進行，方法是堅持讓產品擁有者將無法完全解釋的劇本擺在桌面上，並讓團隊從第 1 部分得出詳細的實作討論。 一個簡單的修正漫無目的討論的方法是使用秒表或計時器。
情境：第 2 部分超出其時間方塊。
同樣，專注。 如果您的團隊說得太多，有時所需要的就是用紀律約束討論，讓會議重新回到主題。 帶一個煮蛋計時器，讓對話在作業評估之間保持一兩分鐘。 目標是準確性，而不是 100% 精確。
其他時候，在第 2 部分期間缺乏專注的根源是在衝刺執行期間缺乏產品待處理項目清理。 清理是當團隊可以查看未來劇本，並可與產品擁有者一起工作，加入劇本或增量，以確定設計方法或解決架構問題的時候。 如果沒有定期的產品待處理項目清理，衝刺待處理項目計劃會變得龐大且令人痛苦。
情境：產品擁有者無法出席。
如果產品擁有者基於任何原因而無法參加會議，且未指定代理，就像產品擁有者未準備就來參加會議一樣。 逐條瀏覽頂端項目，並盡最大努力對它們做出承諾。 您可能會想要變更會議的時間，以配合產品擁有者的時間表。 不要這樣做。 改變會議時間配合一個人的需要代價是浪費許多人的時間。 不值得這樣做。
情境：團隊沒有其需要的接受準則。
我總是建議團隊在第 1 部分詢問產品擁有者「這個的接受準則是什麼？」或者「我們需要如何做以讓您接受該工作？」如果在第 2 部分遺漏這點，則在團隊判定工作時，團隊不知道如何關閉劇本。 如果團隊根據在第 1 部分聽到的內容來進行猜測，則團隊就會存在風險，在衝刺結束時，產品擁有者認為該劇本沒有完成。 從每一個劇本一開始，就詢問接受準則。 ScrumMasters - 指導您的產品擁有者提供此資料。
情境：產品擁有者不知道完成是什麼意思。
就像團隊需要接受準則一樣，產品擁有者應該得到團隊所謂「劇本已完成」的最新描述。此完成清單應該張貼在顯著位置，且是最新的，可供產品使用者隨時使用。 過期的完成清單會讓計劃變得困難，因為在如何才算完成方面沒有共識。 請確保更新完成清單是每一次衝刺檢閱或追溯的一部分。
情境：ScrumMaster 或產品擁有者評估/影響團隊的評估/工作。
在會議的第 2 部分歡迎產品擁有者參與，但產品擁有者在第 2 部分的角色應該限制為澄清需求或解決特定問題。 產品擁有者永遠都不應該干擾團隊就如何實作劇本而做的討論，在工作評估上也不要說一句話。 產品擁有者需要信任團隊執行該工作。
如果產品擁有者跳出了這些方針之外，則 ScrumMaster 應該指導產品擁有者成為更適合的角色。 如果產品擁有者拒絕接受更被動的角色，則 ScrumMaster 有權要求產品擁有者離開。
衝刺 (Sprint) 計劃不需要是富有挑戰性的。 對於整個 Scrum 團隊來說，彼此緊密合作，回答「我們能承諾什麼？」這樣的問題，往往是非常有趣的事情。現在也是時候這樣做了，在此過程中，團隊成員之間會建立其感情。請記住，如果您發現會議執行地太長，則根本原因問題可能導致此情況的發生。 如果您是 ScrumMaster，請讓會議保持專注，方法是確保產品擁有者和團隊清理產品待處理項目。 協助產品擁有者準備妥當，具有劇本接受準則之後，再來參加會議。 最後，協助產品擁有者和團隊專注於手頭的工作，判定他們可以對衝刺承諾什麼。