【正文】 隊目標，團隊決定如何實現(xiàn)目標一個自組織的團隊通常由不同職能專業(yè)、思考方式和行為模式的成員組成，也就是說它是跨職能的團隊。打造自組織團隊，首先要讓團隊需要完全自主； 其次，有了自主，管理者需要引導(dǎo)團隊持續(xù)改進，幫助團隊持續(xù)地挑戰(zhàn)更高的目標；第三，給團隊提供環(huán)境和支持，引導(dǎo)團隊往正確地方向邁進。 但是，如果產(chǎn)品團隊規(guī)模較大，比如是幾十人，甚至幾百人的開發(fā)團隊的時候，我們就需要考慮團隊的結(jié)構(gòu)和組織方式。這種團隊組織的方式，我們稱之為組件團隊，是指每個團隊只是完成系統(tǒng)功能的某一個部件，而不是一個端到端用戶可見的功能。第二：每個團隊專注在自己的模塊，由于各模塊、或分層需求工作量的不同，很容易產(chǎn)生等待，并且容易產(chǎn)生低價值的交付。這種以用戶為中心的團隊叫做特性團隊。 長期穩(wěn)定的團隊，逐個端到端完成客戶特性 跨職能、完整團隊 擁有通用型專家特性團隊看起來像這個樣子：特性團隊的好處： 比較容易在一個Sprint中交付可用的產(chǎn)品增量 責(zé)任范圍的擴大，各種不同領(lǐng)域的專家在一個團隊，增加了一個好的用戶故事包括三個要素：1. 角色：誰要使用這個功能。3. 商業(yè)價值：為什么需要這個功能，這個功能帶來什么樣的價值?！毙枰⒁獾氖怯脩艄适虏荒軌蚴褂眉夹g(shù)語言來描述，要使用用戶可以理解的業(yè)務(wù)語言來描述。 卡片（Card） – 用戶故事一般寫在小的記事卡片上。用戶故事的六個特性 INVESTINVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable一個好的用戶故事應(yīng)該遵循INVEST原則。 獨立性（Independent）— 要盡可能的讓一個用戶故事獨立于其他的用戶故事。通常我們可以通過組合用戶故事和分解用戶故事來減少依賴性。 可協(xié)商性（Negotiable）— 一個用戶故事的內(nèi)容要是可以協(xié)商的，用戶故事不是合同。具體的細節(jié)在溝通階段產(chǎn)出。一個讓用戶故事有價值的好方法是讓客戶來寫下它們。但是讓開發(fā)者難以估計故事的問題來自：對于領(lǐng)域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。 短?。⊿mall）— 一個好的故事在工作量上要盡量短小，最好不要超過10個理想人/天的工作量,至少要確保的是在一個迭代或Sprint中能夠完成。如果一個用戶故事不能夠測試，那么你就無法知道它什么時候可以完成。敏捷估算無論是團隊研發(fā)一款產(chǎn)品或者開發(fā)某一個項目，我們都需要回答“我們大概什么時間能夠完成？”， 或者到某一個時間點，我們能夠做到什么程度， 因此和傳統(tǒng)的開發(fā)模式一樣，我們在工作開始之前需要對我們需要做的事情進行工作量的估算。集體估算，通常采用估算撲克作為工具，團隊通過玩估算游戲進行集體估算。估算撲克由一組類似斐波納契數(shù)列的數(shù)字組成，這些數(shù)字包括：0，,1,2,3,5,8,20,40,?,∞, 每幅撲克有四組這樣的數(shù)字，可供4個人使用。 每個團隊成員拿到一組卡片，包括0,1,2,3,5,8,13,20,40,?,∞,共計12張。 產(chǎn)品負責(zé)人或者一名團隊成員扮演閱讀者的角色，他負責(zé)閱讀需要估算產(chǎn)品Backlog的條目，并且詢問大家是否有疑問。 團隊討論這個條目。 當團隊理解了這個條目之后，每個團隊成員按照自己的想法給出估算結(jié)果，并且選擇對應(yīng)的撲克出牌，估算結(jié)果不能告訴其他人，出牌時數(shù)字朝下扣在桌面上。 所有人都出牌之后，閱讀者向大家確認是否都已經(jīng)確定估算結(jié)果，確認后，數(shù)”1,2,3″,大家同時展示估算結(jié)果。 ？我們是否存在分歧？有沒有什么是我沒有考慮到的？討論之后可以再估算一輪，最終團隊需要達成一致。 回到第二步，開始估算下一個條目。2. 估算大小，而不是估算時間周期，使用相對估算，而不是絕對估算一瓶礦泉水，讓一個3歲的小妹妹把它喝完所花的時間和一個成年人把它喝完所花的時間肯定不一樣，因此同一項工作，不同能力的人完成它花費的時間顯然是不一樣的。敏捷估算時，我們不會估算絕對時間和周期，我們估算大小，和相對值，也就是倍數(shù)。3. 記錄每個Sprint的團隊速度團隊速率是一個Scrum團隊在一個Sprint中實際完成的故事點數(shù)，通過團隊速率可以知道團隊做的有多快。在Sprint執(zhí)行過程中，我們要記錄每個Sprint的速度，為以后的計劃做參考。Scrum是一種迭代和增量式的產(chǎn)品開發(fā)方法，Scrum通過Sprint來實現(xiàn)迭代。Sprint的長度一旦確定，保持不變。Sprint 在整個開發(fā)過程中的周期一致。 ?Sprint 包含并由 Sprint 計劃會議、每日站會、開發(fā)工作、Sprint 評審會議和 Sprint 回顧會議構(gòu)成。越來越多的團隊使用2周的Sprint，很多市場變化快、競爭激烈的領(lǐng)域，比如互聯(lián)網(wǎng)和移動互聯(lián)網(wǎng)產(chǎn)品開發(fā)團隊也會使用1周的迭代。 Sprint的目標 開發(fā)團隊的組成集中優(yōu)勢兵力各個擊破在Sprint執(zhí)行的過程中，團隊要避免一個蘿卜一個坑的工作方式，團隊要協(xié)作，并且要集中優(yōu)勢兵力各個擊破。按照這樣的方式一方面可以加強團隊協(xié)作，另外也有利于及早完成一些需求，讓這些需求及早驗收。只有產(chǎn)品負責(zé)人才有取消 Sprint 的權(quán) 力,但他做這樣的決定也可能是受到利益干系人、團隊或是 Scrum Master 的影響。比如公司的發(fā)展方向, 或是市場、技術(shù)等情況發(fā)生了變化,這些變化都可能導(dǎo)致取消 Sprint。然而,因為 Sprint 周期都較短,所以很少發(fā)生取消 Sprint 的情況。假如有些條目已經(jīng)潛在可交付,那產(chǎn)品負責(zé)人就會采納它。花在它們身上的工作會迅速貶值,所以需要頻 繁地重估。Sprint 終止通常會對團隊造成重創(chuàng),因此這種情況也非常少見。每日站會每日站會的目的在介紹如何開每日站會前， 讓我們先了解一下召開每天的站會的目的和意義是什么？敏捷宣言強調(diào)個體交互重于過程和工具，敏捷原則闡述了面對面的溝通和自組織的團隊這些敏捷的核心思想。Scrum的理論基礎(chǔ)是通過保持過程透明性讓參與過程的所有人了解真實狀況，然后進行檢查和調(diào)整，每日站會是Scrum過程進行每天的檢查和調(diào)整的環(huán)節(jié)。 團隊商量決定誰做什么（不能有領(lǐng)導(dǎo)任務(wù)指派），為當天排一個計劃 團隊回顧昨天的工作，做調(diào)整，持續(xù)改進什么時候、在什么地點開每日站會？Scrum定義了開展每日站會的一些基本的規(guī)則。 任務(wù)板上可以看到當前Sprint的燃盡圖（Burn Down Chart）和Sprint中每個任務(wù)的狀態(tài)。這樣的好處是在開會的時候，每個人都可以看到當前的進展情況。對于跨國界的團隊，存在時間差的情況，可以根據(jù)實際情況做調(diào)整。所有的團隊成員自覺按時到場，因為會議很短，按時召開按時結(jié)束是很重要的。每日站會一定要站著開，每個人要精神集中，不能有懶散的表現(xiàn)。一些的確需要討論的問題，可以先記錄下來，會后作為專題來討論。 不會有ScrumMaster或者其他任何人來指派任務(wù)。3. 團隊成員不會在會上討論或者解決問題，大家會把問題記錄下來，會后找相關(guān)的人討論或召開具體的討論會議。Scrum的最基本原則是“Inspect and Adapt”(檢視然后適應(yīng))，如果什么事情做得很好，問問自己為什么，然后尋找提升的辦法。所以第一步，你可以先按照書本上的方式來做。2. 團隊成員互相交流，不是向ScrumMaster報告。如果你遵守了規(guī)則并按照正確的方式開會，你就不需要再擔(dān)心超時了。一個自組織的團隊有一個非常明顯的每天的節(jié)奏：Daily Scrum之前非常安靜，每日站會之后會有一段活躍的討論，到中餐前的時候就慢慢安靜下來了。這就是一個自組織團隊的脈沖?！巴瓿伞钡亩x當產(chǎn)品代辦事項列表條目或者增量被描述為“完成”的時候,每個人都必須理解“完 成”意味著什么。這就是 Scrum 團隊的“完成” 定義,用來評估產(chǎn)品增量在什么時候完成。每個 Sprint 的目標都是交付遵循 Scrum 團隊當前的“完成”定 義的潛在可交付功能增量。這個增量是可用的,所以產(chǎn)品負責(zé)人可以選擇立即發(fā)布它。隨著 Scrum 團隊的成熟,我們預(yù)期“完成”的定義會擴大,包含更嚴厲標準來保證高質(zhì)量。SCRUM MASTER檢查單一位合格的ScrumMaster通常能夠同時處理2到3個團隊的事務(wù)。在這種情況下，團隊仍然有可能達到預(yù)期的目標，而且有可能不會發(fā)生什么重大事故。一位出色的ScrumMaster一次能夠負責(zé)一個團隊。如果你還沒有發(fā)現(xiàn)你能夠做的事情的話，嘗試聆聽Product Owner，團隊還有團隊以外的公司成員的想法。Product Owner干得怎么樣？（需要注意的是只有Product Owner才能給待辦事列表里面的項目排列優(yōu)先級。 產(chǎn)品待辦事列表里面的項目已經(jīng)根據(jù)Product Owner的最新想法排好優(yōu)先級了嗎？是不是所有來自股東的需求都已經(jīng)被待辦事列表中的項目涵蓋了？要記得待辦事列表是涌現(xiàn)的。 產(chǎn)品待辦事列表的大小是否還能夠維護呢？為了使列表更容易維護，應(yīng)該將細粒度的項目放在靠前的位置，而把粗粒度的項目放在底部。 你是否已經(jīng)讓你的Product Owner了解什么是技術(shù)債務(wù)以及如何避免嗎？其中一個方法就是把自動化測試和重構(gòu)這兩項任務(wù)加入到每個待辦事列表項目的完成的定義中。 待辦事列表是不是能讓所有股東都能夠看懂？ 你能夠通過制訂可視化圖表來傳達足夠的信息嗎？ 是否所有人（包括股東和團隊）都知道目前的團隊速率是否能夠趕上發(fā)布的計劃呢？你可以在每個Sprint評審會議的時候給大家展示Mike Cohn的產(chǎn)品和版本燃盡圖，這樣就可以更早地發(fā)現(xiàn)當前的進度是不是能夠符合預(yù)期。 團隊成員是否在大多數(shù)時間里都能夠進入“流”的狀體？下面是這種狀態(tài)的一些特征（摘錄自Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi）：有清晰的目標（）；集中且專注，高度集中在某個特定的領(lǐng)域或事物上；失去自我意識，完全沉浸在動作和興趣中；扭曲的時間感受，只能感受到主觀世界的時間；直接和立即的反饋（無論是成功還是失敗都能夠馬上感知到，以馬上對行為進行調(diào)整）；在能力和挑戰(zhàn)之間保持平衡；自我的控制能力；行為能夠從本質(zhì)上有所回報，所以感覺毫不費力。 團隊成員之間相處得怎么樣？氣氛融洽嗎？有為彼此的成功感到高興嗎？ 有沒有一些事情團隊會覺得不舒服而避免討論的？（詳見：Crucial Conversations: Tools for Talking When Stakes are High）或者引入專家來緩解不安的談話情緒。 有沒有試過以不同方式或者在不同地點舉行Sprint回顧會議？詳見：Agile Retrospectives: Making Good Teams Great (Esther Derby/Diana Larsen) 團隊的任務(wù)版和燃盡圖都能夠很容易地被團隊看見和使用嗎？ 團隊能夠被保護得足夠好而避免微管理嗎？ 團隊成員會在團隊的房間外忽略自己的職稱嗎？ 你們正在開發(fā)的系統(tǒng)有“開始測試”按鈕能讓每個都很容易地察覺到自己是否破壞了某些功能呢？通常這個是靠xUnit框架來實現(xiàn)的（JUnit，NUnit等等）。 你們能夠在自動化端對端系統(tǒng)測試和自動化單元測試之間保持平衡嗎？ 你們的持續(xù)集成服務(wù)器能夠在回歸測試出現(xiàn)錯誤的一個小時（或者一分鐘）內(nèi)自動發(fā)出警報嗎？ 團隊能夠發(fā)現(xiàn)持續(xù)設(shè)計和無情的重構(gòu)，而不是一開始就進行詳細的設(shè)計帶來的樂趣嗎？重構(gòu)擁有一個嚴格的定義：改變系統(tǒng)的內(nèi)部結(jié)構(gòu)而不改變其外部行為。要在重構(gòu)的時候有充足的信心，就要有足夠的自動化測試覆蓋率。但是有時候結(jié)對編程實在挑戰(zhàn)大家的極限，有時候甚至?xí)雇瓿扇蝿?wù)的時間變長（如果我們更重視數(shù)量而不是質(zhì)量的話）。然后慢慢地，部份人會開始喜歡結(jié)對編程的。 團隊之間有沒有適當?shù)亟涣骱献髂兀縎crum of Scrums是唯一的解決方案。 來自公司內(nèi)部的困難會在適當?shù)臅r候被貼到開發(fā)總監(jiān)的辦公室的墻上嗎？成本能夠以金錢、丟失市場的份額、損失的質(zhì)量或者損失的客戶來量化嗎？ 你的公司已經(jīng)被外界認定為最好的工作場所或者業(yè)界的領(lǐng)頭羊了嗎？恐懼是你的朋友, 一旦你開始意識到你能夠做些事情來改變現(xiàn)狀，你可能會感到恐懼而退縮。