【正文】 的Scrum團隊，可以很容易地按照scrum和敏捷的方式開發(fā)產(chǎn)品。特性團隊的特點： 減少了團隊之間依賴，計劃會更容易Ron Jeffries的3個C關(guān)于用戶故事，Ron Jeffries用3個C來描述它：一個用戶故事卡帶有了太多的細節(jié)，實際上限制了和用戶的溝通。相對與傳統(tǒng)的工作量估算方式，敏捷估算有如下幾個特點：1. 團隊集體估算在Scrum的開發(fā)過程中，團隊共擔責任，集體承諾每個Sprint的工作，因此對于工作量的估算敏捷團隊采用集體估算的方式。新開始的項目或產(chǎn)品開發(fā)，或者是新團隊，沒有初始速度，我們可以做12個Sprint測算一個速度，作為初始速度。新的 Sprint 在上一 個 Sprint 完成之后立即開始。團隊按照蜂擁式（Swarming）的工作方式，團隊先集中工作在少數(shù)幾個需求上面，協(xié)作完成它們，然后在開始下一批需求。當某個 Sprint 被取消時,任何做完和“完成”的產(chǎn)品待辦事項列表條目都需要評審。Scrum的團隊是一個自組織的團隊，團隊每天進行每日站會是團隊面對面溝通和團隊自組織的體現(xiàn)。在每日站會開始之前，團隊需要在任務板上更新任務的狀態(tài)。每個人回答三個問題：我昨天完成了什么任務？我今天打算做什么任務？我遇到了哪些障礙或困難？同一時間只能有一個人發(fā)言，會上只說和這三個問題相關(guān)的話題，任何跑題的討論，需要被ScrumMaster制止。雖然這在不同的 Scrum 團隊之間會有巨大的差別,但是團隊成員必須對 完成工作意味著什么有相同的理解,這樣才能保證透明性。需要注意的是，如果在每個迭代，我們對“完成”的標準要求過低，那么這會導致在每個迭代，我們都會遺留一些完成外的工作，完成外的工作持續(xù)累計會增加項目的風險，有可能導致產(chǎn)品負責人決定發(fā)布的時候，產(chǎn)品卻因為累積了過多的完成外的工作而無法發(fā)布，以致于我們還需要一個額外的Sprint來使它穩(wěn)定。下面我列出了一些ScrumMaster常忽略的東西。但是要注意的是如果在分析需求上面花費過多的時間，效果只會適得其反，因為你的需求會在團隊和客戶/股東的持續(xù)談話中發(fā)生變化。 你能夠通過有效地把信息打印出來然后傳達給其他人嗎？ Sprint待辦事列表能夠真正反映出團隊正在做的事情嗎？所有對Sprint的目標的打斷和干擾都應該被視為障礙。 是不是整個團隊都將團隊看作一個整體，對測試和編寫文檔共同擔當責任呢？工程實踐進行得怎么樣？ 所有的測試都能夠在CI服務器的測試結(jié)果報告中反映出來嗎？ 團隊成員多數(shù)時間都在結(jié)對編程嗎？結(jié)對編程可以大幅度提高代碼的可維護性，也可以大大降低bug出現(xiàn)的機率。 ScrumMaster之間有互相交流嗎？然而，這正是你走上正軌的標志。也可以考慮在團隊中選出代表參加別的團隊的每日站會。 在你的每個產(chǎn)品待辦事列表項目的驗收標準中都包含了完全自動化測試和代碼重構(gòu)這兩項嗎？如果不學習使用極限編程的工程實踐，你就不可能在每個Sprint都能完成潛在可交付的產(chǎn)品（正如Kent Beck, Ron Jeffries等人所說的）。 你的團隊能夠發(fā)現(xiàn)系統(tǒng)測試和單元測試之間的灰色地帶嗎？ 用于解決技術(shù)債務的事項都能夠在待辦事列表里面反映出來嗎？還是需要和Product Owner另外溝通呢？ 團隊在開發(fā)過程中有沒有集中在驗收標準上？也許你應該在Sprint當中舉行一次會議來評審當前Sprint所承諾的產(chǎn)品待辦事列表項目的驗收標準。團隊做得怎么樣？ 如果你正在使用自動工具來管理你的待辦事列表，想一下它真的能夠幫助你嗎？自動化的管理工具有可能成為ScrumMaster了解信息的障礙。我們推薦每個7人左右的團隊都有一位專職的ScrumMaster，尤其是剛開始實施Scrum的時候。每個增量都附加于之前所有增量并經(jīng)過充分測試,以此保證所有的增量都能工作。如果你能夠感受到這個節(jié)奏，則說明團隊是很健康的，每日站會起到了很好的效果。如果這還不夠，參考一下其他人的實踐經(jīng)驗，比如：Martin Fowler’s 《Patterns of Daily Standup Meetings》你如何知道每日站會起到了很好的效果？一個好的每日站會有如下幾個特點：1.2.團隊需要建立他們的工作協(xié)議來確保團隊成員按時出席，并且遵守站會紀律，比如團隊可以商量對于遲到的人員要有一些讓他們改進的措施，比如適當?shù)慕o一些罰金，多少由團隊共同決定，這些錢如何支配也由團隊共同決定， 或者做俯臥撐、掛一個遲到的牌子等等。每日站會必須每天在同一時間、同一地點召開，最好的方式是在團隊的可視化的任務板前面召開?？偟膩碚f,如果某 個 Sprint 對于其所在環(huán)境來說失去了價值和意義,那么它就應該被取消。 Sprint的質(zhì)量目標和驗收標準Sprint的產(chǎn)出是“完成”的、可用 的、潛在可發(fā)布的產(chǎn)品增量。敏捷估算時，我們使用故事點作為計量單位，它是一個倍數(shù)，我們會先找一個我們認為最小的一個功能的大小作為參考基準，定義為1個故事點，把其它的故事和它做比較，如果是2倍大小，就是2個故事點，如果是5倍大小，就是5個故事點。一個不可測試的用戶故事例子：軟件應該是易于使用的。 可以估算性（Estimable）—開發(fā)團隊需要去估計一個用戶故事以便確定優(yōu)先級，工作量，安排計劃。一個用戶故事卡片上只是對用戶故事的一個簡短的描述，不包括太多的細節(jié)。 確認（Confirmation） 通過驗收測試確認用戶故事被正確完成。用戶故事通常按照如下的格式來表達：英文：As a , I want to , so that .中文：作為一個角色, 我想要活動, 以便于商業(yè)價值舉例：作為一個“網(wǎng)站管理員”，我想要“統(tǒng)計每天有多少人訪問了我的網(wǎng)站”，以便于“我的贊助商了解我的網(wǎng)站會給他們帶來什么收益。 團隊內(nèi)可以做到端到端，所以減少了等待，周期加快第三：由于職責單一，限制了學習，使得專業(yè)更加單一化第四：Sprint結(jié)束的時候無法提交可交付的增量產(chǎn)品功能，延遲價值交付按照Scrum和敏捷的交付模式，以用戶為中心，按照用戶場景作為邊界來組織團隊是比較推薦的做法。自組織的團隊不是與生俱來的，打造一個團隊需要一個過程，打造一個組織團隊也是一樣。 授權(quán)團隊 團隊決定誰做什么，即任務的分配什么是自組織團隊？自組織團隊是敏捷軟件開發(fā)的基本觀念 。 團隊成員符合T型技能，即一專多長Scrum開發(fā)團隊的主要職責包括如下五個方面：我們可以在開發(fā)期間通過Backlog的梳理來逐步的細化需求。增量交付增量是一個 Sprint 及以前所有 Sprint 中完成的所有產(chǎn)品代辦事項列表條目的總和。因此,通常都會在Sprint評審會議中調(diào) 整產(chǎn)品待辦事項列表。由于Sprint的產(chǎn)出會涉及到一些?人的“利益”,因此一個明 智的做法是邀請他們參加這個會議,這會很有幫助。在必要時, 開發(fā)團隊會基于會議中的發(fā)現(xiàn)重新組織他們的工作來完成Sprint的??目標。 從現(xiàn)在到下一個每日Scrum,我計劃完成什么。Sprint計劃會議的產(chǎn)出 Sprint計劃會議最終需要Scrum團隊對Sprint需要完成工作的數(shù)量和復雜度達成共識,并預期在一個合理的條件范圍內(nèi)完成它們。這將十分有效地幫助大家更加專注于需要完成的工 作的本質(zhì),而不必花太多精力去關(guān)注那些對于我們需要完成的工作并不重要的?小細節(jié)。因為會議是限制時?長的,Sprint計劃會議的成功?分依賴于產(chǎn)品待辦事項列表的質(zhì)量。每個人都需要清楚預期產(chǎn)出是什么。 把看起來不再重要的事項移除或者降級所有這個Sprint中需要完成，但沒有完成的任務的工作量是累積工作量，團隊會根據(jù)進展情況每天更新累積工作量，如果在Sprint結(jié)束時，累積工作量降低到0，Sprint就成功結(jié)束。開發(fā)團隊至少在每日例會時追蹤所有的剩余工作。隨著任務進 行或者被完成,需要更新每項任務的估算剩余工作量。在復雜的環(huán)境下,將要發(fā)生的東西是未知的,只有已經(jīng)發(fā)生的事情才能用來做前瞻式的決策。產(chǎn)品負責人至少在每個 Sprint 評審的時候追蹤剩余工作總量。梳理在 Sprint 中是一項兼職活動,在產(chǎn)品負責人和開發(fā)團隊之間展開。業(yè) 務需求、市場形勢和技術(shù)的變化都會引起產(chǎn)品待辦事項列表的變化。排序越高,產(chǎn)品待辦事項列表條目越緊急,就越需要仔細斟酌,并且對其價值的意見越一致。 產(chǎn)品待辦事項列表根據(jù)產(chǎn)品和開發(fā)環(huán)境的變化而演進。 在組織范圍內(nèi)計劃 Scrum 的實施 理解并實踐敏捷Scrum Master是Scrum團隊中的服務式領(lǐng)導。開發(fā)團隊的規(guī)模開發(fā)團隊最佳規(guī)模是小到足以保持敏捷性,大到足以完成重要工作。產(chǎn)品負 責人所作的決定在產(chǎn)品待辦事項列表的內(nèi)容和排序中要清晰可見。 對產(chǎn)品代辦事項列表中的條目進行排序,最好地實現(xiàn)目標和使命Scrum 團隊模式的目的是最大限度地優(yōu)化適應性、創(chuàng)造性和生產(chǎn)力。另一個因素就是檢驗工作成果人員的技能水平和積極性。Scrum 采用迭代、增量的方法來優(yōu)化可預見性并控制風險。 它的優(yōu)勢在于可以大規(guī)模批量生產(chǎn)。2002年Ken Schwaber 和Mike Cohn共同創(chuàng)辦了Scrum聯(lián)盟。1986 Scrum這個詞匯首次應用于產(chǎn)品開發(fā)1986年，竹內(nèi)弘高和 野中郁次郎在New New Product Development第三：適應（Adaptation）如果檢驗人員檢驗的時候發(fā)現(xiàn)過程中的一個或多個方面不滿足驗收標準，并且最終產(chǎn)品是不合格的，那么便需要對過程或是材料進行調(diào)整。Scrum的三大支柱如下：第一：透明性（Transparency）透明度是指，在軟件開發(fā)過程的各個環(huán)節(jié)保持高度的可見性，影響交付成果的各個方面對于參與交付的所有人、管理生產(chǎn)結(jié)果的人保持透明。在Sprint中，Scrum團隊從產(chǎn)品Backlog中挑選最高優(yōu)先級的需求進行開發(fā)。Scrum團隊總是先開發(fā)對客戶具有較高價值的需求。Scrum 的三大支柱支撐起每個經(jīng)驗性過程控制的實現(xiàn):透明性、檢驗和適應。另一個因素就是檢驗工作成果人員的技能水平和積極性。當球拋入通道時，前排的3對前鋒隊員互相抗擠，爭相踢球給本方前衛(wèi)或后衛(wèi)隊員，前衛(wèi)和后衛(wèi)隊員必須等候前鋒將球踢回后，方可移動。2001年，Ken Schwaber和Mike Beedle推出第一本Scrum書籍《Scrum敏捷軟件開發(fā)》。預定義的過程的特點是給予固定的輸入，得到固定的輸出，過程可重復?！? Scrum以經(jīng)驗性過程控制理論做為理論基礎(chǔ)的過程。幸運的是，軟件開發(fā)并不會出現(xiàn)這種情況?？缏毮艿膱F隊擁有完成工作所需要的全部技能,不需要依賴團隊外部的人。 清晰地表達產(chǎn)品代辦事項列表條目為保證產(chǎn)品負責人的工作取得成功,組織中的所有人員都必須尊重他的決定。 他們是自組織的,沒有人(即使是 Scrum Master 都不可以)告訴開發(fā)團隊如何把產(chǎn)品 代辦事項列表變成潛在可發(fā)布的功能。 開發(fā)團隊不包含如測試或業(yè)務分析等負責特定領(lǐng)域的子團隊。為了達到這個目的,Scrum Master要確保 Scrum 團隊遵循 Scrum 的理論、實踐和規(guī)則。 在經(jīng)驗主義環(huán)境中理解長期的產(chǎn)品規(guī)劃 領(lǐng)導并指導組織采用 Scrum產(chǎn)品待辦事項列表是一個持續(xù)完善的清單, 最初的版本只列出最初始的和眾所周知的需求。排在頂部的產(chǎn)品待辦事項列表條目需要立即進行開發(fā)。因為需求永遠不會停止改變,所以產(chǎn)品待辦事項列表是個不斷更新的工件。然而, 產(chǎn)品負責人可以隨時更新產(chǎn)品代辦事項列表條目或酌情決定。監(jiān)控向目標前進的進度在任何時間,達成目標的剩余工作量是可以被累計的。 然而,這并不能代替經(jīng)驗主義的重要性。當出現(xiàn)新工作時,開發(fā)團隊需要將其追加到 Sprint 待辦事項列表中去。監(jiān)控 Sprint 進度在 Sprint 中的任意時間點,Sprint 待辦事項列表的所有剩余工作總和都可以被計 算。在Sprint開始的時候，Scrum Team會標示和估計在這個Sprint需要完成的詳細的任務。 保持產(chǎn)品待辦事項列表有序 開發(fā)團隊需要能夠在一個Sprint內(nèi)完成每一個事項。Sprint計劃會議推薦時?是Sprint中的每周對應兩?時或者更少(譯者注:比如,一個Sprint包含2個星 期,則Spr