《SAFe 4.0參考指南：精益軟體與系統工程的規模化靈活架構》SAFe團隊層

本節書摘來自華章出版社《safe 4.0參考指南：精益軟體與系統工程的規模化靈活架構》一書中的第1章，第節，作者 迪恩·萊芬韋爾（dean leffingwell）更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

safe?團隊層

3.1　團隊層介紹

我們、工作、知識是一個整體。

——本書作者

摘要

safe團隊層是項目群層的組成部分，但有時會分開讨論。所有的safe團隊都是靈活釋出火車（art）的一部分——art是項目群層的核心組成部分。團隊層為靈活團隊的活動提供了組織、工件、角色和流程模型。由每個靈活團隊自己負責定義、建構和測試來自團隊待辦事項清單中的使用者故事，這些工作在一系列固定周期的疊代内進行，通過使用共同的疊代節奏，并與其他團隊同步和對齊，進而保證整個系統開發的疊代執行。所有團隊都使用scrumxp或團隊看闆，開發和傳遞高品質的系統，并每兩周進行一次系統示範，進而確定在art上的所有團隊可以共同建立出一個經過內建和測試的系統，利益相關者可以通過快速回報進行評估和響應。系統示範提供了一個正常的

“拉動事件”，用于在特定節點拉取不同團隊的成果，讓困難的內建和測試工作盡量提前。這種方法與“階段–門限”模型有所不同，“階段–門限”模型通常在項目生命周期的後期才進行內建和測試工作。

詳述

團隊層描述了靈活團隊如何驅動靈活釋出火車。靈活團隊采用safe scrumxp或團隊看闆，同時應用内建品質的實踐，確定最終産品品質。每個團隊有5～9名團隊成員（scrumxp），并包括所有必要的角色，確定在每一次疊代中建構一個高品質且有價值的釋出增量。scrumxp角色包括scrum master、 産品負責人、全職工作的團隊成員，以及其他能為團隊創造價值的資源。看闆團隊的角色沒有嚴格的定義，許多safe看闆團隊也使用scrumxp的角色。每個團隊都會得到項目群層中成員的支援，這些成員包括：釋出火車工程師、産品經理、系統架構師/工程師、系統團隊、共享服務、devops和其他必要的角色。是以，團隊應該完全有能力在每次疊代中定義、開發、測試和傳遞可以工作并經過測試的系統。

項目群增量和疊代

所有團隊遵循相同的疊代起止日期和時間周期，也就是有相同的疊代和項目群增量（pi）邊界，以便與art上的其他團隊保持同步和內建。每個pi都起始于團隊的pi計劃，他們建構團隊的pi目标，再彙總成項目群的pi目标，這些目标有助于指導團隊的疊代執行。

團隊會按照事先确定的疊代目标，計劃和執行疊代，每個疊代的時間盒為兩周。每個疊代提供有價值的新功能增量，疊代過程按照以下模式循環進行：疊代計劃、承諾傳遞一些功能

、通過建構和測試使用者故事執行疊代、示範新功能、執行疊代回顧，在下一個疊代再重複進行這些活動。在每次疊代結束時，團隊也需要支援系統示範，它是art的關鍵內建點。在一個包含多個art的大型價值流中，團隊還需要支援解決方案的示範，整個解決方案由多個art全面內建和測試，進行整體示範。

創新與計劃（ip）疊代為團隊提供了一個探索和創新的機會，有專門的時間用于計劃、回顧并通過正式和非正式管道進行學習。如果釋出處于pi的邊界上，團隊需要做最終的系統稽核、驗證和文檔工作。為了能提供一個緩沖，團隊不會在ip疊代中計劃使用者故事的實作，是以對于每個pi而言，資源使用率不會達到100%。這樣做增加了流動、吞吐量和傳遞的可靠性。

pi的時間盒可以用于将大型的、系統級的功能聚合為有價值且可評估的項目群增量。這些功能可以在pi的邊界上進行釋出，也可以更加頻繁的釋出。項目群應該有節奏地開發，并支援任何時間的釋出。

每個pi的疊代數量

safe把開發周期分為pi内的一系列疊代。在safe全景圖中描述了如何通過pi計劃會議啟動一個pi，接下來是4個實施疊代，最後是1個創新與計劃疊代。這種模式具有啟發性，不過有些武斷，其實在一個pi中有多少個疊代是沒有固定規則的。經驗表明，pi持續時間一般是在8～12周的效果最好，并且傾向于最短的持續時間。

使用者故事和團隊待辦事項清單

團隊使用使用者故事來傳遞價值，産品負責人負責使用者故事的建立和接收。使用者故事承載客戶的需求，通過價值流進入到實作階段。團隊待辦事項清單由使用者故事和使能故事組成，其中大部分故事是在pi計劃中，當産品經理向團隊展示願景、路線圖和項目群待辦事項清單時進行确定的。在團隊層基本的需求管理流程是：使用者故事的識别、排序、排期、細化、實施、測試和接收。

參考資料

[1]　leffingwell, dean. agile software requirements: lean requirements

practices for teams, programs, and the enterprise. addison-wesley, 2011.

3.2　靈活團隊

靈活團隊所向無敵。

——safe 語錄

正如靈活宣言（2001年）中所描述的那樣，靈活運動是軟體和系統開發方式的一個重要轉折點。safe正是基于這種變革而建構起來的，它通過授權靈活團隊作為建構單元來創造和傳遞價值。

靈活團隊是由獲得授權并富有激情的成員組成的。如果沒有這種有效的靈活團隊，組織就無法将靈活進行規模化，也無法實作企業級精益–靈活開發的大型業務收益。精益–靈活上司者的主要職責在于建構和指導這些靈活團隊。

safe 靈活團隊是一個跨職能小組，他們有能力和權力來定義、建構和測試解決方案價值，所有的這些活動都在一個短疊代的時間盒内完成。團隊應包含必要的成員來成功地傳遞價值，适當的時候由項目群層或者價值流層的專家提供支援。這也遵循safe的原則#9——去中心化的決策，通過授權團隊對需求和設計進行決策，進而讓每個團隊對自己的工作負責。

在safe中，靈活團隊并非獨立的單元，而是作為靈活釋出火車的一部分，靈活釋出火車上的團隊互相協作，他們負有傳遞大型價值的責任。所有的團隊都在火車上，沒有團隊就無法組成火車。團隊在火車上運作，基于共同願景與其他團隊互相協作，并參與靈活釋出火車的關鍵儀式。團隊與火車是不可分割的，它們作為一個整體的價值遠大于每個部分簡單相加的總和。

靈活團隊是由專職成員組成的一個小團隊（在scrum中是5～9人），他們具有一些必備技能，可以在短時間盒内定義（細化和設計他們的元件/特性）、建構（實作這些元件/特性）以及測試（運作測試用例并驗證元件/特性）價值增量。

在靈活釋出火車中，靈活團隊獲得授權、自我組織、自我管理并對滿足客戶需求和期望的傳遞結果負責。這些團隊開發軟體、硬體、固件，或者都有所涉及，但通常情況下，團隊具備傳遞特性所必要的屬性。

企業将工作交予團隊和火車，而不是把人員配置設定到工作任務上，進而有助于建立團隊，以及規模化團隊，而且這些團隊都是長期存在的，并且專注于持續提升傳遞解決方案的能力。在這種情況下，safe 與傳統方式有所不同，傳統方式中是由經理來指導個人活動的；而在safe中是由團隊來決定建構什麼，以及如何建構他們的特性群組件。精益–靈活上司者為團隊提供願景、上司力和自主權，進而培養和促進高績效團隊。這将不再需要給團隊的每個成員配置設定工作任務，而把去中心化的決策方式交到了團隊成員的層級。

角色和責任

safe摒棄了職能式的、基于筒倉的，以及階段–門限的開發模型。在那些模型中，使用者價值是在漫長的軟體生命周期最後階段，依賴于各個獨立職能部門的輸入而進行傳遞的。靈活團隊執行或參與所有這些職能，在每個疊代中都會進行價值的傳遞：

團隊負責管理自己的工作。

團隊估算工作的大小和複雜度。

團隊在架構指導下根據所關注領域決定技術設計。

團隊承諾在疊代或項目群增量時間盒中完成的工作。

團隊負責價值和建構，進而持續提升傳遞成果的品質。

團隊承諾不斷地提升工作方式。

緊密合作

團隊隻有通過不斷溝通和合作，以及快速、有效和授權的決策能力，才能完成他們所承擔的責任。如果有可能的話，團隊最好能夠在同一地點，每小時、每天、每周都進行溝通。标準的團隊會議要依賴于所選擇的架構，但可能包括每日站立會議、疊代計劃、團隊示範，以及每個疊代最後的回顧。每個團隊成員都完全專注于單一的團隊，在每周的工作時間内緊密合作。團隊成員和其他團隊持續并積極合作，對依賴進行管理并解決障礙。

團隊成員之間的關系完全基于彼此的信任，而共同的任務、共同的疊代目标和團隊的pi目标有助于促進信任的達成。團隊的合作通過持續的回報環不斷提高，這樣的回報模式也建構了團隊的持續學習環。每一次真實的價值傳遞，都能增進信任，降低不确定性和風險，并有助于提升團隊的自信。靈活團隊的激勵因素來自于共同的願景和向客戶傳遞價值的承諾。

團隊可以選擇靈活方法

safe 團隊所使用的靈活實踐，主要基于scrum和團隊看闆。大部分 safe 團隊應用scrum作為基本的項目管理和傳遞架構。scrum産品負責人參與并支援去中心化的決策制訂，而這對于團隊的授權是至關重要的。scrum master 支援團隊達成傳遞目标，并幫助建構一個高績效和自我管理的團隊。

其實scrum也并不是唯一可用的實踐。團隊通過采用注重使用者體驗（ux）的工程實踐和内建品質的多種實踐，來推動有紀律的開發和品質。這些實踐包括集體所有權、結對工作、編碼标準、測試先行和持續內建，通過在開發過程中直接嵌入品質和運作效率而使事情變得更加精益。靈活架構有助于完成高品質的解決方案開發。

然而，由于safe是基于流的系統，大部分團隊也在應用看闆進行工作的可視化，建立wip限制，并使用累積流圖來顯示瓶頸和關鍵機會來提升吞吐量。有些團隊（尤其是維護團隊、devops和系統團隊）經常将看闆作為自己的基本實踐，scrum中的計劃和承諾活動在這些團隊中可能無法有效應用，因為工作内容以活動為主并且是按需發生的，優先級的變化也更加頻繁。

靈活團隊在火車上

safe靈活團隊并不是獨立運作的，他們在靈活釋出火車上互相協作來建構可工作解決方案的有價值的增量。不管團隊是否應用scrum、看闆或兩者的結合，所有團隊都在一個共同的架構下運作，這個架構管理并指導整個火車的運作。這些團隊共同制訂計劃、共同執行內建和示範、共同學習，如圖3.2-1所示。

圖3.2-1　靈活團隊共同計劃、共同內建和示範、共同學習

共同計劃

所有團隊共同參加pi計劃會議（如果可能的話，所有的團隊成員最好都要參加）。在計劃會議上，大家一起計劃和承諾一系列的pi目标。大家都有一個共同的願景和路線圖，共同協作以達成目标。在計劃和執行中，有清晰的工作授權。産品負責人是大型産品管理團隊的一部分（看闆團隊有時對此角色使用不同的名稱）。每個團隊的待辦事項清單都是從項目群待辦事項清單中衍生而來的。

此外，作為靈活釋出火車的一部分，為了與經濟架構保持一緻，所有靈活團隊都使用相同的方法進行估算。這提供了一種有意義的方式，有助于決策者根據經濟情況決策并指導行動。雖然工作方式随着使用的方法不同而不同，但結果往往是相同的，後續在“scrum”和“團隊看闆”的相關章節（3.4～3.6節）中會有進一步讨論。

共同內建和示範

傳遞高品質的複雜系統需要團隊之間的緊密配合與互相協助。為此，團隊按照相同的靈活釋出火車節奏工作，在每個疊代開始時共同提出和溝通疊代目标。在靈活釋出火車同步時，各個團隊也會互相更新狀态，通過與其他團隊的成員進行互動，進而積極地管理互相之間的依賴關系。

當然，這裡所說的目标不是簡單地讓團隊向着目标進行“沖刺”，而是指讓系統向着有品質和有價值的增量進行“沖刺”。為此，團隊在内部和這個火車上，都應用了内建品質并在疊代内進行持續內建，同時所有團隊共同協作，進而可以在每個疊代完成時進行系統示範。

共同學習

所有safe的團隊成員都參與持續改進（參見1.4節中的第4個支柱）。除了團隊級别的回顧會議和随時發生的流程提升之外，團隊也會參與更大的檢視和調整會議，通過這種方式識别優先級，按優先級對改進故事進行排序，并将其放入後續的pi計劃會議中進行處理。用這種方式，團隊完成了一個疊代，靈活釋出火車完成了一個pi，就可以讓“環路閉合”。當然，學習并非僅在回顧會議中進行，學習也是在實踐社群中不斷發生的，實踐社群的建立可以幫助個人和團隊不斷提升本職能和跨職能的技能。

[1]　leffingwell, dean. scaling software agility: best practices for

large enterprises. addison-wesley, 2007.

[2]　lencioni, patrick. the five dysfunctions of a team: a leadership

fable. jossey-bass, 2002.

[3]　cohn, mike. succeeding with agile: software development using scrum.

addison-wesley, 2009.

[4]　manifesto for agile software development. http://agilemanifesto.org/.

3.3　産品負責人

業務人員和開發人員必須互相合作，項目中的每一天都不例外。

——靈活宣言

産品負責人（product owner，po）是團隊的一員，負責定義使用者故事和确定團隊待辦事項清單的優先級，進而銜接項目群優先級事項的執行，并維護團隊所負責的特性群組件在概念和技術上的完整性。産品負責人是品質保證的關鍵人物，并且是團隊中唯一有權力接收已完成使用者故事的人。對于正在向靈活方式轉型的企業來說，産品負責人是一個新的并且非常重要的角色。産品負責人通常是全職的，一個産品負責人通常可以支援一個團隊（最多兩個團隊）。

