把很早之前寫的scrum相關(guān)論文中的某段發(fā)出來供大家參考

置頂感謝，受教大神:

參考文獻

[1]百度百科，Scrum.https://baike.baidu.com/item/Scrum/1698901?fr=aladdin [H],2018-4-16

[2]?Mike Cohn.譯者: 廖靖斌/呂梁岳/陳爭云/陽陸育《Scrum敏捷軟件開發(fā)》[M],清華大學出版社，2010

[3] 周勇.Scrum方法在c公司軟件項目管理中的應(yīng)用研究 [D].華東理科大學，2016（03）

[4] 夏辰未.Scrum在M公司項目管理中的應(yīng)用[D].西南交通大學，2015

[5] 劉謙.《敏捷方法在軟件項目管理中的應(yīng)用》[D] 上海交通大學,2011

[6]禪道.http://www.zentao.net/book/zentaopmshelp/103.html[H],2018-4-16

前言

Scrum這個名字起源于英式橄欖球的對陣爭球，爭球雙方各有8名隊員參與，各方出3名前鋒，在水平排中并肩站立，橫跨頂部和肩部彼此相對，其他前部在臀部肩膀陣容后站在彼此后面

橄欖球?qū)﹃嚑幥虻膱鼍昂徒恿悎鼍皩Ρ龋覀兛纯磧烧呤膊煌?橄欖球運動，團隊作為一個整體前進，而接力賽大部分時間，是一個運動員跑，其他三個站著看。1986年，有人首次把Scrum應(yīng)用于產(chǎn)品開發(fā)，他們表明：傳統(tǒng)“接力式”開發(fā)方法不能應(yīng)對市場變化，而整體或”橄欖球式”的方法----團隊整體前行，在團隊內(nèi)部傳球前進，也許可以更好的滿足當前激烈的市場競爭。 1993年 scrum之父 Jeff Sutherland首次將 Scrum用于軟件開發(fā)，2001年敏捷宣言及12條原則發(fā)布、敏捷聯(lián)盟成立， 從此 Scrum作為一種主流的敏捷方法，被越來越多的人接受。 2002年Scrum聯(lián)盟成立。 我們所說的CSM認證就是Scrum聯(lián)盟頒發(fā)的認證。[1]

第2章 Scrum特點與敏捷原則概述[2]

敏捷宣言

我們的最高目標，是通過盡早和持續(xù)地交付有價值的軟件來滿足客戶；

擁抱需求變更，即使項目后期也要善于利用需求變更幫助客戶獲取競爭優(yōu)勢；

不斷交付可用的軟件，周期幾周到幾個月不等，越短越好；

項目過程中，業(yè)務(wù)人員和開發(fā)必須要一起工作；

要善于激勵項目人員，給他們以需要和環(huán)境支持，并信任他們；

面對面溝通是最高效的方法；

可用的軟件衡量進度的主要指標；

敏捷過程提倡克持續(xù)的開發(fā)，項目方，開發(fā)人員和用戶應(yīng)該保持恒久穩(wěn)定的進展速度

做到簡潔，即盡最大可能減少不必要的工作，這是一門藝術(shù)；

最佳的架構(gòu)，需求和設(shè)計出自于自組織的團隊；

團隊要定期反省如何能做到更有效，并相應(yīng)地調(diào)整團隊行為；

?

2.1 Scrum框架

Scrum Guide是這樣定義Scrum的：Scrum是一個框架，在這個框架中人們可以解決復(fù)雜的自適應(yīng)問題，同時也能高效并創(chuàng)造性地交付盡可能高價值的產(chǎn)品。

第一、框架

什么是框架呢？ 可以舉個例子，房屋的柱子，地基是框架，而不是房子中的墻壁和家具。所謂框架就是基礎(chǔ)，就是原則，計框架必然是穩(wěn)定的。同時框架又是可以靈活填充的。 Scrum框架，就是這樣的，用原則基礎(chǔ)的東西（scrum團隊，團隊角色，團隊工具，scrum規(guī)則）。相scrum框架的填充如 內(nèi)部定制的使用工具，ERP等等，只要達成目的就行。scrum不明確你需要填充的“內(nèi)容”，這些細節(jié)應(yīng)該是Scrum master根據(jù)實際環(huán)境考慮的。

