【正文】 然后慢慢地，部份人會開始喜歡結對編程的。要在重構的時候有充足的信心，就要有足夠的自動化測試覆蓋率。 你們能夠在自動化端對端系統(tǒng)測試和自動化單元測試之間保持平衡嗎？ 團隊的任務版和燃盡圖都能夠很容易地被團隊看見和使用嗎？ 有沒有一些事情團隊會覺得不舒服而避免討論的？（詳見：Crucial Conversations: Tools for Talking When Stakes are High）或者引入專家來緩解不安的談話情緒。 是否所有人（包括股東和團隊）都知道目前的團隊速率是否能夠趕上發(fā)布的計劃呢？ 你是否已經(jīng)讓你的Product Owner了解什么是技術債務以及如何避免嗎？其中一個方法就是把自動化測試和重構這兩項任務加入到每個待辦事列表項目的完成的定義中。（需要注意的是只有Product Owner才能給待辦事列表里面的項目排列優(yōu)先級。在這種情況下，團隊仍然有可能達到預期的目標，而且有可能不會發(fā)生什么重大事故。每個 Sprint 的目標都是交付遵循 Scrum 團隊當前的“完成”定 義的潛在可交付功能增量。一個自組織的團隊有一個非常明顯的每天的節(jié)奏：Daily Scrum之前非常安靜，每日站會之后會有一段活躍的討論，到中餐前的時候就慢慢安靜下來了。如果你遵守了規(guī)則并按照正確的方式開會，你就不需要再擔心超時了。 團隊成員互相交流，不是向ScrumMaster報告。Scrum的最基本原則是“Inspect and Adapt”(檢視然后適應)，如果什么事情做得很好，問問自己為什么，然后尋找提升的辦法。 團隊成員不會在會上討論或者解決問題，大家會把問題記錄下來，會后找相關的人討論或召開具體的討論會議。 對于跨國界的團隊，存在時間差的情況，可以根據(jù)實際情況做調整。 團隊商量決定誰做什么（不能有領導任務指派），為當天排一個計劃花在它們身上的工作會迅速貶值,所以需要頻 繁地重估。只有產(chǎn)品負責人才有取消 Sprint 的權 力,但他做這樣的決定也可能是受到利益干系人、團隊或是 Scrum Master 的影響。越來越多的團隊使用2周的Sprint，很多市場變化快、競爭激烈的領域，比如互聯(lián)網(wǎng)和移動互聯(lián)網(wǎng)產(chǎn)品開發(fā)團隊也會使用1周的迭代。Scrum是一種迭代和增量式的產(chǎn)品開發(fā)方法，Scrum通過Sprint來實現(xiàn)迭代。2. 估算大小，而不是估算時間周期，使用相對估算，而不是絕對估算一瓶礦泉水，讓一個3歲的小妹妹把它喝完所花的時間和一個成年人把它喝完所花的時間肯定不一樣，因此同一項工作，不同能力的人完成它花費的時間顯然是不一樣的。 當團隊理解了這個條目之后，每個團隊成員按照自己的想法給出估算結果，并且選擇對應的撲克出牌，估算結果不能告訴其他人，出牌時數(shù)字朝下扣在桌面上。估算撲克由一組類似斐波納契數(shù)列的數(shù)字組成，這些數(shù)字包括：0，,1,2,3,5,8,20,40,?,∞, 每幅撲克有四組這樣的數(shù)字，可供4個人使用。一個讓用戶故事有價值的好方法是讓客戶來寫下它們。通常我們可以通過組合用戶故事和分解用戶故事來減少依賴性。一個好的用戶故事包括三個要素：1. 角色：誰要使用這個功能。 跨職能、完整團隊這種團隊組織的方式，我們稱之為組件團隊，是指每個團隊只是完成系統(tǒng)功能的某一個部件，而不是一個端到端用戶可見的功能。 誤解4：自組織團隊不需要管理者； 糾正：管理者從微觀管理轉向目標驅動、授權團隊的管理方式 確定團隊目標和愿景對于經(jīng)理領導的團隊來說，管理者除了要確定目標、方向，團隊的上下文（組織結構、團隊結構、團隊組成），還需要監(jiān)督和管理團隊的過程和進度，分配任務即確定誰做什么。 專注、投入 每個迭代對產(chǎn)品和團隊的工作過程做檢查和調整開發(fā)團隊有如下10方面的特征：Scrum中的Scrum Master鼓手的角色，他幫助團隊保持高昂的士氣，并進行良好的協(xié)作，他是一個Scrum的專家，團隊的教練，團隊的服務式領導。高優(yōu)先級的需求驅動在Scrum中，我們使用Product Backlog來管理需求，Product Backlog是一個需求的清單，Product Backlog中的需求是漸進明細的，Backlog當中的條目必須按照商業(yè)價值的高低排序。SCRUM的五個價值觀1. 承諾 – 愿意對目標做出承諾2. 專注– 把你的心思和能力都用到你承諾的工作上去3. 開放– Scrum 把項目中的一切開放給每個人看4. 尊重– 每個人都有他獨特的背景和經(jīng)驗5. 勇氣– 有勇氣做出承諾，履行承諾，接受別人的尊重SCRUM的四大支柱迭代開發(fā)在Scrum的開發(fā)模式下，我們將開發(fā)周期分成多個14周的迭代，每個迭代都交付一些增量的可工作的功能。通常會演?示產(chǎn)品增量,整個小組也會經(jīng)常討論他們在Sprint中觀察到了什么、有哪些新的產(chǎn)品想法出現(xiàn)。Scrum活動:Sprint評審會議Sprint結束時,Scrum團隊和相關?人員一起評審Sprint的產(chǎn)出。它是一個開發(fā) 團隊內部的溝通會議,來保證他們對現(xiàn)狀有一致的了解。開發(fā)團隊通過每日Scrum會議來確認他們仍然可以實現(xiàn)Sprint的目標。決定如何完成工作是開發(fā)團隊的職責,決定做什么則是產(chǎn)品負責人的職責。做多少工作只能由開發(fā)團隊決定。針對排好序的產(chǎn)品待辦事項列表(Product Backlog),產(chǎn) 品負責人和開發(fā)團隊成員討論每個事項,并對該事項達成共識,包括根據(jù)當前的“完成的定 義”,為了完成該事項所需要完成的所有事情。為此,梳理時會特別關注那些即將被實現(xiàn)的事項。SCRUM的五個活動Scrum活動:產(chǎn)品待辦事項列表梳理產(chǎn)品待辦事項通常會很大,也很寬泛,而且想法會變來變去、優(yōu)先級也會變化,所以產(chǎn)品待 辦事項列表梳理是一個貫穿整個Scrum項目始終的活動。燃盡圖（BURNDOWN CHART)Sprint燃盡圖（Sprint Burndown Chart)Sprint Burndown Chart 顯示了Sprint中累積剩余的工作量，它是一個反映工作量完成狀況的趨勢圖。2. 程序缺陷做為新的任務加進來，這個都做為承諾提交任務中未完成的工作。Sprint 代辦事項列表是一份足夠具體的計劃,使得進度上的改變能在每日例會中得到 理解。各種趨勢燃盡圖、燃燒圖和其他計劃實踐都能用來預測進度。產(chǎn)品負責人可以通過協(xié)助團隊權衡取舍來影響他們的 決定。這是一個持續(xù)不斷 的過程,產(chǎn)品負責人和開發(fā)團隊協(xié)作討論產(chǎn)品代表事項列表條目的細節(jié)。開發(fā)團隊在一個 Sprint 中可以“完 成”的產(chǎn)品待辦事項列表條目被認為是“準備好的”或者“可執(zhí)行的”,能在 Sprint 計 劃會議中被選擇。產(chǎn)品待辦事項列表通常以價值、風險、優(yōu)先級和必須性排序。Product Backlog – 產(chǎn)品待辦事項列表產(chǎn)品待辦事項列表是一個排序的列表,包含所有產(chǎn)品需要的東西,也是產(chǎn)品需求變動的唯一來源。 按需推動Scrum活動 清晰地和開發(fā)團隊溝通愿景、目標和產(chǎn)品代表事項列表條目產(chǎn)品負責人和 Scrum Master 的角色不包含在此數(shù)字中,除非他們也參與執(zhí)行 Sprint 代表事項列表中的工作。所產(chǎn)生的協(xié)同工作能最大化 開發(fā)團隊的整體效率和效力。產(chǎn)品負責人是一個人,而不是一個委員會。產(chǎn)品負責人是管理產(chǎn)品待辦事項列表的唯一責任人。Scrum 團隊是自組織、跨職能的完整團隊。在確定檢驗頻率時，需要考慮到檢驗會引起所有過程發(fā)生變化。 “在過程運行機制相當簡單易懂的情況下，典型的做法是采用預定義的建模方式。我們所熟知的是預定義的過程，它通常是使用已知的方法解決已知的問題。1995年Jeff Sutherland和Ken Schwaber規(guī)范化了Scrum框架，并在OOPSLA 95上公開發(fā)布。爭球雙方各有8個隊員參與，各方出3名前鋒隊員，并肩各站成一橫排，面對面躬身互相頂肩，中間形成一條通道，其他前鋒隊員分別站在后面，后排隊員用肩頂住前鋒隊員的臀部，組成3或1陣形。當規(guī)定的檢驗頻率超出了過程檢驗所能容許的程度，那么就會出現(xiàn)問題。經(jīng)驗主義主張知識源于經(jīng)驗, 以及基于已知的東西做決定。在這個框架中，整個開發(fā)過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，每個Sprint的建議長度是2到4周(互聯(lián)網(wǎng)產(chǎn)品研發(fā)可以使用1周的Sprint)。在每個迭代結束時，Scrum團隊將遞交潛在可交付的產(chǎn)品增量。也就是說，當某個人在檢驗一個過程，并確信某一個任務已經(jīng)完成時，這個完成必須等同于他們對完成的定義。Scrum中通過三個活動進行檢驗和適應：每日例會檢驗Sprint目標的進展，做出調整，從而優(yōu)化次日的工作價值；Sprint評審和計劃會議檢驗發(fā)布目標的進展，做出調整，從而優(yōu)化下一個Sprint的工作價值；Sprint回顧會議是用來回顧已經(jīng)完成的Sprint，并且確定做出什么樣的改善可以使接下來的Sprint更加高效、更加令人滿意，并且工作更快樂。如下圖所示，軟件開發(fā)活動通常處在下圖的很復雜的區(qū)域。圖－02如果我們期望解決的問題比較復雜，并且存在著較大的不確定性的時候，我們需要使用經(jīng)驗性過程。 管理生產(chǎn)成果的人不僅要能夠看到過程的這些方面，而且必須理解他們看到的內容。調整工作必須盡快實施，以減少進一步的偏差。增量交付潛在可交付的產(chǎn)品增量保證了 每個迭代都有潛在可發(fā)布的版本。 確保產(chǎn)品代辦事項列表對所有人可見、透明、清晰,并且顯示 Scrum 團隊的下一步工作Scrum角色之：開發(fā)團隊開發(fā)團隊包含了專業(yè)人員,負責在每個 Sprint 的結尾交付潛在可發(fā)布的“完成”產(chǎn) 品增量。小團隊在 Sprint 中可能會 受到技能限制,從而導致無法交付可發(fā)布的產(chǎn)品增量。 Scrum Master 通過改變這些交互來最大化 Scrum 團隊所創(chuàng)造的價值。 指導開發(fā)團隊自組織和跨職能 發(fā)起能提升Scrum 團隊生產(chǎn)力的變革只要產(chǎn)品存在,產(chǎn)品待辦事項列表就存在。根據(jù)更清晰的內容和 更詳盡的信息就能做出更準確的估算。但描述下一步產(chǎn)品開發(fā)工作的產(chǎn)品待辦事項列表只能有一個。然而,何時如何完成優(yōu)化是 Scrum 團隊的決定。這份信息對所有的干系人都透明。Sprint 代辦事項列表是開發(fā)團隊對于哪些功能要包 含在下個增量中,以及交付那些功能所需工作的預計。在 Sprint 內只有開發(fā)團隊可以對 Sprint 待辦事項列表進行修改。通過在 Sprint 中不斷追蹤剩余工作,開發(fā)團隊可以管理自己 的進度。發(fā)布燃盡圖（Release Burndown Chart）在Scrum項目中，團隊通過每個Sprint結束時更新的發(fā)布燃盡圖來跟蹤整個發(fā)布計劃的進展。 將事項分解成更小的事項因此,產(chǎn)品待辦事項列表梳理最好是所有團隊成員都參與的活動,而不單單是產(chǎn)品負責人。在Scrum中,Sprint計劃會議有兩部分:1. 決定在Sprint中需要完成哪些工作2. 決定這些工作如何完成第一部分:需要完成哪些工作?在會議的第一部分,產(chǎn)品負責人向開發(fā)團隊介紹排好序的產(chǎn)品待辦事項,整個Scrum團隊共同理解這些工作。他們進?行?足夠的設計和計劃,從而有信心可以在Sprint中完成所有工作。 總而?言之:在Sprint計劃會議中,開發(fā)團隊和產(chǎn)品負責人一起考慮并討論產(chǎn)品待辦事項,確保他們對這些事項的理解,選擇一些他們預測能完成的事項,創(chuàng)建足夠詳細的計劃來確保他們能夠完成這些事項。每日Scrum中可能有簡要的問題澄清和回答,但是不應該有任何話題的討論。它能幫助 快速發(fā)現(xiàn)問題,并促進團隊的自組織和自?立。每個?人都可以在Sprint評審會議 上發(fā)表意?見。團隊識別出哪些做得好,哪些做得不好,并找出潛在 的改進事項,為將來的改進制定計劃。無論產(chǎn)品負責人是否決定真正發(fā)布它,增量必須可用。但是，在Scrum的工作方式下，總共只有三個角色， 這三個角色分別是產(chǎn)品負責人（PO）,Scrum Master和開發(fā)團隊。 梳理產(chǎn)品Backlog 最大限制的溝通自組織團隊也叫做自管理團隊、或者被授權的團隊。 團隊需要在確保目標的前提下制定團隊內的行為準則 誤解1：團隊自己決定目標是什么 ； 糾正：管理層決定團隊目標特性團隊如果我們的產(chǎn)品開發(fā)團隊只有在10人以內，我們使用一個跨職能