復原與完成
作者 Ken Schwaber 和 David Starr，Scrum.org
2012 年 1 月
交付完成的增量模組是敏捷式軟體開發成功的重要關鍵。 作者使用實際和理論範例，示範「完成」的感覺和實際「完成」之間的差異，以及對專案的成功與否有何影響。 作者使用這些範例繼續示範可以協助小組開始理解完成定義的工具和策略，以及能協助小組針對完成的相依性、狀態及意義進行溝通的方法。
套用至
Application Lifecycle Management; Team Foundation Server
本文內容：
簡介
Anna 的公司失去透明度
人們以為的情況
實際情況
課程
在 Nanomedtronics AZ 的技術負債
人們以為的情況
實際情況
課程
多重小組的技術負債放大
Datum Corporation 的發行計劃
人們以為的情況
實際情況
課程
大規模完工技術
Scrum 中的 Scrum
連續整合
結論
Scrum 是反覆、累加的敏捷式架構。小組使用它以快速增量的交付「完成」，或者潛在可用的軟體功能的週期，或是 Sprint。
「完成」(Done) 是一個簡單但經常受到誤解的字。 對我而言，這表示已經完成、完成和已完成。 已完成即表示沒有任何其他要執行的項目。 「完成」(Done) 定義起來很簡單，但是「交付完成的增量模組」仍舊是 Scrum 和靈活度的其中一個難以定義的基本需求。
靈活度的要求是在每個 Sprint 交付完成且立即可用的可行軟體增量模組。 但多數 Scrun 和敏捷小組會產生部分完成、未完成的遞增。 問到 Scrum 小組為何尚未完成 Sprint 中產品待處理項目需求時，小組成員通常會回答「沒有時間」。
本文件透過早期 Scrum 實際案例研究說明與完成累加相關的問題。 相關的名稱與部分已變更，但我確定這些人會體認自己及自己辛苦的成果。 本文所指的 Sprint 全數是每月一次的反覆項目，除非另有說明。
Anna 的公司失去透明度
Anna 需要自動化其部門財產契據的變更。 她工作的公司是建立及管理横跨北美大部分瓦線管線的公司。 她的部門處理並支付權利金給公司所跨越之土地的擁有人。 Anna 的部門所收到的標題資訊是列印輸出或屬性變更文件。 量變得非常大，所以 Anna 想要自動化摘要和權利金付款程序。
我們對開發小組提議使用 Scrum 為 Anna 建置權利金系統。 這可確保她每個月都有可檢查的軟體。 每個月她也有權限對於我們小組接著會進行任何動作改變心意。
在第三個 Sprint 結束以前，我們已增加其中一個範圍的摘要，將其與舊版資料整合。 我們使用簡單 SQL 方案示範。 Anna 很高興，因為其職員的大部分產品待處理項目都是來自這個範圍。
她要我們教她的成員 SQL，以便他們可以立即開始使用開發小組已交付的軟體。
她說想要使用它是什麼意思？ 當然她未解譯已完成 Sprint 所執行的軟體!
我們告訴 Anna 越小心越好。 她相當的生氣。 「您所謂的尚未完成是什麼意思？」 我看過第一個增量模組、第二個增量模組，我現在想要開始使用它。 現在就部署，並教一下 SQL 好讓我們可以使用它」。
我們開始覺得心神不安。 我們告訴 Anna，是的，完成了。 但這並不是那種類型的完成。 這是要顯示給她的完成項目，但是仍舊有問題需要解決，然後才能使用該軟體。
某些內送紀錄無法被處理。 我們需要用於儲存和管理的設備，而不是將它們捨棄。
內送資料錄中的數個欄位似乎用於記載以外的用途。 該如何處理？
現有資料庫中的欄位包含了指標或是看起來像參考資訊的資訊。 這在整個資料庫中。
當我們執行傳入的摘要及查詢資料庫時，系統當機數次。 資料似乎已在這些當機事件中損毀。
Anna 問我們要多久才能讓事情符合她所預期的方式完成，而且事情辦完後會有用。 我們預估需要另外兩個 Sprint 才能使用遞增。 她告訴我們繼續進行並且為她的部門的使用做好準備。 隔天早上她「要求」我去見她。
第二天早上安娜，她的上司也是開發經理就在那裏。 由於我提出的透明度不存在，他們表達失望。 他們認為我不應該只將未解決的問題記錄成錯誤，而應該以其他方式處理。 由於提供給所有人的待執行工作報表中的進度是錯誤的，因此他們受到干擾。
在會議之後，我們接到的工作指示如下：
調查並更正四個 Bug。
完成並部署前三個增量模組，因此 Anna 的部門可以開始使用它。
改善我們的工程技術和測試自動化，因此我們對「完成」(Done) 的定義會與安娜的定義 (可立即由商務使用) 相同。
變更我們記錄缺失的方式，使得這個需求在這些缺失獲得修正以前，不會視為已完成。
我們被告知這是很好的學習機會 (如果我們記取教訓)。
.gif "Hh765983.collapse_all(zh-tw,VS.110).gif")
人們以為的情況
當我們開發了系統的基準計劃時，它代表專案關係人和 Anna 認為可能會發生的事情。 開發小組報告目前所見的進度，雖然發行愈來愈進入狀況，且也相信報表。
因為顯示正在進行上述計畫中的工作，所以開發小組實際上會認為自己做得很對。
實際情況
速度是開發小組每個 Sprint 的產能測量及歷程記錄。 測量每個 Sprint 的速度，並且用於建立產能模式。
我們的開發小組必須保持每個 Sprint 8 個已完成工作單位的速度才能符合計畫。 速度有可能低於 8 時，我們沒有完成這些項目的所有工作。
我們交付了運作良好的功能，但完成度不足以使用或建置。 我們想要之後加以改善。 當我們回頭估計未完成的工作時，會另外增加 14 個工作單位。
考慮到初始標題摘要的困難情況，我們重新擬定整個計畫以反映可能的二十個月排程。 Anna 的部門大約每個月就會發佈增量模組，並正常提供新的的摘要。 新的自動化摘要在系統啟動後的二十二個月，突然地且大幅地全面減少手動工作。
課程
每個檢視累加的人都必須查看並了解同一件事，才能達到完全透明。 累加透明檢查應可讓 Anna 管理風險並獲得可預測性。 不過，因為增量模組不透明，她無法有效規劃。
在專案開始時，Anna 建立了發行目標。 在 Sprint 1 之後，她會查看她視為適用的「增量模組」，以評估邁向目標的進度。 她針對在 Sprint 2 中要怎樣做才能漸進的達到目標做了一個決定。 如果她認定我們的進度不完備，她可能已經取消專案。
在 Sprint 3 結束時，Anna 認為已完成總數的 3/10，顯然不正確。
可惜的是，我們針對每個累加所執行的只夠用於示範。 未完成的工作會導致 Anna 的部門無法使用累加，而且無法檢查。
不透明，當檢查增量模組就像用濕的冷毛巾蓋住溫度自動調節器時。 自動調溫器無法正確察覺實際室溫，且會在應該冷卻的時候錯誤地啟動加熱功能。
若不採用透明的遞增，專案關係人就無法正確了解實際狀況，可能會因此而錯誤地採取了沒有意義的動作。
簡單說，沒有完全透明，小組就無法有效地檢查並調整。
在 Nanomedtronics AZ 的技術負債
技術負債是在軟體被視為完成前必須完成的延遲工作。 技術負債有很多種形式，像是差勁的決策、重複的程式碼、和未經測試的功能。 下列範例示範技術負債的原因和影響，如同整個專案中未完成的工作。
Nanomedtronics AZ 是一家小型初創軟體公司。 他們派一個 Scrum 小組處理重要產品的新版本；奈米機器人會使用軟體清除高血壓病患的動脈栓塞。
人們以為的情況
在小組開始時，他們必須選擇產品待處理項目，在一個月的 Sprint 中完成 (不再有剩餘工作、可使用、可能可交貨)。 開發小組擁有所有的技術，可以將需求完整地開發成完成增量模組。
當 Scrum 小組開始進行第一次 Sprint 時，他們會看到有 80 個工作單元，必須在 10 個月之內完成。 因此，開發小組克盡職守地，每個 Sprint 選取 8 個單元的工作。 他們了解如果每個 Sprint 只提取 8 個單位，可以在 10 個月後完成公司規定的工作。
開發小組顯示每個 Sprint 結束進行的增量。 就所有外觀來看，Scrum 正在運作且 Nanomedtronics AZ 已按進度依照規劃交付其產品。
實際情況
在開發小組外仍無法釐清的是實際交付的每個遞增包含一些不良的實作、不重要的錯誤、重複的邏輯，以及有點混亂的程式碼。 此外，增量模組尚未經完整測試，因為開發小組在某個 Sprint 中趕時間，停止了測試。 開發小組承諾要照著排程表，並分階段維持一定的品質。
小組會在 10 個月內努力建置專案。 客戶很惀快且準備好要實作和使用軟體。 不過，開發小組已累積 48 個單位未完成工作，如下圖所示已形成新的技術負債。
.png "完成和未完成的工作")
Nanomedtronics AZ 的小組不會考慮所有真正需要完成的活動和工作。 下列主題包含小組沒有考慮到的事項，而且不是詳細的事項。 還可以包含許多其他事物。
分析
設計
相依性分析
效能測試
穩定性測試
重構
免疫回應測試
與任何其他處理特定產品之小組的工作整合
與任何其他小組的工作進行整合測試，因此增量模組是所有小組參與的整體貢獻。
版本資訊
六個產品銷售市場之文化特性的國際化
使用者接受度測試
回復測試
程式碼檢閱
必須完成上述工作，才能在 Sprint 結尾建立一個完整、整合的遞增。 不過，大部分的開發小組都不會完成上述所有工作。 他們每次 Sprint 都會留下一些「未完的」工作。 這樣建立的累加會包含一些不良設計、重複的程式碼、過於複雜的邏輯、未經測試的功能，或其他形式的不足之處。 這是小組在軟體中製造技術負債的方式。
Nanomedtronics AZ 了解其產品包含要交付給客戶所需的所有功能，但還包含許多缺失，而且沒有做到產品實際上市所需的包裝和最後修飾工作。 假設每 Sprint 有 8 個單元且是不正確的速度，開發小組不慎建立了需要 6 個月才能完成的待處理項目。
公司負責人不能接受產品要等 6 個月才能送貨，而且 3 個月後產品就送出了，但仍有工作未完成。 失敗的可能結果不是延遲 3 個月交付產品，而是延緩加入新功能，就像開發小組現在必須在未來 Sprint 中跟技術負債奮鬥。
課程
技術負債遮住真實的進度並覆蓋產品擁有者和專案關係人所要進行的決策制定的透明度。 技術負債要支付，不論是在設計階段中更正技術問題的時間花費，或是因為延遲交件或品質不佳所造成的損失。
在大部分情況下，當發行產品時，產品中至少會有 50% 的工作未完成。 因此，未完成的工作變成積習難改的持續性負債。 技術負債快速地造成產品的脆弱，並且最終將可能導致像是重新撰寫軟體甚或放棄產品這種負面的商業決策。
多重小組的技術負債放大
開發小組必須小心選擇剛好可在一個 Sprint 中完成的工作。 開發小組了解到多少工作是透過經驗。 儘管如此，小組必須要採用現代化的工程方法，像是自動化組建和回復測試，以完成更多的事情。 如果這些都不使用，手動工作通常需要四或五個 Sprint，讓小組不勝負荷。
考量有三位程式設計人員及兩個 QA 專業人員的開發小組。 程式設計人員每天都要將程式碼簽入原始程式碼系統中。 它正在測試中，已偵測到一些 Bug，交由適當的程式設計人員來處理。 偵測並報告簽入程式碼和缺失之間經過的時間。 在這段時間內，其他程式設計人員可能會在有錯誤的程式碼之上簽入程式碼。 修正初始問題所需的工夫現在愈來愈多。 如果開發小組具有連續組建和測試裝置，會立即偵測到這個錯誤。 使用者可以對它進行調查、修正，然後繼續執行。 額外的工作和浪費就可以避免了。
許多組織使用一個以上的 Scrum 小組來建置軟體。 發生這種情況時，本節所描述的技術負債問題會擴大。 要在錯誤程式碼之上簽入程式碼的機會相當地大,。 修復軟體增加的缺陷所花費的成本會隨著工作進度日漸增加。
Datum Corporation 的發行計劃
我最近為另一家公司工作，名稱是 A Datum Corporation，這是一家基礎結構軟體公司。 主要產品線雇用超過 800 位開發人員，包括 250 位程式設計人員。 開發基礎結構部分是自動化，部分是手動。 測試通常延遲程式碼的天數。 程式設計人員檢查不良程式碼與偵測並回報不良程式碼之間的時間通常需要十天以上。
為盡可能降低這麼多程式設計人員的複雜度，每個開發小組處理其本身的程式碼分支。 開發經理會協助組識產品待處理項目，將相依性減至最低。 如果每個開發小組會每天將其程式碼合併到主要程式碼行，可能發生的重複作業數量就會降到最低。
不過，管理階段認為這會耗費太多時間。 管理階層決定每隔三個 Sprint 將所有程式碼分支合併到根部。 整合測試將會尋找所有缺失，這些缺失要接著進行修正。 每到第三個月結束前就會準備好發行候選版本。
人們以為的情況
下圖顯示計劃好的發行排程和循環。
.png "已規劃的發行排程和週期")
原始計畫假設:
9 個 Sprint
3 個發行候選版本，然後完整版
800 人開發組織
實際情況
這個組織在九次每月 Sprint 後來到發行日期時，產品尚未作好發行準備。 第六個發行候選版本的缺失超過 5,000 個，且有 2,000 個以上未完成的產品待處理項目需求。 我們想知道會怎麼樣。 我們每到第三個月會有一個發行候選版本。 當我們研究時，我們發現示範的來源是每個開發小組的程式碼分支。 並未進行任何整合。 並未進行任何整合測試。
為維持發行日期所需的速度，開發小組已延後所有整合工作，因此建立許多技術負債。 結果與排定的發行日期相差八個月。 「發行候選版本」一詞沒有意義。
下圖顯示實際專案以及以及穩定專案所需的時間。
.png "實際專案所需時間加上穩定性調整所需的時間")
發行候選版本中每個 Team 的程式碼分支有部分可用功能。 在發行之前需要五個月份的「持穩」。 一個特別棘手的缺失 (比其他人更延遲交付) 是「效能不佳」。這個問題已記錄在第一次 Sprint。
課程
處理相同軟體的不同小組最後會合併其工作。 整合軟體確保其運作的做法可以降低整合風險，應經常採行。
等候合併多個小組的工作非常令人期待，因為可以延遲合併成本。 不過，延遲的最終成本需視相關小組數量及必須整合的分支數量而定。
大規模完工技術
跨多個小組達到「完成」狀態是相當困難的。 包含的多個複雜性。 在小組之間和跨程式碼分支當中有相依性存在。 雖然這種複雜程有其代價，還是可以達成，而且當同步的小組以相同的步調一起交付時，就會產生極大的價值。
我找到幾項適合多個小組合作的實用技巧。
Scrum 中的 Scrum
許多 Scrum 小組處理同一專案時，會需要協調工作的技巧。 我已建議採用「Scrum 中的 Scrum」。這是在每個小組的每日 Scrum 之後立即進行的日常活動。 有人技術從每一個小組呈現。 每個小組代表都會描述其小組所處理的項目。 她或他接著說明他們打算要在接下來的一天處理。 根據這項資訊，代表會嘗試找出任何需要的重新作業、任何將來的相依性和任何可能必須重新排定的工作。
Scrum 的 Scrum 對許多組織都相當有用。 但是比較不適合。 由於問題是預計的而非已知的，因此不一定能成功地識別相依性和重新作業。 非預期的相依性導致重新作業及測試失敗。 某些小組在每個 Sprint 中，在建構與重工相依的工作上花費超過 50% 以上。
連續整合
極限程式設計 (Extreme Programming，XP) 需要小組的工作的連續整合與整合測試。 為何不延伸到所有小組？ 無論有兩個或五十個小組、小組必須在每次 Sprint 結束時產生整合的整合測試遞增。 若要這麼做，小組必須經常整合其工作。 因為任何未整合的工作可能會包含無法解析的相依性，持續整合是最佳的解決方案。
所有工作的連續整合類似於精實生產技術。 在精實生產線上，許多技術已用於評估整個生產製程的產品品質。 發生偏差或品質問題時，生產線會中止。 連續整合和整合測試所提供的技術與軟體產品開發的相同。
儘管很困難，還是建議所有小組及小組成員，如果遇到連續組建或測試失敗，就停止撰寫程式碼。 任何接續工作都可能建置在錯誤之上，並造成錯誤的連鎖效應。 如果使用連續整合，小組會密切合作以避免整合失敗。 他們的工作習慣改善了，減少了浪費，而且品質也得以提升。
採用 Scrum 的大多數組織不是一開始就具備所有的設計技能和工具可以用來建置完成的增量模組。 必須開始進行並追求嚴密的計畫以達成完成的增量模組。 小於五十個人員的群組可以快速達到在 Sprint 中即將完成已進行之增量模組的狀態。 開發人員超過五百位的組織通常需要數年才能到達這個地步。
復原累加會建立浪費並防止小組發揮真正的靈活度。 未完成工作的實際成本遠超過缺少特殊功能或函式的累加成本。 成本包含遞增未完成的必要重新計畫和的重新件業造成的浪費，以及較低預測性與較高風險所造成的成本。
許多組織想要靈活度的效益，而使用 Scrum 來取得它們。 交付完成的增量模組是敏捷式軟體開發成功的重要關鍵。 小組應從有意義的定義「完成」開始，然後一次又一次刻意的去擴展其定義。 只有此時，他們才會達到真正的靈活度。