該角色是開發團隊與外界的重要接口，例如與産品經理（負責項目群待辦事項清單）合作，為pi計劃會議做準備。

産品負責人是靈活團隊的成員之一，他是團隊與客戶之間的接口，負責與産品管理人員以及其他利益相關者（包括其他産品負責人）協作來确定團隊待辦事項清單中使用者故事的優先級，以便解決方案能夠有效處理項目群優先級事項（特性/使能），同時保持技術的完整性。理想情況下，産品負責人與團隊的其他人在同一地點辦公，産品負責人與團隊擁有同一個經理、擁有同樣的激勵機制和文化。但是産品負責人也會參加産品經理的會議讨論有關計劃、待辦事項清單和願景的梳理等。

責任

safe産品負責人的主要責任如下。

籌備和參加pi計劃會議

作為産品管理團隊的一員，産品負責人積極參與項目群待辦事項清單細化和準備pi計劃會議的工作，同時也積極參與pi計劃。在pi計劃之前，産品負責人更新團隊待辦事項清單，審查和參與制訂願景、路線圖和進行内容展示。

在pi計劃期間，産品負責人參與使用者故事定義，為團隊澄清産品需求，以便團隊進行使用者故事估算和使用者故事排序，并為項目群增量起草團隊目标。

疊代執行

待辦事項清單梳理——産品負責人的主要職責是從系統架構師/工程師和其他利益相關者那裡獲得輸入資訊，并建構、裁剪和維護團隊待辦事項清單。待辦事項清單主要是由使用者故事組成，但也包括缺陷和使能。待辦事項清單基于使用者價值、時間和其他團隊依賴關系進行優先級排序，團隊依賴關系在pi計劃會議上确定并在pi執行期間進行優化。

疊代計劃——作為籌備疊代計劃工作的一部分，産品負責人審查和重新排定待辦事項清單（參見3.5節中的“疊代計劃”的内容），有時還需要與其他産品負責人協調互相的依賴關系。在疊代計劃會議上，産品負責人負責澄清使用者故事細節和使用者故事優先級，并負責接收最終疊代計劃。

準時制（just-in-time，jit）的使用者故事細化——待辦事項清單中的大部分條目都會細化成使用者故事進行實施。這可能會發生在疊代之前、疊代計劃過程中或疊代執行過程中。雖然任何團隊成員都可以寫使用者故事和接收标準，但産品負責人對保持整個流程的順暢性負有主要責任。通常比較好的做法是，在團隊待辦事項清單中的使用者故事可供兩個疊代執行。如果故事過多，則會導緻産生隊列等待；如果故事過少，則會抑制流動的進行。

支援atdd——産品負責人參加使用者故事接收标準的制訂和起草，并提供示例以支援atdd（acceptance test-driven-development，接收測試驅動開發）規範制訂。可參考8.2節的内容。

故事接收——産品負責人是唯一可以接收使用者故事完成的團隊成員。接收使用者故事包括驗證使用者故事符合接收标準，通過了适當和長期的接收測試，或者通過其他方式能夠驗證使用者故事滿足完成的定義。通過故事接收，産品負責人履行了品質保證的職能，主要側重功能是否适合使用。

了解使能工作——雖然産品負責人無需推動技術決策，但是他們需要了解後續使能工作的範圍，并與系統和解決方案架構師/工程師協同工作來幫助做決策，并為那些實作新商業功能的關鍵技術基礎設施排定順序。這通常需要進行人力物力安排，可參考4.8節中的描述。

參加團隊示範和回顧——作為團隊不可或缺的成員和團隊需求負責人，産品負責人在團隊示範、評審和接收使用者故事，以及疊代回顧（參見3.12節）中發揮着重要作用。在回顧活動中，團隊成員聚集在一起，改進流程。産品負責人也積極參與靈活釋出火車的“檢視和調整”工作坊。

項目群執行

疊代和團隊都服務于一個更大的目标——頻繁、可靠和持續地釋出以便實作解決方案的增值。在每個pi的過程中，産品負責人與其他團隊的産品負責人協調各團隊的功能相關性，通常産品負責人需要每周參加産品負責人協調會議來保障這一點。詳細資訊請參閱4.10節。

産品負責人在為項目群和價值流利益相關者進行示範的過程中也起到關鍵作用。

檢視和調整

團隊可以在pi的檢視和調整工作坊上來處理那些較大的障礙。在工作坊中，各團隊産品負責人協同工作來定義和實施改進故事，以提高項目群的速度和品質。

pi系統示範在檢視和調整工作坊中進行，産品負責人在為項目群利益相關者進行pi系統示範時發揮重要作用。

産品負責人也參與pi系統示範的準備，以確定能夠為利益相關者展現解決方案的最關鍵環節。

内容授權

對于大規模項目，一個人不可能身兼數職——既處理産品和市場政策也服務于某一個靈活團隊。因為在項目群中，産品經理和産品負責人分擔“内容權力”，是以職責劃分是非常重要的。通常的職責劃分如圖3.3-1所示。

産品經理        産品負責人      團隊

面對市場/客戶。識别市場需求。與市場/業務人員在一起辦公。

負責願景、路線圖、項目群待辦事項清單、定價以及roi。

通過對特性和使能排定優先級來實作pi目标并釋出内容。

建立特性的接收标準。        協調解決方案、技術和團隊互動。與團隊一起辦公。

參與制訂願景和項目群待辦事項清單。負責團隊待辦事項清單及實施。

定義疊代和故事。接收疊代增量。

通過合理排序故事實作疊代目标和疊代内容。

建立故事接收标準，接收故事并釋出到産品基線。        面對客戶/利益相關者。

負責故事估算并實作其價值。

參與意圖式架構制訂。負責浮現式設計。

協助細化待辦事項清單和建立故事。

與其他團隊進行內建。

圖3.3-1　釋出内容治理

産品經理、産品負責人和靈活團隊的人員配比

項目取得成功的一個重要因素是企業内各個崗位的人員配比。不合适的崗位人員配比會嚴重影響執行速度。是以，産品經理、産品負責人以及靈活團隊的人數必須是大體平衡的，以便正确地駕駛靈活釋出火車，否則整個系統将花費大量的時間在等待定義、澄清和接收等工作中。safe架構建議的人員配比如圖3.3-2所示。

每個産品經理通常可以支援最多4個産品負責人，每個産品負責人最多可以負責1～2個靈活團隊的待辦事項清單。

practices for teams, programs, and the enterprise. addison-wesley, 2011,

chapter 11.

[2]　larman, craig, and bas vodde. practices for scaling lean & agile

development: large, multisite, and offshore product development with

large-scale scrum. addison-wesley, 2010, chapter 3.

3.4　scrum master

好的上司者首先必須是個好仆人。

—— 羅伯特·k·格林裡夫

大多數safe團隊采用的是scrumxp，這是一種用于有效地進行靈活項目管理和産品傳遞的輕量級的團隊架構。scrum master的角色由團隊中的一員承擔，主要職責是幫助自組織、自我管理的團隊實作其目标。scrum master通過教學和指導safe，實施并支援safe的原則和實踐，識别和消除不利因素的影響，引導流動。

safe團隊從scrum、看闆、xp和其他精益靈活方法中挑選最佳實踐來調整他們的過程。雖然scrum master這個角色主要基于标準的scrum模型，但是大多數團隊——甚至是那些基于事務或工作流的團隊（主要應用看闆）——也有效地采用了scrum master這個角色來幫助團隊達成目标，并協調與其他團隊的溝通活動。

scrum master對于靈活團隊來說是一個專門的角色，他會花大量的時間幫助團隊成員進行溝通、協調、合作；一般來說，scrum master會協助團隊達成他們的傳遞目标。scrum master是基于團隊的管理代理人和仆人式上司，他通過有效的靈活實踐，幫助團隊實作自組織、自我管理和傳遞工作。scrum master支援和實施scrum流程的規則以及團隊認可的其他規則。scrum master也幫助團隊在靈活釋出火車上與其他團隊進行協調配合，在必要的時候向管理層溝通目前的狀态。

在團隊中的責任

優秀的safe scrum master是基于團隊的仆人式上司：

展現精益–靈活的上司力——展現出具有精益–靈活思維的上司者行為。幫助團隊擁抱safe的核心價值觀，采納和應用safe原則，并實施safe實踐。

支援規則——雖然scrum的規則是輕量級的，但依然是規則，scrum master負責遵循實行這些規則，包括scrum規則、在制品限制，以及團隊認可的其他規則。

引導團隊向着目标前進——scrum master接受教育訓練并成為團隊引導者，不斷地挑戰舊有的軟體開發範式，同時保持團隊專注于疊代目标。scrum master在品質、可預測性、流動和速度等方面幫助團隊。以目前産品增量目标為基準，幫助團隊關注于日常工作和疊代目标。

上司團隊進行持續改進——幫助團隊進行改進，并對自己的行為負責。引導團隊進行回顧。教給團隊如何解決問題，并幫助團隊成為自身問題的解決者。

引導會議——引導所有的團隊會議，包括每日站會、疊代計劃、團隊示範和疊代回顧。

支援産品負責人——在團隊中産品負責人有專門的職責。scrum master支援産品負責人的工作，促進健康的團隊内部優先級和範圍的動态調整。

消除障礙——很多阻礙問題都超出團隊授權，或是需要來自其他團隊的協助。scrum master需要積極解決這些問題，以便團隊能夠保持專注于疊代目标的達成。

宣傳推廣safe品質實踐——safe提供了指導，幫助團隊持續改進傳遞物的品質，達成完成定義（dod）。scrum master幫助團隊培養技術自律和匠藝精神文化，這是卓越靈活團隊的标志，scrum master還培育和支援相關實踐的社群。

建立高效團隊——緻力于不斷提高團隊的動力和績效。幫助團隊管理人際沖突、挑戰和成長機會。必要時可以把人員問題上升到管理層，但這僅限于通過内部解決無法達成目标時才進行。scrum master 還可以通過人事變動幫助團隊和個人開展工作。

保護和溝通——與管理層和外部利益相關者進行溝通。保護團隊不受那些不可控插隊工作的影響。

在靈活釋出火車上的責任

scrum master幫助協調團隊之間的合作，以便團隊真正地成為“在火車上的團隊”。

與其他團隊進行協調——一般而言，scrum master作為代表，參加scrum of scrums會議，把會議上的資訊傳達回團隊（細節資訊參見4.10節）。經常和系統團隊、使用者體驗、devops、共享服務，以及釋出管理團隊進行協調。需要注意的一點是，團隊間協調的責任不能完全委托給scrum master，每一個團隊成員在這方面都負有責任。

引導靈活釋出火車儀式的準備和就緒——幫助團隊準備靈活釋出火車活動，包括pi計劃會議，系統示範，以及檢視和調整工作坊。

協助估算——指導團隊建立标準化的估算方法，幫助團隊和靈活釋出火車進行大型特性及能力的估算。

角色來源

scrum master可以是全職或兼職的，這取決于團隊規模、環境和其他職責。然而對企業來說，接受每個靈活團隊有一個全職scrum master是一件有挑戰的事情。畢竟，如果企業組建了100個新的靈活團隊，将100個開發團隊成員全職地放在這個新職責上，而不再做開發或測試工作，這看起來不太經濟，而且行政上的可操作性也不高。就更不要說給每個團隊配備一個全職或者兼職的顧問，來幫助團隊學習和掌握新的思想了。可能在團隊有機會證明這個角色的價值之前，這種變革就已經胎死腹中了。

是以，safe提供了務實的方法和假定，通常情況下，scrum master是由靈活團隊的成員、項目經理、團隊上司或者其他角色兼職擔任。然而在safe推行的初始階段，這個角色的活動會很密集，這時候組織會發現讓外部顧問指導團隊，使團隊在scrum和safe執行中熟練起來很有益處。通常來說，外部的scrum master教練和咨詢師能夠同時指導多個團隊。

[1]　www.scrumalliance.org.

[2]　leffingwell, dean. agile software requirements: lean requirements

3.5　scrumxp

“……一套整體的，或者說是‘橄榄球’的方法——團隊在來回傳球的過程中作為一個整體而行動，也許能更好地服務于當今的競争需求。”

——野中郁次郎和竹内弘高，《新型的新産品開發遊戲》

多數safe團隊采用scrum作為他們基本的團隊級别項目管理架構。scrum是一個輕量的、有紀律的、高效的過程，适合于跨職能、自組織團隊在safe環境下使用。scrum規定了三個角色：scrum master、産品負責人和開發團隊成員（參考資料[3]）。scrum master是仆人式上司，他幫助團隊遵守scrum規則，并且清除團隊内外的阻礙。産品負責人負責定義需求，他是團隊待辦事項清單的負責人（在scrum中稱為産品待辦事項清單，在safe中稱為團隊待辦事項清單）。通過将精益品質管理實踐延伸到軟體開發，并結合來自于極限程式設計（xp）的工程實踐，safe的scrumxp團隊為safe提供了基礎的靈活單元。

但是，safe的scrumxp團隊當然并不是孤立的，每個團隊都是更大的靈活釋出火車的一部分，團隊之間互相協作建構大型的系統，進而努力達成目标。為此，為了確定整個系統的疊代和增量式演進，所有的靈活團隊都會共同計劃、共同內建和示範、共同學習。

scrumxp靈活團隊是一個包括5～9人的自組織、自管理的跨職能團隊，并且盡可能工作在一起。這樣的規模和結構優化了團隊溝通、互動和傳遞價值的能力。自組織意味着團隊中沒有團隊主管或經理角色來給團隊配置設定任務、估算工作量、為特定的目标做承諾，或是制訂明确的解決方案。團隊在獲知疊代的意圖之後，獨立地決定在意圖範圍内哪些是他們可以實際承諾的，以及他們将如何建構這個價值增量。

團隊是跨職能的，是以具備用于傳遞增量的所有角色和技能。團隊自組織和跨職能的性質，以及持續地溝通、有建設性的沖突、充滿活力的互動，這些都可以為團隊成員創造一個高效的團隊氛圍和更愉快的工作環境。

scrum定義了兩個特殊的角色：産品負責人和scrum master，他們是safe scrumxp 團隊的成員，各自被賦予特定且具體的職責。每個角色在本書中都有一個同名的章節做詳細闡述。下文是對其各自職責的一個概括。