第二、最佳適用場景-復(fù)雜問題

根據(jù)軟件開發(fā)維護工作的復(fù)雜程度，可以把軟件相關(guān)工作分為3類：簡單問題、繁雜問題、復(fù)雜問題。簡單問題指需求很明確、很穩(wěn)定、不會變化，需要掌握的技術(shù)很簡單，最佳解決方案顯而易見。比如安裝一個軟件，一路點“下一步”，就安裝好了。繁雜問題指諸如軟件日常維護、修bug之類的工作。復(fù)雜問題指創(chuàng)新型的新產(chǎn)品開發(fā)，或者現(xiàn)有產(chǎn)品的創(chuàng)新型的新功能的開發(fā)。Scrum最適合用來處理復(fù)雜問題，指導創(chuàng)新型軟件開發(fā)工作。

第三、高價值

正如敏捷的12條原則中的第一條所述，“我們最重要的目標是通過持續(xù)提供有價值的軟件來滿足我們的客戶。這里的價值是指對顧客的價值，是指商業(yè)價值。Scrum并不追求軟件開發(fā)范圍最大化，不認為開發(fā)的功能越多越好，而追求商業(yè)價值最大化。

最后，我們用三句話總結(jié)一下Scrum能干什么。第一句，Scrum是一個框架，它告訴我們Scrum團隊的角色、進行的活動和產(chǎn)出的工件不能變，又允許我們自定義實施Scrum的具體細節(jié)。第二句，Scrum最適合用來指導創(chuàng)新型產(chǎn)品的開發(fā)。第三句，Scrum幫忙我們交付高價值產(chǎn)品。

2.2 Scrum角色、過程、工件

第一、角色

在scrum項目開發(fā)中可以包含多個scrum團隊，每個團隊中Scrum中的角色分為三類，即product owner、Scrum Master、team。

Product owner 是授權(quán)的產(chǎn)品領(lǐng)導核心，是唯一能對產(chǎn)品方向、產(chǎn)品要求、產(chǎn)品優(yōu)先級功能、（限定期限中）進行最大化產(chǎn)出和規(guī)劃下一階段計劃的角色

主要溝通工作分為對外和對內(nèi)2方面。1.了解外部干系人，以分析和理解該干系人的期望及需求，從而精細化對外部干系角色進行定義，制定精確的用戶故事 產(chǎn)品架構(gòu)、流程，維護product backlog。 2.將產(chǎn)品規(guī)劃及產(chǎn)品設(shè)計場景觸發(fā)等輸出給team幫助開發(fā)人員在開發(fā)過程中正確理解產(chǎn)品，規(guī)避理解偏差帶來的風險問題

Scrum Master是團隊中協(xié)調(diào)式領(lǐng)導（本質(zhì)無任何職權(quán)），是幫助PO、Team角色正確理解scrum精要，確保內(nèi)部團隊更好的協(xié)調(diào)，提升整個團隊生產(chǎn)力，提高整個產(chǎn)出效率，一般來說這類角色以scrum經(jīng)驗豐富的人擔任

Team是有該case中所需迭代產(chǎn)品專業(yè)人員組成的（架構(gòu)師、設(shè)計師、開發(fā)、測試等等）跨職能人員，負責在每個sprint周期內(nèi)完成工作任務(wù)及實現(xiàn)方式，并在沖刺完成后交付可運行的產(chǎn)品交付物（注：一般5～9人為宜）

第二、過程

產(chǎn)品計劃： Scrum方法中，首先由 product owner將利益干系人進行分解（客戶、用戶、市場、高層等等），了解期需求及期望，通過此建立產(chǎn)品愿景及 story，再根據(jù)需求權(quán)重將每項的商業(yè)價值、需求類型、風險判斷、開發(fā)難易、緊急程度等等判斷其優(yōu)先級建立 product backlog。再通過計劃會確定此次產(chǎn)品迭代增量目標（2-6周）

