【正文】 就可以啟動Sprint了，而不必等到所有的需求都細化之后。十、 SCRUM團隊在傳統(tǒng)的工作方式下，開發(fā)團隊會有很多不同的角色，比如項目經(jīng)理、產(chǎn)品經(jīng)理、架構(gòu)師、設(shè)計師、用戶體驗設(shè)計師，程序員，測試人員，DBA等等。我們通?？梢砸詣濤堉鄣膱F隊角色來類比Scrum的角色，劃龍舟通常有舵手、鼓手、劃槳團隊三個角色。Scrum中的Scrum Master鼓手的角色，他幫助團隊保持高昂的士氣，并進行良好的協(xié)作，他是一個Scrum的專家，團隊的教練，團隊的服務(wù)式領(lǐng)導(dǎo)。Scrum的開發(fā)團隊對實現(xiàn)Sprint目標(biāo)需要做的所有事情負責(zé)，包括技術(shù)方案和決策，團隊分工（誰做什么），執(zhí)行Sprint開發(fā)任務(wù)等，而且作為自組織的團隊，他們也對他們的工作進度的跟蹤和管理負責(zé)。 執(zhí)行Sprint 做Sprint計劃 每個迭代對產(chǎn)品和團隊的工作過程做檢查和調(diào)整開發(fā)團隊有如下10方面的特征： 多元化、跨職能的完整團隊 持續(xù)改進 透明溝通 專注、投入 團隊長期存在，人員穩(wěn)定十一、 自組織團隊敏捷宣言的原則中提到 :“最好的架構(gòu)、需求和設(shè)計出于自組織團隊 ”。團隊被授權(quán)自己管理他們的工作過程和進度、并且團隊決定如何完成工作。對于經(jīng)理領(lǐng)導(dǎo)的團隊來說，管理者除了要確定目標(biāo)、方向，團隊的上下文（組織結(jié)構(gòu)、團隊結(jié)構(gòu)、團隊組成），還需要監(jiān)督和管理團隊的過程和進度，分配任務(wù)即確定誰做什么。對于自組織團隊來說，他們擁有如下權(quán)利： 團隊決定如何做，如何實現(xiàn)目標(biāo)，即團隊做技術(shù)決策 團隊有義務(wù)保持過程的透明性 確定團隊目標(biāo)和愿景 提供環(huán)境和支持（安全感、良好的團隊空間、氛圍，技能輔導(dǎo)等） 訓(xùn)練協(xié)作對于自組織團隊的普遍誤解： 誤解2：團隊自己決定誰進入團隊； 糾正：管理層決定團隊上下文 誤解4：自組織團隊不需要管理者； 糾正：管理者從微觀管理轉(zhuǎn)向目標(biāo)驅(qū)動、授權(quán)團隊的管理方式 誤解6：自組織團隊想干什么就干什么； 糾正：管理層決定團隊目標(biāo)，團隊決定如何實現(xiàn)目標(biāo)一個自組織的團隊通常由不同職能專業(yè)、思考方式和行為模式的成員組成，也就是說它是跨職能的團隊。打造自組織團隊，首先要讓團隊需要完全自主； 其次，有了自主，管理者需要引導(dǎo)團隊持續(xù)改進，幫助團隊持續(xù)地挑戰(zhàn)更高的目標(biāo)；第三，給團隊提供環(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)域的專家在一個團隊，增加了個人學(xué)習(xí)和團隊學(xué)習(xí)的機會十三、 用戶故事什么是用戶故事？用戶故事是從用戶的角度來描述用戶渴望得到的功能。2. 活動：需要完成什么樣的功能。用戶故事通常按照如下的格式來表達：英文：As a , I want to , so that .中文：作為一個角色, 我想要活動, 以便于商業(yè)價值舉例：作為一個“網(wǎng)站管理員”，我想要“統(tǒng)計每天有多少人訪問了我的網(wǎng)站”，以便于“我的贊助商了解我的網(wǎng)站會給他們帶來什么收益。Ron Jeffries的3個C關(guān)于用戶故事，Ron Jeffries用3個C來描述它：卡片上可能會寫上故事的簡短描述，工作量估算等。 交談（Conversation） 用戶故事背后的細節(jié)來源于和客戶或者產(chǎn)品負責(zé)人的交流溝通。 確認（Confirmation） 通過驗收測試確認用戶故事被正確完成。 獨立性（Independent）— 要盡可能的讓一個用戶故事獨立于其他的用戶故事。通常我們可以通過組合用戶故事和分解用戶故事來減少依賴性。 可協(xié)商性（Negotiable）— 一個用戶故事的內(nèi)容要是可以協(xié)商的，用戶故事不是合同。具體的細節(jié)在溝通階段產(chǎn)出。一個讓用戶故事有價值的好方法是讓客戶來寫下它們。但是讓開發(fā)者難以估計故事的問題來自：對于領(lǐng)域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。 短小（Small）— 一個好的故事在工作量上要盡量短小，最好不要超過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的條目，并且詢問大家是否有疑問。 團隊討論這個條目。 當(dāng)團隊理解了這個條目之后，每個團隊成員按照自己的想法給出估算結(jié)果，并且選擇對應(yīng)的撲克出牌，估算結(jié)果不能告訴其他人，出牌時數(shù)字朝下扣在桌面上。 所有人都出牌之后，閱讀者向大家確認是否都已經(jīng)確定估算結(jié)果，確認后，數(shù)”1,2,3″,大家同時展示估算結(jié)果。 ？我們是否存在分歧？有沒有什么是我沒有考慮到的？討論之后可以再估算一輪，最終團隊需要達成一致。 回到第二步，開始估算下一個條目。2. 估算大小，而不是估算時間周期，使用相對估算，而不是絕對估算一瓶礦泉水，讓一個3歲的小妹妹把它喝完所花的時間和一個成年人把它喝完所花的時間肯定不一樣，因此同一項工作，不同能力的人完成它花費的時間顯然是不一樣的。敏捷估算時，我們不會估算絕對時間和周期，我們估算大小，和相對值，也就是倍數(shù)。3. 記錄每個Sprint的團隊速度團隊速率是一個Scrum團隊在一個Sprint中實際完成的故事點數(shù)，通過團隊速率可以知道團隊做的有多快。在Sprint執(zhí)行過程中，我們要記錄每個Sprint的速度，為以后的計劃做參考。十五、 SPRINGScrum是一種迭代和增量式的產(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的目標(biāo) 開發(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é)人就會采納它?；ㄔ谒鼈兩砩系墓ぷ鲿杆儋H值,所以需要頻 繁地重估。Sprint 終止通常會對團隊造成重創(chuàng),因此這種情況也非常少見。Scrum的團隊是一個自組織的團隊，團隊每天進行每日站會是團隊面對面溝通和團隊自組織的體現(xiàn)。每日站會是團隊自己的會 團隊溝通狀態(tài)，了解現(xiàn)狀，發(fā)現(xiàn)障礙每日站會必須每天在同一時間、同一地點召開，最好的方式是在團隊的可視化的任務(wù)板前面召開。在每日站會開始之前，團隊需要在任務(wù)板上更新任務(wù)的狀態(tài)。每日站會是Scrum團隊每天的第一件事情，這樣可以讓每個人在每天一開始就清楚的了解他一天的安排。每日站會的紀律會議時間最多不超過15分鐘。團隊需要建立他們的工作協(xié)議來確保團隊成員按時出席，并且遵守站會紀律，比如團隊可以商量對于遲到的人員要有一些讓他們改進的措施，比如適當(dāng)?shù)慕o一些罰金，多少由團隊共同決定，這些錢如何支配也由團隊共同決定， 或者做俯臥撐、掛一個遲到的牌子等等。每個人回答三個問題：我昨天完成了什么任務(wù)？我今天打算做什么任務(wù)？我遇到了哪些障礙或困難？同一時間只能有一個人發(fā)言，會上只說和這三個問題相關(guān)的話題，任何跑題的討論，需要被ScrumMaster制止。為什么每日站會沒有效果？每日站會和傳統(tǒng)的項目會議有如下幾點不同： Master或者其他任何人來指派任務(wù)。，大家會把問題記錄下來，會后找相關(guān)的人討論或召開具體的討論會議。Scrum的最基本原則是“Inspect and Adapt”(檢視然后適應(yīng))，如果什么事情做得很好，問問自己為什么，然后尋找提升的辦法。所以第一步，你可以先按照書本上的方式來做。，不是向ScrumMaster報告。如果你遵守了規(guī)則并按照正確的方式開會，你就不需要再擔(dān)心超時了。一個自組織的團隊有一個非常明顯的每天的節(jié)奏：Daily Scrum之前非常安靜，每日站會之后會有一段活躍的討論，到中餐前的時候就慢慢安靜下來了。這就是一個自組織團隊的脈沖。十七、 “完成”的定義當(dāng)產(chǎn)品代辦事項列表條目或者增量被描述為“完成”的時候,每個人都必須理解“完 成”意味著什么。這就是 Scrum 團隊的“完成” 定義,用來評估產(chǎn)品增量在什么時候完成。每個 Sprint 的目標(biāo)都是交付遵循 Scrum 團隊當(dāng)前的“完成”定 義的潛在可交付功能增量。這個增量是可用的,所以產(chǎn)品負責(zé)人可以選擇立即發(fā)布它。隨著 Scrum 團隊的成熟,我們預(yù)期“完成”的定義會擴大,包含更嚴厲標(biāo)準(zhǔn)來保證高質(zhì)量。 完美WORD格式編輯