産品負責人（po）

每個scrumxp團隊有一個産品負責人負責團隊待辦事項清單。産品負責人與團隊其他成員的互動是重要的、日常性的，并且高度聚焦于工作的事項。是以，最有效的模式是每個團隊擁有一個專職的産品負責人，或者最多兩個團隊擁有一個産品負責人。這有助于産品負責人在疊代執行過程中對團隊進行有效的支援，包括回答問題，在開發中提供更多的功能細節，評審、接收并将已完成的故事釋出到産品基線。

scrum master（sm）

scrum master是團隊的引導者和靈活教練，其主要職責包括：確定團隊遵循開發流程，向團隊提供scrum、xp和safe實踐的教育訓練，以及提供持續改進的環境。scrum master也負責上司團隊移除阻礙。scrum master可以是全職的，或是由團隊成員兼職。此外，一些專職的scrum master可以支援2～3個scrum團隊。

scrum流程

scrum流程本身是一個輕量級的項目管理架構，能夠促進快速、疊代式進階解決方案能力的建構，并且有利于持續改進以支援更高效的産能和更好的傳遞。其流程圍繞着疊代進行（注：scrum采用術語“沖刺”（sprint），safe采用更通用的術語“疊代”（iteration），疊代是一個短周期時間盒，在safe中是兩周，在此期間團隊定義、開發、測試和接收結果。以下是scrum流程的進一步描述。

疊代計劃

疊代開始于疊代計劃，該計劃也是一個遵循時間盒（不超過4小時）的會議，産品負責人可以展示疊代相關的故事。團隊評審故事，定義接收标準，必要時将大故事拆分成更小的故事，估算故事點數，最後根據已知的團隊速度（每個疊代傳遞的故事點數）承諾可以完成的故事。許多團隊進一步将故事拆分成任務，以小時為機關來估算任務，以此完善對工作的了解。最終，團隊承諾一系列的疊代目标。

其實早在疊代開始之前，scrum團隊就通過梳理團隊待辦事項清單為新疊代準備内容，以確定團隊對于将在新疊代中傳遞的工作有一個預先的了解。

可視化工作

在執行過程中，團隊以每隔幾天就可以傳遞一兩個故事的速度進行開發和測試。這種串行的工作方式限制了在制品數量，并幫助避免了疊代瀑布化。團隊采用大型可視化資訊雷達（big visual information radiators，bvir）掌握并跟蹤疊代執行過程。在整個疊代過程中，團隊的故事闆用于可視化故事及其進度。在故事闆中團隊往往把每一列作為一個實作的步驟，随時間從左至右移動故事，如圖3.5-1所示。

圖3.5-1　團隊故事闆示例

有些團隊在部分步驟中應用在制品限制，進而在疊代中創造“拉動”過程，持續平衡工作以提高産能。事實上，很多團隊把scrum和看闆的最佳實踐結合起來，以促進工作的流動性。在這種情況下，簡單的故事闆演變成了結構化的看闆闆（kanban board）。更多資訊可以參見3.6節的内容。

協調每日站會

團隊每天都舉行一個正式的儀式——每日站會（daily stand up meeting，dsu），用于了解團隊目前的狀況，提出問題，以及向其他團隊成員尋求幫助。在會議中，每個團隊成員描述昨天做了什麼，今天将要做什麼，以及遇到的任何阻礙。由于這是一個每天進行的協調會，是以scrum master應該保持會議簡短且聚焦，每日站會不應超過15分鐘，而且是在故事闆前站立完成的。

團隊溝通并不僅限于每日站會，團隊成員在整個疊代過程中保持互動。溝通的便利性是scrumxp推薦團隊成員盡可能在一起工作的主要原因。

價值示範和過程改進

在每個疊代的結尾，團隊要進行一次團隊示範和疊代回顧。在示範過程中，團隊展示疊代中每一個完成的故事，其總和就是此次疊代團隊的價值增量。這不是一個正式的狀況報告，而是一次有形的疊代成果的評審。接下來，團隊進行一個簡短的回顧，反思在疊代過程中，哪些地方做得好，以及目前有什麼阻礙。然後，團隊生成一些改進故事，放入下一個疊代執行。

内建品質

正如一條safe的宗旨所說，“你不能規模化糟糕的代碼。”是以，safe的一個核心價值觀是“內建品質”。內建品質需要從代碼群組件層面抓起，由此生成解決方案；否則，要想確定從元件內建到系統和解決方案過程中的品質，就是一件非常困難的事情，有時候甚至是完全做不到的。

為了確定團隊在代碼群組件方面的内建品質，safe指出了5種來自于極限程式設計（xp）中的工程和品質實踐，用以擴充scrum項目管理實踐。它們是：持續內建、測試先行、重構、結對工作和集體代碼所有權。除了這5個實踐之外，一些團隊還會采用更多的極限程式設計實踐，如結對程式設計、隐喻（參考資料[2]）。

scrumxp團隊“在火車上”

如果一個大型系統包括了不同的技術平台，涵蓋硬體、軟體以及系統工程等多種領域，在這種情況下，即使團隊是跨職能的，讓一個7、8個人的團隊傳遞最終使用者價值也往往是不現實的，我們需要多個團隊一起協作。為此，safe靈活團隊運作在靈活釋出火車之上，靈活釋出火車可以幫助對齊任務目标，提供協作環境，使團隊可以互相協作以具備建構更大型解決方案的能力。作為靈活釋出火車的一部分，scrumxp團隊共同計劃、共同內建和示範、共同學習，如圖3.5-2所示。

有關團隊如何參與“共擔職責的項目群”的更多細節，參見3.2節的内容。

scrumxp 團隊上司力

管理者通常不是跨職能團隊的一部分。然而，最初的團隊組建往往會圍繞着特性、元件和子系統來進行，而靈活釋出火車的設計和架構，往往是管理者的職責，同時要以團隊的輸入為基礎。是以，團隊管理人員的日常管理職責存在一個質的轉變，即從指導團隊具體技術實作的專家管理者，轉變為使能員工、發展員工的精益–靈活上司者。

圖3.5-2　safe靈活團隊共同計劃，共同內建和示範，共同學習

[1]　kniberg, henrik. scrum and xp from the trenches. lulu.com, 2015.

[2]　beck, kent and cynthia andres. extreme programming explained:

embrace change, 2nd edition. addison-wesley, 2004.

[3]　sutherland, jeff and ken schwaber. http://www.scrumguides.org.

3.6　團隊看闆

造成庫存擠壓的唯一原因，是因為使用了過量的人力。

——艾利·高德拉特

也有可能是因為職責劃分太過專門化了？

盡管出于不同的目的，看闆系統廣泛應用于safe的投資組合、價值流、項目群和團隊等各個層級。本節将闡述團隊看闆，一種可以幫助團隊通過可視化工作流來促進價值流動、建立在制品限制、度量生産能力和持續改進流程的方法。

safe團隊可以自行選擇靈活方法，多數團隊會選擇scrum方法，它是一種輕量級、有效和普遍适用的管理方法。開發團隊也會采用極限程式設計，進而專注在軟體工程和代碼品質上。有些團隊，特别是系統團隊、devops團隊，以及維護團隊，會選擇看闆來作為他們主要的靈活方法。在有些場景下可能會導緻團隊選擇使用看闆方法，比如快速響應、救火式的工作特點、快速變化的優先級、“在下個疊代裡确切計劃要做哪些工作”是沒有意義的行為等。本節将描述如何使看闆系統較好地适用于safe靈活團隊，與此同時，這些safe團隊是“在火車上的”，并且需要遵循特定的火車規則。

通常，看闆被描述為一個拉動系統，當團隊有能力勝任某項工作時，是通過“拉動”而不是“推動”的方式來完成這項任務的。本節将讨論團隊看闆，一種可以幫助團隊通過可視化工作流，進而促進價值流動、建立在制品限制、度量生産能力，以及持續改進流程的方法。

看闆系統是建立在工作流狀态基礎之上的，大多數狀态是有在制品（wip）限制的，即一個新的工作項隻有在該狀态的wip小于限制的時候，才能夠加入到該狀态的隊列裡。有一些狀态是沒有wip限制的，例如開始和結束狀态。

wip限制由團隊自己定義和調整，進而快速适應複雜系統開發中流動的變化。在safe裡，團隊看闆應用于靈活釋出火車的節奏與同步中。這確定了團隊間的對齊，依賴管理，以及快速地、基于內建的學習環，也為推進更大型的解決方案提供了客觀證據。

看闆描述

看闆（kanban，意為“可視化的信号”）的本質是一個用于可視化和管理工作的方法。雖然對于如何将看闆用于軟體開發有很多種了解，但一般來講用于開發的看闆系統包括以下幾個主要方面：

系統包含一系列需要經曆的工作狀态的定義；

所有的工作都是可視化的，每個任務的進度都會被跟蹤；

團隊對于每個工作狀态的在制品（wip）限制數達成一緻，并在必要時更改wip以優化工作流；

團隊制訂工作管理政策；

度量流動。工作項從進入系統開始被跟蹤，直至離開；這樣就可以持續地訓示在制品數量以及目前的前置時間（lead time，一個工作項通過系統所需的平均時間）；

通過配置設定服務等級進行排序，而服務等級是由延遲成本決定的。

可視化流動和限制wip

啟用看闆之初，團隊通常會建立一個大緻的工作流程，并設定初始的wip限制。圖3.6-1展示了一個團隊的初始看闆例子，他們目前的工作流程是：分析–評審–建構–內建–測試。

在圖3.6-1中，該團隊還決定建立兩個緩沖區（“準備就緒”）來更好地管理流動的變

化。一個是在“評審”

狀态之前，這可能需要團隊外的領域專家（産品經理或者其他專家），而這些專家的工作時間有限或者不均衡。另外一個緩沖區是在 “內建和測試” 狀态之前，在這個團隊的例子裡，需要使用共享的測試裝置和資源。因為內建和測試是由同一群人在同一個環境上完成的，是以這兩個步驟被視為同一個狀态。考慮到成本因素，團隊允許對

“評審”與“內建和測試”兩個狀态設定更高的wip。

圖3.6-1　團隊初始看闆示例

團隊看闆的改進是疊代式進行的。在定義初始流程和wip，并且執行一段時間之後，團隊的瓶頸将會顯現出來。如果沒有的話，團隊可以梳理工作的流程，或進一步降低wip，直至某些狀态出現明顯的空閑或者過載，這會有助于團隊向更優化的流進行調整。通過驗證假設，以調整wip，進而使工作流程步驟得以合并、拆分，或者重新定義。

度量流動

為了更好地了解和改進流動與流程，看闆團隊采用客觀的度量，包括平均前置時間、wip、吞吐量。其中常用的一種度量方式是累積流圖（cumulative flow

diagram，cfd），如圖3.6-2所示。

圖3.6-2　累積流圖展示了前置時間和wip按天的變化

每一個工作項都是有時間戳的，包括其進入工作流的時間（從團隊待辦事項清單拉入開始實施狀态）及完成時間。“到達曲線”表示拉入工作流的工作項數量，“離開曲線”表示完成并被接收的工作項數量。兩條曲線在x軸的內插補點是平均前置時間——也就是一項工作通過系統所花費的時間。在y軸的內插補點是wip——也就是在任何時間點上，系統中所有工作項的數量。吞吐量——指在給定時間段内完成的工作項數量，它也是一個非常關鍵的名額。safe中看闆團隊以疊代為工作節奏，是以會度量每個疊代的故事吞吐量。

累積流圖為團隊提供資料，以計算他們疊代的吞吐量。

為此，團隊用平均wip除以平均前置時間，得到平均每天可以處理的故事數量，然後再乘以14。其結果就是每個疊代以故事數量計算的平均吞吐量，這有助于制訂計劃。（這對于計算團隊速度也是很重要的，相關内容将在本節後面描述。）

累積流圖也将明顯的流動變化進行了可視化。這可能是團隊沒有意識到的系統内部阻礙，或者是外部力量幹擾了流動。累積流圖是一個客觀的度量工具，可以幫助看闆團隊持續改進。

通過服務等級改進流動

此外，團隊需要有能力管理依賴、確定與裡程碑保持一緻。看闆使用服務等級機制幫助團隊優化工作項的執行。服務等級提供了一種方法，基于延遲成本區分工作項。對于每一類服務等級都有一個特定的執行政策。例如：

1.标準——大部分工作項都屬于這個服務等級：沒有特定的日期依賴的新功能開發。對于标準類别的任務，它的延遲成本是線性的，它的價值隻有在完成傳遞的時候才會達成，但對它沒有固定完成日期的要求。

2.固定日期——有固定日期的工作項意味着裡程碑和預先設定日期的依賴關系。其延遲成本是非線性的。需要及時“拉動”這些工作任務進入開發狀态，以期按時傳遞。有些工作項需要額外的分析，以便調整期望的前置時間。有些工作項在落後于計劃進度時需要将其類别改為“加速”。

3.加速——“加速”類别工作項有着難以接受的延遲成本，因而需要立即引起團隊關注；它可以在違反目前wip限制的情況下被“拉動”進入開發狀态。通常在系統裡同一時間内隻允許有一個“加速”類别的工作項，并且團隊可以設定“蜂擁”政策，以便該工作項迅速通過系統。

如果團隊發現很多工作項都需要加速，那麼系統極有可能是超負荷負載的。有可能是需求超過處理能力，也有可能是輸入流程缺乏紀律。這時需要對工作流程重新進行調整。

如圖3.6-3所示，通常情況下服務等級被可視化為“泳道”。

此外，團隊可以把不同類别的工作項對應到特定顔色上（參見4.11節），如“新功能”“研究探針”（spike）“模組化”等，這有助于團隊進一步了解正在執行的工作項。

密切關注工作流的結構可以給看闆團隊提供改進的機會。例如，累積流圖中發生的變化可能揭示了平均wip在增加（這将導緻前置時間拉長）。這也許是某種更深層次問題的一個表象，現在團隊有能力做出識别。定期省思和調整流程是擷取高度可視化益處的必要措施。

圖3.6-3　看闆上的服務等級

safe 看闆團隊“在火車上”