沖刺會議：在沖刺大會上，我們也稱為沖刺計劃會議。目的是將 PO細化的產(chǎn)品功能 list供開發(fā)團隊選擇（在此會議之前 PO須重新審視優(yōu)先級，并反復(fù)確認）開發(fā)團隊在選擇過程中根據(jù)優(yōu)先級從高到低選擇出細化開發(fā)任務(wù)，細小到自己可2天之內(nèi)開發(fā)完成，形成 sprint backlog，同時明確產(chǎn)品評審會、回顧會時間（4-8小時會議）；

每日站立會議：每次會議控制在15分鐘左右，由 PO、 M、 T組成會議成員，每個人都（必須）發(fā)言（其他人只能作為旁觀者不能發(fā)言），你必須親自向所有成員報告你昨天完成的任務(wù)，并向所有成員承諾今天要完成的任務(wù)，并且還可以提出你無法解決的問題。每個人的答案完成后，他們必須去黑板更新他們自己的Sprint燒錄地圖。并排除障礙；

沖刺評審：目的是對本次沖刺任務(wù)進行審核，沖刺會議憶由利益干系人、用戶、 PO、 M、 T參加，在此過程中由 T向他人進行演示沖刺計劃中的增量迭代功能，在演示完后，驗收者對此進行一定反饋，以便以后進行迭代；

回顧會議：由PO、M、T對此過程進行回顧，討論其過程中的缺失和可行性方法，并提出和應(yīng)用改進意見；

第三、工件

1.product backlog：產(chǎn)品負責人結(jié)合產(chǎn)品利益關(guān)系人、M、T的意見建議及商業(yè)價值，風險等考量，形成優(yōu)先級的產(chǎn)品列表降序排列。優(yōu)秀的產(chǎn)品list具有以下特征：1）沒有廢話；2）動態(tài)（實時調(diào)整） ；3）容易理解，4）有初步的投入產(chǎn)出計算

2.sprint backlog：由Team成員對sprint中需要交付的功能可視化的表達，其包括預(yù)期計劃時間，實際耗時，用戶故事，目前狀態(tài)，驗收標準等等，sprint backlog在執(zhí)行過程中是不能改變的，除開 tame在過程中確認無法在當前時間下完成，這時PO和team會再次就sprint backlog重新調(diào)整

3. 燃盡圖：burndown圖表用于顯示sprint中剩余工作任務(wù)的總量，以了解sprint的開發(fā)工作量和完成趨勢。結(jié)合 sprint backlog來對過程中問題解決以改進的可視化工具

2.3 Scrum轉(zhuǎn)型

第一、ADAPT模型

ADAPT需要滿足5個要求，即意識、渴望、能力、推廣、傳遞

要知道所有的革命都是來自現(xiàn)實與理想的不平衡，即使如此，意識到目前的方法效率不佳還是一件難事，一般來說行動時間與意識時間都有一個時間差。

有意識后我們需要強烈的動機去渴望改變，就好像你想找個女朋友但你未必行動，必須得有個強烈的動機去找女朋友。渴望改變是對動機的支撐，要說服一個人渴望改變，必須滿足天時地利任何，時機不對多說無益，但是在對的時間、對的地點、對的人去給他說或許就能從意識改變到渴望改變

意識到改變，渴望改變還需要與之相匹配的能力才行，在轉(zhuǎn)型過程中，scrum團隊不得不對過去告別，不斷接受擁抱變化，比如使用新的工具，新的技能，新的團隊工作思維模式，學會適用在短時迭代的高效率、高投入產(chǎn)出比的項目

成功驗證scrum轉(zhuǎn)型后，就可以將此方法推廣到其他項目組，同時公司制度也應(yīng)為這種轉(zhuǎn)型進行改變，保持scrum的成果，比如績效獎金等等[3]

第二、逆抵觸

scrum轉(zhuǎn)型會對規(guī)章制度權(quán)利分配（底部）重新洗牌，導致有人獲利有人利益受損，因此基于風控原則來說，在執(zhí)行scrum前我們要了解自己的組織架構(gòu)并對有可能產(chǎn)生的影響作出準確的預(yù)測抵觸，并將風險前置。

