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