safe 看闆團隊在更大的架構下運作，這需要多個靈活團隊甚至跨多個靈活釋出火車來建構一個解決方案。為了實作這一目标，團隊除了需要遵守正常看闆原則之外，還需要遵守特定的safe規則。這些規則包括：團隊之間共同制訂計劃，共同內建和示範，共同學習，如3.2節描述的那樣。共同制訂計劃是一個值得進一步讨論的話題，如下文所述。

估算工作内容

通常，看闆團隊在估算或者任務配置設定上花費的時間沒有scrum團隊那麼多。團隊檢視要做的工作項，把較大工作項進行必要的拆分，然後緻力于完成拆分出來的故事，通常不會在意故事的大小。然而，safe團隊需要具備對pi計劃的需求進行估算的能力，以及參與對較大工作項做經濟估算。同時，為了能夠做預測，需要對團隊的速度、其他團隊的速度，以及靈活釋出火車的速度有一緻的了解。

為估算建立一個共同的起點

最初，一個新的看闆團隊并不清楚其吞吐量，因為吞吐量是基于曆史資料計算出來的。啟動之初，safe 看闆團隊必須有一種方法來估算工作，這往往從第一個pi計劃會議開始。這在一定程度上與scrum團隊一緻，看闆團隊的初始能力估計是從标準化估算開始（參見3.9節的描述）。然後，看闆團隊把估算過的故事加入到疊代中，如scrum團隊所做的一樣。團隊的初始能力是他們所假設的速度，至少在第一個pi時是這樣的。

計算“導出”速度

從啟動開始，看闆團隊可以使用累積流圖來計算每次疊代的故事吞吐量（或者也可以先簡單地相加再計算平均值）。由此看闆團隊通過用吞吐量乘以故事平均大小（通常是3~5點）來計算“導出”速度。這樣，safe scrum團隊和safe 看闆團隊都可以參與到大的經濟架構中來，進而為投資組合運作提供基本的經濟環境。

估算大的工作項

在投資組合和價值流層級，通常需要估算更大的工作項（諸如史詩或能力）來确定它們的潛在經濟可行性。此外，對靈活釋出火車和價值流路線圖的開發需要同時具備估算知識（工作項的大小），以及靈活釋出火車的速度（art的吞吐量）。為了做到這點，看闆團隊會把大的舉措分解為故事并進行估算，與scrum團隊所采取的方式類似。這提供了更細顆粒度的解決方案來幫助估算大規模工作任務。故事用标準化的故事點數進行估算，這為企業提供了從各個團隊聚合估算的能力，而且在整個過程中避免了過度的争論。

[1]　anderson, david. kanban: successful evolutionary change for your

technology business. blue hole press, 2010.

[2]　kniberg, henrik. lean from the trenches: managing large-scale

projects with kanban. pragmatic programmers, 2012.

3.7　團隊待辦事項清單

待辦事項清單的定義：

1. 隐藏在舒适表面下的大型清單

2. 未完成的任務或未處理資料的聚集

上述第一種待辦事項清單的燃盡速度緩慢，而第二種待辦事項清單的燃盡速度迅速。

團隊待辦事項清單代表了一個團隊為提升系統需要做的所有事情的集合，它包含了使用者故事和使能故事，其中大部分都來自于項目群待辦事項清單，有些則是來自團隊自己的具體場景。團隊待辦事項清單由産品負責人負責，雖然産品負責人是待辦事項清單的“責任人”，但這并不意味着隻有産品負責人可以建立使用者故事，而是需要産品負責人對工作進行優先級排序。

由于使用者故事和使能故事都是待辦事項清單的一部分，是以通過有效配置資源以確定投資可以在需求沖突中得到平衡，這一點顯得尤為重要。資源的配置需要把靈活釋出火車看成一個整體，并根據火車的需要進行協調。

雖然“待辦事項清單”看起來是一個簡單的概念，然而在其背後卻有許多微妙的影響。

待辦事項清單需要包含所有要做的事情，如果工作項處于清單中，那麼就需要被完成；如果工作項不在清單中，那麼就不會被完成。

待辦事項清單是一個“希望實作工作項”的清單，而不是一個承諾。工作項可被估算（推薦）也可以不用估算，但無論哪種情況都不會包括承諾該項工作的具體完成時間。

待辦事項清單有唯一的責任人——團隊的産品負責人。這樣可以保護團隊免受多方面利益相關者的幹擾，因為每一個利益相關者的關注重點都有所不同。

所有的團隊成員都可以将自己認為重要的使用者故事放入待辦事項清單。

待辦事項清單包含使用者故事、使能故事和“改進故事”，其中“改進故事”是從團隊疊代回顧會議的結果中識别出來的改進内容。

團隊待辦事項清單是一個簡單而統一的形式，但也隐藏了靈活在規模化過程中的複雜性。圖3.7-1說明了團隊待辦事項清單的三個主要來源。

圖3.7-1　團隊待辦事項清單的分解圖

項目群待辦事項清單中包括将要實作的特性，通常會計劃在靈活釋出火車中進行傳遞。在pi計劃會上，計劃在項目群增量（pi）中傳遞的特性會被分解成故事，并且暫時配置設定進入團隊待辦事項清單以便在下一個疊代進行實作。此外，也會計劃一些将來需要開展的工作，在這種情況下，團隊待辦事項清單也可以包含一些尚未拆分成故事的特性。有時需要由多個團隊共同傳遞一個特性，在這種情況下，就需要為相關團隊建立相應的工作，然後對其進行估算，并在團隊待辦事項清單中進行維護。

團隊也需要根據自己的實際情況開展工作。除了需要實作那些來自于特性的故事之外，團隊也會有一些自己建立的故事，比如新功能、重構、缺陷、研究探針，以及技術債等。這些由團隊自己建立的故事也需要加以識别，可以寫成使能故事，進行估算，并排序放入待辦事項清單中。

靈活釋出火車上的團隊并不是孤立存在的，不同團隊的待辦事項清單中的使用者故事可能會互相關聯，進而滿足利益相關者的目标。這些故事可能會包含對特性、能力甚至史詩故事的研究和估算探針，同時也會反映團隊之間的依賴關系，以及對外部的承諾。

通過容量配置設定優化價值傳遞和系統健康

與靈活釋出火車一樣，每個團隊都會面臨待辦事項清單中内部和外部工作項的平衡問題，内部工作項包括維護、重構、技術債等；外部工作項是指立即能傳遞價值的新使用者故事。“永遠保持新功能的開發”在一定程度上比較有效，甚至可以立即滿足市場需要，但是這種效果将是短暫的，因為可能會由于沉重的技術債務而影響傳遞速度。為了避免速度的降低，以及推遲由于技術過時導緻的大量系統更換，團隊需要持續關注解決方案的技術演進，及時修複缺陷和改進提升，進而保證現有客戶的滿意度。

産品負責人對于工作項的排序是一件複雜和極具挑戰的事，他需要在3種不同類型的工作中進行價值比較：1）缺陷；2）重構、重新設計和技術更新；3）新的使用者故事。而且這些工作項按需發生，持續增加。大多數情況下，工作項來自項目群待辦事項清單，然後通過容量配置設定有助于團隊形成一種機制，用于明确在給定時間周期内開展哪些類型的活動，如圖3.7-2所示。

圖3.7-2　團隊待辦事項清單的容量配置設定

一旦團隊做出決定，他們就可以從每個“切片”中選擇最高優先級的工作項，放入疊代中進行實作。對于那些在項目群中已經承諾的故事，在pi計劃的時候就已經進行了優先級的排定；但是對于團隊自己添加的本地故事，産品負責人需要按照價值/規模大小，或者采用wsjf（權重最短作業優先）進行優先級排序。此外，為了平衡長期的産品健康和價值傳遞，配置設定到各個工作項類型的百分比可能會有所不同（例如，在每個pi中都會有所不同）。

待辦事項清單梳理

在本節的讨論中，可以看出待辦事項清單中的有些故事已經比較完善，并準備就緒可以進行下一步的實作了，這樣的故事不會帶來太大的風險和意外。因為，整個團隊都參與了讨論，大家采取了基于流的方法，通常是每個疊代（或者每周）至少有一個團隊對将要實作的故事（有時也會讨論特性）開展一個工作坊，進行讨論、估算，并且建立初步的接收标準。

對于這個會議，業界沒有标準的術語，在safe 中稱為待辦事項清單梳理會，但是需要指出的一點是，待辦事項清單梳理是一項持續的工作，而不僅僅是一次會議就能解決全部問題的。應用接收測試驅動開發（atdd）的團隊，通常會在前期投入更多的時間用于開發特定的接收測試，有時也會開展一些相關會議，稱為規格說明工作坊（specification workshop）。此外，由于多個團隊都在做待辦事項清單的梳理，可能會出現新的問題、依賴關系和故事。在這種方式中，待辦事項清單梳理的流程會有助于把目前計劃中存在的問題暴露出來，并更新到靈活釋出火車的同步會議中進行更進一步的讨論。

3.8　疊代

我平生從來沒有做過一次偶然的發明。我的一切發明都是經過深思熟慮，嚴格試驗的結果。

——托馬斯·愛迪生

疊代是靈活開發的基本組成單元，每個疊代都是一個固定的時間盒，團隊在這個固定時間内建構一個商業價值或産品功能的增量。safe的疊代長度是2周，這為團隊提供了一個開發産品特性群組件的基本開發節奏。在這個短周期之内，團隊需要完成疊代待辦事項清單中使用者故事的開發，與其他團隊的輸出結果進行內建，以及準備整個系統的示範等一系列工作。疊代是連續的，一個接着一個進行，以穩定的速度提供持續的商業價值傳遞。

疊代的節奏是safe提到的第一個節奏，safe項目群增量的時間盒更長，由一組和諧的短疊代組成。pi時間盒為靈活釋出火車上所有的團隊提供了一個外部節奏，團隊在這個時間盒裡共同計劃、共同內建和示範、共同學習成長。

由于快速學習是safe學習環的關鍵目标，是以靈活團隊需要盡可能快地執行pdca （plan-do-check-adjust）循環，包括計劃、執行、檢查、調整四個步驟，如圖3.8-1所示。

每個pdca循環就是一個疊代，每個疊代以固定的、可預測的開發節奏産生新的價值增量，同時也優化以前疊代産生的價值增量。在兩周時間内，每個團隊通過計劃、建構、測試、內建和示範等一系列工作完成系統增量的輸出。在短暫的疊代時間内，團隊、産品負責人、産品經理（pm）和其他利益相關者能夠通過可工作的系統完成技術和業務假設條件的驗證。每個疊代都會觸發一次“內建點”，就是所謂的“拉動事件”，通過團隊成員的一緻努力把系統的不同方面進行內建，內建包括功能、品質、校準和可用性等。

計劃疊代

疊代計劃會議是pdca循環中的“計劃”步驟。所有團隊成員在會議中對團隊目标達成一緻，此目标在團隊pi目标中描述，在團隊和系統示範中展示最終結果。

盡管團隊使用scrumxp或看闆會帶來一些計劃活動上的不同，但是在計劃會議中，團隊會檢查待辦事項清單來設定疊代目标，并從系統角度明确需要在疊代結束時進行內建和示範的詳細内容。

執行疊代

疊代執行對應pdca循環中的“執行”步驟，它描述了開展工作的過程。團隊在疊代執行中，開發和測試新功能，以增量的方式傳遞使用者故事，當使用者故事完成後盡快向産品負責人進行示範，并且通過示範來顯示團隊的工作進展情況。

在執行階段還包含一個更小的pdca循環，即每日站會。團隊成員每天都面對面地評估疊代目标的進展情況，更新自己的工作進度。每日站會就是一個以天為機關的pdca循環，它允許團隊每天計劃、檢查，以及調整他們的疊代計劃。

團隊示範

團隊示範對應pdca循環中的“檢查”步驟。在示範會議上，團隊向産品負責人示範經過充分測試的價值增量，并且獲得産品負責人的回報。團隊也會根據示範的結果來調整下一個疊代的團隊待辦事項清單。在示範會上某些使用者故事會被産品負責人接收，另外一些會根據疊代中所收集到的回報進行改進。

團隊示範後，團隊成員緊接着會參與整個系統的示範。在靈活釋出火車中，系統示範是一個必需的、正式的“內建點”，也是一個“拉動事件”，它會對多個團隊的成果進行內建，確定在項目群層級進行盡早的內建和驗證。在疊代中，每個團隊都可以站在系統的角度，對自己的工作進行持續內建和評估，進而滿足整個系統的要求。

改進流程

疊代回顧會“檢查”整個疊代的工作，對應pdca循環中的“調整”步驟。在疊代回顧會議中，團隊成員一起評估開發流程和上一個疊代中改進故事的執行情況，識别問題及其發生的根本原因，當然也會回顧工作中做得好的地方，團隊把識别出的改進故事放到待辦事項清單中，放入下一個疊代中實作。疊代回顧是團隊進行持續改進（safe精益–靈活思想的支柱之一）的關鍵方式之一。不論是立刻進行，還是在檢視和調整工作坊時進行，疊代回顧都可以驅動項目群層的流程改進。

在下個疊代計劃會議開始前，待辦事項清單會根據示範會議和回顧會議的決策重新進行調整。産品負責人根據需要，對新的和原有的待辦事項進行重構或重新排序。

[1]　cockburn, alistair. “using both incremental

and iterative development.” stsc crosstalk 21 (2008):

27 – 30.

[2]　maurya, ash. running lean: iterate from plan a to a plan that works.

o’reilly media, 2012.

3.9　疊代計劃

堅守對決定的承諾，但保持靈活的操作方法。

——湯姆·羅賓斯

基于團隊的疊代計劃是去中心化的控制，以及授權快速、局部決策的主要機制之一。在scrum中，團隊進行計劃，從産品待辦事項清單中選取故事，并承諾在接下來的疊代中進行實作。

這個基本流程對safe來說也是最為基礎的，而且适用于更廣泛的靈活釋出火車層面，因為safe團隊是靈活釋出火車不可分割的組成部分。是以，在pi計劃會議中團隊的待辦事項已經确定或部分确定。此外，團隊不僅可以從之前的疊代中獲得回報，而且也能從系統示範和其他團隊那裡獲得回報。雖然，按照事情發展的自然規律和事實變更的模式來說，疊代計劃應該涉及更大的範圍。但是，此處的疊代計劃流程與scrum中的方式大緻相同，都需要靈活團隊在時間盒會議中對下一個疊代進行計劃。疊代計劃會議的輸出如下：