對于改變每個人都有不同反應(yīng)，馬爾塞懷特和英格拉姆將此分為3類即創(chuàng)新主義者、實用主義者、保守主義者。創(chuàng)新主義喜歡改變，實用主義可能是抵觸者也可能是支持者，保守主義最可能是抵觸者

據(jù)07研究抵觸研究發(fā)現(xiàn)，管理者抵觸的首要原因是控制和權(quán)利，其次是缺少時間，再次是對現(xiàn)狀滿意，而對員工而言抵觸的原因是缺乏意識，其次是對未知事物恐懼，再次是缺乏職業(yè)上的安全感

第三、角色轉(zhuǎn)變與技術(shù)轉(zhuǎn)型

在一般的開發(fā)管理流程上，部門leader負責資源分配和進度監(jiān)管，項目經(jīng)理是項目的負責人，（產(chǎn)品）分析員承擔需求調(diào)研分析挖掘等任務(wù)，架構(gòu)師負責整個程序的的架構(gòu)設(shè)計和技術(shù)指導，開發(fā)人員負責代碼的撰寫，功能實現(xiàn)、缺陷修復(fù)，測試人員則負責測試產(chǎn)品找出缺陷，盡量避免將有缺陷的產(chǎn)品在線或交付給客戶。以上角色在scrum的改變下職責上會發(fā)生或多或少的變化。

1）?部門leader

在一般開發(fā)模式下說，部門leader擁有行政權(quán)利，可以分配項目人員還可以直接參與項目任務(wù)的分配。Scrum轉(zhuǎn)型后，工作任務(wù)是team中個人自己選擇，部門leader不能干預(yù)，部門leader和scrum團隊之間相對于之前項目關(guān)系會減弱。

2）?架構(gòu)師

scrum角色中是沒有架構(gòu)師職位的，架構(gòu)師角色的職責會有開發(fā)team循序漸進完成整個架構(gòu)設(shè)計工作。在技術(shù)咨詢上開發(fā)人員也應(yīng)該對架構(gòu)師意見進行交流學習，同時在產(chǎn)品功能架構(gòu)出來后，PO（產(chǎn)品負責人）應(yīng)與架構(gòu)師溝通交流意見。

3）?分析員（產(chǎn)品經(jīng)理）

傳統(tǒng)的分析員（產(chǎn)品經(jīng)理）對于產(chǎn)品知識及業(yè)務(wù)相當熟悉，同時善于溝通協(xié)調(diào)，一般來說產(chǎn)品經(jīng)理會在擔任產(chǎn)品負責人的角色，傳統(tǒng)的的分析員是盡量完成需求分析，而scrum則要求動態(tài)分析需求，盡量比沖刺規(guī)劃早一些完成需求分析任務(wù)，在傳統(tǒng)開發(fā)流程中，一般采用文檔進行信息分享，在scrum中提倡非正式的情況下對于team進行分享。

4）?開發(fā)人員

傳統(tǒng)的開發(fā)人員主要負責需求中的功能實現(xiàn)、并將產(chǎn)品中的缺陷進行修復(fù)，在scrum團隊中，開發(fā)人員不再告知需要完成哪些功能，而是主動獲取理解和掌握需求。

5）?測試人員

scrum轉(zhuǎn)型后，開發(fā)團隊的重心從理解需求到討論需求，故而測試人員不能在確保實現(xiàn)需求文檔中功能作為職責，而是主動與PO（產(chǎn)品負責人）、用戶、客戶和其他干系人交談，了解某個特性的期望響應(yīng)時間是多久，業(yè)務(wù)流程是怎樣的等等，在測試環(huán)節(jié)，不能像以前一樣各司其職，完成分配所屬的測試模塊，而應(yīng)該和開發(fā)人員及其他測試溝通協(xié)作，且從手動過度到自動化測試。

第3章 基于D公司實戰(zhàn)中Scrum的經(jīng)驗方法論

3.1 D公司Scrum項目過程改進

第一、D公司困境之問題列表

本來是想基于整個項目貫穿說一次D公司困境，篇幅有限故此直接羅列問題。

1.?需求中途老是變更導致開發(fā)團隊無法按時完成（需求收集問題）

