敏捷開發之scrum

如今敏捷開發是愈來愈火了，人人都在談敏捷，人人都在學習Scrum和XP...

 

爲了避免落後他人，因而我也開始學習Scrum，今天主要是對我最近閱讀的相關資料，根據本身的理解，用本身的話來說述Scrum中的各個環節，主要目的有兩個，一個是進行知識的總結，另一個是以爲網上不少學習資料的講述方式讓初學者不太容易理解；因此我決定寫一篇掃盲性的博文，同時試着也與園內的朋友一塊兒分享交流一下，但願對初學者有幫助。

 

 什麼是敏捷開發？

敏捷開發(Agile Development)是一種以人爲核心、迭代、按部就班的開發方法。

怎麼理解呢？首先，咱們要理解它不是一門技術，它是一種開發方法，也就是一種軟件開發的流程，它會指導咱們用規定的環節去一步一步完成項目的開發；而這種開發方式的主要驅動核心是人；它採用的是迭代式開發；

 

爲何說是以人爲核心？

咱們大部分人都學過瀑布開發模型，它是以文檔爲驅動的，爲何呢？由於在瀑布的整個開發過程當中，要寫大量的文檔，把需求文檔寫出來後，開發人員都是根據文檔進行開發的，一切以文檔爲依據；而敏捷開發它只寫有必要的文檔，或儘可能少寫文檔，敏捷開發注重的是人與人之間，面對面的交流，因此它強調以人爲核心。

 

什麼是迭代？

迭代是指把一個複雜且開發週期很長的開發任務，分解爲不少小週期可完成的任務，這樣的一個週期就是一次迭代的過程；同時每一次迭代均可以生產或開發出一個能夠交付的軟件產品。

 

關於Scrum和XP

前面說了敏捷它是一種指導思想或開發方式，可是它沒有明確告訴咱們到底採用什麼樣的流程進行開發，而Scrum和XP就是敏捷開發的具體方式了，你能夠採用Scrum方式也能夠採用XP方式；Scrum和XP的區別是，Scrum偏重於過程，XP則偏重於實踐，可是實際中，二者是結合一塊兒應用的，這裏我主要講Scrum。

 

什麼是Scrum？

Scrum的英文意思是橄欖球運動的一個專業術語，表示「爭球」的動做；把一個開發流程的名字取名爲Scrum，我想你必定能想象出你的開發團隊在開發一個項目時，你們像打橄欖球同樣迅速、富有戰鬥激情、人人你爭我搶地完成它，你必定會感到很是興奮的。

而Scrum就是這樣的一個開發流程，運用該流程，你就能看到你團隊高效的工做。

 

【Scrum開發流程中的三大角色】

產品負責人（Product Owner）

主要負責肯定產品的功能和達到要求的標準，指定軟件的發佈日期和交付的內容，同時有權力接受或拒絕開發團隊的工做成果。

 

流程管理員（Scrum Master）

主要負責整個Scrum流程在項目中的順利實施和進行，以及清除擋在客戶和開發工做之間的溝通障礙，使得客戶能夠直接驅動開發。

 

開發團隊（Scrum Team）

主要負責軟件產品在Scrum規定流程下進行開發工做，人數控制在5~10人左右，每一個成員可能負責不一樣的技術方面，但要求每成員必需要有很強的自我管理能力，同時具備必定的表達能力；成員能夠採用任何工做方式，只要能達到Sprint的目標。

 

 

Scrum流程圖

 

//------------------------

下面，咱們開始講具體實施流程，可是在講以前，我還要對一個英文單詞進行講解。

什麼是Sprint？

Sprint是短距離賽跑的意思，這裏面指的是一次迭代，而一次迭代的週期是1個月時間（即4個星期），也就是咱們要把一次迭代的開發內容以最快的速度完成它，這個過程咱們稱它爲Sprint。

 

如何進行Scrum開發？

一、咱們首先須要肯定一個Product Backlog（按優先順序排列的一個產品需求列表），這個是由Product Owner 負責的；