1.疊代待辦事項清單，包括本疊代承諾的故事，以及故事的接收标準

2.疊代目标陳述，通常是描述本疊代中業務目标的一兩句話

3.團隊對于達成目标所需要做的工作的承諾

疊代計劃的目的是組織工作并為疊代定義切合實際的範圍。每個靈活團隊為下一個疊代（依據疊代待辦事項清單）确定需要完成的故事，并将這些故事彙總成一組疊代目标。疊代待辦事項清單和目标是基于團隊能力來設定的，同時也考慮了每個故事的複雜性、規模大小，以及與其他故事和其他團隊的依賴關系。

在疊代計劃的結尾，團隊對疊代目标做出承諾，并對故事做必要的調整，進而可以實作更大的目标。在這個過程中，管理層不會幹擾或調整疊代範圍，以便使團隊能夠集中精力制訂出有效的目标。

疊代計劃的輸入

在safe中，疊代計劃是細節層面的細化，也是對在靈活釋出火車pi計劃過程中建立的初始疊代計劃的調整。團隊通過預先詳盡闡述的團隊待辦事項清單制訂疊代計劃（他們通常在上一次疊代期間召開待辦事項清單的梳理會議）。計劃會議的輸入有如下内容：

在pi計劃中建立的團隊和項目群pi目标

團隊pi計劃待辦事項清單，包括在pi計劃時确定的故事

基于當時狀況産生的額外故事，這些額外故事來源于pi計劃環節之後産生的缺陷、重構和新故事等

從先前疊代中得到的回報，包括在疊代過程中沒能順利完成的那些故事（沒有達到完成的定義，請參閱5.10節中的“規模化的完成定義”）

從系統示範中得到的回報

在疊代計劃會議之前，産品負責人會根據團隊在項目群增量中的進展，準備好一些初步的疊代目标。通常情況下，在會議開始時，産品負責人需評審拟定的疊代目标和團隊待辦事項清單中優先級較高的故事。在疊代計劃會議期間，靈活團隊讨論實施方案、技術問題、非功能性需求（nonfunctional requirement，nfr）和依賴關系，然後制訂疊代計劃。由産品負責人來定義要實作什麼（what）；由團隊來定義怎麼做（how）和做多少（how much）。

在整個會議期間，團隊對接收标準進行詳細闡述并且評估完成每個故事的工作量。根據他們的完成速度确定候選故事。很多團隊将每個故事分解成任務，并以小時為機關對任務進行估算，以便确認他們是否有能力和技能去完成相應的工作。一旦确認，團隊将全力投入工作，并通過可視化的工具記錄疊代待辦事項清單，如故事闆或其他工具。疊代計劃會議的時間盒最多不超過4個小時。

确定速度

首先，團隊對他們在即将到來的疊代中執行工作的容量進行量化。每個團隊成員确定其可用時間和不可用時間，以及其他需要承擔的職責。同時也考慮其他的正常職責（參見3.7節中關于“容量配置設定”的描述），比如維護職責，這些正常職責與新故事的開發有着顯著不同。

疊代目标

一旦團隊成員的容量已經明确，團隊就應把注意力放在了解一個或多個疊代目标并對其達成一緻意見，而這些目标正是以pi計劃會議中建立的團隊和項目群的pi目标為基礎的。疊代時間距離pi計劃會議越近，就越有可能保持項目群目标不變。

故事分析與估算

團隊會以建議的疊代目标作為參考點，對其待辦事項清單進行評審。對每個故事進行讨論，涉及相對難度、規模大小、複雜程度、技術挑戰和接收标準。最後，團隊對故事的估算達成共識。通常團隊待辦事項清單也包含其他類型的故事，包括建構基礎設施工作的使能、重構、研究探針、架構改進以及缺陷，這些故事也會進行優先級排序和估算。

任務

許多團隊會将故事再分解成任務。随着任務的确立，團隊成員也會對其進行讨論：誰會是完成任務的最佳人選，大約多久會完成（通常以小時計算），它可能和其他任務或故事存在的依賴關系。一旦将這些内容都了解清楚了，團隊成員就需要為确定的任務承擔起責任。當團隊成員開始執行任務時，他們的疊代容量就開始遞減，一直減少到零。通常情況下，疊代接近尾聲時，一些團隊成員會發現自己承諾了過多的任務，而另一些人還有容量空餘。這種情況下，團隊會進行更深入的讨論以達成任務的均勻配置設定。

承諾

當團隊成員容量之和達到承諾的故事需要的容量時，就不會再從團隊待辦事項清單中承諾更多的故事了。此時，産品負責人和團隊針對将要完成的最終故事清單達成一緻意見，并且重新檢查和描述疊代目标。此後整個團隊就會全身心緻力于疊代目标，而工作範圍在疊代期間保持固定不變。

參與人員

疊代計劃會議的參與人員包括：

産品負責人

scrum master，負責主持會議

所有其他團隊成員

任何其他利益相關者，包括來自其他靈活團隊或者靈活釋出火車的代表，以及負責某個專題的專家

議程

疊代計劃會議議程示例如下：

團隊決定可用的疊代速度

産品負責人介紹疊代目标，團隊經過讨論并最終同意目标

團隊按順序（或按優先次序）對每個故事進行讨論。對于每一個故事，團隊還應該：

按照故事點确定或調整每個故事的大小，必要時對其進行拆分

通過交談詳細闡述每個故事的接收标準

基于規模和價值/時間/風險，産品負責人可能對故事進行重新排序

可選工作：按照排定的順序，團隊将故事分解為任務，并以小時為機關進行估算、明确責任

一旦計劃的故事點達到了團隊的容量，就不再讨論新的故事了

團隊和産品負責人協商并最終确定所選擇的故事

每個人都對疊代目标做出承諾

指導原則

下面是舉行一個成功的疊代計劃會議的技巧：

會議的時間限制在4小時以内

會議由團隊發起并舉行

團隊對工作所做出的承諾，不應該超出自身容量或曆史速度

相對估算、速度和标準化故事點估算

靈活團隊使用相對估算來估算故事點的規模大小（參考資料[2]和[3]）。使用相對估算，每個故事的規模大小（工作量）是相對于其他故事的規模來進行估算的。團隊的疊代速度等于疊代中能完成故事的規模大小的總和。了解團隊的速度可以幫助制訂計劃，這也是限制wip的一個關鍵因素，因為團隊不會承擔超出他們以前速度所能完成的故事點。團隊也可以使用速度來估算需要花多長時間才能完成大型的特性或史詩，特性和史詩同樣也可以用故事點來估算。

标準化故事點估算

在标準的scrum中，每個團隊的故事點估算和速度是局部的、獨立的。有可能一個小型團隊使用自己的估算方式得到的速度為50，而另一個較大的團隊估算出的速度隻有12，其實這樣的結果對其他團隊來講沒有什麼參考意義。

然而，在safe中故事點速度必須标準化，以友善那些需要很多團隊支援的特性或史詩可以建立在合理的經濟環境中。畢竟，如果你不知道投資的是什麼，就無法确定潛在的投資回報。

為了做到這一點，safe團隊建立了一種方式，使得一個故事點對一個團隊和其他團隊都有相同的意義。在這樣的方式下，伴随着對不同區域經濟情況的調整，工作的估算和優先級排序可以基于從故事點到成本的轉化來完成。這對初始的pi計劃特别有用，因為很多團隊是初次接觸靈活，他們需要一種方法來估算第一次pi的工作範圍。以下說明了如何開始估算：

除了産品負責人之外，給團隊中的每一個成員8個點（非專職成員可做适當調整）

每個團隊成員休假日和公共假日減1個點

找到一個較小的故事，花費大約半天時間開發、半天時間測試和驗證，将其定義為1個點

相對于上述故事，對其他所有的故事進行估算

例如：假設一個6人組成的小團隊，包括3個開發人員、2個測試人員和1個産品負責人，他們都沒有休假計劃，那麼就可以估算初始速度= 5人×8點=40點/疊代。（注：如果開發人員和測試人員中有一人同時擔任scrum master，則速度可能需要調整得慢一點）。

通過采用這種方法，所有團隊都可以用共同的方式進行估算，管理人員就能夠為某一特定領域的團隊，公平、快速地估算一個故事點所需的成本。然後，他們以有意義的方式為即将實作的特性或史詩建立總成本估算。

注：在此之後，沒有必要校準團隊估算或速度，這僅僅是一個共同的起始基準。

雖然團隊會随着時間的推移提高其速度，這确實是一件好事，但事實上這個數字往往相當穩定，影響團隊速度的更大因素是團隊規模、結構和技術背景，而不是生産率的變化。而且，如果有必要，财務規劃人員可以稍微調整一下每個故事點的成本。相對于那些在非标準化情況下，大規模團隊間大相徑庭的速度呈現來說，這種财務調整的影響就顯得微不足道了。

chapter 9.

[2]　leffingwell, dean. scaling software agility: best practices for

large enterprises. addison-wesley, 2007, chapter 10.

[3]　cohn, mike. agile estimating and planning. robert c. martin series.

prentice hall, 2005.

3.10　疊代執行

沒有執行的願景隻是幻覺。

每個靈活團隊都有一個核心焦點：在短時間盒内開發出一個有效、高品質、可工作、測試過的系統增量。這也是每個精益–靈活團隊、項目群、價值流、投資組合乃至整個企業所面臨的根本挑戰。如果缺乏有效的疊代執行，即使有完備的準備和計劃，也無法實作規模化，解決方案的品質也會受到影響，所有人都會感受到負面的業務影響。

本節将對如何在整個疊代時間盒内進行工作管理提供有效的指導，這些指導對于獨立運作的團隊或者靈活釋出火車上的團隊都适用。

在疊代過程中，團隊密切合作，共同定義、建構和測試疊代計劃中承諾的故事，并全部展示在團隊示範中。團隊使用故事、看闆和每日站會來跟蹤疊代進展和提高價值流。團隊在疊代中傳遞故事，并避免“瀑布”模式，他們會省思實踐和挑戰，來保證持續增量的小步改進，他們與靈活釋出火車上的其他團隊有效合作，通過采用内建品質以保證正确地建構大型系統。這些工作需要花很大精力完成，但是高效的靈活團隊完全能勝任這些工作。?

靈活團隊與傳統項目管理和開發模式有所不同，他們得到充分的授權，充滿能量和激情，富有使命感和清晰的願景，進而專注于更快速的價值傳遞。其核心就是有效地執行每一次疊代。每個團隊可能會采用不同的做法，但關注的焦點都是一樣的，即通過傳遞疊代計劃中承諾的故事來實作疊代目标。

除了有效的局部疊代執行，靈活團隊有一個更遠大的使命，即優化項目群執行。這也是safe的四個核心價值觀之一。

為實作這個目标，團隊在靈活釋出火車的環境中運作，以協調各團隊達成一緻并實作團隊和項目群的pi目标。所有團隊都有相同的疊代節奏和時間以保證在進行團隊示範和系統示範時，能夠同步他們的工作成果以便內建、評估和示範。?

成功疊代執行的關鍵要素包括：

跟蹤疊代進度——使用故事闆和看闆來跟蹤疊代的進度

持續和增量地建構故事——避免“迷你瀑布”，并增量式建構故事

持續溝通——通過團隊每日站會進行持續溝通和資訊同步

改善流——通過管理在制品，内建品質，持續接收故事來優化流

項目群執行——以靈活釋出火車的模式運作來實作項目群pi目标

跟蹤疊代進展

跟蹤疊代進展需要對故事、缺陷，以及疊代期間團隊的其他活動進行狀态的可視化管理。為此，大多數團隊會在自己的工作區域或者會議室裡，在牆壁上使用大型可視化資訊雷達（big visible information radiator，bvir）。?看闆團隊使用看闆闆，scrumxp團隊使用故事闆，大緻如圖3.10-1所示。

使用這個簡單的故事闆，團隊隻需要将紅标尺移動到目前日期，就能對團隊在疊代中的目前狀态提供一個簡單易懂的可視化評估。（圖3.10-1清楚地顯示了目前疊代是存在風險的。）團隊可以基于這些資訊來讨論成功完成疊代所需的工作。如果遠端參與者或關鍵利益相關者需要擷取狀态資訊，團隊可以通過網絡攝像頭、電子郵件或網頁進行分享。當然，如果需要進行規模化，幾乎所有靈活團隊都能使用靈活項目管理工具來捕獲故事、狀态、缺陷、測試用例、估算、實際進展、任務配置設定、燃盡資訊等，而且這些内容都是大型可視化資訊雷達的有益補充。

圖3.10-1　使用故事闆跟蹤疊代進度

持續溝通

團隊協作的關鍵是具備開放的環境和在同一地點辦公。否則，由于問題和假設造成的延遲，将很快導緻價值傳遞的延遲。在最壞的情況下，在不同工作地點的團隊可以通過網絡攝像頭、即時資訊和其他協作工具長期保持線上，進而建立一個開放的溝通環境。

每日站會（dsu）

每天，團隊成員在同一時間和地點召開會議，通過回答以下問題來協調他們的工作：

我昨天做了什麼故事（及其狀态）？

我今天能夠完成什麼故事？

我工作過程中遇到什麼困難了嗎（我被阻礙了嗎）？

每日站會是團隊資訊同步和自組織的關鍵。最有效的每日站會，是團隊站在标明了目前疊代目标故事狀态的bvir前進行的。每日站會需嚴格控制在15分鐘之内，它不是解決問題的會議，而是一種用來識别問題、依賴關系和溝通的機制，問題可以在每日站會完成之後處理。scrum master在“會後處理闆”（meet after board）上記錄需要進一步讨論的問

題，隻有與問題有關的成員需要參與“會後處理”會議。無效的每日站會表現有：需要更系統化的方法并陷入深層次的讨論，并且常常需要scrum master協調和幹預。

注意    雖然每日站會屬于scrum架構，但許多看闆團隊也在其看闆前進行每日站會，來協調工作和檢視面臨的瓶頸或在制品問題。

管理在制品