2.?需求傳達不準確導致過程中需求方與開發(fā)團隊溝通成本增加（溝通問題）

3.?沒有規(guī)范的需求流程，各自為政，沿用上家公司的流程，沒有達到有效的團隊契合

4.?代碼編寫具有個人特色，導致接收代碼者，閱讀代碼困難

5.?開發(fā)方式不能應(yīng)對市場，導致經(jīng)常延期（本地構(gòu)建）

6.?開發(fā)代碼質(zhì)量不高，再后期上線需更改代碼時，消耗大量時間成本（測試驅(qū)動開發(fā)）

7.?代碼無法系統(tǒng)化規(guī)劃，缺失架構(gòu)觀及集體共享，使得開發(fā)人員對其他模塊不了解，導致開發(fā)出現(xiàn)代碼缺陷（代碼集體權(quán)）

第二、需求收集和分析的改進

不管是什么樣的需求管理，需求收集與分析都是最重要的環(huán)節(jié)，挖掘用戶、客戶、市場的需求，并要在過程中保證傳遞的信息準確。

1.?在scrum敏捷開發(fā)模式下，產(chǎn)品負責人在內(nèi)部是唯一需求方，產(chǎn)品負責人參與整個項目可以最大程度上規(guī)避傳遞信息的誤差率，產(chǎn)品負責應(yīng)該定期與不定期拜訪需求源（用戶、客戶、市場）從需求源上了解公司產(chǎn)品問題，把反饋整理到product backlog中去。

2.?真正挖掘客戶需求和市場趨勢，使用外部數(shù)據(jù)如：行業(yè)數(shù)據(jù)，艾瑞咨詢、某某研究院對產(chǎn)品目標用戶的行為偏好，使用習慣，未來趨勢來定位產(chǎn)品走向，同時也能讓自身產(chǎn)品落地，貼合用戶。

3.?需求的描述：應(yīng)用簡潔易懂的句子即描述用戶或角色處于什么樣環(huán)境下，需要達成什么樣的目標。講故事的使用可以清楚地表達用戶的真實需求并避免理解上的偏差。

用戶故事invest原則[6]

Idependent(獨立的):用戶故事應(yīng)該獨立于（盡可能）另一個用戶故事。故事之間的依賴導致計劃的增加，建立了有限的水平，故事估計這些任務(wù)非常困難。通常，通過組合用戶故事或分割用戶故事可以減少依賴關(guān)系。

Negotiable(便于溝通的):一個用戶故事是便于溝通的。故事卡片是對故事細節(jié)的簡要描述。這些詳情是通過討論階段來完成的。有很多細節(jié)的卡實際上減少了與客戶的談話。

Valuable(有價值的):每個故事都必須對客戶有價值（無論是用戶還是買家）。讓用戶故事有價值的好方法是讓客戶寫下來。一旦客戶意識到用戶故事不是合同并且可以談判，他們會很樂意編寫故事。

Estimable(可估計的):開發(fā)人員需要估算用戶故事，以確定有限的級別并計劃故事。但是讓開發(fā)者難以估計故事的問題來自：缺乏領(lǐng)域知識（在這種情況下需要更多溝通），或者故事太大（需要將故事分成更小的故事）。

Small(短小):一個好的故事應(yīng)該在工作量方面較短，描述具有代表性，且不超過2-3人周的工作。超出此范圍的用戶故事在范圍和估算中會有很多錯誤。

Testable(可測試的) :用戶故事可以測試以確認完成。如果你不能測試那么你永遠不知道你什么時候是完成了。一個不可測試的用戶故事例子：軟件應(yīng)該是易于使用的。

。

第二、共識需求規(guī)則流程

基于Scrum框架來說，需求過程本質(zhì)上分為，收集確定和 細化迭代product backlog 2個階段。

收集確定：由PO首先與用戶（客戶、市場）溝通，并確定整個項目的整體架構(gòu)，對于業(yè)務(wù)范圍較大的管理系統(tǒng)，可以由PO將干系人拉到一起，召開產(chǎn)品密集需求會議，由PO確最后確認需求優(yōu)先級，發(fā)現(xiàn)其不合理或缺陷的地方。生成“最終版”產(chǎn)品列表后，由干系人簽字，作為驗收基石；