二、Scrum Team根據Product Backlog列表，作工做量的預估和安排；

三、有了Product Backlog列表，咱們須要經過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出一個Story做爲本次迭代完成的目標，這個目標的時間週期是1~4個星期，而後把這個Story進行細化，造成一個Sprint Backlog；

四、Sprint Backlog是由Scrum Team去完成的，每一個成員根據Sprint Backlog再細化成更小的任務（細到每一個任務的工做量在2天內能完成）；

五、在Scrum Team完成計劃會議上選出的Sprint Backlog過程當中，須要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每一個人都必須發言，而且要向全部成員當面彙報你昨天完成了什麼，而且向全部成員承諾你今天要完成什麼，同時遇到不能解決的問題也能夠提出，每一個人回答完成後，要走到黑板前更新本身的 Sprint burn down（Sprint燃盡圖）；

六、作到每日集成，也就是天天都要有一個能夠成功編譯、而且能夠演示的版本；不少人可能尚未用過自動化的每日集成，其實TFS就有這個功能，它能夠支持每次有成員進行簽入操做的時候，在服務器上自動獲取最新版本，而後在服務器中編譯，若是經過則立刻再執行單元測試代碼，若是也所有經過，則將該版本發佈，這時一次正式的簽入操做才保存到TFS中，中間有任何失敗，都會用郵件通知項目管理人員；

七、當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，咱們要進行 Srpint Review Meeting（演示會議），也稱爲評審會議，產品負責人和客戶都要參加（最好本公司老闆也參加），每個Scrum Team的成員都要向他們演示本身完成的軟件產品（這個會議很是重要，必定不能取消）；

八、最後就是 Sprint Retrospective Meeting（回顧會議），也稱爲總結會議，以輪流發言方式進行，每一個人都要發言，總結並討論改進的地方，放入下一輪Sprint的產品需求中；

 

 

下面是運用Scrum開發流程中的一些場景圖：

上圖是一個 Product Backlog 的示例。

 

上圖就是每日的站立會議了，參會人員能夠隨意姿式站立，任務看板要保證讓每一個人看到，當每一個人發言完後，要走到任務版前更新本身的燃盡圖。

任務看版包含 未完成、正在作、已完成 的工做狀態，假設你今天把一個未完成的工做已經完成，那麼你要把小卡片從未完成區域貼到已完成區域。

 

每一個人的工做進度和完成狀況都是公開的，若是有一我的的工做任務在某一個位置放了好幾天，你們都能發現他的工做進度出現了什麼問題（成員人數最好是5~7個，這樣每人可使用一種專用顏色的標籤紙，一眼就能夠從任務版看出誰的工做進度快，誰的工做進度慢）

 

 

 上圖可不是撲克牌，它是計劃紙牌，它的做用是防止項目在開發過程當中，被某些人所領導。

怎麼用的呢？好比A程序員開發一個功能，須要5個小時，B程序員認爲只須要半小時，那他們各自取相應的牌，藏在手中，最後攤牌，若是時間差距很大，那麼A和B就能夠討論A爲何要5個小時...

 

敏捷開發的4句宣言

個體與交互 賽過 過程與工具

能夠工做的軟件 賽過 面面俱到的文擋

客戶協做 賽過 合同談判

響應變化 賽過 遵循計劃

 

 

 

經驗一：整個團隊必須理解 Scrum 的目的和限制。
若是管理團隊把 Scrum 看成一種新的管理流程，那麼這個理解絕對是錯誤的，並且有害。要正確理解 Scrum 的實施原則，須要從理解其設計目的開始。

 

我所理解的 Scrum 的目的在於兩點：