限制在制品提供了一種政策，可以預防開發中遇到的瓶頸問題，也有助于改進流。同時還能提高團隊的專注力，促進資訊共享和集體所有權。所有safe團隊成員都應該對他們的在制品和流有着清晰的了解。

一般來講，看闆小組都會使用限制在制品的方法，scrumxp團隊有時也會采用限制在制品的方法。應用在制品可以是顯式的或隐式的——例如，隐式的應用表現在，當團隊成員計劃自己的工作時，隻接受按照其速度預測可完成的故事數量。這種方式強制要求輸入的工作（協商的疊代目标和故事）與容量（團隊的速度）相比對。?疊代時間盒也可以限制在制品，它可以在一定時間内防止不受控制的工作蔓延。

scrumxp團隊也可以在他們的故事闆上使用顯式的限制在制品方法。例如，圖3.10-1中如果沒有限制在制品，開發人員在完成故事5之後會做什麼呢？他們很可能會開始另一個故事的開發。但如果限制“進行中”和“測試”階段的在制品數量為3，開發人員則可能會去幫助做測試，這樣總産出便會增加。要了解更多有關限制在制品的内容，請參閱safe原則#6。

内建品質?

靈活釋出火車以最快的、可持續的前置時間來執行和傳遞新功能。為此，他們必須創造可預測開發速度的高品質系統。safe采納了一系列品質管理方法和工程實踐，以緻力建立适用于最大型的解決方案的内建品質，例如測試優先、持續內建、重構、結對工作和集體所有權。確定從一開始就保證品質，以便更快、更容易、更低成本地進行價值傳遞。?

持續接收使用者故事

持續地接收故事，可以不斷提升流動性。（圖3.10-1展示了一個非流動的疊代，團隊在6天内隻接收了1個故事。）團隊成員一旦準備好就可以示範新故事，而不必等待疊代結束時的團隊示範。沒有被接收的故事則由團隊成員進行返工。這樣做可以快速有效地解決問題，也會防止其他成員在不可工作的故事之上，繼續開發新的故事，還可以防止團隊成員在不同的上下文場景中來回切換所帶來的開銷。

測試自動化

在可能的情況下，盡量将産品負責人和靈活團隊成員描述的系統接收标準，轉換成可以反複運作的故事接收測試用例，并随着系統開發進行持續改進以確定測試用例的适用性、一緻性。自動化也能實作快速的系統回歸測試，強化持續的系統級內建、重構和維護。通常，這些測試使用業務可讀性、領域專業性的語言編寫，進而可以為系統建立“可自動執行的規範和測試”。?

連續和增量式建構故事?

避免疊代内的“瀑布模式”

團隊應該避免将疊代“瀑布”化的趨勢，確定以疊代的方式完成“定義–建構–測試”的循環，如圖3.10-2所示。

增量式建構故事

圖3.10-3說明了如何将故事拆分成縱向的獨立切片，進而實作真正的增量式開發、內建和測試。

圖3.10-2　通過跨職能的疊代，避免“迷你瀑布”模式

圖3.10-3　增量式開發的關鍵是用縱向切片的方式實作故事

增量式建構故事可以縮短回報周期，使得團隊能夠增量式地對可工作的系統進行持續內建和測試，也可以讓靈活團隊成員能夠更好地了解相應的功能，實作更頻繁的結對開發和內建。團隊内外甚至靈活釋出火車團隊之間的依賴關系，也可以進行更有效的管理，因為被依賴的團隊可以更早地接觸新功能。增量式建構故事還有助于減少不确定性，驗證架構和設計決策，促進早期學習和知識共享。

專注于項目群執行?

雖然疊代成功很重要，但所有靈活團隊的最終目标是成功實作項目群增量的執行。?為幫助確定團隊避免僅僅專注于本地優化而忽視整體優化，safe各團隊會共同計劃、共同內建和示範、共同學習，如圖3.10-4所示。

關于各團隊共同工作的實踐，以及成功實作項目群增量開發的詳細内容，可以參考3.2節中的描述。

圖3.10-4　各團隊會共同計劃、共同內建和示範、共同學習

3.11　團隊示範

可工作的軟體是進度的首要度量标準。

眼見為實。

——佚名

在人們真正看到、觸碰到最終成果之前，故事或特性都隻是一個抽象的概念，是以向客戶（或其代理人）示範可運作的、經過測試的系統，是一個具有實質意義和影響深遠的時刻。為此，在safe中，基于解決方案的不同範圍定義了3種示範：解決方案示範、系統示範和團隊示範。系統示範是由靈活釋出火車的所有團隊提供的對新系統所有内容的內建展示，而解決方案示範則是衡量價值流進展的首要度量标準。

本節将對團隊示範進行描述。團隊示範基于scrum定義的儀式，用于評審本次疊代所完成的增量結果，有些看闆團隊也會使用團隊示範。如果要計劃和舉辦一次有效的團隊示範，是需要團隊成員提前做一些工作的。如果沒有這種示範，團隊就無法得到快速回報，也無法沿着正确的方向前進。

團隊示範的重要性不言而喻，它提供了一種快速的方式，可以從發起人和客戶那裡收集到基于上下文的回報。是以，每次示範提供3個重要職能：

團隊示範是疊代時間盒的結尾，同時展現了團隊成員所做出的貢獻與努力，向業務提供了新的價值

團隊示範為團隊提供了一個機會，可以向業務部門展示自己做出的貢獻與努力，并讓團隊感受到工作和進展中的滿足感與自豪感

團隊示範允許客戶和利益相關者看到可工作的特性并提供回報

目的

團隊示範的目的是向産品負責人和其他利益相關者展示可工作的故事，并得到他們的回報，進而度量團隊的進展。團隊示範是一個1～2小時的新功能示範，其準備工作是在疊代計劃期間就開始考慮了，團隊需要思考如何對所承諾的故事進行示範。團隊應該能示範每個使用者故事、探針、重構，以及新的非功能性需求。這種“以終為始”的心态，能幫助和培養團隊對所需功能點達到更細緻深入和更準确的了解，進而也有助于疊代計劃的進行。

流程

團隊示範一般從評審疊代目标開始，然後走查所有承諾過的故事。每個已完成的故事要以一個可工作、已測試的系統來示範。探針可以通過用研究成果的形式來示範。當把所有已完成的故事示範之後，如果存在沒有完成的故事，團隊可以反思一下沒有完成的原因。這種讨論通常會幫助團隊發現開發障礙或風險、錯誤假設、優先級的變更、不準确的估算，或者過度的承諾。可以把這些結果帶到疊代回顧會議上，團隊就如何更好地計劃和執行以後的疊代進行更深入的讨論。圖3.11-1說明了團隊示範情況。

團隊示範除了能讓團隊感受到他們在已結束的疊代中的出色工作之外，還可以讓團隊省思一下他們距離完成pi目标的差距和進展情況。

團隊示範的參與人員包括：

靈活團隊，包括産品負責人和scrum master

靈活傳遞火車中的其他利益相關者，或者本疊代中涉及的共享服務人員

業務負責人、高層管理者（發起人）、客戶，還可能有其他團隊的成員。當這些人參加團隊示範時，他們通常會把興趣和對細節的關注，更多地放在如何與系統示範保持一緻性上。否則的話，可能由于團隊示範往往更加注重在團隊的細節層面上，容易導緻“示範疲勞”。

下面是團隊示範議程的一個示例：

評審此次疊代的業務環境和疊代目标

示範每個故事、探針、重構，以及可應用的非功能性需求，并收集回報

讨論所有未完成的故事，并且查明原因（原因可能會有助于下一次疊代計劃）

識别從本次疊代或示範中湧現出來的目前最新風險和障礙

以下是成功進行團隊示範的一些小提示：

團隊成員對單個故事的示範準備，要限制在1～2小時

示範會議的時間盒設定為1～2小時

最小化ppt幻燈片的使用

隻示範已完成故事的可工作、已測試的系統功能（參照5.10節中關于“完成定義”的描述）

如果一個主要的利益相關者不能參加，産品負責人應該在會後及時跟進向其彙報進度并獲得回報

large enterprises. addison-wesley, 2007, chapter 15.

3.12　疊代回顧

團隊定期地反思如何能提高成效，并依次調整自身的舉止表現。

在每個疊代結束時，采用scrum架構的靈活團隊成員會聚集起來舉行一次疊代回顧會議（有時看闆團隊也會進行回顧），在回顧中讨論他們所采取的實踐，以及如何改進。每次回顧的時間盒是1小時或更短的時間，團隊在回顧時需要總結“哪些工作做得好”“哪些工作做得不好”和“哪些工作下一次可以通過改進做得更好”。

每次回顧都包括定量和定性兩個方面。定量評審是收集和審查團隊所使用的名額并度量其績效；定性部分會讨論在最近的1～2個疊代中團隊所采用的各種實踐方法和所面臨的挑戰。當問題已經被識别出來，也分析了根本原因，讨論了潛在的糾正措施後，就會把改進故事放入團隊待辦事項清單中。

靈活團隊通過疊代回顧來省思已完成的疊代，并擷取新的想法用以改進疊代的過程。這有助于在個人和團隊中貫徹持續改進的概念，持續改進也是safe精益–靈活思維的支柱之一。疊代回顧還有助于確定每一次疊代過程中，對團隊的流程都進行一些小的改進。

回顧過程需要整個團隊的參與，他們與scrum master一起，通過應用工具和流程，進行資料采集和問題解決。團隊實施的回顧分為兩部分：定量部分和定性部分。

定量評審

團隊評估他們是否達成了疊代目标，這是一個二進制的評定标準，答案為“是”或“否”。他們也同時收集那些已商定的分析标準，比如團隊速度，通常包括兩部分内容：一部分用于新功能的開發，另一部分緻力于已有功能的維護，二者缺一不可。

靈活團隊收集和應用其他可視化的疊代名額，并幫助其過程改進。同時這些資料也可以作為輸入，用于後續的定性研究。

定性評審

首先，團隊評審那些在以前的回顧中已經識别出來的改進故事的完成情況，然後分析流程現狀，并把焦點放在找到他們下一次疊代可以做得更好的1～2件事情上。由于許多改進的故事所涉及的範圍較大，是以團隊應該将它們劃分為更小的改進故事，進而使團隊能夠專注于在一個疊代中的具體改進工作。

關于疊代成功的幾種流行的主觀回報技術如下（參考資料[1]）：

個人——每個人寫下記事貼，分小組找出其中的規律

欣賞——記錄下是否有人曾經幫助過你，或者幫助過團隊

概念——選擇一個詞語來描述本次疊代

評分——疊代評分範圍為1～5分，給本次疊代打分，然後集體讨論如何使下一次疊代達到5分

簡單——列出3列内容，然後開放性讨論

以上最後一種方法比較常用，由scrum master在紙上畫出3列内容，分别是 “做得好的”（what went well）“做得不好的”（what didn’t）和“下次可以做得更好的”（do better next time），然後開始進行開放性頭腦風暴會議。這種方法執行簡單，而且使得所有成就和挑戰都清晰可見，如圖31.12-1所示。

圖3.12-1　團隊的回顧會議結果示例

一個疊代回顧議程的示例如下。

第一步：定量

團隊是否達到疊代目标（是/否）？收集和評審團隊已商定的疊代名額。

第二步：定性

回顧上一次疊代中的改進故事。它們都完成了嗎？如果沒有，我們需要針對這些改進故事做些什麼？

對于本次疊代，進行分析：

哪些是做得好的？

哪些是做得不好的？

哪些是我們可以在下一次做得更好的？

以下是成功進行疊代回顧的一些小提示：

保持會議的時間盒在1小時或更短的時間。請記住，每兩周舉行一次會議，目标必須足夠小，按照持續改進的步驟進行。

隻挑選1～2件可以在下次做得更好的事情，并将其作為改進故事，在下一次疊代中進行實施。

確定每一個人都發言。

scrum master應該花費時間準備回顧會議，因為它是疊代改進的主要手段。

聚焦在團隊可以處理的改進項上，而不是那些無法解決的内容。

確定在疊代回顧開始時，進行定量評審的過程中，對前一個疊代中的改進故事進行評審并檢視其進展情況。

疊代回顧是一個團隊的内部會議，應該隻限于團隊成員參與。

[1]　derby, esther and diana larson. agile retrospectives: making good

teams great. pragmatic bookshelf, 2006.

large enterprises. addison-wesley, 2007, chapter 15, “regular

reflection and adaptation.”

3.13　故事

故事，作為一種“行話”，能夠使使用者和開發者充分了解，達成一緻，進而高效地協同工作。

—bill wake，極限程式設計聯合發明人

故事是靈活開發過程中用于定義系統行為的主要工件。故事不是需求，它是對期望實作的較小功能的簡明描述，通常從使用者的角度，使用使用者的語言來進行編寫。每個故事都可以支援系統功能的小型和縱向切片實作，進而可以支援系統的增量開發。靈活開發中，故事基本上取代了傳統的需求規範文檔，也可以在後期用需求規範文檔彙總成必需的傳統需求文檔。

故事對于要實作的意圖提供了足夠的資訊，可以讓業務人員和技術人員充分了解。故事是“承諾進行交談”的，它作為一個載體，可以對系統行為和影響進行全面的讨論，而對細節的讨論，可以推遲到故事準備就緒進行實作時再進行。通過接收标準的确定，故事在實作過程中變得更加明确，而系統的品質也得以保證。接收标準可以在接收測試的過程中被自動捕獲和驗證。不論是最初描述故事的時候，還是後期方案演進的時候，這些測試都可以保證系統的功能被正确地實作。這是safe内建品質實踐的至關重要的一環。

使能故事是另一種類型的故事。它們不是用來描述系統功能的，而是用來支援探索、架構和基礎設施等相關方面的工作，并将這些工作進行可視化呈現。

safe架構提供了一個四層的體系結構，用于描述功能層面的系統行為，包括：史詩（epic）＞能力（capability）＞特性（feature）＞故事（story）。它們和非功能性需求一起構成了靈活需求（系統行為）的描述要素，用來定義系統和解決方案意圖，模組化系統行為，并建構起靈活架構跑道。

史詩、能力、特性和使能，它們被用于描述更大的意圖行為，而細節的實作是通過故事來描述的，故事是團隊待辦事項清單的組成部分。大多數故事來源于項目群待辦事項清單的業務和使能特性，也有一些是團隊根據自己的情況建立的。

