【正文】 然而，這正是你走上正軌的標(biāo)志。 你能夠幫助公司成為一個(gè)學(xué)習(xí)型企業(yè)嗎？ 你的公司的職業(yè)發(fā)展道路和你的團(tuán)隊(duì)的集體目標(biāo)相符嗎？如果以測(cè)試、自動(dòng)化測(cè)試或者開(kāi)發(fā)文檔為代價(jià)來(lái)鼓勵(lì)編程或者設(shè)計(jì)架構(gòu)，那么答案就是否定的。 ScrumMaster之間有互相交流嗎？也可以考慮在團(tuán)隊(duì)中選出代表參加別的團(tuán)隊(duì)的每日站會(huì)。整個(gè)公司的做得怎么樣？所以，比較推薦的做法是和團(tuán)隊(duì)成員先討論以選擇在一周內(nèi)大家愿意嘗試使用結(jié)對(duì)編程的時(shí)間，而不是從一開(kāi)始就強(qiáng)迫團(tuán)隊(duì)使用結(jié)對(duì)編程。 團(tuán)隊(duì)成員多數(shù)時(shí)間都在結(jié)對(duì)編程嗎？結(jié)對(duì)編程可以大幅度提高代碼的可維護(hù)性，也可以大大降低bug出現(xiàn)的機(jī)率。 在你的每個(gè)產(chǎn)品待辦事列表項(xiàng)目的驗(yàn)收標(biāo)準(zhǔn)中都包含了完全自動(dòng)化測(cè)試和代碼重構(gòu)這兩項(xiàng)嗎？如果不學(xué)習(xí)使用極限編程的工程實(shí)踐，你就不可能在每個(gè)Sprint都能完成潛在可交付的產(chǎn)品（正如Kent Beck, Ron Jeffries等人所說(shuō)的）。測(cè)試覆蓋率的漏洞和推遲的重構(gòu)被稱作技術(shù)債務(wù)。重構(gòu)需要在每個(gè)小時(shí)內(nèi)進(jìn)行多次，每當(dāng)有重復(fù)代碼，復(fù)雜的條件邏輯（通常表現(xiàn)為過(guò)量的縮進(jìn)和冗長(zhǎng)的方法），糟糕的命名，對(duì)象間的過(guò)度耦合，一個(gè)對(duì)象的職責(zé)過(guò)多等等問(wèn)題出現(xiàn)的時(shí)候就需要進(jìn)行重構(gòu)。 所有的測(cè)試都能夠在CI服務(wù)器的測(cè)試結(jié)果報(bào)告中反映出來(lái)嗎？ 你的團(tuán)隊(duì)能夠發(fā)現(xiàn)系統(tǒng)測(cè)試和單元測(cè)試之間的灰色地帶嗎？ 團(tuán)隊(duì)在開(kāi)發(fā)系統(tǒng)功能測(cè)試和單元測(cè)試的時(shí)候使用的是同一種語(yǔ)言嗎（而不是使用團(tuán)隊(duì)里只有部分成員懂的腳本語(yǔ)言）？這個(gè)是可能的。 是不是整個(gè)團(tuán)隊(duì)都將團(tuán)隊(duì)看作一個(gè)整體，對(duì)測(cè)試和編寫(xiě)文檔共同擔(dān)當(dāng)責(zé)任呢？工程實(shí)踐進(jìn)行得怎么樣？ 用于解決技術(shù)債務(wù)的事項(xiàng)都能夠在待辦事列表里面反映出來(lái)嗎？還是需要和Product Owner另外溝通呢？ 團(tuán)隊(duì)成員都能夠自己領(lǐng)取任務(wù)嗎？ 團(tuán)隊(duì)有保持更新任務(wù)版嗎？ Sprint待辦事列表能夠真正反映出團(tuán)隊(duì)正在做的事情嗎？所有對(duì)Sprint的目標(biāo)的打斷和干擾都應(yīng)該被視為障礙。 團(tuán)隊(duì)在開(kāi)發(fā)過(guò)程中有沒(méi)有集中在驗(yàn)收標(biāo)準(zhǔn)上？也許你應(yīng)該在Sprint當(dāng)中舉行一次會(huì)議來(lái)評(píng)審當(dāng)前Sprint所承諾的產(chǎn)品待辦事列表項(xiàng)目的驗(yàn)收標(biāo)準(zhǔn)。 團(tuán)隊(duì)成員之間會(huì)以高標(biāo)準(zhǔn)要求對(duì)方嗎？會(huì)互相挑戰(zhàn)來(lái)促進(jìn)成長(zhǎng)嗎？團(tuán)隊(duì)做得怎么樣？ Product Owner有根據(jù)上次Sprint評(píng)審會(huì)議來(lái)調(diào)整發(fā)布計(jì)劃嗎？通常Product Owner應(yīng)該至少在個(gè)Sprint之后調(diào)整發(fā)布計(jì)劃，一般來(lái)說(shuō)會(huì)把一些工作放到后面的版本中，原因是發(fā)現(xiàn)了一些更重要的工作要做。 你有曾經(jīng)幫助過(guò)Product Owner整理待辦事列表項(xiàng)目，然后分配到不同的版本中去嗎？ 你能夠通過(guò)有效地把信息打印出來(lái)然后傳達(dá)給其他人嗎？ 如果你正在使用自動(dòng)工具來(lái)管理你的待辦事列表，想一下它真的能夠幫助你嗎？自動(dòng)化的管理工具有可能成為ScrumMaster了解信息的障礙。 需求（特別是在產(chǎn)品待辦事列表最頂端的需求）能夠以獨(dú)立的、有價(jià)值的、可協(xié)商的、可估計(jì)的、可測(cè)試的小粒度用戶展現(xiàn)出來(lái)嗎？但是要注意的是如果在分析需求上面花費(fèi)過(guò)多的時(shí)間，效果只會(huì)適得其反，因?yàn)槟愕男枨髸?huì)在團(tuán)隊(duì)和客戶/股東的持續(xù)談話中發(fā)生變化。） 你可以通過(guò)幫助Product Owner維護(hù)產(chǎn)品待辦事列表和發(fā)布計(jì)劃來(lái)提高他的效率。下面我列出了一些ScrumMaster常忽略的東西。我們推薦每個(gè)7人左右的團(tuán)隊(duì)都有一位專職的ScrumMaster，尤其是剛開(kāi)始實(shí)施Scrum的時(shí)候。但是如果你展望團(tuán)隊(duì)能夠做到你之前無(wú)法想象的事情的時(shí)候，你就成為了一位出色的ScrumMaster。如果你愿意把你的角色限制在組織會(huì)議，控制時(shí)間盒以及處理團(tuán)隊(duì)成員提出的障礙的話，你可以將這個(gè)角色當(dāng)作成兼職來(lái)對(duì)待。需要注意的是，如果在每個(gè)迭代，我們對(duì)“完成”的標(biāo)準(zhǔn)要求過(guò)低，那么這會(huì)導(dǎo)致在每個(gè)迭代，我們都會(huì)遺留一些完成外的工作，完成外的工作持續(xù)累計(jì)會(huì)增加項(xiàng)目的風(fēng)險(xiǎn)，有可能導(dǎo)致產(chǎn)品負(fù)責(zé)人決定發(fā)布的時(shí)候，產(chǎn)品卻因?yàn)槔鄯e了過(guò)多的完成外的工作而無(wú)法發(fā)布，以致于我們還需要一個(gè)額外的Sprint來(lái)使它穩(wěn)定。每個(gè)增量都附加于之前所有增量并經(jīng)過(guò)充分測(cè)試,以此保證所有的增量都能工作。開(kāi)發(fā)團(tuán)隊(duì)在每個(gè) Sprint 交付產(chǎn)品功能增量。這個(gè)定義也同時(shí)被用來(lái)指導(dǎo)開(kāi)發(fā)團(tuán)隊(duì)了解在 Sprint 計(jì)劃會(huì)議的時(shí)候他們能選擇多少 產(chǎn)品代辦事項(xiàng)列表?xiàng)l目。雖然這在不同的 Scrum 團(tuán)隊(duì)之間會(huì)有巨大的差別,但是團(tuán)隊(duì)成員必須對(duì) 完成工作意味著什么有相同的理解,這樣才能保證透明性。如果你能夠感受到這個(gè)節(jié)奏，則說(shuō)明團(tuán)隊(duì)是很健康的，每日站會(huì)起到了很好的效果。午飯之后會(huì)有另外一個(gè)階段的活躍討論，當(dāng)下班前慢慢的安靜下來(lái)。 站會(huì)結(jié)束后，ScrumMaster知道哪些問(wèn)題需要幫助團(tuán)隊(duì)成員解決。4. 每日站會(huì)都會(huì)在15分鐘以內(nèi)完成。3. ScrumMaster不會(huì)逐個(gè)的問(wèn)每個(gè)人問(wèn)題，如果是，那么這個(gè)會(huì)議已經(jīng)淪為了報(bào)告會(huì)。如果這還不夠，參考一下其他人的實(shí)踐經(jīng)驗(yàn)，比如：Martin Fowler’s 《Patterns of Daily Standup Meetings》你如何知道每日站會(huì)起到了很好的效果？一個(gè)好的每日站會(huì)有如下幾個(gè)特點(diǎn)：1.如果每日站會(huì)沒(méi)有效果，檢查一下這些規(guī)則：你是不是每天在認(rèn)真開(kāi)每日站會(huì)？如果不是為什么？如果你改變了Scrum的一些基本的規(guī)則，你可能會(huì)面臨一些風(fēng)險(xiǎn)，因?yàn)檫@些規(guī)則都是經(jīng)過(guò)錘煉和項(xiàng)目考驗(yàn)的一些通用規(guī)則。 任何團(tuán)隊(duì)之外的人不得發(fā)言或干擾會(huì)議。4. 團(tuán)隊(duì)成員不是向ScrumMaster匯報(bào)情況，每日站會(huì)是團(tuán)隊(duì)自己的會(huì)。2. 為什么每日站會(huì)沒(méi)有效果？每日站會(huì)和傳統(tǒng)的項(xiàng)目會(huì)議有如下幾點(diǎn)不同：1. 每個(gè)人回答三個(gè)問(wèn)題：我昨天完成了什么任務(wù)？我今天打算做什么任務(wù)？我遇到了哪些障礙或困難？同一時(shí)間只能有一個(gè)人發(fā)言，會(huì)上只說(shuō)和這三個(gè)問(wèn)題相關(guān)的話題，任何跑題的討論，需要被ScrumMaster制止。團(tuán)隊(duì)需要建立他們的工作協(xié)議來(lái)確保團(tuán)隊(duì)成員按時(shí)出席，并且遵守站會(huì)紀(jì)律，比如團(tuán)隊(duì)可以商量對(duì)于遲到的人員要有一些讓他們改進(jìn)的措施，比如適當(dāng)?shù)慕o一些罰金，多少由團(tuán)隊(duì)共同決定，這些錢如何支配也由團(tuán)隊(duì)共同決定， 或者做俯臥撐、掛一個(gè)遲到的牌子等等。每日站會(huì)的紀(jì)律會(huì)議時(shí)間最多不超過(guò)15分鐘。每日站會(huì)是Scrum團(tuán)隊(duì)每天的第一件事情，這樣可以讓每個(gè)人在每天一開(kāi)始就清楚的了解他一天的安排。在每日站會(huì)開(kāi)始之前，團(tuán)隊(duì)需要在任務(wù)板上更新任務(wù)的狀態(tài)。每日站會(huì)必須每天在同一時(shí)間、同一地點(diǎn)召開(kāi)，最好的方式是在團(tuán)隊(duì)的可視化的任務(wù)板前面召開(kāi)。 團(tuán)隊(duì)溝通狀態(tài)，了解現(xiàn)狀，發(fā)現(xiàn)障礙每日站會(huì)是團(tuán)隊(duì)自己的會(huì)Scrum的團(tuán)隊(duì)是一個(gè)自組織的團(tuán)隊(duì)，團(tuán)隊(duì)每天進(jìn)行每日站會(huì)是團(tuán)隊(duì)面對(duì)面溝通和團(tuán)隊(duì)自組織的體現(xiàn)。取消 Sprint 會(huì)消耗資源,因?yàn)槊總€(gè)人都需要在新召開(kāi)的 Sprint 計(jì)劃會(huì)議中重新開(kāi)始 另一個(gè) Sprint。所有未完成的條目就都要 放回到產(chǎn)品待辦事項(xiàng)列表中,并重新估算。當(dāng)某個(gè) Sprint 被取消時(shí),任何做完和“完成”的產(chǎn)品待辦事項(xiàng)列表?xiàng)l目都需要評(píng)審。總的來(lái)說(shuō),如果某 個(gè) Sprint 對(duì)于其所在環(huán)境來(lái)說(shuō)失去了價(jià)值和意義,那么它就應(yīng)該被取消。如果某個(gè) Sprint 的目標(biāo)過(guò)時(shí)了,那么就需要取消該 Sprint。取消一個(gè) SprintSprint 可以在 Sprint 時(shí)間盒結(jié)束之前取消。團(tuán)隊(duì)按照蜂擁式（Swarming）的工作方式，團(tuán)隊(duì)先集中工作在少數(shù)幾個(gè)需求上面，協(xié)作完成它們，然后在開(kāi)始下一批需求。 Sprint的質(zhì)量目標(biāo)和驗(yàn)收標(biāo)準(zhǔn)在Sprint進(jìn)行過(guò)程中，如下內(nèi)容不能發(fā)生變化：Scrum采用迭代增量的方式，是因?yàn)樾枨笫怯楷F(xiàn)的，我們對(duì)產(chǎn)品和需求的理解是漸進(jìn)式的，Sprint長(zhǎng)度越長(zhǎng)，我們需要預(yù)測(cè)的越多，復(fù)雜度會(huì)提升、風(fēng)險(xiǎn)也會(huì)增加，所以Sprint的長(zhǎng)度最多不超過(guò)4周。新的 Sprint 在上一 個(gè) Sprint 完成之后立即開(kāi)始。Sprint的產(chǎn)出是“完成”的、可用 的、潛在可發(fā)布的產(chǎn)品增量。一個(gè)Sprint是指一個(gè)1周－4周的迭代，它是一個(gè)時(shí)間盒。我們估算了產(chǎn)品Backlog的故事點(diǎn)總數(shù)，然后又知道了每個(gè)Sprint團(tuán)隊(duì)的平均速度，那么我們就可以推算我們大概需要多少個(gè)Sprint可以做完，這樣我們就得到了周期。新開(kāi)始的項(xiàng)目或產(chǎn)品開(kāi)發(fā)，或者是新團(tuán)隊(duì)，沒(méi)有初始速度，我們可以做12個(gè)Sprint測(cè)算一個(gè)速度，作為初始速度。敏捷估算時(shí)，我們使用故事點(diǎn)作為計(jì)量單位，它是一個(gè)倍數(shù)，我們會(huì)先找一個(gè)我們認(rèn)為最小的一個(gè)功能的大小作為參考基準(zhǔn)，定義為1個(gè)故事點(diǎn)，把其它的故事和它做比較，如果是2倍大小，就是2個(gè)故事點(diǎn)，如果是5倍大小，就是5個(gè)故事點(diǎn)。如果我們要估算從家到公司的絕對(duì)距離時(shí)多少公里，您可能不一定知道，但是如果您時(shí)做地鐵上班，從家里到公司有多少站，你一定很容易知道，當(dāng)我們知道有多少站之后，我們就可以大概清楚路上需要花多長(zhǎng)時(shí)間了。關(guān)注Scrum中文網(wǎng)微信公眾號(hào)可以獲得微信版估算撲克。估算撲克的使用方法：使用估算撲克來(lái)做工作量估算是最有效，也是非常有趣的一種估算方式。相對(duì)與傳統(tǒng)的工作量估算方式，敏捷估算有如下幾個(gè)特點(diǎn)：1. 團(tuán)隊(duì)集體估算在Scrum的開(kāi)發(fā)過(guò)程中，團(tuán)隊(duì)共擔(dān)責(zé)任，集體承諾每個(gè)Sprint的工作，因此對(duì)于工作量的估算敏捷團(tuán)隊(duì)采用集體估算的方式。一個(gè)不可測(cè)試的用戶故事例子：軟件應(yīng)該是易于使用的。 可測(cè)試性（Testable）—一個(gè)用戶故事要是可以測(cè)試的，以便于確認(rèn)它是可以完成的。用戶故事越大，在安排計(jì)劃，工作量估算等方面的風(fēng)險(xiǎn)就會(huì)越大。 可以估算性（Estimable）—開(kāi)發(fā)團(tuán)隊(duì)需要去估計(jì)一個(gè)用戶故事以便確定優(yōu)先級(jí)，工作量，安排計(jì)劃。一旦一個(gè)客戶意識(shí)到這是一個(gè)用戶故事并不是一個(gè)契約而且可以進(jìn)行協(xié)商的時(shí)候，他們將非常樂(lè)意寫(xiě)下故事。 有價(jià)值（Valuable）— 每個(gè)故事必須對(duì)客戶具有價(jià)值（無(wú)論是用戶還是購(gòu)買方）。一個(gè)用戶故事卡帶有了太多的細(xì)節(jié)，實(shí)際上限制了和用戶的溝通。一個(gè)用戶故事卡片上只是對(duì)用戶故事的一個(gè)簡(jiǎn)短的描述，不包括太多的細(xì)節(jié)。用戶故事之間的依賴使得制定計(jì)劃，確定優(yōu)先級(jí)，工作量估算都變得很困難。 確認(rèn)（Confirmation） 通過(guò)驗(yàn)收測(cè)試確認(rèn)用戶故事被正確完成。 交談（Conversation） 用戶故事背后的細(xì)節(jié)來(lái)源于和客戶或者產(chǎn)品負(fù)責(zé)人的交流溝通?？ㄆ峡赡軙?huì)寫(xiě)上故事的簡(jiǎn)短描述，工作量估算等。Ron Jeffries的3個(gè)C關(guān)于用戶故事，Ron Jeffries用3個(gè)C來(lái)描述它：用戶故事通常按照如下的格式來(lái)表達(dá)：英文：As a , I want to , so that .中文：作為一個(gè)角色, 我想要活動(dòng), 以便于商業(yè)價(jià)值舉例：作為一個(gè)“網(wǎng)站管理員”，我想要“統(tǒng)計(jì)每天有多少人訪問(wèn)了我的網(wǎng)站”，以便于“我的贊助商了解我的網(wǎng)站會(huì)給他們帶來(lái)什么收益。2. 活動(dòng)：需要完成什么樣的功能。 個(gè)人學(xué)習(xí)和團(tuán)隊(duì)學(xué)習(xí)的機(jī)會(huì)用戶故事什么是用戶故事？用戶故事是從用戶的角度來(lái)描述用戶渴望得到的功能。 減少了團(tuán)隊(duì)之間依賴，計(jì)劃會(huì)更容易 團(tuán)隊(duì)內(nèi)可以做到端到端，所以減少了等待，周期加快 共享代碼庫(kù)，統(tǒng)一的持續(xù)集成 以客戶為中心的特性驅(qū)動(dòng)特性團(tuán)隊(duì)的特點(diǎn)：第三：由于職責(zé)單一，限制了學(xué)習(xí)，使得專業(yè)更加單一化第四：Sprint結(jié)束的時(shí)候無(wú)法提交可交付的增量產(chǎn)品功能，延遲價(jià)值交付按照Scrum和敏捷的交付模式，以用戶為中心，按照用戶場(chǎng)景作為邊界來(lái)組織團(tuán)隊(duì)是比較推薦的做法。組件團(tuán)隊(duì)看起來(lái)像這個(gè)樣子：按照Scrum和敏捷的交付模式，組件團(tuán)隊(duì)有如下一些限制：第一：按照組件來(lái)組織團(tuán)隊(duì)，很難避免團(tuán)隊(duì)之間的依賴，跨團(tuán)隊(duì)的協(xié)調(diào)和依賴管理更加復(fù)雜，不利于跨組件或者各個(gè)層之間的溝通。在一個(gè)大的開(kāi)發(fā)組織中，Scrum會(huì)把大的開(kāi)發(fā)團(tuán)隊(duì)劃分成多個(gè)59人的小團(tuán)隊(duì)，那么我們應(yīng)該按照什么方式來(lái)劃分呢？在傳統(tǒng)的開(kāi)發(fā)模式下，我們習(xí)慣于按照系統(tǒng)的架構(gòu)模塊，或者系統(tǒng)分層組織團(tuán)隊(duì)，也有的團(tuán)隊(duì)按照系統(tǒng)需求、開(kāi)發(fā)、測(cè)試結(jié)合系統(tǒng)架構(gòu)混合組織的方式。特性團(tuán)隊(duì)如果我們的產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)只有在10人以內(nèi)，我們使用一個(gè)跨職能的Scrum團(tuán)隊(duì)，可以很容易地按照scrum和敏捷的方式開(kāi)發(fā)產(chǎn)品。自組織的團(tuán)隊(duì)不是與生俱來(lái)的，打造一個(gè)團(tuán)隊(duì)需要一個(gè)過(guò)程，打造一個(gè)組織團(tuán)隊(duì)也是