1. 適應變化。Scrum 的一個基本假設，就是外部需求模糊而難以理解。Scrum 對此的理念是：讓客戶直接看到半成品，他們才知道本身要什麼。不少 Scrum 的原則都是圍繞如何解決這個問題的：好比每一個 Sprint 結束時由 Product Owner 爲客戶進行展現，又好比任務細化通常不超過一個 Sprint。理解了這一點，纔會理解爲何 Scrum 彷佛總在變化，由於需求總在變化。
2. 快速迭代。Scrum 的另外一個基本假設，是團隊生存在一個快速變化且充滿競爭的世界。若是本身一年半才能發佈一個新版本，而競爭對手半年就能發佈，那麼幾年以內，咱們就會被對手甩得遠遠的。Scrum 對此的理念是：發佈即 Milestone（里程碑），寧肯每次發佈二十個功能發佈五次，也不要在內部搞五個 Milestone 而後一口氣發佈一百個功能。理解了這一點，纔會理解爲何 Scrum 會認爲發佈時砍功能是一種正常狀況而非一種失敗。

要實施 Scrum，整個團隊至少必須取得共識，即以上兩點是不能商量的。流程必須爲目的服務。若是隊伍相信增長前期溝通才是讓需求清晰起來的最好方法，或者相信發佈的功能必須是大批量一次性，那麼請使用瀑布開發模式。

相應地，咱們必須明白 Scrum 不能作什麼。個人理解可能聳人聽聞，還是兩點：

1. 由於發佈週期縮短，團隊沒有能力保證做出的每個決定都正確，不少開銷都必須花在試錯上；
2. 快速發佈實際上致使 Scrum 團隊的抗風險能力弱於瀑布模型團隊，由於一我的的離職或病假均可能對單一功能的進度形成影響，不利於短時間頻繁發佈。

Scrum 對此的解答是：不要試圖不犯錯誤，而是保證小的錯誤能被儘快發現從而不會釀成大錯。因此 Scrum 過程當中總會有些不肯定性，或者功能不合需求而返工，或者忽然缺了人手致使一些單個功能必須延期完成。若是非要事先肯定發佈週期並且還得保證不準功能裁剪，請出門左轉找 CMM 認證：它能夠把任務精確到每一個對話框上該用什麼字體。前期計劃精確到這個粒度，什麼均可以在掌控之中。但問題是，咱們必須用更長的發佈週期來換。

理解了上面的內容，咱們實施時就不會對某些形式性的東西過於糾結，好比 Burn down chart，好比 Scrum 撲克。需知形式服務於目的，而形式未必適用於每個團隊，正如瀑布模型在每個團隊中也都有差別。若是僅僅是由於團隊成員沒有在 planning meeting 上打撲克就認定這不是 Scrum，那麼未免愚蠢了些。反過來，某些看似煩人的「流程」卻不可或缺，好比天天的 15 分鐘 stand-up，若是咱們明白它對交流方面的重要做用，就絕對不會認爲它能夠被省略。

舉個實際的例子，在咱們的團隊裏，咱們強迫一週一個 Sprint。就我所知，即便在不少實施很成功的項目中，這種作法也是至關激進的。一開始我也不理解這一點，但實施了一段時間後，我開始認同這一條，由於一週的發佈週期讓咱們沒有機會把任務日後推，從而迫使咱們儘快從瀑布模型中轉移出來。這對一個有着悠久瀑布開發傳統的團隊來講很是重要，但對別的團隊來講，就不必定了。

經驗二：正肯定位隊伍中的 Scrum Master。
爲何單獨提 Scrum Master？若是隻是看書本和參加培訓，我相信多數人都會贊成個人觀點，即 Scrum Master 或許是整個開發過程當中做用最不清楚的角色：不參與需求分析、不參與代碼開發、甚至不參與任何人事問題，只有一句「去除阻礙」這種含糊的表述。可是，當我真正當起這個 Scrum Master 以後，才發現這個角色承擔的職責很是具體。好比：