每個故事都是一個小的、獨立的行為，可以通過增量實作向使用者和解決方案提供相應的價值。故事是功能的縱向切片，有助于確定在每個疊代都傳遞新價值。為此，就需要對故事進行必要的拆分，使其能在一個疊代中實作。

起初，故事被寫在一些索引卡片或者記事貼上。因為索引卡片是有形的實體，有助于在團隊、故事和使用者之間建立起聯系，鼓勵大家一起編寫使用者故事。這些卡片也是動态的，有助于将工作任務進行可視化，可以把它們貼在牆上或放在桌子上，重新排序、互相傳遞，甚至抛棄掉某些卡片。這些卡片可以幫助團隊更好地了解其工作範圍（“哇，看看這些故事，讓我們接收這些工作吧”）和工作進展（“看看這些故事，都是我們在本次疊代内完成的”）。

雖然任何人都可以寫故事，但是隻有産品負責人有權準許故事進入團隊待辦事項清單和接收故事進入系統基線。當然，在整個企業環境中使用記事貼，不太容易進行規模化擴充，是以就出現了很多靈活項目管理工具，用于輔助管理和跟蹤故事。safe裡有兩種類型的故事，使用者故事和使能故事，接下來将詳細介紹。

故事的來源

在safe裡，故事通常來源于業務特性和使能特性的拆分，如圖3.13-1所示。

圖3.13-1　業務特性拆分成故事的示例

使用者故事

使用者故事是表達功能需求的主要方式，它們基本上替代了傳統的需求規格說明書。（然而，在某些情況下，使用者故事被用于了解和開發要實作的系統功能，而這些系統功能後期要被記錄在傳統的需求規格說明書裡，以便檢查功能的合規性、可追蹤性，或者其他用途。）

使用者故事以價值為中心，它着眼于使用者而非系統，展示出使用者的興趣。為此，推薦的表達方式是如下的“使用者之聲格式”：

作為一個<使用者角色>，我可以<活動>，以便<業務價值>

使用這種格式，團隊可以持續地關注和了解誰正在使用這個系統，他們如何使用這個系統，以及他們為什麼需要這個系統。應用這種使用者之聲格式，能夠提高團隊在該領域的勝任能力，他們可以逐漸地、更好地了解使用者真正的業務需求。圖3.13-2提供了一個例子。

雖然使用者故事的格式比較通用，但也不是每個系統都與最終使用者打交道。有時，“使用者”是一台裝置（如列印機）或者其他系統（如交易伺服器）。在這種情況下，故事的描述可以采用如圖3.13-3所示的格式。

使能故事

團隊也需要開發一些技術方面的功能，這些功能可以用于實作許多不同的使用者故事，或者用于支援系統中的其他元件。在這種情況下，故事可能不直接接觸任何終端使用者。這就出現了使能故事，使能故事可以支援探索、架構和基礎設施建設，就像其他内容的推進器一樣。在這種情況下，故事的描述就是從技術的角度，而非使用者的語言了，如圖3.13-4所示。

    圖3.13-2　使用者之聲格式的    圖3.13-3　系統作為使用者的    圖3.13-4　使能故事示例

                       使用者故事示例               

使用者故事示例

使能故事可以包括以下内容：

重構和探針（與極限程式設計中的定義相同）。

建構或改進開發/部署的基礎設施。

運作需要人工幹預的任務（例如，檢索100萬個網頁）

根據不同的目的，生成不同的産品或元件的配置

執行特殊類型的系統品質驗證（例如，安全脆弱性測試等）

當然，使能故事和使用者故事一樣，可以進行示範，典型的做法是可以示範生成的工件，或者通過使用者界面（ui）、打樁（stub）和模拟（mock）進行。

編寫好的故事

3c：卡片（card）、交談（conversation）、确認（confirmation）

ron jeffries是極限程式設計的發起者之一，他提出了使用者故事的3c方法。

卡片（card）指的是用一張索引卡片、記事貼或使用其他工具，捕獲和表明使用者故事的意圖。索引卡片很自然地提供了團隊和故事之間的聯系。卡片的大小從實體上限制了故事描述的長度，進而也限制了系統行為的早期特征。卡片也可以幫助團隊“感覺”到故事涉及的範圍，比如團隊手中拿着10張卡片的感覺，與用眼睛看10行電子表格的感覺是有差別的。

交談（conversation）表達的意思是在團隊、客戶/使用者、産品負責人和其他利益相關者之間“承諾進行交談”。這是一些必要的讨論，用來決定為了實作某些意圖所需要的細節行為。這些交談也可能會産生其他形式的變化，比如模拟、原型、表單、算法、時序圖等。交談跨越了故事的整個生命周期：

待辦事項清單的梳理

計劃

實作

示範

交談提供了共享的氛圍，這是正式文檔所無法提供的。交談通過讨論功能的具體執行個體，讓需求變得不再模糊。交談也有助于發現一些沒考慮到的情況或者一些非功能性的需求。有些團隊也會在故事卡片的确認欄中記下他們将如何示範該故事。

對接收标準的确認（confirmation）提供了明确的條件，用于確定故事可以被正确地實作，并且滿足了所有相關的功能性和非功能性的需求。圖3.13-5提供了一個示例。

靈活團隊會盡可能地做到自動化接收測試，通常使用業務可讀性、領域專業性的語言編寫，由此為系統建立“可自動執行的規範和測試”。自動化也提供了對系統進行快速回歸測試的能力，這種能力增強了持續內建、重構和維護。

對好故事進行投資

人們通常會用bill wake發明的縮略詞“invest”來提醒良好的故事應該具備的要素：

i——獨立性（independent，獨立于其他所有故事）

n——可協商（negotiable，靈活的意圖表述，不是合同）

v——有價值（valuable，提供給客戶有價值的縱向切片）

e——可估算（estimable，小的，也是可協商的）

s——小的（small，适合一次疊代完成）

t——可測試（testable，充分地了解如何進行測試）

在參考資料[1]和參考資料[2]中，可以得到更多資訊。

故事的估算

safe中的scrumxp靈活團隊使用故事點和估算撲克（參考資料[2]和[3]），對其工作進行估算。故事點是一個數字，用于代表以下内容的：

數量——有多少？

複雜度——有多難？

知識——哪些是已知的？

不确定性——哪些是未知的？

故事點是相對的，它們和任何特定的度量機關無關。假定一個最小的故事，給它賦1點，然後其他故事的大小（工作量）可以相對于這個最小的故事進行估算。safe應用修改過的斐波那契數列（1，2，3，5，8，13，20，40，100）來展現估算中的不确定性，尤其是對于一些較大的數字（如20，40，100等）（參考資料[2]）。

估算撲克

靈活團隊通常使用“估算撲克”，可以綜合專家意見、模拟類比、分解等手段來快速可靠地進行估算（也可以使用其他的估算方法）。使用“估算撲克”的規則有：

所有團隊成員都參加

發給每個估算者一疊卡片，1，2，3，5，8，13，20，40，100，∞，以及 ?

産品負責人參加會議，但不做估算

scrum master參加會議，但不做估算，除非他也參加實際的開發工作

對于每一個需要估算的工作項，産品負責人講讀故事的描述

進行問題的提問和解答

每個估算者獨立地選出一張估算卡片，用于代表他的估算

所有的估算卡片同時翻開，所有參與者能看到其他人的估算

給出估算點數最高和最低的人，向其他人進行解釋

經過一番讨論，每個估算者使用估算卡片重新進行估算

估算将會傾向于收斂。如果沒有，重複以上過程

進行一些前期的設計讨論是适宜的，然而，花費過多的時間用于設計讨論就是浪費精力。估算撲克的真正價值就是對故事的範圍達成一緻，而且也很有趣！

速度

團隊的速度等于一個疊代中完成的所有故事（達到了完成定義）的故事點的總和。了解團隊的速度有助于制訂計劃，也是限制在制品的一個關鍵因素，因為團隊不應該承擔超過其速度的過多故事。大型的史詩、能力、特性和使能，都會使用故事點進行估算，是以速度也可以用于估算它們的傳遞時間。

估算的通用起始基準

然而，在safe中，故事點速度必須有一個通用的起始基準，以便于那些需要很多團隊支援的特性或史詩可以建立在合理的經濟環境中。為了做到這一點，safe團隊建立了一種方式，使得一個故事點對一個團隊和其他團隊都有相同的意義。在這樣的方式下，伴随着對不同區域經濟情況的調整，工作的估算和優先級排序可以基于從故事點到成本的轉化來完成。畢竟，如果沒有可比性的“通用貨币”，就無法确定潛在的投資回報。

對于故事和速度所采取的一種通用的起始基準如下：

對于團隊中的每一個開發人員、測試人員，給予8個點（如果非專職成員做适當調整）

例如：假設一個6人組成的小團隊，包括3個開發人員、2個測試人員和1個産品負責人，他們都沒有休假計劃，那麼就可以估算初始速度= 5人×8點=40點/疊代。（注意：如果開發人員和測試人員中有一人同時擔任scrum master，則速度可能需要調整得慢一點）。

通過采用這種方法，故事點數在某種程度上可以類比于一個理想開發人日，所有團隊都可以用共同的方式進行估算，管理人員就能夠為某一特定領域的團隊，公平、快速地估算一個故事點所需的成本。然後，他們以有意義的方式為即将實作的特性或史詩建立總成本估算。

注意    在此之後，沒有必要校準團隊估算或速度，這僅僅是一個共同的起始基準。

雖然團隊會随着時間的推移提高其速度，這确實是一件好事，但事實上這個數字往往相當穩定，影響團隊速度的更大因素是團隊規模、結構和技術背景，而不是生産率的變化。而且，如果有必要，财務規劃人員可以稍微調整一下每個故事點的成本。相對于那些在非标準化情況下，大規模團隊間大相徑庭的速度呈現來說，這種财務調整的影響就顯得微不足道了。而且沒有通用的起始基準，也就無法進行企業的規模化，因為無法找到決策的經濟基礎。

故事拆分

顆粒度小的故事可以更快、更可靠地實作，因為小顆粒可以快速地通過系統，減少變異性，易于管理風險。是以，把大顆粒的故事拆分成小顆粒的故事，是每一個靈活團隊的必備生存技能，也是增量式開發的一項藝術和科學。有10種故事拆分的方法（參考資料[1]），以下是這些方法的簡要總結：

1.工作流程步驟

2.業務規則變化

3.主要工作量

4.簡單/複雜

5.資料的變化

6.資料入口方法

7.延遲系統品質

8.操作（例如：建立、讀取、更新、删除或crud）

9.用例場景

10.建立一個探針

圖3.13-6展示了以上第9項中，通過用例場景拆分故事的示例。

圖3.13-6　将大故事拆分成小故事的示例

safe需求模型中的故事

正如safe需求模型所描述的那樣，該架構使用了一套完備的工件及其之間的聯系，用于在精益和靈活的環境中定義和測試複雜系統。圖3.13-7說明了在大架構中故事的呈現方式。

圖3.13-7　在safe 需求模型中的故事

如圖3.13-7所示，故事通常是由特性衍生出來的（有時也有例外，比如團隊根據具體情況建立的故事），而且每個故事都與故事接收測試相關聯。在極限程式設計和safe的scrumxp中，每個故事都會有一個單元測試，單元測試的主要作用是確定故事的實作是正确的。此外，因為單元測試容易自動化，是以這是自動化測試的一個關鍵起始點，可以參考8.2節中的描述。

注意    在圖3.13-7中，使用的是uml方式描述對象之間的關系：0對多（0，1），1對多（1..*），1對1（1），等等。

chapter 6.

[2]　cohn, mike. user stories applied: for agile software development.

addison-wesley, 2004.

3.14　疊代目标

清晰的闡述可以讓深刻的思想更加出色。

——luc de clapiers

疊代目标是靈活團隊和産品負責人達成的共識，是可以在一個疊代内完成的業務和技術目标的高度概括性描述。靈活釋出火車作為自組織、自管理的衆多團隊的集合，可以通過各團隊的疊代目标進行彙總和有效協調。疊代目标有助于團隊成員和産品負責人把共同的使命對齊到疊代中，也有助于每個團隊對齊到項目群的pi目标上，進而可以為了解和處理團隊之間的依賴提供依據。最後，疊代目标可以為團隊、管理層以及業務負責人之間的溝通提供一份簡單的協定，讓所有人可以朝一個共同的目标努力，管理層可以持續地獲知工作進展。

無論團隊應用scrum還是看闆，疊代目标都提供了一種共同的語言，讓項目群利益相關者、管理層和靈活團隊可以保持一緻，管理依賴，并在項目群增量的執行過程中進行必要的調整。

正如3.9節中所述，計劃過程會産生三個輸出：

1.疊代待辦事項清單，由承諾在疊代内完成的故事組成。

2.疊代目标的描述，如圖3.14-1所示。

3.為了實作疊代目标，靈活團隊對于需完成工作的承諾。

疊代目标往往反映了以下幾點：

特性、特性切片或特性部分，如研究、必要的架構等

業務或技術裡程碑

架構、技術或基礎設施工作

正常的工作

其他承諾，如維護、文檔等

疊代目标可以通過完成疊代待辦事項清單來實作，但這并不意味着要完成所有故事才能達成疊代目标。換句話說，疊代目标要高于任何特定的故事。有時候，甚至有必要添加預先未能想到的故事，才能實作疊代目标。

為什麼需要疊代目标

疊代目标在safe和scrum中是必需的（scrum稱之為沖刺目标）。靈活團隊在一個疊代裡通過完成足夠小的故事來開展工作。把使用者價值分割成足夠小的、縱向的、可測試的故事，這是一項基本的靈活能力，但這樣往往會造成“隻見樹木不見森林”。在靈活釋出火車中，疊代目标會幫助團隊從更高的角度了解和維護每次疊代待完成的工作，以及要在下一次系統示範會議上的示範内容。這就是透明性、協調一緻和項目群執行的基礎，它們是safe四個核心價值觀中的三個。簡單地說，團隊承諾在一個疊代裡完成一系列使用者故事是不夠的，團隊必須始終關注每次疊代的業務價值，而且能夠用業務術語與業務負責人、管理層和其他利益相關者就這些價值進行溝通。

