【正文】 需要注意的是，如果在每個迭代，我們對“完成”的標(biāo)準(zhǔn)要求過低，那么這會導(dǎo)致在每個迭代，我們都會遺留一些完成外的工作，完成外的工作持續(xù)累計會增加項目的風(fēng)險，有可能導(dǎo)致產(chǎn)品負(fù)責(zé)人決定發(fā)布的時候，產(chǎn)品卻因為累積了過多的完成外的工作而無法發(fā)布，以致于我們還需要一個額外的Sprint來使它穩(wěn)定。每個增量都附加于之前所有增量并經(jīng)過充分測試,以此保證所有的增量都能工作。開發(fā)團(tuán)隊在每個 Sprint 交付產(chǎn)品功能增量。這個定義也同時被用來指導(dǎo)開發(fā)團(tuán)隊了解在 Sprint 計劃會議的時候他們能選擇多少 產(chǎn)品代辦事項列表條目。雖然這在不同的 Scrum 團(tuán)隊之間會有巨大的差別,但是團(tuán)隊成員必須對 完成工作意味著什么有相同的理解,這樣才能保證透明性。如果你能夠感受到這個節(jié)奏，則說明團(tuán)隊是很健康的，每日站會起到了很好的效果。午飯之后會有另外一個階段的活躍討論，當(dāng)下班前慢慢的安靜下來。，Scrum Master知道哪些問題需要幫助團(tuán)隊成員解決。如果這還不夠，參考一下其他人的實踐經(jīng)驗，比如：Martin Fowler’s 《Patterns of Daily Standup Meetings》你如何知道每日站會起到了很好的效果？一個好的每日站會有如下幾個特點： Master不會逐個的問每個人問題，如果是，那么這個會議已經(jīng)淪為了報告會。如果每日站會沒有效果，檢查一下這些規(guī)則：你是不是每天在認(rèn)真開每日站會？如果不是為什么？如果你改變了Scrum的一些基本的規(guī)則，你可能會面臨一些風(fēng)險，因為這些規(guī)則都是經(jīng)過錘煉和項目考驗的一些通用規(guī)則。 Master匯報情況，每日站會是團(tuán)隊自己的會。一些的確需要討論的問題，可以先記錄下來，會后作為專題來討論。每日站會一定要站著開，每個人要精神集中，不能有懶散的表現(xiàn)。所有的團(tuán)隊成員自覺按時到場，因為會議很短，按時召開按時結(jié)束是很重要的。對于跨國界的團(tuán)隊，存在時間差的情況，可以根據(jù)實際情況做調(diào)整。這樣的好處是在開會的時候，每個人都可以看到當(dāng)前的進(jìn)展情況。 任務(wù)板上可以看到當(dāng)前Sprint的燃盡圖（Burn Down Chart）和Sprint中每個任務(wù)的狀態(tài)。 團(tuán)隊回顧昨天的工作，做調(diào)整，持續(xù)改進(jìn)什么時候、在什么地點開每日站會？Scrum定義了開展每日站會的一些基本的規(guī)則。 團(tuán)隊商量決定誰做什么（不能有領(lǐng)導(dǎo)任務(wù)指派），為當(dāng)天排一個計劃Scrum的理論基礎(chǔ)是通過保持過程透明性讓參與過程的所有人了解真實狀況，然后進(jìn)行檢查和調(diào)整，每日站會是Scrum過程進(jìn)行每天的檢查和調(diào)整的環(huán)節(jié)。十六、 每日站會每日站會的目的在介紹如何開每日站會前， 讓我們先了解一下召開每天的站會的目的和意義是什么？敏捷宣言強調(diào)個體交互重于過程和工具，敏捷原則闡述了面對面的溝通和自組織的團(tuán)隊這些敏捷的核心思想。取消 Sprint 會消耗資源,因為每個人都需要在新召開的 Sprint 計劃會議中重新開始 另一個 Sprint。所有未完成的條目就都要 放回到產(chǎn)品待辦事項列表中,并重新估算。當(dāng)某個 Sprint 被取消時,任何做完和“完成”的產(chǎn)品待辦事項列表條目都需要評審。總的來說,如果某 個 Sprint 對于其所在環(huán)境來說失去了價值和意義,那么它就應(yīng)該被取消。如果某個 Sprint 的目標(biāo)過時了,那么就需要取消該 Sprint。取消一個 SprintSprint 可以在 Sprint 時間盒結(jié)束之前取消。團(tuán)隊按照蜂擁式（Swarming）的工作方式，團(tuán)隊先集中工作在少數(shù)幾個需求上面，協(xié)作完成它們，然后在開始下一批需求。 Sprint的質(zhì)量目標(biāo)和驗收標(biāo)準(zhǔn)在Sprint進(jìn)行過程中，如下內(nèi)容不能發(fā)生變化：Scrum采用迭代增量的方式，是因為需求是涌現(xiàn)的，我們對產(chǎn)品和需求的理解是漸進(jìn)式的，Sprint長度越長，我們需要預(yù)測的越多，復(fù)雜度會提升、風(fēng)險也會增加，所以Sprint的長度最多不超過4周。新的 Sprint 在上一 個 Sprint 完成之后立即開始。Sprint的產(chǎn)出是“完成”的、可用 的、潛在可發(fā)布的產(chǎn)品增量。一個Sprint是指一個1周－4周的迭代，它是一個時間盒。我們估算了產(chǎn)品Backlog的故事點總數(shù)，然后又知道了每個Sprint團(tuán)隊的平均速度，那么我們就可以推算我們大概需要多少個Sprint可以做完，這樣我們就得到了周期。新開始的項目或產(chǎn)品開發(fā)，或者是新團(tuán)隊，沒有初始速度，我們可以做12個Sprint測算一個速度，作為初始速度。敏捷估算時，我們使用故事點作為計量單位，它是一個倍數(shù)，我們會先找一個我們認(rèn)為最小的一個功能的大小作為參考基準(zhǔn)，定義為1個故事點，把其它的故事和它做比較，如果是2倍大小，就是2個故事點，如果是5倍大小，就是5個故事點。如果我們要估算從家到公司的絕對距離時多少公里，您可能不一定知道，但是如果您時做地鐵上班，從家里到公司有多少站，你一定很容易知道，當(dāng)我們知道有多少站之后，我們就可以大概清楚路上需要花多長時間了。關(guān)注Scrum中文網(wǎng)微信公眾號可以獲得微信版估算撲克。估算撲克的使用方法：使用估算撲克來做工作量估算是最有效，也是非常有趣的一種估算方式。相對與傳統(tǒng)的工作量估算方式，敏捷估算有如下幾個特點：1. 團(tuán)隊集體估算在Scrum的開發(fā)過程中，團(tuán)隊共擔(dān)責(zé)任，集體承諾每個Sprint的工作，因此對于工作量的估算敏捷團(tuán)隊采用集體估算的方式。一個不可測試的用戶故事例子：軟件應(yīng)該是易于使用的。 可測試性（Testable）—一個用戶故事要是可以測試的，以便于確認(rèn)它是可以完成的。用戶故事越大，在安排計劃，工作量估算等方面的風(fēng)險就會越大。 可估算性（Estimable）—開發(fā)團(tuán)隊需要去估計一個用戶故事以便確定優(yōu)先級，工作量，安排計劃。一旦一個客戶意識到這是一個用戶故事并不是一個契約而且可以進(jìn)行協(xié)商的時候，他們將非常樂意寫下故事。 有價值（Valuable）— 每個故事必須對客戶具有價值（無論是用戶還是購買方）。一個用戶故事卡帶有了太多的細(xì)節(jié)，實際上限制了和用戶的溝通。一個用戶故事卡片上只是對用戶故事的一個簡短的描述，不包括太多的細(xì)節(jié)。用戶故事之間的依賴使得制定計劃，確定優(yōu)先級，工作量估算都變得很困難。用戶故事的六個特性 INVESTINVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable一個好的用戶故事應(yīng)該遵循INVEST原則，分別如下： 卡片（Card） – 用戶故事一般寫在小的記事卡片上?！毙枰⒁獾氖怯脩艄适虏荒軌蚴褂眉夹g(shù)語言來描述，要使用用戶可以理解的業(yè)務(wù)語言來描述。3. 商業(yè)價值：為什么需要這個功能，這個功能帶來什么樣的價值。一個好的用戶故事包括三個要素：1. 角色：誰要使用這個功能。 減少了團(tuán)隊之間依賴，計劃會更容易 團(tuán)隊內(nèi)可以做到端到端，所以減少了等待，周期加快 共享代碼庫，統(tǒng)一的持續(xù)集成 以客戶為中心的特性驅(qū)動特性團(tuán)隊的特點：第三：由于職責(zé)單一，限制了學(xué)習(xí)，使得專業(yè)更加單一化第四：Sprint結(jié)束的時候無法提交可交付的增量產(chǎn)品功能，延遲價值交付按照Scrum和敏捷的交付模式，以用戶為中心，按照用戶場景作為邊界來組織團(tuán)隊是比較推薦的做法。組件團(tuán)隊看起來像這個樣子：按照Scrum和敏捷的交付模式，組件團(tuán)隊有如下一些限制：第一：按照組件來組織團(tuán)隊，很難避免團(tuán)隊之間的依賴，跨團(tuán)隊的協(xié)調(diào)和依賴管理更加復(fù)雜，不利于跨組件或者各個層之間的溝通。在一個大的開發(fā)組織中，Scrum會把大的開發(fā)團(tuán)隊劃分成多個59人的小團(tuán)隊，那么我們應(yīng)該按照什么方式來劃分呢？在傳統(tǒng)的開發(fā)模式下，我們習(xí)慣于按照系統(tǒng)的架構(gòu)模塊，或者系統(tǒng)分層組織團(tuán)隊，也有的團(tuán)隊按照系統(tǒng)需求、開發(fā)、測試結(jié)合系統(tǒng)架構(gòu)混合組織的方式。十二、 特性團(tuán)隊如果我們的產(chǎn)品開發(fā)團(tuán)隊只有在10人以內(nèi)，我們使用一個跨職能的Scrum團(tuán)隊，可以很容易地按照scrum和敏捷的方式開發(fā)產(chǎn)品。自組織的團(tuán)隊不是與生俱來的，打造一個團(tuán)隊需要一個過程，打造一個自組織團(tuán)隊也是一樣。 誤解5：自組織團(tuán)隊需要員工更加主動； 糾正：自組織讓團(tuán)隊更加主動，每個人都不喜歡被命令和控制，每個人期望有成就感、期望被認(rèn)可 誤解3：團(tuán)隊自己設(shè)計團(tuán)隊結(jié)構(gòu)； 糾正：管理層決定團(tuán)隊上下文 誤解1：團(tuán)隊自己決定目標(biāo)是什么 ； 糾正：管理層決定團(tuán)隊目標(biāo) 授權(quán)團(tuán)隊 確定團(tuán)隊上下文，組織結(jié)構(gòu)、團(tuán)隊結(jié)構(gòu)、團(tuán)隊組成 團(tuán)隊監(jiān)督和管理他們的過程和進(jìn)度在自組織團(tuán)隊的環(huán)境下，管理層關(guān)注在如下幾個方面： 團(tuán)隊需要在確保目標(biāo)的前提下制定團(tuán)隊內(nèi)的行為準(zhǔn)則 團(tuán)隊決定誰做什么，即任務(wù)的分配這種團(tuán)隊的管理方式，更多的是命令與控制，以及微觀管理。自組織團(tuán)隊和經(jīng)理領(lǐng)導(dǎo)的團(tuán)隊的區(qū)別對于經(jīng)理領(lǐng)導(dǎo)的團(tuán)隊來說，團(tuán)隊成員被分配任務(wù)，團(tuán)隊成員只有執(zhí)行任務(wù)的權(quán)利。自組織團(tuán)隊也叫做自管理團(tuán)隊、或者被授權(quán)的團(tuán)隊。什么是自組織團(tuán)隊？自組織團(tuán)隊是敏捷軟件開發(fā)的基本觀念 。 按照可持續(xù)的節(jié)奏工作 2個披薩的團(tuán)隊大?。?9人） 最大限制的溝通 團(tuán)隊成員符合T型技能，即一專多長 自組織 每天跟進(jìn)工作進(jìn)展，并對他們的工作做檢查和調(diào)整 梳理產(chǎn)品BacklogScrum開發(fā)團(tuán)隊的主要職責(zé)包括如下五個方面：Scrum中的團(tuán)隊，對應(yīng)到龍舟賽的劃槳團(tuán)隊，團(tuán)隊必須協(xié)調(diào)一致，作為一個整體前進(jìn)，在這樣的環(huán)境下單打獨斗，各自為政沒有任何勝算。Scrum中的PO就是舵手的角色，他對產(chǎn)品的方向負(fù)責(zé)，對產(chǎn)品的Why和What負(fù)責(zé)，對產(chǎn)品的愿景，產(chǎn)品包括哪些主要的特性負(fù)責(zé)。但是，在Scrum的工作方式下，總共只有三個角色， 這三個角色分別是產(chǎn)品負(fù)責(zé)人（PO）,Scrum Master和開發(fā)團(tuán)隊。我們可以在開發(fā)期間通過Backlog的梳理來逐步的細(xì)化需求。Scrum團(tuán)隊在開發(fā)需求的時候，從Backlog最上層的高優(yōu)先級的需求開始開發(fā)。自組織團(tuán)隊Scrum團(tuán)隊是一個自組織的團(tuán)隊，傳統(tǒng)的命令與控制式的團(tuán)隊只有執(zhí)行任務(wù)的權(quán)利，而自組織團(tuán)隊有權(quán)進(jìn)行設(shè)計、計劃和執(zhí)行任務(wù)，自組織團(tuán)隊還需要自己監(jiān)督和管理他們的工程過程和進(jìn)度，自組織團(tuán)隊自己決定團(tuán)隊內(nèi)如何開展工作，決定誰來做什么，即分工協(xié)作的方式。無論產(chǎn)品負(fù)責(zé)人是否決定真正發(fā)布它,增量必須可用。增量交付增量是一個 Sprint 及以前所有 Sprint 中完成的所有產(chǎn)品代辦事項列表條目的總和。迭代的長度是固定的，如果我們選擇了1周的迭代，那么保持它的長度不要發(fā)生變化，在整個產(chǎn)品開發(fā)周期內(nèi)