1. 確保流程執行正確。進入 Scrum 以後，不少團隊仍然會以各類方式走老路，好比有意無心地拉長 Sprint 週期，並以此區別計劃周、開發周和測試周，其實是把原來三個月的瀑布開發週期變成了兩到四個星期的瀑布週期；又好比以開發時間有限爲理由把自動測試開發任務縮減爲手工測試。好的 Scrum Master 應該有能力發現並制止這種狀況。——順便說一句，相信我，不要覺得兩個星期的瀑布週期是個可行的開發計劃，咱們不可能完成測試任務的。
2. 制止官僚主義流程。典型的例子就是一個又一個的 spec/plan review 和 sign-off 郵件；又好比非要區分所謂 Unit Test、BVT 和 Functional Test：或許對一個圖形界面程序來講這二者區別極大，可對於函數庫則幾乎沒有原則差異。合格的 Scrum Master 應該制止這樣的傾向。——不過我也得說，這一條我如今作得不好，還須要改進。
3. 構建交叉知識結構。整個團隊的知識模型應該是各有專長但互有交叉的，而傳統開發的一個很重要的問題是知識結構不平衡，好比測試的只管測試，開發的只管開發。這種模式對於發佈時間長的大團隊來講也許能接受，但對人手短缺又要求快速發佈的小團隊則是致命的。好的 Scrum Master 應當可以對團隊的決策具有影響力，確保不會讓某個任務陷入「只有一我的知道細節」的狀況。——這一條在習慣了傳統瀑布開發模型的團隊中每每是最大的阻礙，須要時間改善。

但正由於上面的理解，我基本上不一樣意 Scrum Alliance 的教科書裏關於 Scrum Master 的大多數表述。首先，Scrum Master 必須承擔一部分開發任務，由於沒有介入一線開發，很難想象 Scrum Master 會真正理解團隊的「痛點」。其次，Scrum Master 須要關注團隊的每個人，否則隊伍可能因爲所謂「自組織」的原則而隱藏一些問題，好比某我的過於專精某一項而忽略了和其它成員的交流。固然，也有些部門的 Scrum Master 只負責寫報告和推事情。這不是我共事過的任何一位 Scrum Master 的作法，並且我也能夠很自信地說，這種 Scrum Master 在咱們公司是生存不下去的。

Scrum Master，你是肩負着人類使命的人啊！嗯！（握拳）

最後，貼兩句最近剛學到的話：

1. 50% percent of our decisions are wrong. Fail fast, learn fast. （咱們做出的決定中， 50% 都是錯誤的。早早失敗，早早學習。）
2. No matter what you want to do, choose what is good for your team.（不管你選擇作什麼，選擇對你的團隊有利的事）

先聲明，說上面兩句話的哥們本人在咱們隊伍裏不算很受歡迎，但這兩句我很喜歡。在我眼裏，這兩句話指出了 Scrum 的全部實質。

-----------------------------------------------------------------------------------------------

咱們公司的開發團隊，實踐Scrum的效果很是好。在項目開始以前，咱們在內部作了一個 Scrum 的科普，很是適合這個問題，我稍加修改發在這裏，確定能幫到你們。

 

1、角色分配和價值觀

咱們先來看看，一個團隊實踐 Scrum 的角色分配▼

 

Scrum 中的角色結構很是扁平，有三種角色：

一、PO：Product Owner，產品負責人，肯定「你們要作什麼」。互聯網公司的 PO 通常由相關的產品經理擔任；若是是爲客戶作項目，PO 通常就是客戶負責人。

二、Scrum Master：Scrum的推進者，掌控大節奏的人。

三、Team：通常由多個 developer 組成，開發的主力。

 

三種角色有各自的責任，但三者間並無上司和下屬的關係。這正是 Scrum 區別於傳統開發流程的精華：

一、傳統的開發流程，是由領導拍板的中央集權制；

二、Scurm 是人人平等的民主制，每一個人的能力都被信任，更加自主，能發揮出更高的效率。

 

Scrum 的價值觀▼

 

 

2、三大神器

 

Production Backlog、Sprint Backlog 和燃盡圖是三大神器。下面一一介紹。

 

Backlog 是 Scrum中的一個專用名詞，意思是待辦工做事項的集合。

 

1. Product Backlog (產品待辦事項列表)是量化的用戶需求，條目化地表達實際須要開發的需求。