疊代目标提供了三方面的價值，進而構成了一個全面的方法來幫助團隊和靈活釋出火車保持協調一緻，并始終緻力于一個共同的目标和使命，具體描述如下。

将團隊成員對齊到共同的目标

疊代執行是一個快速和激烈的過程，兩周的時間一晃而過。疊代目标可以幫助團隊和産品負責人，回到他們最初計劃釋出業務價值時所達成的共識，保持團隊和項目群pi目标的對齊，并幫助團隊落地實作已确定的目标，如圖3.14-2所示。

将項目群團隊對齊到共同的pi目标并管理依賴關系

safe團隊并不是一些靈活孤島。相反，它們屬于一個更大的項目群環境和目标的有機整體。是以，每個團隊必須與其他團隊和釋出火車工程師就下一個疊代的目标進行溝通，進而能夠確定大家保持對齊到項目群pi目标上。此外，各個團隊的疊代目标也提供了發現和解決依賴關系的必要環境，如圖3.14-3所示。

提供持續的管理資訊

為了擴充到項目群層面，同時又要保持精益和靈活的理念，這就依賴于建立自管理、自組織的靈活團隊。這些團隊應該很少需要行政管理幹預或日常監管。在這種情況下，經理們可以向上管理和跨團隊管理，而不是向下管理。這樣就可以建立一個充分授權的、更加精益的組織，管理層就可以承擔更多責任，用自己的組織能力來消除障礙并幫助推動組織級改進。然而，管理層不能也不應該抛棄了解團隊的責任，他們應該了解團隊正在進行的工作以及開展這些工作的原因，因為管理者仍然負有責任去提高組織的開發能力并保證價值釋出的成果。為此，将釋出火車上的疊代目标進行彙總，進而提供一個簡單的、文本化的、以兩周為周期的工作内容概要，如圖3.14-4所示。

    圖3.14-2　疊代目标幫助團隊對齊  圖3.14-3　疊代目标對齊團隊到項目群pi目标，

               并幫助識别團隊間的依賴關系

圖3.14-4　疊代目标提供了可視化及與管理層的溝通途徑

3.15　内建品質

通過快速內建學習環，進行增量式建構。

—— safe原則#4

内建品質是safe的四個核心價值觀之一。企業以最快的可持續前置時間傳遞新功能，并應對瞬息萬變的商業環境，這些都有賴于解決方案的品質。内建品質不是safe特有的概念，它是精益–靈活的核心原則之一，有助于避免與需求召回、返工及缺陷修複相關的延遲成本。靈活宣言同樣專注于品質，其中有一條靈活原則是這樣描述的：“堅持不懈地追求技術卓越和良好設計，靈活能力由此增強”（參考資料[1]）。内建品質對于大規模系統的價值是确切無疑的，并且屬于強制性的。為此，本節将介紹軟體、固件和硬體的品質實踐。

軟體方面的品質實踐——很多是受到極限程式設計的啟發，而且在極限程式設計中也有描述——可以幫助靈活軟體開發團隊，確定他們所建構的解決方案是高品質的，易于響應變化的。這些實踐間的互相協同的本質，重點在于頻繁地确認，以及建立一種把工程和匠藝作為關鍵業務推動者的自發的文化氛圍。

對于固件和硬體，其品質目标和軟體是相同的，但是在實體和經濟上有些不同，是以實踐上也有些差異。這些差異包括，固件和硬體的開發會更加專注于模組化、模拟和更多的早期探索過程，以及更多的設計驗證和更頻繁的系統級內建。

當企業需要應對變化時，建立在良好的技術基礎上的軟體和系統更容易去改變和适應。這對大型系統來說則更為重要，因為即使是小缺陷的累積效應以及錯誤的假設，都可能造成令人無法接受的後果。

實作高品質的系統是一項嚴謹的工作，需要持續的教育訓練和承諾，但對業務收益的投資也是非常必要的：

更高的客戶滿意度——低缺陷率的産品和服務能提供更好的客戶滿意度、更高的安全性、更好的投資回報，并給業務部門增添更多的信心。

開發組織的預見性與信任——如未在解決方案的品質上進行可靠的控制，那麼對新功能的開發不可能做出可預測性的計劃，也無法确定開發的速度。是以在公司内會造成一種信任感缺乏，降低個體對軟體工藝的榮譽感，造成士氣的低落。

可延展性——當元件能清楚地表達設計意圖，展現出簡潔的風格，并在系統架構上支援內建和測試，這時投入更多的人力和資源會為企業帶來更多的商業價值。否則，增加更多的開發和測試人員反而會給企業帶來拖累，最終将導緻高度不确定的、企業無法接受的品質和延遲。

速度、靈活性和系統性能——更高的品質有助于提高可維護性和增強快速開發新業務功能的能力。同時也會提高團隊維護和提升關鍵的非功能性需求的能力，包括：性能、可擴充性、安全性和可靠性。

創新的能力——創新出現在聰明的、富有激情的人身上，以及由他們所掌控的環境中。在高品質創造出的良好技術環境下，創新的想法能夠很容易地産生原型、測試和示範。

下文将對在軟體、固件和硬體上達成内建品質的實踐進行總結。

軟體

safe是建立在長達幾十年的不斷演化、不斷追求更好的工程實踐的基礎之上的，在很大程度上受到了創新性的精益和靈活方法的推動。當談到軟體工程時，極限程式設計實踐起着引領的地位（參考資料[2]）。除了靈活架構在保證系統級的品質中所起的關鍵作用之外，safe還引入了關鍵的精益–靈活軟體工程實踐，以幫助團隊實作最進階别的品質。下文總結了這些實踐，其中的兩個——持續內建和測試先行，在本書中會有更深入的闡述。

持續內建

持續內建（continuous integration，ci）是一種軟體工程實踐，它每天不間斷地把開發人員自己工作空間中的代碼合并到單一主幹代碼分支上。通過這種方式，所有共同開發程式的人員能一直保持在最新的程式版本上工作，開發人員之間的程式缺陷能立即被發現，假設也能立刻得到驗證。持續內建有助于避免系統內建的延遲風險，及其對系統品質和項目可預測性的不利影響。

持續內建需要專業的基礎設施和工具，包括自動化建構伺服器和自動化測試架構。但更重要的是需要建立一種文化和使命感，要求個人和團隊以傳遞完全內建和全面測試的軟體為榮。

在safe中，團隊至少每天執行一次本地內建，但同樣重要的是要将完整的系統進行內建，并在必要的時候運作回歸測試，以確定系統向期望的方向發展。在初期實作每日內建不太可行，是以合理的初始目标可能是，在每疊代中至少實作一到兩次全系統的內建。這樣也為成功地進行每兩周一次的系統示範提供了基線。

8.1節中提供了關于該主題的更多内容，特别是系統級和解決方案級的持續內建。

測試先行

測試先行是一種鼓勵團隊在代碼實作前深入思考系統行為的哲學。它提升了編碼的效率并使得産品更易于使用，它同時建立了一種更為全面的測試政策，由此系統的需求被轉化為一系列的測試案例，通常這些測試案例在編寫代碼前會事先寫好。

測試先行政策可細分為測試驅動開發（tdd）和接收測試驅動開發（atdd）。兩者都由自動化測試所支援，自動化測試是支援持續內建、團隊速度和開發有效性所必需的。

在測試驅動開發中，開發人員首先編寫自動化單元測試案例，執行測試案例并觀察其運作失敗，然後編寫一個最小的代碼用以通過測試。測試驅動開發主要适用于編碼方法或者單元（技術）層面，這保證了測試的真實存在，防止鍍金和編寫不必要的更複雜的代碼。同時，測試驅動開發還有助于保證需求能持續得到自動化測試，并保持最新的狀态。

接收測試驅動開發是一種先進的技術，表征系統行為的接收标準由産品負責人确定，然後将接收标準轉換為可反複執行的接收測試，在系統演進的過程中保證持續的一緻性。接收測試驅動開發有助于團隊專注于系統級别的、使用者可觀測的需求，這給團隊提供了清晰的成功标準。

8.2節中提供了關于該主題的更多内容。

重構

重構是“重組代碼的現有結構，改變其内部結構而不改變其外部行為的技術”（參考資料[3]）。靈活避免“大量的前期設計”（bufd），并遵從“即使在開發後期，也擁抱需求變

更”（參考資料[1]），這意味着目前的代碼庫在業務需要新增功能時是經得起考驗的。為了保持這種應變能力，團隊不間斷地通過一系列小的改進持續進行重構，為未來的發展打下堅實的基礎。如果因為“總是希望增加新功能”，而忽視重構，就會快速建構起一個僵化和不可維護的系統，最終導緻經濟效益越來越差。

重構是實作浮現式設計的關鍵，而且是靈活開發中必要和不可或缺的組成部分。有關重構的更多指導資訊，請參見“重構”的有關闡述。

結對工作

結對工作與結對程式設計相對應，結對程式設計是極限程式設計中的一種強制實踐，需要兩個程式員在同一台電腦上工作。一個人編碼，另一個人是觀察員，負責評審、檢查和為編碼過程增值，在結對過程中角色可以互換。在每寫一行代碼前，結對人員都要讨論需要做的事情，并達成對需求、設計、測試的一緻了解。觀察員檢查代碼，提出關于如何提高代碼的意見，并指出潛在的錯誤。結對程式設計中會進行實時的、全面的同行評審。

結對程式設計是極限程式設計的組成部分，但它也是有争議的，有些人認為結對增加了成本，因為兩個人在同樣的代碼上工作。同時，結對程式設計也可能面臨人際交往和文化上的挑戰。

對很多人而言，結對程式設計過于極端了。然而在實踐中，靈活團隊中有很多種不同的結對工作方式，每一種都有其價值，并且可以結合起來應用。有的團隊在所有編碼工作上都遵循結對程式設計标準，就像極限程式設計中所描述的那樣；有的團隊中開發人員與測試人員針對故事進行結對，在故事完成時評審彼此的工作；還有的團隊更傾向于自發的結對，開發人員在關鍵代碼片段、重構遺留代碼、開發接口定義以及系統級别內建等有挑戰性的工作上進行結對。結對工作是重構、持續內建、測試自動化，以及代碼集體所有權的重要基礎。

集體所有權

集體所有權“鼓勵每個人為項目的所有部分貢獻新的想法。任何開發人員都可以更改任意一行代碼去增加新的功能、修複缺陷、改進設計或重構。沒有人會成為變化的瓶頸”（參考資料[4]）。集體所有權在safe體系中尤為重要，因為大型系統擁有大型代碼庫，最初的開發人員很可能已經不在項目團隊中了。即使那些人還在團隊中，如果總是依賴某一個人去修改代碼，就會造成工作上的交接，也一定會帶來延遲等待。

擴充集體所有權的實施，需要在整個項目群中遵循經過驗證的、一緻商定的編碼标準，擁抱簡單的設計，揭示代碼結構中的意圖，并建立接口機制用于進行靈活的系統修改。

固件和硬體

除了編碼以外，沒人能夠擴充低品質的元件或系統。硬體元素都很少涉及“軟”的部分，比如電子、電氣、流體、光學、機械、包裝、熱能等，是以它們更加難以變更，而且如果發生變更會更為昂貴。如圖3.15-1所示（參考資料[5]），固件和硬體中的錯誤和未經證明的假設可能導緻更高的變更和返工成本。

如下文所述，這種更高的後期變更成本，促使網絡實體系統的精益開發人員使用一些相關實踐，確定在解決方案開發過程中的内建品質。

探索早期疊代

正如參考文獻[6]中所強調的，即使在建造“哈雷–戴維森摩托”時，也需要一個非常完整的團隊在道路上測試新的機車，更頻繁的設計周期是系統建構者的有效工具，它能夠用以加快對産品知識的掌握，降低風險和後期發現錯誤的成本。在這方面，safe使用與軟體相同的方式來處理固件和硬體，比如所涉及的疊代和項目群增量節奏，以及目标期望等都大緻相同。然而，早期的疊代是特别關鍵的，因為變更成本還沒有達到很高的水準。精益系統建構者應用“更軟”的工具系統展開更快的疊代，包括以下内容：

靈活架構

基于模型的系統工程

基于集合的設計

頻繁的系統級內建和測試

持續內建是許多軟體解決方案的一個有價值的、可實作的目标。然而，在網絡實體系統中卻難以應用甚至難以想象，因為有許多實體部件——模具、機械、小部件等，産品演變緩慢，而且無法每天進行內建和評估。但是，這不能成為延遲和難于進行內建的借口。

畢竟，最終所有不同的元件和子系統——軟體、固件、硬體等——必須內建到一起，才能提供有效的解決方案級的行為，而且越早越好。為此，精益系統建構者嘗試在早期頻繁地內建和測試子系統和完整系統。這通常需要增加在開發、部署、測試等基礎設施方面的投資。

設計驗證

然而，僅僅內建和測試是不夠的。首先，由于系統的各種元件在可用性方面的依賴，內建和測試可能在整個流程中發生得太晚；第二，內建和測試不可能覆寫所有可能的使用情況和失敗場景。為了解決這個問題，系統建構者執行設計驗證以確定設計滿足解決方案的意圖。設計驗證可以包括：諸如子系統之間需求的規範和分析的步驟，最差情況下的容忍度和性能分析，失敗模型和影響分析，可跟蹤性，熱分析，環境，以及其他系統級部署方面等。

在軟體領域，雖然設計驗證的諸多方法也很重要，但由于軟體的變更成本較低，是以在設計的選擇上不需要太多的事先承諾。然而，對于固件和硬體，需要前期設計方面的更多考慮，以及工作規範上的保證。

[1]　manifesto for agile software development. www.agilemanifesto.org.

[2]　beck, kent, and cynthia andres. extreme programming explained:

embrace change. addison-wesley, 2004.

[3]　fowler, martin. refactoring.com.

[4]　http://www.extremeprogramming.org/rules/collective.html.

[5]　rubin, ken.

http://www.innolution.com/blog/agile-in-a-hardware-firmware-environment-draw-the-cost-ofchange-curve.

[6]　oosterwal, dantar p. the lean machine: how harley-davidson drove

top-line growth and profitability with revolutionary lean product development.

amacom, 2010.