前不久我在團(tuán)隊(duì)做過(guò)一段時(shí)間 Scrum Master， 當(dāng) Scrum Master 的實(shí)踐過(guò)程中，曾經(jīng)很淺略地做過(guò)一些關(guān)于迭代開(kāi)發(fā)的思考和總結(jié)（《關(guān)于迭代的一些思考》 ，不過(guò)里面關(guān)于 Scrum 框架和敏捷開(kāi)發(fā)大多是經(jīng)驗(yàn)和直覺(jué)上的認(rèn)知，缺少相應(yīng)理論知識(shí)的理解和支持。
為了更深入地理解 Scrum 框架和敏捷開(kāi)發(fā)，春節(jié)前后以及工作之余閱讀了一些關(guān)于敏捷和 Scrum 框架的書(shū)籍和文章，從中收獲頗多；恰逢 3 月 10、11 號(hào)公司作了敏捷培訓(xùn)，過(guò)程中我更是獲益匪淺，并且自己對(duì)于敏捷和 Scrum 的認(rèn)知和理解在培訓(xùn)中得到了進(jìn)一步的驗(yàn)證和調(diào)整。
所以，在這里我將敏捷和 Scrum 框架的相關(guān)知識(shí)做適當(dāng)?shù)娜∩帷⒄{(diào)整并整合起來(lái)（做知識(shí)的搬運(yùn)工），同時(shí)也把從理論和實(shí)踐所得的這些認(rèn)知和理解寫(xiě)出來(lái)，希望能就 如何使用 scrum 框架做敏捷開(kāi)發(fā) 這個(gè)主題做一個(gè)足夠的闡述。
注：敏捷或者 Scrum 框架的知識(shí)浩如煙海，難以用一篇文章將其說(shuō)透說(shuō)全，這里主要講解 Scrum 框架的重要組成部分 —— 角色、工件與活動(dòng)；另外敏捷或者 Scrum 不像實(shí)打?qū)嵉募夹g(shù)，里面很多觀點(diǎn)都可能比較主觀，希望自己認(rèn)知和理解的內(nèi)容能盡量客觀地對(duì)其作出闡述；當(dāng)然，由于知識(shí)和經(jīng)驗(yàn)有限，如有偏頗，歡迎探討和指正。
在下一章節(jié)，我們先來(lái)談?wù)勔幌旅艚蓍_(kāi)發(fā)，往后再繼續(xù)談 Scrum 框架。
敏捷開(kāi)發(fā)是一種從上個(gè)世紀(jì)九十年代開(kāi)始逐漸引起廣泛關(guān)注的一些新型軟件開(kāi)發(fā)方法，是一種應(yīng)對(duì)快速變化的需求的一種軟件開(kāi)發(fā)能力。常言道：“天下武功，唯快不破”，此言用于形容“敏捷”的威力相當(dāng)合適；但我更喜歡另一句西方諺語(yǔ)：“A chess novice can defeat a master if moving twice each round（如果允許一個(gè)新手一次走兩步，那么他就可以擊敗象棋大師）”。敏捷意思為快，但敏捷思想不僅僅求快，它更多強(qiáng)調(diào)“多快好省”，產(chǎn)出得多，產(chǎn)出得快，產(chǎn)出得好，同時(shí)節(jié)省各種成本，既經(jīng)濟(jì)又實(shí)用。
它們更強(qiáng)調(diào)程序員團(tuán)隊(duì)與業(yè)務(wù)專(zhuān)家之間的緊密協(xié)作、面對(duì)面的溝通（認(rèn)為比書(shū)面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團(tuán)隊(duì)、能夠很好地適應(yīng)需求變化的代碼編寫(xiě)和團(tuán)隊(duì)組織方法，也更注重軟件開(kāi)發(fā)過(guò)程中人的作用。
2001 年，17 位軟件開(kāi)發(fā)人員（包括來(lái)自于極限編程、Scrum、DSDM、自適應(yīng)軟件開(kāi)發(fā)、水晶系列、特征驅(qū)動(dòng)開(kāi)發(fā)、實(shí)效編程的代表們，還包括了希望找到文檔驅(qū)動(dòng)、重型軟件開(kāi)發(fā)過(guò)程的替代品的一些推動(dòng)者）齊聚猶他州的雪鳥(niǎo)鎮(zhèn)，共同探討一種輕量級(jí)的開(kāi)發(fā)方法。雪鳥(niǎo)會(huì)議上，所有的與會(huì)代表就使用『 敏捷 』一詞概括這種新型的輕量級(jí)方法達(dá)成了共識(shí)，并簽署且發(fā)表了《Manifesto for Agile Software Development》（即《敏捷軟件開(kāi)發(fā)宣言》），這成為敏捷開(kāi)發(fā)正式誕生的標(biāo)志，他們稱(chēng)自己為“敏捷聯(lián)盟”。
那么，究竟《敏捷軟件開(kāi)發(fā)宣言》都宣言了些什么呢？接下來(lái)我們仔細(xì)看看。
雪鳥(niǎo)會(huì)議上發(fā)表的《敏捷軟件開(kāi)發(fā)宣言》摘錄如下：
我們一直在實(shí)踐中探尋更好的軟件開(kāi)發(fā)方法，身體力行的同時(shí)也幫助他人。由此我們建立了如下價(jià)值觀：
個(gè)體和互動(dòng) 高于 流程和工具
工作的軟件 高于 詳盡的文檔
客戶(hù)合作 高于 合同談判
響應(yīng)變化 高于 遵循計(jì)劃
也就是說(shuō)，盡管右項(xiàng)有其價(jià)值，我們更重視左項(xiàng)的價(jià)值。
另外，宣言中還包括以下十二條原則：
我們最重要的目標(biāo)，是通過(guò)持續(xù)不斷地及早交付有價(jià)值的軟件使客戶(hù)滿(mǎn)意。
欣然面對(duì)需求變化，即使在開(kāi)發(fā)后期也一樣。為了客戶(hù)的競(jìng)爭(zhēng)優(yōu)勢(shì)，敏捷過(guò)程掌控變化。
經(jīng)常地交付可工作的軟件，相隔幾星期或一兩個(gè)月，傾向于采取較短的周期。
業(yè)務(wù)人員和開(kāi)發(fā)人員必須相互合作，項(xiàng)目中的每一天都不例外。
激發(fā)個(gè)體的斗志，以他們?yōu)楹诵拇罱?xiàng)目。提供所需的環(huán)境和支援，輔以信任，從而達(dá)成目標(biāo)。
不論團(tuán)隊(duì)內(nèi)外，傳遞信息效果最好效率也最高的方式是面對(duì)面的交談。
可工作的軟件是進(jìn)度的首要度量標(biāo)準(zhǔn)。
敏捷過(guò)程倡導(dǎo)可持續(xù)開(kāi)發(fā)。責(zé)任人、開(kāi)發(fā)人員和用戶(hù)要能夠共同維持其步調(diào)穩(wěn)定延續(xù)。
堅(jiān)持不懈地追求技術(shù)卓越和良好設(shè)計(jì)，敏捷能力由此增強(qiáng)。
以簡(jiǎn)潔為本，它是極力減少不必要工作量的藝術(shù)。
最好的架構(gòu)、需求和設(shè)計(jì)出自自組織團(tuán)隊(duì)。
團(tuán)隊(duì)定期地反思如何能提高成效，并依此調(diào)整自身的舉止表現(xiàn)
敏捷宣言中這些價(jià)值觀和原則，所謂入門(mén)容易精通難，在旁人或者入門(mén)者看來(lái)也許略顯空洞，所言無(wú)物；然而，敏捷精髓的實(shí)踐者們一直堅(jiān)信著這些理念，覺(jué)得它們字字珠璣，所言極是。不管我們是走敏捷的哪個(gè)流派，都不妨在實(shí)踐敏捷的過(guò)程中，回過(guò)頭來(lái)看看這些價(jià)值觀和原則，想必會(huì)?？闯Ｐ?，大有裨益。
以下思維導(dǎo)圖是其他具體的敏捷原則的說(shuō)明。
作為敏捷眾多流派中的被廣泛實(shí)踐的 Scrum 流派，同時(shí)也是我工作之后的兩年多時(shí)間里團(tuán)隊(duì)中使用的敏捷開(kāi)發(fā)方式，下一章我們來(lái)初步了解一下。
不過(guò)正式介紹 Scrum 框架之前，我想有必要先談?wù)勔粋€(gè)詞 ——『 敏捷型組織 』。在實(shí)踐敏捷的過(guò)程中，個(gè)人要敏捷，團(tuán)隊(duì)要敏捷，更重要的是組織也要敏捷，而且我認(rèn)為組織的敏捷是團(tuán)隊(duì)和個(gè)人真正實(shí)踐敏捷的重要基石。
組織結(jié)構(gòu)指的是一個(gè)組織內(nèi)部團(tuán)隊(duì)之間相互關(guān)系的布局。
它包括把員工分配到不同的部門(mén)和團(tuán)隊(duì)，也包括為了發(fā)號(hào)施令而安排的層次結(jié)構(gòu)。各公司有不同的組織結(jié)構(gòu)，職能型和矩陣型兩種基本結(jié)構(gòu)已經(jīng)使用多年，然而一種被稱(chēng)為敏捷型結(jié)構(gòu)的組織結(jié)構(gòu)更適用于軟件開(kāi)發(fā)行業(yè)。
我們先來(lái)看看這三種組織結(jié)構(gòu)：
2.4.1.1 職能型組織的含義
軍隊(duì)和工業(yè)界曾經(jīng)使用過(guò)職能型結(jié)構(gòu)的組織形式，這形式的結(jié)構(gòu)按照主要目的或職能來(lái)設(shè)置部門(mén)，基本上根據(jù)員工的基本職能來(lái)組織。在技術(shù)組織內(nèi)，按照職能的不同分成不同的部門(mén)，如工程部，質(zhì)量保證部，運(yùn)維部，項(xiàng)目管理部等；同時(shí)，每個(gè)部門(mén)都有自己的管理層級(jí)結(jié)構(gòu)，都有自己的負(fù)責(zé)人。在工程部，工程師向工程經(jīng)理匯報(bào)，工程經(jīng)理向工程副總匯報(bào)；在其他部門(mén)的匯報(bào)關(guān)系類(lèi)似。
2.4.1.2 職能型組織的優(yōu)缺點(diǎn)
這種職能型組織結(jié)構(gòu)很多優(yōu)點(diǎn)，比如
所有的經(jīng)理幾乎都是按照層級(jí)提升的；
員工在專(zhuān)業(yè)性方面也容易取得一致，技術(shù)相關(guān)的同事們（包括經(jīng)理）很容易回答涉及技術(shù)方面的問(wèn)題，整個(gè)機(jī)構(gòu)都是按照專(zhuān)業(yè)分工來(lái)組織的，經(jīng)理和工作伙伴具有同質(zhì)性；
職責(zé)明確、容易分配任務(wù)、更好地遵循標(biāo)準(zhǔn)規(guī)范，這種簡(jiǎn)潔性使得工作分配極為容易。
當(dāng)然，職能型組織結(jié)構(gòu)有它的問(wèn)題：
缺乏單一的項(xiàng)目負(fù)責(zé)人；
跨部門(mén)的溝通效果不佳；
部門(mén)間存在情感性沖突。
考慮到這些利弊，當(dāng)其同質(zhì)性的好處超過(guò)整體協(xié)調(diào)和所有權(quán)帶來(lái)的問(wèn)題的時(shí)候，可以考慮采用職能型組織結(jié)構(gòu)。比如，采用瀑布式開(kāi)發(fā)的組織，經(jīng)常能從按職能劃分的組織結(jié)構(gòu)中獲益。因?yàn)樵摻Y(jié)構(gòu)下號(hào)與瀑布型方法中固有的階段控制相匹配。
2.4.2.1 矩陣型組織的含義
盡管職能型組織結(jié)構(gòu)有一些不可否認(rèn)的優(yōu)點(diǎn)，但仍存在弊端。為了克服這個(gè)問(wèn)題，公司甚至軍事機(jī)構(gòu)演化出矩陣型組織。矩陣型組織機(jī)構(gòu)的主要概念是層級(jí)的兩個(gè)維度。在職能型組織的每個(gè)團(tuán)隊(duì)有一個(gè)經(jīng)理，每個(gè)團(tuán)隊(duì)的成員向一個(gè)老板匯報(bào)；而矩陣型組織與職能型組織相反，包括至少兩個(gè)管理維度，每個(gè)團(tuán)隊(duì)的成員或許有兩個(gè)或多個(gè)老板，比如，傳統(tǒng)的職能組織旁邊增加了項(xiàng)目管理團(tuán)隊(duì)。
如上圖，深藍(lán)色標(biāo)注的員工，包括項(xiàng)目經(jīng)理 1、工程師 1、工程師 2、質(zhì)量保證工程師 1、質(zhì)量保證工程師 2、產(chǎn)品 1、產(chǎn)品 2 組成了一個(gè)項(xiàng)目團(tuán)隊(duì)在一起工作；深藍(lán)色標(biāo)注的員工組成一個(gè)團(tuán)隊(duì)；橙色標(biāo)注的員工又組成另一個(gè)團(tuán)隊(duì)；每個(gè)團(tuán)隊(duì)里的項(xiàng)目經(jīng)理對(duì)任務(wù)分配和項(xiàng)目進(jìn)度負(fù)有責(zé)任。在更大和更復(fù)雜的組織里，許多來(lái)自不同團(tuán)隊(duì)的人可以屬于同一個(gè)項(xiàng)目團(tuán)隊(duì)。
2.4.2.2 矩陣型組織的優(yōu)缺點(diǎn)
職能型組織的是三個(gè)問(wèn)題：缺乏單一的項(xiàng)目負(fù)責(zé)人；跨部門(mén)的溝通效果不佳；部門(mén)間存在情感性沖突。而在矩陣型組織里，存在以下優(yōu)點(diǎn)：
項(xiàng)目團(tuán)隊(duì)負(fù)責(zé)解決所有的問(wèn)題，承擔(dān)項(xiàng)目的所有責(zé)任；
項(xiàng)目組會(huì)頻繁地開(kāi)會(huì)和郵件溝通來(lái)解決溝通不佳的問(wèn)題。
同樣的，矩陣型組織也有其弊端：
獨(dú)立貢獻(xiàn)者向多個(gè)有不同優(yōu)先級(jí)的經(jīng)理匯報(bào)，壓力增加；
比如工程師現(xiàn)在工程經(jīng)理和項(xiàng)目經(jīng)理之間，工程經(jīng)理讓他按照標(biāo)準(zhǔn)寫(xiě)代碼，項(xiàng)目經(jīng)理堅(jiān)持必須按時(shí)完成任務(wù)，工程師面臨壓力和憂(yōu)慮，擔(dān)心自己的表現(xiàn)不能讓經(jīng)理們滿(mǎn)意。
個(gè)人精力分散，項(xiàng)目團(tuán)隊(duì)本身也需要很多會(huì)議和郵件來(lái)維持項(xiàng)目的進(jìn)展，占用更多的個(gè)人時(shí)間。
矩陣型組織結(jié)構(gòu)解決了一些問(wèn)題的同時(shí)，又引入了一些新的問(wèn)題。假如保持職能型和矩陣型組織結(jié)構(gòu)的優(yōu)點(diǎn)，“是否有更好的辦法？”答案是“有”，這就是“敏捷型組織”。
2.4.3.1 敏捷型組織的含義
隨著從提供軟件向提供服務(wù)方向的發(fā)展（SaaS —— 軟件即服務(wù)，現(xiàn)在還有 PaaS —— 平臺(tái)即服務(wù) 和 IaaS —— 基礎(chǔ)架構(gòu)即服務(wù)），技術(shù)人員開(kāi)始思考如何做個(gè)好的服務(wù)提供者而不是軟件開(kāi)發(fā)者。伴隨著這一演進(jìn)，人們開(kāi)始思考服務(wù)的質(zhì)量和可靠性。另外，敏捷開(kāi)發(fā)方式的出現(xiàn)，還有職能型和矩陣型組織弊端的存在，使被稱(chēng)為敏捷型的新組織結(jié)構(gòu)應(yīng)運(yùn)而生。
我們把跨職能同時(shí)符合服務(wù)架構(gòu)的組織，標(biāo)示為敏捷性組織。在這種組織中，團(tuán)隊(duì)是完全自主管理和自給自足的。從形成概念，到研發(fā)，再到生產(chǎn)系統(tǒng)中的服務(wù)支持，團(tuán)隊(duì)負(fù)有全部的責(zé)任。跨職能部門(mén)的額總監(jiān)、副總裁以及敏捷型團(tuán)隊(duì)替代了工程副總裁這樣的常規(guī)管理角色。
2.4.3.1 敏捷型組織的優(yōu)缺點(diǎn)
敏捷性組織具有如下優(yōu)點(diǎn)：
組織邊界適當(dāng)變小，有效地降低情感性沖突（部門(mén)或者團(tuán)隊(duì)之間的互相推諉和相互抱怨）；組織人員豐富多樣，提高認(rèn)知性沖突（經(jīng)驗(yàn)、技能和關(guān)系的多樣性帶來(lái)更優(yōu)的解決方案）；
沖突有好壞之分，好的沖突（認(rèn)知型沖突）是健康的爭(zhēng)辯，是團(tuán)隊(duì)關(guān)于該做什么或者為什么要做（以及該怎么做）而發(fā)生的沖突，它涉及更大的視角和更多的經(jīng)驗(yàn)；壞的沖突（情感型沖突）基于角色，經(jīng)常涉及該誰(shuí)做，糾纏不清的基于角色的討論往往被認(rèn)為是政治性或者領(lǐng)地性的，如果處理不當(dāng)會(huì)對(duì)團(tuán)隊(duì)產(chǎn)生不良影響。
認(rèn)知型沖突有助于團(tuán)隊(duì)擴(kuò)大行動(dòng)的可能范圍，不同的見(jiàn)解和經(jīng)驗(yàn)湊在一起有機(jī)會(huì)從多角度出發(fā)解決難題；
情感型沖突會(huì)帶來(lái)組織的創(chuàng)傷，結(jié)果會(huì)在戰(zhàn)術(shù)和戰(zhàn)略上限制選擇，爭(zhēng)斗關(guān)閉了我們思維的選擇空間，意味著結(jié)果可能不是最佳的。
通過(guò)營(yíng)造開(kāi)發(fā)、尊重的文化氛圍，推動(dòng)健康的爭(zhēng)辯，吸納各類(lèi)人在技能和視野上互補(bǔ)，最大化策略的選擇范圍，把認(rèn)知性沖突最大化，情感型沖突最小化，讓團(tuán)隊(duì)快速成長(zhǎng)。
團(tuán)隊(duì)共享一個(gè)目標(biāo)，榮辱與共，不再爭(zhēng)論誰(shuí)負(fù)責(zé)什么或誰(shuí)應(yīng)該執(zhí)行哪些任務(wù)，個(gè)體對(duì)提供高質(zhì)量、高可用性并能滿(mǎn)足商業(yè)目標(biāo)的服務(wù)負(fù)有更多的責(zé)任，并有能力處理產(chǎn)品或服務(wù)的全生命周期；
團(tuán)隊(duì)被充分授權(quán)，有權(quán)力做出決定，高效地完成高質(zhì)量的任務(wù)的動(dòng)力更足，能進(jìn)行產(chǎn)品的自主研發(fā)；
團(tuán)隊(duì)溝通協(xié)作更為充分和順暢，信息共享更為實(shí)時(shí)，提高團(tuán)隊(duì)的創(chuàng)造力與表現(xiàn)水平。
敏捷性組織的缺點(diǎn)：
敏捷性組織去除了部門(mén)傳統(tǒng)的管理角色，比如“工程副總裁”，有組織架構(gòu)調(diào)整的緩沖期；
敏捷性組織需要原來(lái)團(tuán)隊(duì)按照組織設(shè)計(jì)中面向用戶(hù)的服務(wù)重新組織。
沒(méi)有一個(gè)組織結(jié)構(gòu)是完美的，即便敏捷型組織存在著弊端，那些正在掙扎著試圖解決不良的服務(wù)支持、大量的沖突、員工自我驅(qū)動(dòng)力不強(qiáng)和整體缺乏創(chuàng)新的公司來(lái)說(shuō)，敏捷型組織模式是個(gè)理想的選擇。
我個(gè)人一個(gè)淺薄的觀點(diǎn)：公司內(nèi)部建設(shè)走“戰(zhàn)區(qū)主戰(zhàn)，軍種主建”之路，其中的“戰(zhàn)區(qū)”正是由相應(yīng)的業(yè)務(wù)、產(chǎn)品，研發(fā)，測(cè)試、運(yùn)維，設(shè)計(jì)等主力提供智能投顧和余額代償服務(wù)的相關(guān)人員共同組成的敏捷型組織的陣地。
敏捷的相關(guān)知識(shí)介紹到此，接下來(lái)主要是介紹 Scrum 框架，首先從 Scrum 的含義、起源和發(fā)展開(kāi)始。
Scrum 在英語(yǔ)中是『 英式橄欖球運(yùn)動(dòng)中爭(zhēng)球』的意思，在爭(zhēng)球過(guò)程中，兩個(gè)隊(duì)的前鋒在球前面圍成一圈，彼此的胳膊架在一起，低頭爭(zhēng)奪球權(quán)，此時(shí)球隊(duì)兩軍對(duì)壘，劍拔弩張，環(huán)境變化很快，如果團(tuán)隊(duì)沒(méi)有共同目標(biāo)和方向，力量分散，很難搶到球。
當(dāng)搶到球后，必須把球往后場(chǎng)傳遞以便得分，這又需要球隊(duì)作為一個(gè)整體具有高度的默契與高超的技巧才辦得到。
最后賽場(chǎng)上所有球員處于同一時(shí)間和空間，賽場(chǎng)的秋毫變化（球的位置、隊(duì)友的位置、敵對(duì)人員的位置、觀眾的加油聲、團(tuán)隊(duì)士氣與人員狀況、天氣與球場(chǎng)的狀況、裁判的表現(xiàn)和教練的戰(zhàn)術(shù)等等的變化）都被實(shí)時(shí)共享，大家瞬間聚力討論快速?zèng)Q策適應(yīng)這些變化，這樣的狀態(tài)對(duì)于取得爭(zhēng)球的勝利是至關(guān)重要的。
在軟件開(kāi)發(fā)歷史過(guò)程中，Scrum 先驅(qū)們將 Scrum 這個(gè)詞的隱喻應(yīng)用于軟件開(kāi)發(fā)。它是一套輕量級(jí)的核心價(jià)值觀、原則和實(shí)踐，統(tǒng)稱(chēng)為 Scrum 框架，在這個(gè)框架中人們可以解決復(fù)雜的自適應(yīng)問(wèn)題，同時(shí)也能高效并有創(chuàng)造性地交付盡可能高價(jià)值的產(chǎn)品。
在這個(gè)框架下，我們可以檢驗(yàn) Scrum 團(tuán)隊(duì)是否符合 Scrum 原意的要求：
團(tuán)隊(duì)成員是否有共同目標(biāo)？
團(tuán)隊(duì)成員是否開(kāi)誠(chéng)布公地緊密合作？
團(tuán)隊(duì)成員是否經(jīng)常檢視和調(diào)整？
團(tuán)隊(duì)成員是否各自發(fā)一顆球（各做各的用戶(hù)故事等），各自努力往后場(chǎng)沖刺以爭(zhēng)取個(gè)人績(jī)效？
......
如果我們的 Scrum 團(tuán)隊(duì)遭遇困難，可以思考一下如何向優(yōu)秀的球隊(duì)學(xué)習(xí)，也許是一個(gè)突破困境的機(jī)會(huì)。在進(jìn)一步探討 Scrum 框架之前，我們先來(lái)了解一下 Scrum 的起源和發(fā)展。
1986 年，『 竹內(nèi)弘高 』和『 野中郁次郎 』在《哈佛商業(yè)評(píng)論》中刊登一篇題為“新型新產(chǎn)品開(kāi)發(fā)策略（The New New Product Development Game）”的文章，將橄欖球和爭(zhēng)球—— Scrum 的隱約應(yīng)用于軟件開(kāi)發(fā)：
產(chǎn)品開(kāi)發(fā)的“接力賽”方式......可能和要求最快，最靈活的目標(biāo)有沖突。一種整體方式或“橄欖球”方式（即團(tuán)隊(duì)作為一個(gè)整體打完比賽，來(lái)回傳球），也許能夠更好地迎合當(dāng)下的競(jìng)爭(zhēng)需求。
（英文原文：The traditional sequential or “relay race” approach to product development—exemplified by the National Aeronautics and Space Administration’s phased program planning (PPP) system—may conflict with the goals of maximum speed and flexibility. Instead, a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.）
這篇文章描述了本田、佳能、富士施樂(lè)這樣的公司是如何通過(guò)可伸縮、基于團(tuán)隊(duì)的“蜂擁式”的方式開(kāi)發(fā)世界一流的產(chǎn)品。
1993 年，被譽(yù)為 Scrum 之父的其中一位 —— Jeff Sutherland（曾參與敏捷軟件開(kāi)發(fā)宣言的起草，是Scrum的共同發(fā)明人，現(xiàn)為Scrum基金會(huì)總裁） 和他的團(tuán)隊(duì)把 1986 年竹內(nèi)弘高 和野中郁次郎那篇文章的概念與面向?qū)ο箝_(kāi)發(fā)，基于經(jīng)驗(yàn)的過(guò)程控制、迭代和增量開(kāi)發(fā)、軟件過(guò)程和生產(chǎn)率研究、復(fù)雜適應(yīng)系統(tǒng)中的概念結(jié)合起來(lái)，創(chuàng)立了用于指導(dǎo)軟件開(kāi)發(fā)工作的 Scrum 過(guò)程。
1995 年，被譽(yù)為 Scrum 之父的另外一位 —— Ken Schwaber（敏捷軟件開(kāi)發(fā)宣言的17位發(fā)起人之一，與 Jeff Sutherland 合作，共同建立了 Scrum 軟件開(kāi)發(fā)方法）在 OOPSLA 上發(fā)表第一篇關(guān)于 Scrum 的論文 —— 《SCRUM 開(kāi)發(fā)過(guò)程（SCRUM Development Process）》。
此后，Sutherland 和 Schwaber 一起完成了一份關(guān)于 Scrum 的重要文檔 ——《Scrum 指南（The Scrum Guide）》。兩位 Scrum 先驅(qū)把這本指南描述為 “Scrum 金科玉律，Scrum 專(zhuān)有文檔”，并把它比作是象棋游戲的游戲規(guī)則說(shuō)明：“描述棋子（各個(gè)部件）的行走規(guī)則，順序，輸贏如何定義，等等。”盡管指南有像說(shuō)明書(shū)一樣的價(jià)值，但是這本身也是指南的局限 —— 我們并不能僅依靠一份說(shuō)明書(shū)就能把象棋下好，關(guān)于 Scrum 更多的原則，價(jià)值和實(shí)踐需要進(jìn)一步的去探討。
在日常開(kāi)發(fā)中，我們經(jīng)常定義迭代名為 Sprint 1、Sprint 2 ... Sprint N，這里 Sprint 的英文原意是沖刺的意思，所以對(duì)應(yīng)著 Sprint 1、Sprint 2 更合適的稱(chēng)呼是沖刺 1、沖刺 2。但這里更想強(qiáng)調(diào)的一點(diǎn)是，迭代式開(kāi)發(fā)，增量式開(kāi)發(fā)和沖刺開(kāi)發(fā)不僅僅是術(shù)語(yǔ)的不同，其在開(kāi)發(fā)方式上也是有區(qū)別的。
基于的觀念：
承認(rèn)在把事情做對(duì)之前有可能做錯(cuò)，在把事情做好之前有可能做壞；
迭代式開(kāi)發(fā)本身是一種有計(jì)劃修改的開(kāi)發(fā)策略：
通過(guò)多次開(kāi)發(fā)來(lái)改善正在構(gòu)建的特性，逐步得到一個(gè)完善的解決方案；
例如，對(duì)一個(gè)知之甚少的產(chǎn)品：
開(kāi)始時(shí)可以先創(chuàng)建原型以獲得重要知識(shí)；
接著可以創(chuàng)建一個(gè)更好一點(diǎn)的修改版；
在接下來(lái)是一個(gè)相對(duì)好的版本；
最后得到想要的完整的產(chǎn)品；
優(yōu)點(diǎn)：
改進(jìn)產(chǎn)品的一種非常好的方式
缺點(diǎn)：
在遇到不確定因素時(shí)，很難實(shí)現(xiàn)確定需要改進(jìn)多少次。
基于的原則：
先構(gòu)建部分，再構(gòu)建整體；
增量式開(kāi)發(fā)是一種逐步增加特性的開(kāi)發(fā)策略：
把產(chǎn)品分解成更小的特性，先構(gòu)建一部分，在從中了解它們?cè)谀繕?biāo)使用環(huán)境中的具體情形，然后根據(jù)更多的理解來(lái)做出調(diào)整，構(gòu)建更多的特性。
優(yōu)點(diǎn)：
過(guò)程中獲得重要的信息，使我們能夠適應(yīng)開(kāi)發(fā)工作并改變工作方式
缺點(diǎn)：
逐步構(gòu)建的過(guò)程中，有迷失全局的風(fēng)險(xiǎn)（見(jiàn)木不見(jiàn)林）
基于的觀念：
同時(shí)利用迭代式開(kāi)發(fā)和增量式開(kāi)發(fā)優(yōu)點(diǎn)，消除兩者的缺點(diǎn)，即既迭代又增量。
沖刺開(kāi)發(fā)是一種使用固定時(shí)間盒來(lái)適應(yīng)性迭代產(chǎn)品增量的開(kāi)發(fā)策略：
在沖刺內(nèi)做完所有的相關(guān)階段工作（分析、設(shè)計(jì)、開(kāi)發(fā)、測(cè)試、集成等），而不是一個(gè)階段工作，創(chuàng)建可工作的產(chǎn)品增量（產(chǎn)品的部分特性而不是全部）。
這個(gè)增量需要包含前期已開(kāi)發(fā)的特性，或者需要與前期已開(kāi)發(fā)的特性集成與測(cè)試，而不是分離的特性并且沒(méi)有與前期的特性集成，否則就不能被認(rèn)為完成。
沖刺每次做一個(gè)或多個(gè)特性，這樣能快速地修改特性，體會(huì)到迭代式開(kāi)發(fā)的好處，同時(shí)又不必特意為后面的迭代制定計(jì)劃。
優(yōu)點(diǎn)：
沖刺完成獲取相關(guān)反饋后，我們可以進(jìn)行調(diào)整，在接下來(lái)的沖刺中可以選擇開(kāi)發(fā)其他特性（評(píng)審檢視產(chǎn)品）或者修改用于構(gòu)建下一組特性的過(guò)程（回顧檢視過(guò)程），這有助于解決實(shí)現(xiàn)不知道需要改進(jìn)多少次的問(wèn)題。沖刺開(kāi)發(fā)不需要提前確定迭代次數(shù)，在增量開(kāi)發(fā)產(chǎn)品時(shí)，持續(xù)不斷的反饋能做到迭代次數(shù)合理，經(jīng)濟(jì)合理。
沖刺思想的一種誤用：
每個(gè)沖刺只做一種類(lèi)型的工作 —— 例如，沖刺 1（分析）、沖刺 2（設(shè)計(jì)）、沖刺 3（編碼）、沖刺 4（測(cè)試）。這種做法是把 Scrum 披上瀑布式開(kāi)發(fā)的皮 —— 被戲稱(chēng)為 WaterScrum 或者 Scrummerfall。
這一節(jié)主要是簡(jiǎn)單描述一下 Scrum 的概要框架，讓大家有個(gè)初步的認(rèn)識(shí)，后面會(huì)有關(guān)于 Scrum 框架更為詳細(xì)的說(shuō)明。
上圖描述了一個(gè) Scrum 沖刺的概要框架，就像大家所熟知的那樣：
『 產(chǎn)品列表 』首先要建立產(chǎn)品列表 —— 一個(gè)按優(yōu)先級(jí)排序的、有粗略估算的、成功開(kāi)發(fā)產(chǎn)品所需特性及其他功能的列表。
在產(chǎn)品列表的指導(dǎo)下，我們總是先做優(yōu)先級(jí)最高的條目（比如上圖中的特性 A、B、C）；
換句話(huà)說(shuō)就是，當(dāng)一個(gè)沖刺完成時(shí)，已完成的條目都是優(yōu)先級(jí)最高的。
『 沖刺計(jì)劃會(huì) 』一般情況下，產(chǎn)品列表中的工作量遠(yuǎn)遠(yuǎn)不是一個(gè)短期沖刺內(nèi)能夠完成的。所以沖刺開(kāi)始時(shí)，團(tuán)隊(duì)需要制定計(jì)劃，說(shuō)明在下一個(gè)沖刺中要?jiǎng)?chuàng)建產(chǎn)品列表中的哪幾個(gè)高優(yōu)先級(jí)的特性。
『 沖刺 』工作本身是在一些短周期、時(shí)長(zhǎng)固定的沖刺中完成的，每個(gè)沖刺從一周到一個(gè)月。
在每個(gè)沖刺中，自組織，跨職能的團(tuán)隊(duì)完成所有必需的工作 —— 例如設(shè)計(jì)、開(kāi)發(fā)、構(gòu)建和測(cè)試 —— 產(chǎn)生完整的、可工作的、可以放入產(chǎn)品的特性。
『 沖刺評(píng)審會(huì)回顧會(huì) 』在沖刺結(jié)束時(shí)，團(tuán)隊(duì)與利益干系人一起評(píng)審已經(jīng)完成的特性，獲得它們的反饋，產(chǎn)品負(fù)責(zé)人和團(tuán)隊(duì)既可以對(duì)下一步工作內(nèi)容進(jìn)行修改（在評(píng)審會(huì)上），也可以修改以前的工作方式（在回顧會(huì)上）。
評(píng)審會(huì)上，如果利益干系人在看到一個(gè)完成的特性時(shí)，意識(shí)到自己沒(méi)有考慮到另一個(gè)必須包含在產(chǎn)品中的特性，此時(shí)，產(chǎn)品負(fù)責(zé)人只需要建立一個(gè)代表該特性的新條目，并把它以適當(dāng)?shù)挠芯€順序插入產(chǎn)品列表，留到后面的沖刺中完成。
回顧會(huì)上，如果開(kāi)發(fā)團(tuán)隊(duì)在回顧沖刺過(guò)程中，意識(shí)到自己沒(méi)有考慮到依賴(lài)風(fēng)險(xiǎn)導(dǎo)致開(kāi)發(fā)過(guò)程不必要的等待時(shí)，開(kāi)發(fā)團(tuán)隊(duì)可以提出下一沖刺計(jì)劃會(huì)上考慮依賴(lài)風(fēng)險(xiǎn)并做好相應(yīng)的控制。
『 潛在可發(fā)布產(chǎn)品增量 』在沖刺結(jié)束時(shí)，團(tuán)隊(duì)?wèi)?yīng)當(dāng)?shù)玫揭粋€(gè)潛在可發(fā)布產(chǎn)品（或者產(chǎn)品增量）。如果業(yè)務(wù)上適合，就可以發(fā)布；如果不適合在每次沖刺后發(fā)布，可以把多個(gè)沖刺的一組特性合并在一起發(fā)布。
到這里為止，我們對(duì) Scrum 框架有了個(gè)初步的了解，這時(shí)候我們可能會(huì)有疑問(wèn)，為什么我們要使用這樣的框架來(lái)做軟件開(kāi)發(fā)呢？它適用于所有的軟件開(kāi)發(fā)活動(dòng)嗎？下面一節(jié)我們來(lái)做個(gè)簡(jiǎn)單的探討。
我們先來(lái)看一下著名的 Cynefin 框架，它可以幫助我們更好地理解工作環(huán)境并確定適合的工作方式。
Cynefin 框架最早是在 1999 年威爾士學(xué)者 Dave Snowden 在知識(shí)管理和組織戰(zhàn)略中提出的。Cynefin 是威爾士語(yǔ)，意為 “棲息地” 或 “住所”，指人們對(duì)生活環(huán)境的共同文化、宗教、地理和部落的總體經(jīng)驗(yàn)和感受。這個(gè)框架用于描述問(wèn)題、環(huán)境與系統(tǒng)，說(shuō)明什么環(huán)境適合使用什么解決方案。
Cynefin 框架定義了五種域：復(fù)雜、繁雜、混亂
、簡(jiǎn)單和無(wú)序，并且比較了各個(gè)域的差別，以及描述了 Scrum 適合哪些域。
特征與處理方式：
在處理復(fù)雜問(wèn)題時(shí)，不可預(yù)測(cè)性 > 可預(yù)測(cè)性
如果有正確答案，也只有事后才知道
問(wèn)題是涌現(xiàn)的。
需要研究探索才能認(rèn)識(shí)問(wèn)題、進(jìn)而根據(jù)認(rèn)知進(jìn)行檢視、調(diào)整
處理復(fù)雜問(wèn)題需要?jiǎng)?chuàng)造性的創(chuàng)新的方法
需要為試驗(yàn)活動(dòng)營(yíng)造一個(gè)容忍失敗的環(huán)境，以便獲取重要信息
大量的互動(dòng)和交流必不可少
Scrum 框架適用性： 特別適用
適用的軟件開(kāi)發(fā)活動(dòng)舉例： 創(chuàng)新的新產(chǎn)品的開(kāi)發(fā)
特征與處理方式：
在處理繁雜問(wèn)題時(shí)，可預(yù)測(cè)性 > 不可預(yù)測(cè)性
因果可以發(fā)現(xiàn)，但不是很明顯
可能有很多正確答案，需要專(zhuān)家診斷并找出這些答案
繁雜問(wèn)題是專(zhuān)家控制的良好實(shí)踐域
通過(guò)測(cè)量數(shù)據(jù)獲得控制權(quán)
Scrum 框架適用性： 適用，但非最佳方案
適用的軟件開(kāi)發(fā)活動(dòng)舉例： 1. 性能優(yōu)化（性能優(yōu)化工作需要調(diào)整參數(shù)來(lái)找出系統(tǒng)的最佳整體性能，這個(gè)問(wèn)題最好能找到專(zhuān)家，讓他們?cè)u(píng)估情況，調(diào)研幾種備選方案，根據(jù)實(shí)踐做出響應(yīng)）2. 軟件日常運(yùn)維
特征與處理方式：
在處理混亂問(wèn)題時(shí)，需要快速度響應(yīng)，立即采取行動(dòng)，然后檢視，看情況是否穩(wěn)定，然后調(diào)整并把環(huán)境遷到復(fù)雜域中
需要作出很多決定，沒(méi)有時(shí)間思考
立即采取行動(dòng)，重新建立秩序
尋找可行（而非正確的）答案
新領(lǐng)域，沒(méi)有人知道
沒(méi)有清晰的因果關(guān)系
Scrum 框架適用性： 適用，但非最佳方案
適用的軟件開(kāi)發(fā)活動(dòng)舉例： 1. 突發(fā)情況（已經(jīng)沒(méi)時(shí)間再排列優(yōu)先級(jí)并確定下個(gè)迭代做什么工作，需要立即采取行動(dòng)，果斷止損）；2. 處理外部依賴(lài)缺陷（比如通過(guò)立即升級(jí)來(lái)處理 fastjson 缺陷）
特征與處理方式：
在處理簡(jiǎn)單問(wèn)題時(shí)，因果關(guān)系顯而易見(jiàn)
問(wèn)題和解決方案相對(duì)穩(wěn)定，不太可能變更
有已知的解決方案，評(píng)估后選一種合適的解決方案。
評(píng)估實(shí)際情況，將情況分類(lèi)，根據(jù)已經(jīng)確定的時(shí)間提出響應(yīng)措施
適合使用一組明確的、可重復(fù)的、已知能夠解決問(wèn)題的步驟
Scrum 框架適用性： 適用，但非最佳方案
適用的軟件開(kāi)發(fā)活動(dòng)舉例： 1. 生產(chǎn)同樣的產(chǎn)品；2. 部署環(huán)境
如果不知道自己處于哪個(gè)域，說(shuō)明就是在無(wú)序域中。因?yàn)闊o(wú)法理解自己的處境，所以這個(gè)域很危險(xiǎn)；如果處于無(wú)序域，要考慮的不是在無(wú)序域中如何使用 Scrum，而是要盡早擺脫這個(gè)域；擺脫無(wú)序域需要把問(wèn)題分解為小的組成部分，并安排到另外 4 種域之一中。
特征與處理方式：
不知今后很長(zhǎng)一段時(shí)間有多少工作，無(wú)法為一周或者更長(zhǎng)時(shí)間的迭代指定可行的計(jì)劃，即便知道有多少工作，也很可能收到高優(yōu)先級(jí)的支持請(qǐng)求并把預(yù)定的長(zhǎng)遠(yuǎn)計(jì)劃替換掉（比如客服）
Scrum 框架適用性：不適用，適合看板
適用的軟件開(kāi)發(fā)活動(dòng)舉例： 1. 常常被打斷的支持與維護(hù)工作（非日常運(yùn)維）
從上一節(jié)的 Cynefin 框架可知，Scrum 框架最適用于復(fù)雜域、適用于繁雜域但非最佳。如果我們的軟件開(kāi)發(fā)活動(dòng)所處的領(lǐng)域很復(fù)雜，未知的東西比已經(jīng)的多，那么我們需要一種開(kāi)發(fā)方式，能夠讓我們快速探索新想法和新方法，快速了解哪些解決方案可行、哪些不可行（即快速探索和反饋）。
如果把沒(méi)有采用敏捷（或者 Scrum ）而是采用傳統(tǒng)開(kāi)發(fā)方式或者沒(méi)有任何開(kāi)發(fā)方式的業(yè)務(wù)人員和開(kāi)發(fā)人員找到一起，問(wèn)他們“你們對(duì)軟件開(kāi)發(fā)工作的結(jié)果感到滿(mǎn)意嗎？”或者“你們認(rèn)為我們是否及時(shí)、經(jīng)濟(jì)、高質(zhì)量地交付了良好的客戶(hù)價(jià)值？”，通常他們的回答都是“否”，并如出一轍地補(bǔ)充說(shuō)：
“項(xiàng)目失敗率高得讓人無(wú)法接受”；
“交付日期延遲了”；
“投資帶來(lái)的匯報(bào)常常打不到預(yù)期”；
“軟件質(zhì)量很差”；
“生產(chǎn)率低得讓人羞愧”；
“沒(méi)有人對(duì)結(jié)果負(fù)責(zé)”；
“員工士氣低落”；
......
而認(rèn)真踏實(shí)地使用 Scrum 的團(tuán)隊(duì)和組織，卻是另一番不一樣的情況。
這些組織或者團(tuán)隊(duì)總是讓客戶(hù)感到滿(mǎn)意，他們不僅僅交付了客戶(hù)第一天在對(duì)真正需求知之甚少的情況下提出的功能，而且交付了客戶(hù)真正想要的功能；
他們還頻繁地發(fā)布了較小的版本并由此提升了投資回報(bào)；
而且，毫不留情地暴露組織功能失調(diào)和浪費(fèi)的地方，還為他們節(jié)約了成本。
Scrum 關(guān)注在每個(gè)沖刺交付可以工作的、集成好的、經(jīng)過(guò)測(cè)試的、具有業(yè)務(wù)價(jià)值的特性，力爭(zhēng)更快交付成果。處于復(fù)雜域的組織必須根據(jù)競(jìng)爭(zhēng)對(duì)手、客戶(hù)、用戶(hù)、監(jiān)管部門(mén)和其他利益干系人的互動(dòng)快速做出調(diào)整，Scrum 能很好地幫助他們?nèi)〉贸晒Α?/span>
本章節(jié)會(huì)詳細(xì)講解 Scrum 框架的各大角色、工件以及活動(dòng)。
參考下圖，圖中綠色標(biāo)記的是三大角色（產(chǎn)品負(fù)責(zé)人、Scrum Master、開(kāi)發(fā)團(tuán)隊(duì)）、藍(lán)色部分標(biāo)記的是三大工件（產(chǎn)品列表、沖刺列表、潛在可交付產(chǎn)品增量）、橙色標(biāo)記的是七大活動(dòng)（沖刺、產(chǎn)品列表梳理、沖刺計(jì)劃會(huì)、沖刺執(zhí)行、每日站會(huì)、沖刺評(píng)審會(huì)、沖刺回顧會(huì)）。
是有授權(quán)的產(chǎn)品領(lǐng)導(dǎo)力中心，是唯一有權(quán)決定要構(gòu)建哪些特性并以何種順序構(gòu)建這些特性的人；
需要保持一個(gè)清晰的構(gòu)想并把它傳遞給每一個(gè)參與者(包括利益干系人、開(kāi)發(fā)團(tuán)隊(duì)等)；
產(chǎn)品負(fù)責(zé)人的身份決定他要對(duì)正在開(kāi)發(fā)和維護(hù)的解決方案全面負(fù)責(zé)；
還有責(zé)任確?？偰?span>完成價(jià)值最高的工作（可能包括偏技術(shù)的工作）；
與 Scrum Master 和開(kāi)發(fā)團(tuán)隊(duì)積極合作，及時(shí)解答 Scrum Master 和開(kāi)發(fā)團(tuán)隊(duì)提出的問(wèn)題。
產(chǎn)品負(fù)責(zé)人勾勒產(chǎn)品愿景、為產(chǎn)品指明方向、計(jì)劃開(kāi)發(fā)節(jié)奏、考慮開(kāi)發(fā)成本等，他責(zé)任重大，一方面要理解組織中利益干系人、客戶(hù)、用戶(hù)（有時(shí)候還包括開(kāi)發(fā)團(tuán)隊(duì)）的需求，是他們的代言人，擔(dān)任的是產(chǎn)品經(jīng)理的角色；另一方面，對(duì)正在開(kāi)發(fā)的特性和開(kāi)發(fā)順序，要和開(kāi)發(fā)團(tuán)隊(duì)緊密合作，驗(yàn)收開(kāi)發(fā)出來(lái)的產(chǎn)品，擔(dān)任的是業(yè)務(wù)分析員和測(cè)試人員的角色。
以下思維導(dǎo)圖是產(chǎn)品負(fù)責(zé)人主要職責(zé)的說(shuō)明。
雖然優(yōu)秀的產(chǎn)品負(fù)責(zé)人體現(xiàn)出很多特征或技能，但可以歸為四類(lèi)：領(lǐng)域知識(shí)，人際交往能力，決策力和責(zé)任心。
以下思維導(dǎo)圖是產(chǎn)品負(fù)責(zé)人主要特征或技能的說(shuō)明。
為了更好地理解產(chǎn)品負(fù)責(zé)人的職責(zé)，這里也通過(guò)一張圖大致列一下產(chǎn)品負(fù)責(zé)人的日常工作內(nèi)容。
以下圖片是產(chǎn)品負(fù)責(zé)人主要日常工作內(nèi)容的說(shuō)明。
負(fù)責(zé)指導(dǎo)團(tuán)隊(duì)在通用的 Scrum 框架上建立并遵循自己的過(guò)程，幫助每個(gè)參與者理解并樂(lè)于接受 Scrum 的價(jià)值觀、原則和實(shí)踐；
充當(dāng)教練、在過(guò)程方面發(fā)揮教導(dǎo)作用，幫助團(tuán)隊(duì)以及組織中的其他人指定合適的高績(jī)效、有組織特色的 Scrum 方法；如果采用 Scrum 可能是一個(gè)充滿(mǎn)挑戰(zhàn)的變革管理過(guò)程，需要幫助組織順利適應(yīng)這個(gè)過(guò)程；
負(fù)責(zé)保護(hù)團(tuán)隊(duì)不收外部干擾和障礙，（在個(gè)人無(wú)法有效解決遇到的障礙時(shí)）發(fā)揮領(lǐng)導(dǎo)作用，清楚阻礙團(tuán)隊(duì)生產(chǎn)率的障礙；
是領(lǐng)導(dǎo)者，不是管理者，無(wú)權(quán)控制團(tuán)隊(duì)。
Scrum Master 既是 Scrum 團(tuán)隊(duì)的教練、是 Scrum 過(guò)程權(quán)威，也是團(tuán)隊(duì)服務(wù)型領(lǐng)導(dǎo)、“保護(hù)傘”和“清道夫”，一個(gè)真正優(yōu)秀的 Master 同樣不易養(yǎng)成。
以下思維導(dǎo)圖是 Scrum Master 主要職責(zé)的說(shuō)明。
Scrum Master 必須見(jiàn)多識(shí)廣，具備領(lǐng)域知識(shí)和技術(shù)知識(shí)，要善于提問(wèn)，要有耐心和協(xié)作精神，要懂得保護(hù)團(tuán)隊(duì)，并且讓溝通公開(kāi)透明。
以下思維導(dǎo)圖是 Scrum Master 主要特征或技能的說(shuō)明。
為了更好地理解 Scrum Master 的職責(zé)，這里也通過(guò)一張圖大致列一下 Scrum Master 的日常工作內(nèi)容。
以下思維導(dǎo)圖是 Scrum Master 主要日常工作內(nèi)容的說(shuō)明。
負(fù)責(zé)確定如何交付產(chǎn)品負(fù)責(zé)人要求的產(chǎn)品；
由多種職位的人組成的多樣化跨職能團(tuán)隊(duì)，負(fù)責(zé)產(chǎn)品的設(shè)計(jì)、研發(fā)、測(cè)試等，包括架構(gòu)師、開(kāi)發(fā)人員、測(cè)試人員、數(shù)據(jù)庫(kù)管理員、運(yùn)維人員等；
開(kāi)發(fā)團(tuán)隊(duì)成員整體具備的技能足以實(shí)現(xiàn)產(chǎn)品負(fù)責(zé)人要求交付的業(yè)務(wù)價(jià)值。
以下圖片是開(kāi)發(fā)團(tuán)隊(duì)主要職責(zé)的說(shuō)明。
以下思維導(dǎo)圖是開(kāi)發(fā)團(tuán)隊(duì)主要特征或技能的說(shuō)明。
雖然 Scrum 框架中并沒(méi)有明確定義經(jīng)理的角色，但經(jīng)理在敏捷組織中依然發(fā)揮著重要的作用。
以下思維導(dǎo)圖是職能經(jīng)理主要職責(zé)的說(shuō)明。
瀑布開(kāi)發(fā)以及 Scrum 開(kāi)發(fā)對(duì)待需求的不同:
瀑布開(kāi)發(fā)：需求是必需的、是不可協(xié)商的、早早地就已細(xì)化并且是獨(dú)立的。
Scrum 開(kāi)發(fā)：需求細(xì)節(jié)是在開(kāi)發(fā)期間持續(xù)不斷的對(duì)話(huà)中商討出來(lái)的，而且是等到團(tuán)隊(duì)開(kāi)始構(gòu)建功能的時(shí)候，及時(shí)、剛好地細(xì)化這些需求為團(tuán)隊(duì)提供支持，分為大便級(jí)需求、板磚級(jí)需求、鉆石級(jí)需求。
定義：
用戶(hù)故事是可用于陳述業(yè)務(wù)價(jià)值的一種簡(jiǎn)便格式，適合各種 PBI，特別是特性。
意義：
用戶(hù)故事的制作方式旨在幫助業(yè)務(wù)人員與技術(shù)人員雙方都能了解需求（關(guān)注做什么，為什么做）。
格式：
作為<用戶(hù)角色>，我想<目標(biāo)>，這樣可以<利益>；
樣例：作為一名典型用戶(hù)，我想看到某地址周?chē)宛^的公正評(píng)價(jià)，這樣可以決定去哪里吃飯。
抽象級(jí)別：
史詩(shī)、主題、用戶(hù)故事（特性）
注意項(xiàng)：
任務(wù)不是故事，要詳細(xì)地說(shuō)明如何做，它不是故事，因此在寫(xiě)故事的時(shí)候必須要避免任務(wù)級(jí)細(xì)節(jié)。
好故事的 INVEST 原則：
獨(dú)立（Independent ）:
用戶(hù)故事應(yīng)該是獨(dú)立的，至少也應(yīng)該是相互間松耦合的；依賴(lài)程度高的故事會(huì)使估算、排優(yōu)先級(jí)順序和規(guī)劃復(fù)雜化；這里的獨(dú)立也不是說(shuō)完全消除依賴(lài)，而是在寫(xiě)故事的時(shí)候，盡量避免依賴(lài)關(guān)系。
可協(xié)商（Negotiable）：
故事的細(xì)節(jié)是可協(xié)商的，不是以前需求文檔寫(xiě)就的書(shū)面合同；可協(xié)商有助于避免彼此推諉，相互指責(zé)的心態(tài)。如果故事可協(xié)商，開(kāi)發(fā)人員就不會(huì)說(shuō)：“如果你想要，就該把它寫(xiě)到文檔里”，業(yè)務(wù)人員也不會(huì)說(shuō)：“你明顯沒(méi)有理解需求文檔，因?yàn)槟汩_(kāi)發(fā)的東西是有誤的”。
產(chǎn)品負(fù)責(zé)人告訴團(tuán)隊(duì)如何實(shí)現(xiàn)故事，這是違背可協(xié)商性的常見(jiàn)例子。如果如何做變得不可協(xié)商，就會(huì)減少團(tuán)隊(duì)創(chuàng)新的機(jī)會(huì)，由此導(dǎo)致創(chuàng)新浪費(fèi)。
有價(jià)值（Valuable）：
對(duì)客戶(hù)、用戶(hù)或者兩者來(lái)說(shuō)，故事都要有價(jià)值，否則就會(huì)造成浪費(fèi)。
這里主要想強(qiáng)調(diào)一下技術(shù)故事，比如“作為開(kāi)發(fā)人員、我想遷移系統(tǒng)到最新版 Oracle 數(shù)據(jù)庫(kù)管理系統(tǒng)上，這樣就可以避免在即將退役的 Oracle 版本上運(yùn)營(yíng)”，技術(shù)故事要說(shuō)服產(chǎn)品負(fù)責(zé)人以適當(dāng)?shù)捻樞蚣拥疆a(chǎn)品列表。
但有時(shí)候，很多技術(shù)故事實(shí)際都不應(yīng)該納入產(chǎn)品列表，為什么？
比如“作為開(kāi)發(fā)人員，我想對(duì)（上個(gè)沖刺的）特性 A 做集成并部署在線上環(huán)境，這樣可以讓特性 A 交付給客戶(hù)”，這類(lèi)故事應(yīng)該屬于完成業(yè)務(wù)價(jià)值所涉及的任務(wù)。如果開(kāi)發(fā)團(tuán)隊(duì)的完成定義比較嚴(yán)，就沒(méi)有必要再寫(xiě)這些故事，因?yàn)橥瓿梢呀?jīng)隱含這些工作。
可估算（Estimatable）
團(tuán)隊(duì)無(wú)法估算故事的大小，原因不外乎兩個(gè)：這個(gè)故事太大或太模糊以至于估不出來(lái)；團(tuán)隊(duì)積累的知識(shí)還不夠多，所以估不出來(lái)。對(duì)于前者，團(tuán)隊(duì)就得和負(fù)責(zé)人一起，把它拆成更容易估算的故事（鉆石級(jí)）；如果是后者，就需要通過(guò)某種形式的探索活動(dòng)來(lái)獲取信息。
?。⊿mall —— 大小合適）
可測(cè)試（Testable）
故事的相關(guān)測(cè)試要么通過(guò)，要么失敗。“可測(cè)試”意味著故事要有相應(yīng)的優(yōu)質(zhì)接受標(biāo)準(zhǔn)。如果沒(méi)有可測(cè)試的標(biāo)準(zhǔn)，沖刺結(jié)束時(shí)我們?cè)趺粗拦适掠袥](méi)有做完？另外，因?yàn)檫@些測(cè)試往往提供重要的故事細(xì)節(jié)，所以團(tuán)隊(duì)很可能需要這些測(cè)試來(lái)估算故事的大小。
排好優(yōu)先級(jí)的具有粗略估算的產(chǎn)品特性列表
對(duì)于開(kāi)發(fā)新產(chǎn)品，產(chǎn)品列表是為了滿(mǎn)足產(chǎn)品負(fù)責(zé)人的愿景而開(kāi)發(fā)的新特性；
對(duì)于正在開(kāi)發(fā)的產(chǎn)品，產(chǎn)品列表還可能包含新特性、對(duì)現(xiàn)有特性的變更、需要修復(fù)的缺陷以及技術(shù)改進(jìn)點(diǎn)（重構(gòu)或償還技術(shù)宅）等；
高優(yōu)先級(jí)條目出現(xiàn)在產(chǎn)品列表的頂部，低優(yōu)先級(jí)條目出現(xiàn)在底部；
是一個(gè)不斷演進(jìn)的工件，在業(yè)務(wù)環(huán)境發(fā)生變化或 Scrum 團(tuán)隊(duì)（通過(guò)每個(gè)沖刺獲得的對(duì)軟件的反饋）深入了解產(chǎn)品后，可以添加、刪除或修改其中的條目；
產(chǎn)品列表中保留合理的存量（經(jīng)過(guò)梳理的，準(zhǔn)備就緒并可以實(shí)現(xiàn)的條目），一個(gè)似乎對(duì)很多團(tuán)隊(duì)都有效的、有啟發(fā)意義的方法是準(zhǔn)備好兩三個(gè)沖刺的故事。
比如，如果團(tuán)隊(duì)在每個(gè)沖刺一般能做大約 5 個(gè) PBI，那么團(tuán)隊(duì)在梳理列表時(shí)，任何時(shí)刻都總有大約 10 到 15 個(gè) PBI 是準(zhǔn)備就緒的（沒(méi)記錯(cuò)的話(huà)，我在白板上看到拿鐵團(tuán)隊(duì)下個(gè)迭代準(zhǔn)備改進(jìn)的一個(gè)點(diǎn)就是準(zhǔn)備好 2 個(gè)沖刺量的故事點(diǎn)）。
已選定的高優(yōu)先級(jí)的并將在下一個(gè)沖刺完成的的產(chǎn)品特性條目
大多數(shù)情況下需要細(xì)分成任務(wù)進(jìn)入沖刺，少數(shù)情況下沖刺列表如果足夠細(xì)，可以直接稱(chēng)為任務(wù)進(jìn)入沖刺；
是沖刺結(jié)束后的產(chǎn)出，包含軟件的新特性、修復(fù)的缺陷、改進(jìn)后的技術(shù)點(diǎn)等
最低限度的定義為：產(chǎn)出一個(gè)完整的產(chǎn)品功能，經(jīng)過(guò)設(shè)計(jì)、構(gòu)建、集成、測(cè)試并且編寫(xiě)了文檔；
最激進(jìn)的定義為：當(dāng)業(yè)務(wù)部門(mén)想要交付（或部署、發(fā)布）時(shí)，能夠確保每個(gè)沖刺都為內(nèi)外部客戶(hù)交付所需價(jià)值；
“潛在可發(fā)布”并不是說(shuō)開(kāi)發(fā)什么必須實(shí)際交付，交付是一個(gè)業(yè)務(wù)上的決策，只有適合時(shí)才做交付；最好理解為對(duì)沖刺中實(shí)際開(kāi)發(fā)的產(chǎn)品的一種信心：意味著如果業(yè)務(wù)部門(mén)想要交付的話(huà)，那么我們?cè)诮桓哆@個(gè)沖刺的結(jié)果之前，不需要再做其他重要工作（比如重要的測(cè)試和集成等）。
產(chǎn)品負(fù)責(zé)人建立產(chǎn)品愿景，因?yàn)樵妇翱赡芎艽?，所以需要建立一組特性并收集到按優(yōu)先級(jí)排序并有粗略估算的產(chǎn)品列表中。這個(gè)建立和優(yōu)化產(chǎn)品列表?xiàng)l目、估算并確定他們的優(yōu)先級(jí)的順序的過(guò)程成為“產(chǎn)品列表梳理”。
梳理包括創(chuàng)建、增加、修改、刪除條目或者調(diào)整條目的優(yōu)先級(jí)等
設(shè)定 WIP 數(shù)量限定
強(qiáng)制排列優(yōu)先順序
時(shí)間盒強(qiáng)制我們按照優(yōu)先級(jí)排序并執(zhí)行最重要的最小批量的工作，因此可以集中注意力快速完成有價(jià)值的事情。
展示進(jìn)度
在沖刺結(jié)束前，通過(guò)完成和驗(yàn)證重要的工作，時(shí)間盒幫我們展示相關(guān)進(jìn)度，特別是沖刺產(chǎn)出在大特性上的進(jìn)度。
避免不必要的完美主義
避免花太多時(shí)間嘗試把事情做“完美”，或者說(shuō)避免當(dāng)“足夠好”已經(jīng)滿(mǎn)足要求的時(shí)候還要“鍍金”，時(shí)間盒強(qiáng)制結(jié)束可能無(wú)休止的工作(無(wú)休止的知識(shí)探索、無(wú)休止的原型試驗(yàn)、無(wú)休止的優(yōu)化等)。
促進(jìn)結(jié)束
當(dāng)團(tuán)隊(duì)有一個(gè)確定的結(jié)束日期時(shí)，事情更有可能做完。沖刺結(jié)束的最后期限不容更改，可能激發(fā)團(tuán)隊(duì)成員全力以赴按時(shí)完成工作。
增強(qiáng)可預(yù)測(cè)性
雖然我們不能準(zhǔn)確預(yù)測(cè)從現(xiàn)在開(kāi)始一年內(nèi)、半年內(nèi)要完成哪些工作，但預(yù)測(cè)下一個(gè)短沖刺能夠完成的工作是完全可以做到的。
團(tuán)隊(duì)在當(dāng)前沖刺中無(wú)法完成所有的工作，這并不是延長(zhǎng)沖刺長(zhǎng)度的正當(dāng)理由。到了沖刺最后一天才意識(shí)到無(wú)法完成工作，所以想通融通融，增加一天兩天來(lái)完成，這種做法是不合適的。需要延長(zhǎng)沖刺是不能正常工作或者有改進(jìn)空間的征兆。
節(jié)奏感
沖刺中穩(wěn)定的節(jié)奏感讓人們能夠“專(zhuān)攻這個(gè)領(lǐng)域”、“屢戰(zhàn)屢勝”、或者“進(jìn)入最佳狀態(tài)”；這是因?yàn)榉€(wěn)定的節(jié)奏感使單調(diào)而必要的活動(dòng)成為習(xí)慣，從而留出心力，集中做有趣、增值的工作
消除工作強(qiáng)度的差別
傳統(tǒng)瀑布項(xiàng)目中，工作強(qiáng)度到項(xiàng)目最后陡然增長(zhǎng)，而在 Scrum 中，每個(gè)沖刺的強(qiáng)度量變曲線都和其他沖刺相近。
每個(gè)人都知道需求梳理、沖刺計(jì)劃會(huì)、沖刺評(píng)審會(huì)回顧會(huì)等活動(dòng)的時(shí)間安排，減少不必要的召集會(huì)議人員的溝通時(shí)間、也能更好地讓所有參與人安排時(shí)間，減少等待；
簡(jiǎn)化計(jì)劃過(guò)程
團(tuán)隊(duì)使用長(zhǎng)度可變的沖刺時(shí)，“團(tuán)隊(duì)的平均速率是每個(gè)沖刺 20 個(gè)點(diǎn)”這類(lèi)的說(shuō)法就沒(méi)有意義了；由于長(zhǎng)度可變，團(tuán)隊(duì)的平均速率估算變得復(fù)雜，當(dāng)開(kāi)發(fā)大版本需要多個(gè)沖刺完成時(shí)，將難以估算究竟需要多少個(gè)沖刺才能完成。
短迭代容易規(guī)劃，并且規(guī)劃相對(duì)科學(xué)
短時(shí)間范圍做規(guī)劃所需要的工作量比給長(zhǎng)時(shí)間范圍的計(jì)劃工作量小得多，結(jié)果也準(zhǔn)確得多。
反饋快
短周期的沖刺可以產(chǎn)生快速的反饋
每個(gè)短沖刺開(kāi)發(fā)一些可以工作的軟件，然后有機(jī)會(huì)檢視和調(diào)整所構(gòu)建的軟件以及構(gòu)建軟件所需的方法。
這種快速反饋能夠使我們迅速剪掉不適合的產(chǎn)品路徑或開(kāi)發(fā)方法，避免在錯(cuò)誤決定的基礎(chǔ)上做出更多錯(cuò)誤的決定而導(dǎo)致錯(cuò)上加錯(cuò)；
還能使我們更快地發(fā)現(xiàn)和利用稍縱即逝的商機(jī)。
投入產(chǎn)出比高
更早、更頻繁的交付，可以更快地產(chǎn)生收入，從而提高整體的投入產(chǎn)出比
錯(cuò)誤有限
持續(xù)期短的沖刺所犯的錯(cuò)誤也有限，一個(gè)兩周的沖刺，所犯的錯(cuò)誤相對(duì)小且可控；
由于有快速反饋，錯(cuò)誤被及時(shí)制止。
有助于“滿(mǎn)血復(fù)活”
人類(lèi)的本性如此，等待滿(mǎn)足的時(shí)間太長(zhǎng)，興趣和興奮度會(huì)越來(lái)越弱；如果做的項(xiàng)目持續(xù)期非常長(zhǎng)，不僅失敗的可能性增加，還可能最終失去工作熱情；
沒(méi)有可見(jiàn)的進(jìn)度，也看不到結(jié)果，人們開(kāi)始失去興趣，到了最后，他們自己寧愿自己出錢(qián)也要做其他產(chǎn)品。
頻繁交付可以工作的產(chǎn)品，讓參與者保持較高的參與熱情；早期頻繁交付所帶來(lái)的滿(mǎn)足感，會(huì)使我們回復(fù)興趣并渴望繼續(xù)完成目標(biāo)。
有意義的檢查點(diǎn)多
每個(gè)沖刺的評(píng)審會(huì)都是一個(gè)有意義的檢查點(diǎn)，多個(gè)沖刺保證有足夠多的檢查點(diǎn)做檢查和修正，為決策提供支持。
沖刺目標(biāo)是團(tuán)隊(duì)和產(chǎn)品負(fù)責(zé)人作出共同承諾的基礎(chǔ)
團(tuán)隊(duì)承諾在當(dāng)前沖刺結(jié)束之前完成目標(biāo)；
產(chǎn)品負(fù)責(zé)人承諾在沖刺執(zhí)行過(guò)程中不變更需求；
另外，項(xiàng)目或者職能經(jīng)理承諾在沖刺執(zhí)行過(guò)程中不變更人員
這種共同承諾說(shuō)明了沖刺的重要性，它既能做到順應(yīng)變化而調(diào)整業(yè)務(wù)需求，又能讓團(tuán)隊(duì)集中精力在一個(gè)短的固定周期內(nèi)高效發(fā)揮其才能以創(chuàng)造價(jià)值。通過(guò)定義和遵循目標(biāo)， Scrum 團(tuán)隊(duì)能夠一直高度關(guān)注一個(gè)明確定義的、有價(jià)值的目標(biāo)。
不許變更、允許澄清
變更是工作或資源的變動(dòng)，在經(jīng)濟(jì)上會(huì)造成潛在的嚴(yán)重浪費(fèi)、中斷工作流或在一個(gè)沖刺內(nèi)大量增加工作范圍。
比如產(chǎn)品負(fù)責(zé)人：“哦，我所說(shuō)的是要能夠在警察數(shù)據(jù)庫(kù)中搜索少年犯，并不只是按姓名搜索，還要能夠按照嫌犯的紋身照片來(lái)搜索數(shù)據(jù)庫(kù)” —— 增加根據(jù)照片的搜索很有可能以為著開(kāi)發(fā)量大增，勢(shì)必會(huì)影響團(tuán)隊(duì)承諾交付的按照姓名搜索的能力。（這種情況下，創(chuàng)建新的 PBI 放到 Backlog 里）
澄清是在沖刺執(zhí)行期間提供更多的細(xì)節(jié)，幫助團(tuán)隊(duì)實(shí)現(xiàn)沖刺目標(biāo)。
開(kāi)發(fā)團(tuán)隊(duì)：“你說(shuō)搜索出來(lái)的少年犯應(yīng)該顯示在列表中，你對(duì)列表排序有什么偏好嗎？” 產(chǎn)品負(fù)責(zé)人：“有，按姓名字母排序?！?開(kāi)發(fā)團(tuán)隊(duì)：“沒(méi)問(wèn)題?！?/p>
如果在沖刺計(jì)劃完成之后再變，不僅影響投入，還會(huì)付出額外的成本對(duì)沖刺中的變更重新制定計(jì)劃（耗費(fèi)時(shí)間重新梳理 PBI 優(yōu)先級(jí)，依賴(lài)，耗費(fèi)時(shí)間移除已開(kāi)發(fā)的特性等）。
變更還可能損害團(tuán)隊(duì)的士氣和信任關(guān)系。
產(chǎn)品負(fù)責(zé)人作出承諾，說(shuō)不改變目標(biāo)，但最后出爾反爾，這樣做自然影響團(tuán)隊(duì)士氣，進(jìn)而影響到他們努力做完其他 PBI 的目標(biāo)。
注重實(shí)效勝于“鎖定目標(biāo)”
當(dāng)環(huán)境發(fā)生變化急需更改目標(biāo)時(shí)，固守原有目標(biāo)毫無(wú)意義，我們需要“鎖定目標(biāo)”，但更應(yīng)從經(jīng)濟(jì)技術(shù)等角度考慮，更應(yīng)注重實(shí)效。
完成的定義至少要產(chǎn)生一個(gè)產(chǎn)品功能的完整切片，即經(jīng)過(guò)設(shè)計(jì)、構(gòu)建、集成、測(cè)試并編寫(xiě)了文檔，能夠交付已驗(yàn)證的客戶(hù)價(jià)值。
如果性能測(cè)試重要，則要包含性能測(cè)試，否則不能算是真正的潛在可發(fā)布產(chǎn)品增量。槽糕的是，當(dāng)沖刺結(jié)束很久之后做性能測(cè)試，發(fā)現(xiàn)不能正常運(yùn)行，將要花更多的時(shí)間和精力去修復(fù)，甚至重新設(shè)計(jì)開(kāi)發(fā)。
Scrum 團(tuán)隊(duì)需要又一個(gè)健全的完成的定義，自信構(gòu)建的產(chǎn)品增量質(zhì)量高、可交付。任何妥協(xié)都會(huì)剝奪組織根據(jù)自身情況交付商業(yè)價(jià)值的機(jī)會(huì)并欠下技術(shù)債。
以下圖片是沖刺計(jì)劃會(huì)的參與者、輸入和輸出。
除了圖片所示，我們還應(yīng)該關(guān)注的是：
產(chǎn)品負(fù)責(zé)人、開(kāi)發(fā)團(tuán)隊(duì)和 Scrum Master 一起確定下一個(gè)沖刺要開(kāi)發(fā)的產(chǎn)品列表?xiàng)l目最高優(yōu)先級(jí)的子集，并且細(xì)分出每個(gè)條目的任務(wù)的過(guò)程。
沖刺計(jì)劃要注意輸入（特別是約束--假設(shè)，依賴(lài)，業(yè)務(wù)或技術(shù)風(fēng)險(xiǎn)等）
過(guò)程中，開(kāi)發(fā)團(tuán)隊(duì)給出完成每項(xiàng)任務(wù)所需工作量的估算值。
在使用估算撲克時(shí)，我們不用平均數(shù)，也不使用數(shù)值范圍之外的數(shù)字，在要求人們?yōu)槿蝿?wù)作出一個(gè)估算大小時(shí)，實(shí)際是在激發(fā)人們思考任務(wù)的細(xì)節(jié)，讓所有假設(shè)和風(fēng)險(xiǎn)顯露出來(lái)，讓開(kāi)發(fā)團(tuán)隊(duì)從團(tuán)隊(duì)的角度對(duì)任務(wù)的工作量達(dá)成共識(shí)。
團(tuán)隊(duì)成員輪流回答三個(gè)問(wèn)題：
昨天我完成了什么工作？
今天我計(jì)劃完成什么工作？
有什么障礙讓我無(wú)法取得進(jìn)展？
通過(guò)回答這些問(wèn)題，每個(gè)人都能了解全局，知道發(fā)生了什么，實(shí)現(xiàn)沖刺目標(biāo)的進(jìn)展如何，是否需要修改當(dāng)天的工作計(jì)劃，有什么需要處理的問(wèn)題等。
每日例會(huì)必不可少，它能幫助團(tuán)隊(duì)管理一個(gè)沖刺內(nèi)快速、靈活的工作流。
不是用來(lái)解決問(wèn)題的，而是檢視、同步和適應(yīng)性制定每日計(jì)劃的活動(dòng)；團(tuán)隊(duì)可以選擇把問(wèn)題的討論放在每日例會(huì)之后和相關(guān)人討論；
不是傳統(tǒng)意義上的狀態(tài)會(huì)議，尤其不是以前那種由項(xiàng)目經(jīng)理召集、為了了解項(xiàng)目最新?tīng)顟B(tài)而舉行的會(huì)議。
以下圖片是沖刺執(zhí)行的參與者、輸入和輸出。
除了圖片所示，我們還應(yīng)該關(guān)注的是：
蜂擁式開(kāi)發(fā)
有余力的團(tuán)隊(duì)成員聚在一起合力做完一個(gè)已經(jīng)開(kāi)始的條目之后再繼續(xù)轉(zhuǎn)做其他的條目；
擁有火槍手態(tài)度和 T 型技能的團(tuán)隊(duì)會(huì)采用蜂蛹式開(kāi)發(fā)。
任務(wù)執(zhí)行：強(qiáng)調(diào)技術(shù)實(shí)踐 —— 極限編程
我們希望開(kāi)發(fā)團(tuán)隊(duì)成員在工作中發(fā)揮自己的技術(shù)特長(zhǎng)，在短期，固定市場(chǎng)的沖刺中完成工作并控制技術(shù)債。這里的技術(shù)實(shí)踐并不是指深?yuàn)W難懂的技能，而是已經(jīng)用了數(shù)十年當(dāng)仍然決定 Scrum 或其他軟件開(kāi)發(fā)方法成敗的技能。
敏捷社區(qū)把這些技術(shù)實(shí)踐成為“極限編程”
測(cè)試驅(qū)動(dòng)開(kāi)發(fā)
重構(gòu)
簡(jiǎn)約設(shè)計(jì)
結(jié)對(duì)編程
持續(xù)集成
集體代碼所有制
編碼規(guī)范
隱喻
自動(dòng)化測(cè)試
...
以下圖片是沖刺評(píng)審會(huì)的參與者、輸入和輸出。
除了圖片所示，我們還應(yīng)該關(guān)注的是：
評(píng)審會(huì)檢視與調(diào)整“產(chǎn)品”；
所有參與人（包括 Scrum 團(tuán)隊(duì)、利益干系人、客戶(hù)或其他團(tuán)隊(duì)感興趣成員）清楚了解產(chǎn)品現(xiàn)狀提出反饋，并指導(dǎo)下一步開(kāi)發(fā)工作，以確保產(chǎn)出最合適的解決方案。
以下圖片是沖刺回顧會(huì)的參與者、輸入和輸出。
除了圖片所示，我們還應(yīng)該關(guān)注的是：
回顧會(huì)檢視與調(diào)整“過(guò)程”；
回顧會(huì)要充分利用主觀和客觀數(shù)據(jù)（禪道上 bug 統(tǒng)計(jì)，bug 修復(fù)時(shí)長(zhǎng)，燃盡圖等）
重點(diǎn)關(guān)注必要的持續(xù)過(guò)程改進(jìn)，討論 Scrum 流程、開(kāi)發(fā)過(guò)程、相關(guān)技術(shù)實(shí)踐哪些是可行的，哪些是不可行的，幫助優(yōu)秀的團(tuán)隊(duì)成為卓越的團(tuán)隊(duì)；
找數(shù)量適中的過(guò)程改進(jìn)項(xiàng)并承諾在下一個(gè)沖刺采用。
到這里，關(guān)于 Scrum 框架的角色、工件與活動(dòng)已經(jīng)大體講完，下面講一個(gè)重要的概 念 —— 技術(shù)債作為本文的結(jié)束。
本章節(jié)主要講什么是技術(shù)債，有哪些類(lèi)型技術(shù)債，技術(shù)債有什么影響，以及如何處理技術(shù)債。
1992年，Ward Cunningham 率先提出技術(shù)債的概念，他的定義如下:
代碼寫(xiě)好就交，意味著欠債的開(kāi)始。稍微欠點(diǎn)技術(shù)債的確可以加快開(kāi)發(fā)速度，但前提是事后及時(shí)重寫(xiě)代碼，...... 如果只結(jié)不還，后果很危險(xiǎn)。在不確定的代碼上花的每一分鐘，都算是技術(shù)債的應(yīng)付利息。不穩(wěn)定，脆弱的代碼所引發(fā)的債務(wù)負(fù)擔(dān)，會(huì)使整個(gè)工程陷入裹足不前的艱難境地......
技術(shù)債具體包括：
不合適（或糟糕）的設(shè)計(jì) —— 因?yàn)楫?dāng)前所用技術(shù)或業(yè)務(wù)發(fā)生重大變化，我們之前曾經(jīng)有效的設(shè)計(jì)變得不再使用；
缺陷 —— 我們已知但還沒(méi)有時(shí)間解決的軟件的問(wèn)題；
測(cè)試覆蓋不充分 —— 有些地方我們明明知道該做更多測(cè)試卻沒(méi)有做；
手工測(cè)試過(guò)多 —— 實(shí)際該做自動(dòng)化測(cè)試的時(shí)候我們還在做手工測(cè)試；
集成和版本管理不善 —— 在集成和版本管理的時(shí)候，采用的方式既費(fèi)事又容易出錯(cuò)；
缺乏平臺(tái)經(jīng)驗(yàn)；
...
技術(shù)債的分類(lèi)：
低級(jí)技術(shù)債
團(tuán)隊(duì)成員或業(yè)務(wù)人員業(yè)務(wù)或技術(shù)不成熟或流程缺陷而導(dǎo)致設(shè)計(jì)粗糙，工程實(shí)踐糟糕和測(cè)試不足；
不可避免的技術(shù)債
良好的設(shè)計(jì)要演進(jìn)而來(lái)，一開(kāi)始的設(shè)計(jì)難免因不完善而帶有技術(shù)債，表現(xiàn)為隨著時(shí)間推進(jìn)而受影響，必須做出改動(dòng)；
依賴(lài)的第三方接口不斷演進(jìn)，我們沒(méi)有及時(shí)跟進(jìn)。
策略性技術(shù)債
組織有意做出策略性決定，讓產(chǎn)品開(kāi)發(fā)抄近道，希望實(shí)現(xiàn)一個(gè)重要的短期目標(biāo)；
組織為削減成本，把帶有技術(shù)宅的產(chǎn)品推到市場(chǎng)，等有收益后再有資金做后續(xù)開(kāi)發(fā)。
技術(shù)債不可預(yù)測(cè)
技術(shù)債的一個(gè)重要特質(zhì)：以不可預(yù)測(cè)的非線性方式增長(zhǎng)；
當(dāng)技術(shù)債積累到某個(gè)臨界點(diǎn)，增加任何一丁點(diǎn)的技術(shù)債，都會(huì)讓產(chǎn)品達(dá)到爆發(fā)點(diǎn)，變得不可管理或混亂，從而誘發(fā)不確定的大災(zāi)難；
不償還的技術(shù)債逐步積累，我們不知道最后一根稻草何時(shí)會(huì)壓死駱駝，然而一旦發(fā)生，后果不堪設(shè)想。
交付時(shí)間變長(zhǎng)
承擔(dān)技術(shù)債意味著現(xiàn)在向未來(lái)申請(qǐng)借用工作時(shí)間
今天的債務(wù)越多，明天的速率就越慢，速率越慢，交付新特性和產(chǎn)品補(bǔ)丁需要的時(shí)間越長(zhǎng)；
缺陷數(shù)量過(guò)多而無(wú)力生產(chǎn)
技術(shù)債使的產(chǎn)品變得復(fù)雜，不同的缺陷盤(pán)根錯(cuò)節(jié)，以高的驚人的頻率造成重大的產(chǎn)品故障，再有缺陷過(guò)多難以管理，從而影響正常的增值開(kāi)發(fā)工作。
開(kāi)發(fā)和支持成本上升
可預(yù)測(cè)性降低
如果債臺(tái)高筑，基本上不太可能進(jìn)行任何形式的預(yù)測(cè)
導(dǎo)致的結(jié)果是我們做出承諾并未兌現(xiàn)承諾而建立合理預(yù)期的能力被大大削弱
挫折感四處彌漫
開(kāi)發(fā)鏈路中所有人都因此備受挫折，久而久之，開(kāi)發(fā)的樂(lè)趣消失殆盡，取而代之的是日復(fù)一日、周而復(fù)始地與不受人待見(jiàn)卻得硬著頭皮面對(duì)的問(wèn)題“戰(zhàn)斗”。
使用良好的實(shí)踐
停止向產(chǎn)品增加低級(jí)債務(wù) —— 再不粗心大意和添亂了
測(cè)試驅(qū)動(dòng)開(kāi)發(fā)、持續(xù)集成、自動(dòng)化測(cè)試和代碼重構(gòu)等
使用強(qiáng)完成定義
完成定義檢查表中包含的技術(shù)細(xì)節(jié)越多，積累技術(shù)債的可能性就越少
讓技術(shù)債可見(jiàn)
把技術(shù)債當(dāng)做缺陷錄入缺陷跟蹤系統(tǒng)（比如禪道）
為技術(shù)債創(chuàng)建 PBI，使重要的技術(shù)債與產(chǎn)品列表的新特性一樣醒目
創(chuàng)建一個(gè)特殊的技術(shù)債列表（比如在任務(wù)白板旁邊安置一個(gè)技術(shù)債白板，用便利貼來(lái)記錄具體的各項(xiàng)技術(shù)債，讓每日例會(huì)和沖刺過(guò)程中可見(jiàn)）
償還技術(shù)債
并非所有技術(shù)債都應(yīng)償還
行將就木的產(chǎn)品
一次性原型 —— 原型的價(jià)值不在于代碼，而在于經(jīng)驗(yàn)認(rèn)知
短命產(chǎn)品
應(yīng)用“童子軍原則”，有債就還
“童子軍原則”:'離開(kāi)營(yíng)地時(shí)，要讓它比你進(jìn)去時(shí)更干凈'，如果發(fā)現(xiàn)營(yíng)地臟亂，就應(yīng)該清理，不管罪魁禍?zhǔn)资钦l(shuí)，要有意識(shí)地為亦喜下一個(gè)露營(yíng)隊(duì)改善環(huán)境；
同樣的，我們?cè)诿看胃膭?dòng)產(chǎn)品時(shí)，都要嘗試讓產(chǎn)品設(shè)計(jì)和實(shí)現(xiàn)更好，而不是更差；
針對(duì)每個(gè) PBI，我們承諾保質(zhì)保量完成工作，而且在自己所開(kāi)發(fā)特性的相關(guān)區(qū)域內(nèi)如果發(fā)現(xiàn)技術(shù)債，只要力所能及，就要清理干凈；
當(dāng)然，對(duì)于某些技術(shù)債，償還到一個(gè)合理的閾值就好，因?yàn)檫€有其他更重要的工作要完成。
分期償還技術(shù)債
面對(duì)債臺(tái)高筑的產(chǎn)品，團(tuán)隊(duì)往往會(huì)選用一次性付清的方式解除技術(shù)債；更好的做法是分期、分步驟償還已知技術(shù)債，而不是后期一次性付清；
單獨(dú)創(chuàng)建“技術(shù)債沖刺”或“重構(gòu)沖刺”，這樣的沖刺只有一個(gè)目的：“工作核心就是減少技術(shù)債”；這樣的話(huà)，團(tuán)隊(duì)選擇的不是交付客戶(hù)價(jià)值，而是舍本逐末，專(zhuān)門(mén)解決本該在每個(gè)沖刺中逐步解決的技術(shù)債；后期一次性解除成本高，導(dǎo)致浪費(fèi)。
先償還高利息技術(shù)債
一邊做有客戶(hù)價(jià)值的工作，一邊償還技術(shù)債
在做 PBI 的同時(shí)，維護(hù)已知技術(shù)債；既能夠?qū)Ｗ⒂诟呦⒓夹g(shù)債，又能夠把維護(hù)技術(shù)債與以?xún)r(jià)值為中心的方式結(jié)合。
參考書(shū)籍：
1.《Scrum 精髓 - 敏捷轉(zhuǎn)型指南》
2.《Scrum敏捷軟件開(kāi)發(fā)》
3.《架構(gòu)即未來(lái)》 —— 好書(shū)，推薦！
本文轉(zhuǎn)自：開(kāi)發(fā)者頭條
微信號(hào)：IdeaofSE
聯(lián)系客服