細化迭代：沖刺活動前，由PO 重新審視剩余產(chǎn)品，并將優(yōu)先級高的需求細化，補充完整，進而為開發(fā)鋪墊（有甲方時需與甲方確定）。

共識需求規(guī)則流程是為了讓大家統(tǒng)一工作節(jié)奏，保證每個時間段知道自己所參與的項目活動及角色職責；

第三、明確需求變更規(guī)則流程

在功能開發(fā)過程，PO會受到老板及甲方（市場）的需求制約，導致需求變更，這時PO首先確定接受到的需求源是誰？需求是否真實，需求范圍影響，開發(fā)成本及商業(yè)價值，在確認需求確實需要變更的時候，?PO署《需求變更報告》同時讓需求提出者簽字（甲方或老板，PO提出自己簽字）同時對團隊強調(diào)不管變更對進度的影響和成本影響都需要納入開發(fā)計劃。這樣做是為了對整個產(chǎn)品開發(fā)歷史做回顧，同時作為對上級和甲方報告進度延期的憑證[4]。

3.2 技術(shù)改進

第一、測試驅(qū)動開發(fā)

通過先一步編寫測試代碼寫入開發(fā)代碼中來保證開發(fā)代碼符合需求，覆蓋率高的代碼測試代碼可以結(jié)合“持續(xù)集成工具”來提提高產(chǎn)品代碼質(zhì)量。

第二、不定期重構(gòu)

常規(guī)：基于代碼互查獲得代碼質(zhì)量反饋，開發(fā)需要代碼進行重構(gòu)，迭代自身代碼質(zhì)量，優(yōu)化規(guī)范。

?不定期：任務(wù)空隙提倡開發(fā)不定期定通過重構(gòu)代碼過程改善自身代碼質(zhì)量。

第三、持續(xù)集成

通過使用集成工具，讓團隊在本地服務(wù)器上執(zhí)行本地構(gòu)建，然后提交版本控制庫。確保代碼變更不會導致集成失敗，開發(fā)人員每天至少更新一次代碼，同時保證每次構(gòu)建都要100%通過（能生成可用性產(chǎn)品），如若構(gòu)建失敗將最高優(yōu)先級處理。持續(xù)集成有助于檢查缺陷，了解軟件健康狀況，減少假設(shè)并提高產(chǎn)品質(zhì)量。

第四、代碼集體共有權(quán)

之前開發(fā)人員只對自己的代碼負責，但是代碼集體權(quán)提倡團隊對每人對代碼負責，顯著表現(xiàn)為每人都可以編寫他人寫的代碼或修改他人的功能，若需要修改他人代碼可以無需讓原著開發(fā)幫忙修改，代碼集體權(quán)的好處是讓團隊對代碼結(jié)構(gòu)了解，而不存在“祖?zhèn)鞔a”的問題，降低協(xié)作成本，但是修改他人代碼也會帶來一定風險，可以通過“測試驅(qū)動開發(fā)”和持續(xù)集成快速發(fā)現(xiàn)問題，并很快定位代碼缺陷。

第五、代碼規(guī)范標準

在推行代碼集體權(quán)中，需要看的懂他人代碼，這時代碼規(guī)范的重要性就顯而易見，一行行擁有代碼規(guī)范的代碼會對團隊協(xié)作非常有幫助，所以開發(fā)團隊講代碼的風格，函數(shù)及變量定義、注釋規(guī)范、代碼屬性一一統(tǒng)一起來，并形成《代碼規(guī)范手冊》，作為對代碼規(guī)范的標準文檔，同時也可以給新人進行培訓。

第4章 Scrum局限性

隨著我們不斷加深對 SCRUM的理解發(fā)現(xiàn) SCRUM在指導研究和開發(fā)，特別是復(fù)雜的軟件開發(fā)方面有很大的局限性：SCRUM涵蓋了軟件開發(fā)生命周期的構(gòu)建階段，但它缺少了團隊初始創(chuàng)建階段，項目啟動，即將發(fā)布的軟件版本以及軟件階段維護的指導價值。