2. Sprint Backlog（任務列表）是一次迭代中須要完成的任務，也是開發過程用得最多的Backlog，很是細化。

 

二者區別見下圖▼

 

 

3. 什麼是燃盡圖？

 

咱們天天累加全部任務的剩餘時間，將其標註在圖表上。用藍色的表示計劃走向，紅色線則是實際走向，兩條線共同組成了燃盡圖。

好比下圖中的燃盡圖，一開始表明實際走向的紅線高於計劃藍線，說明開發初始，任務完成慢，可能遇到了困難。

 

 

3、Scrum 的四個會議

 

1. Sprint 計劃會

 

Sprint 計劃會就是你們坐下來，PO 向你們介紹排好序的產品待辦事項（Production Backlog），而後你們共同思考決定如何推動計劃，梳理出 Sprint Backlog 來完成後續的工做。

簡單點說，這是一個你們理解「須要作什麼」，而後討論「怎麼完成」，並造成待辦事項列表的會議。

 

2. 每日站會 Daily Scrum

 

你們在一塊兒，自發地彙報三點：

a：從昨天Daily Scrum到這一刻，我完成了什麼工做？

b：從這一刻到明天的Daily Scrum，我計劃完成什麼工做？

c：是否有什麼困難阻礙了個人進展？

 

3. Sprint 評審會（Sprint Review）

 

在 Sprint 結束後，你們一塊兒評審本次 Sprint 的產出。每一個人均可以自由發表見解，協助產品負責人對將來工做作出最終決定。並根據實際狀況，適度調整產品待辦事項列表（Product Backlog）。

 

4. Sprint回顧會（Sprint Retrospective）

 

在一次Sprint結束後，你們聚在一塊兒開這個會，回顧一下團隊在流程和溝通等方面的成效。你們一塊兒討論，哪裏完成得好，哪裏還需改進？

 

 

以上四種會議，都是你們集思共享的快速會議，注意控制好每次會議的時長。

 

4、用Teambition 打造小而美的 Scrum 團隊

 

傳統的 Scrum，會用白板和 Excel 等工具。但正如前面所說，Scrum 不拘泥於形式，是探索更高效率的實踐，因此有很多團隊開始使用協做工具，在這方面咱們選了 Teambition。

 

使用協做工具來實踐 Scrum，最直觀的感覺就是，對 Backlog 的管理和會議活動管理很是方便，能更好地實現團隊協做、需求到研發的信息關聯與共享。好比 Teambition 中的「任務」看板功能，把全部任務及進程都「平鋪」開來顯示，實現了便捷的項目流程化管理；「分享」功能，你們在其中共享工做信息、總結知識經驗 ；「文檔」至關於該項目的共享協做網盤，你們能隨時訪問、更新共享資料；「羣聊」則更像是該項目的微信羣聊，支持項目成員隨時溝通想法，而且自動保留每一條消息。別再用微信溝通工做，讓工做的溝通發生在工做的平臺上。

 

除了團隊的溝通與共享，協做工具在對 Backlog 上的管理也很是方便。

 

一、用 Teambition 管理 Product Backlog

 

二、用 Teambition 管理 Sprint Backlog ▼

 

三、不一樣 Backlog 間的聯動，從 Product Backlog中提取需求到 Sprint Backlog▼

 

 

四、關於實踐 Scrum，前面介紹了四種會議，用協做工具線上開會也很是方便，這裏以 Daliy Scrum 爲例：每日立會能夠經過在 TB 項目的日程中設置，Scrum的團隊成員都添加爲參與者，將站會的日程設爲每一個工做日重複，而且提早15分鐘提醒你們▼

 

 

五、開 Sprint 評審和回顧會議時，能夠將會議記錄在線記錄在分享中，並和日程關聯起來，方便你們查閱▼

 

 

 

以上是咱們實踐 Scrum 的一些心得，經過共享與協做，在開發過程當中提升了效率，這應該也是 Scrum 現在這麼受歡迎的緣由。以爲回答有幫助，歡迎點贊支持~