【正文】 任何其他人的指令。只有開發(fā)團隊的成員才能創(chuàng)造增量。所產(chǎn)生的協(xié)同工作能最大化 開發(fā)團隊的整體效率和效力。 他們是自組織的,沒有人(即使是 Scrum Master 都不可以)告訴開發(fā)團隊如何把產(chǎn)品 代辦事項列表變成潛在可發(fā)布的功能。 開發(fā)團隊是跨職能的,團隊作為一個整體擁有創(chuàng)造產(chǎn)品增量所需要的全部技能。 Scrum 不認可開發(fā)團隊成員的頭銜,無論承擔哪種工作他們都是開發(fā)者。 開發(fā)團隊不包含如測試或業(yè)務分析等負責特定領(lǐng)域的子團隊。少于 3 人的開發(fā) 團隊沒有足夠的交互,因而所獲得的生產(chǎn)力增長也不會很大。大于 9 人的團隊需要過多的協(xié)調(diào)溝 通工作。產(chǎn)品負責人和 Scrum Master 的角色不包含在此數(shù)字中,除非他們也參與執(zhí)行 Sprint 代表事項列表中的工作。為了達到這個目的,Scrum Master要確保 Scrum 團隊遵循 Scrum 的理論、實踐和規(guī)則。Scrum Master 幫助 Scrum 團隊外的人員了解他們?nèi)绾闻c Scrum 團隊交互是有益的。Scrum Master 服務于產(chǎn)品負責人Scrum Master 以各種方式服務于產(chǎn)品負責人,包括: 清晰地和開發(fā)團隊溝通愿景、目標和產(chǎn)品代表事項列表條目 在經(jīng)驗主義環(huán)境中理解長期的產(chǎn)品規(guī)劃 按需推動Scrum活動Scrum Master 服務于開發(fā)團隊Scrum Master 以各種方式服務于開發(fā)團隊,包括: 教導并領(lǐng)導開發(fā)團隊創(chuàng)造高價值的產(chǎn)品 按需推動Scrum活動 領(lǐng)導并指導組織采用 Scrum 幫助員工及干系人理解并實施 Scrum 和經(jīng)驗性產(chǎn)品開發(fā) 與其他 Scrum Master 一起工作,幫助組織更有效的應用ScrumSCRUM的三個工件Scrum 的工件以不同的方式展現(xiàn)工作和價值,可以用來提供透明性以及檢驗和適應的機會。Product Backlog – 產(chǎn)品待辦事項列表產(chǎn)品待辦事項列表是一個排序的列表,包含所有產(chǎn)品需要的東西,也是產(chǎn)品需求變動的唯一來源。產(chǎn)品待辦事項列表是一個持續(xù)完善的清單, 最初的版本只列出最初始的和眾所周知的需求。待辦事項列表是動態(tài)的,它經(jīng)常發(fā)生變化以識別使產(chǎn)品合理、有競爭力和有用所必需的東西。產(chǎn)品待辦事項列表列出了所有的特性、功能、需求、改進方法和缺陷修復等對未來發(fā)布產(chǎn)品進行的改變。產(chǎn)品待辦事項列表通常以價值、風險、優(yōu)先級和必須性排序。排在頂部的產(chǎn)品待辦事項列表條目需要立即進行開發(fā)。排序越高的產(chǎn)品待辦事項列表條目比排序低的更清晰、更具體。優(yōu)先級越低,細節(jié)信息越少。開發(fā)團隊在一個 Sprint 中可以“完 成”的產(chǎn)品待辦事項列表條目被認為是“準備好的”或者“可執(zhí)行的”,能在 Sprint 計 劃會議中被選擇。因為需求永遠不會停止改變,所以產(chǎn)品待辦事項列表是個不斷更新的工件。若干個 Scrum 團隊常常會一起開發(fā)某個產(chǎn)品。那么這就需要使用對產(chǎn)品待辦事項列表條目進行分組的屬性。這是一個持續(xù)不斷 的過程,產(chǎn)品負責人和開發(fā)團隊協(xié)作討論產(chǎn)品代表事項列表條目的細節(jié)。然而, 產(chǎn)品負責人可以隨時更新產(chǎn)品代辦事項列表條目或酌情決定。通常,開發(fā) 團隊有自行優(yōu)化的領(lǐng)域知識。優(yōu)化通常占用不超過開發(fā)團隊 10%的時間。產(chǎn)品負責人可以通過協(xié)助團隊權(quán)衡取舍來影響他們的 決定。監(jiān)控向目標前進的進度在任何時間,達成目標的剩余工作量是可以被累計的。產(chǎn)品負責人把這個數(shù)量與之前 Sprint 評審時的剩余工作 量做比較,來評估在希望的時間點完成預計工作達成目標的進度。Scrum 不考慮已經(jīng)花在產(chǎn)品代辦事項列表條目上的工作時間。各種趨勢燃盡圖、燃燒圖和其他計劃實踐都能用來預測進度。 然而,這并不能代替經(jīng)驗主義的重要性。SPRINT BACKLOGSprint 代辦事項列表是一組為當前 Sprint 選出的產(chǎn)品代辦事項列表條目,外加交付 產(chǎn)品增量和實現(xiàn) Sprint 目標的計劃。Sprint 代辦事項列表定義了開發(fā)團隊把產(chǎn)品代辦事項列表條目轉(zhuǎn)換成“完成”的增量 所需要執(zhí)行的工作。Sprint 代辦事項列表是一份足夠具體的計劃,使得進度上的改變能在每日例會中得到 理解。當出現(xiàn)新工作時,開發(fā)團隊需要將其追加到 Sprint 待辦事項列表中去。如果計劃中某個部分失去開發(fā)的意 義,就可以將其除去。 Sprint 待辦事項列表是高度可見的,是對團隊計劃在當前 Sprint 內(nèi)完成工作的實時反 映,并且,該列表只屬于開發(fā)團隊。2. 程序缺陷做為新的任務加進來，這個都做為承諾提交任務中未完成的工作。監(jiān)控 Sprint 進度在 Sprint 中的任意時間點,Sprint 待辦事項列表的所有剩余工作總和都可以被計 算。開發(fā)團隊每天追蹤剩余總和并預測 達成 Sprint 目標的可能性。Scrum 不考慮已經(jīng)花在 Sprint 待辦事項列表上的工作時間。燃盡圖（BURNDOWN CHART)Sprint燃盡圖（Sprint Burndown Chart)Sprint Burndown Chart 顯示了Sprint中累積剩余的工作量，它是一個反映工作量完成狀況的趨勢圖。在Sprint開始的時候，Scrum Team會標示和估計在這個Sprint需要完成的詳細的任務。由于在Sprint的剛開始的時候，增加的任務工作量可能大于完成的任務工作量，所以燃盡圖有可能略微呈上升趨勢。發(fā)布燃盡圖記錄了在一段時間內(nèi)產(chǎn)品Backlog的總剩余估算工作量的變化趨勢。SCRUM的五個活動Scrum活動:產(chǎn)品待辦事項列表梳理產(chǎn)品待辦事項通常會很大,也很寬泛,而且想法會變來變?nèi)?、?yōu)先級也會變化,所以產(chǎn)品待 辦事項列表梳理是一個貫穿整個Scrum項目始終的活動。 保持產(chǎn)品待辦事項列表有序 增加或提升涌現(xiàn)出來的或變得更重要的事項 將事項歸并為更大的事項為此,梳理時會特別關(guān)注那些即將被實現(xiàn)的事項。 開發(fā)團隊需要能夠在一個Sprint內(nèi)完成每一個事項。產(chǎn)品開發(fā)決定了,有可能需要其它的技能和輸入。Scrum活動：Sprint計劃會議每個Sprint都以Sprint計劃會議作為開始， 這是一個固定時長的會議，在這個會議中,Scrum團隊共同選擇和理解在即將到來的Sprint中要完成的工作。針對排好序的產(chǎn)品待辦事項列表(Product Backlog),產(chǎn) 品負責人和開發(fā)團隊成員討論每個事項,并對該事項達成共識,包括根據(jù)當前的“完成的定 義”,為了完成該事項所需要完成的所有事情。Sprint計劃會議推薦時?是Sprint中的每周對應兩?時或者更少(譯者注:比如,一個Sprint包含2個星 期,則Sprint計劃會議時長應為4個小時或者更少)。這就是產(chǎn)品待辦事項列表梳理十分重要的原因。Sprint中需要完成的產(chǎn)品待辦事項數(shù)目完全由開發(fā)團隊決定。做多少工作只能由開發(fā)團隊決定。通常Sprint都有個目標,稱作Sprint目標。第二部分:如何完成工作?在會議的第二部分?里,開發(fā)團隊需要根據(jù)當前的“完成的定義”一起決定如何實現(xiàn)下一個產(chǎn)品增 量。頭幾天的工作會 被分解成?小的單元,每個工作單元不超過一天。決定如何完成工作是開發(fā)團隊的職責,決定做什么則是產(chǎn)品負責人的職責。不管怎樣,團隊應該很容易找到產(chǎn)品負責人。開發(fā)團隊預測并共同承諾他們要完成的工作量。最終產(chǎn)生的待辦事項列表就是“Sprint待辦事項列表(Sprint Backlog)”。開發(fā)團隊通過每日Scrum會議來確認他們?nèi)匀豢梢詫崿F(xiàn)Sprint的目標。每一個開發(fā)團隊成員需要提供以下三點信息:從上一個每日Scrum到現(xiàn)在,我完成了什么。 有什么阻礙了我的進展。通常,許多團隊 會在每日Scrum之后?馬上開會處理他們遇到的任何問題。它是一個開發(fā) 團隊內(nèi)部的溝通會議,來保證他們對現(xiàn)狀有一致的了解。其他感興趣的?人可以來旁聽。每日Scrum是Scrum的一個關(guān)鍵組成部分,它可以帶來透明性,信任和更好的績效。所有Scrum會議都是限定時?長的。Scrum活動:Sprint評審會議Sprint結(jié)束時,Scrum團隊和相關(guān)?人員一起評審Sprint的產(chǎn)出。討論圍繞著Sprint中完成的產(chǎn)品增量。這個會議是個?非正式的會議,幫助?大家 了解我們??目前進展到哪?里,并一起討論我們下一步如何推進。當然,產(chǎn)品負責?人會對未來做出最終的決定,并適當?shù)卣{(diào)整產(chǎn)品待辦事項列表 (Product Backlog)。通常會演?示產(chǎn)品增量,整個小組也會經(jīng)常討論他們在Sprint中觀察到了什么、有哪些新的產(chǎn)品想法出現(xiàn)。Sprint評審會議向每個?人展?示了當前產(chǎn)品增量的概況。Scrum活動:Sprint回顧會議在每個Sprint結(jié)束后,Scrum團隊會聚在一起開Sprint回顧會議,目的是回顧一下團隊在流程人際關(guān)系以及工具方面做得如何。所有的Scrum會議都是限定時?長的,Sprint回顧會議的 推薦時?長是Sprint中的每一周對應一個小時(譯者注:?比如,一個Sprint包含2個星期,則 Sprint回顧會議時?長為2個小時)。SCRUM的五個價值觀1. 承諾 – 愿意對目標做出承諾2. 專注– 把你的心思和能力都用到你承諾的工作上去3. 開放– Scrum 把項目中的一切開放給每個人看4. 尊重– 每個人都有他獨特的背景和經(jīng)驗5. 勇氣– 有勇氣做出承諾，履行承諾，接受別人的尊重SCRUM的四大支柱迭代開發(fā)在Scrum的開發(fā)模式下，我們將開發(fā)周期分成多個14周的迭代，每個迭代都交付一些增量的可工作的功能。這里需要強調(diào)的是在每個迭代必須產(chǎn)出可工作的增量功能，而不是第一個迭代做需求、第二個迭代做設(shè)計、第三個迭代做代碼。 在 Sprint 的結(jié)尾,新的增量必須“完成”,這意味著它必須可用并且達到了 Scrum 團隊 “完成”的定義的標準。增量是從用戶的角度來描述的，它意味著從用戶的角度可工作。高優(yōu)先級的需求驅(qū)動在Scrum中，我們使用Product Backlog來管理需求，Product Backlog是一個需求的清單，Product Backlog中的需求是漸進明細的，Backlog當中的條目必須按照商業(yè)價值的高低排序。在Scrum中，只要有足夠12個Sprint開發(fā)的細化了的高優(yōu)先級的需求，我們就可以啟動Sprint了，而不必等到所有的需求都細化之后。SCRUM團隊在傳統(tǒng)的工作方式下，開發(fā)團隊會有很多不同的角色，比如項目經(jīng)理、產(chǎn)品經(jīng)理、架構(gòu)師、設(shè)計師、用戶體驗設(shè)計師，程序員，測試人員，DBA等等。我們通?？梢砸詣濤堉鄣膱F隊角色來類比Scrum的角色，劃龍舟通常有舵手、鼓手、劃槳團隊三個角色。Scrum中的Scrum Master鼓手的角色，他幫助團隊保持高昂的士氣，并進行良好的協(xié)作，他是一個Scrum的專家，團隊的教練，團隊的服務式領(lǐng)導。Scrum的開發(fā)團隊對實現(xiàn)Sprint目標需要做的所有事情負責，包括技術(shù)方案和決策，團隊分工（誰做什么），執(zhí)行Sprint開發(fā)任務等，而且作為自組織的團隊，他們也對他們的工作進度的跟蹤和管理負責。 執(zhí)行Sprint 做Sprint計劃 每個迭代對產(chǎn)品和團隊的工作過程做檢查和調(diào)整開發(fā)團隊有如下10方面的特征： 多元化、跨職能的完整團隊 持續(xù)改進 透明溝通 專注、投入 團隊長期存在，人員穩(wěn)定自組織團隊敏捷宣言的原則中提到 :“最好的架構(gòu)、需求和設(shè)計出于自組織團隊 ”。團隊被授權(quán)自己管理他們的工作過程和進度、并且團隊決定如何完成工作。對于經(jīng)理領(lǐng)導的團隊來說，管理者除了要確定目標、方向，團隊的上下文（組織結(jié)構(gòu)、團隊結(jié)構(gòu)、團隊組成），還需要監(jiān)督和管理團隊的過程和進度，分配任務即確定誰做什么。對于自組織團隊來說，他們擁有如下權(quán)利： 團隊決定如何做，如何實現(xiàn)目標，即團隊做技術(shù)決策 團隊有義務保持過程的透明性 確定團隊目標和愿景 提供環(huán)境和支持（安全感、良好的團隊空間、氛圍，技能輔導等） 訓練協(xié)作對于自組織團隊的普遍誤解： 誤解2：團隊自己決定誰進入團隊； 糾正：管理層決定團隊上下文 誤解4：自組織團隊不需要管理者； 糾正：管理者從微觀管理轉(zhuǎn)向目標驅(qū)動、授權(quán)團隊的管理方式 誤解6：自組織團隊想干什么就干什么； 糾正：管理層決定團