一、Scrum基礎(chǔ)概念

敏捷開發(fā)背景
速度是企業(yè)競爭致勝的關(guān)鍵因素，軟件項(xiàng)目的最大挑戰(zhàn)在于一方面需要應(yīng)付變動中的需求，一方面需要在有限的時間完成項(xiàng)目，傳統(tǒng)的軟件工程難以滿足這些要求
所以軟件團(tuán)隊(duì)除了在技術(shù)上必須日益精進(jìn)，更需要運(yùn)用有效的開發(fā)流程，以確保團(tuán)隊(duì)能夠發(fā)揮綜效。這正是Agile Process (敏捷的軟件開發(fā)流程)于近年來興起的主要原因。

1.1 傳統(tǒng)開發(fā)模式與敏捷開發(fā)的區(qū)別

1、瀑布開發(fā)：

• 預(yù)見性開發(fā)模式
• 每一個步驟有嚴(yán)格產(chǎn)出成果
• 設(shè)計越完美，成本損失越小
• 不適應(yīng)快速變化
  
  2、敏捷開發(fā)
• 人和交互重于過程和工具
• 可工作的軟件 重于全而完備的文檔
• 客戶協(xié)作 重于合同談判
• 隨時應(yīng)對變化 重于 循規(guī)蹈矩
  

1.2 傳統(tǒng)項(xiàng)目管理與敏捷項(xiàng)目管理的區(qū)別

1、傳統(tǒng)項(xiàng)目管理

• 事先對整個項(xiàng)目進(jìn)行估計、計劃、分析
• 反對變更，變更需要重新估計、重新規(guī)些
• 嚴(yán)密的合同來減少風(fēng)險，如果改變需求要走CR 流程
• 項(xiàng)目作為一個“黑盒子”，對客戶與供應(yīng)商的可視性差
• 文檔和計劃驅(qū)動的方法軟件交付時間晚，意識到風(fēng)險的時間晚WBS,甘特圖,關(guān)鍵路徑分析

2、敏捷項(xiàng)目管理

• 對整個項(xiàng)目做一個粗略的估計,每一次迭代都有詳細(xì)的計劃
• 鼓勵變化，客戶價值驅(qū)動開發(fā)
• 信任和賦予權(quán)力;合約使變更變得簡單，增加價值
• 客戶和開發(fā)人員之間是緊密的連續(xù)的合作關(guān)系
• 每次迭代都產(chǎn)生可交付的軟件，專注于交付軟件
• 第一次迭代就可交付能工作的版本，風(fēng)險發(fā)現(xiàn)的早

1.3 敏捷宣言

1、敏捷宣言

1. 個體和交互 勝于 流程和工具
2. 可工作軟件 勝于 幾長的文檔
3. 與客戶協(xié)作 勝于 合同的談判
4. 對變化響應(yīng) 勝于 遵循原計劃

敏捷開發(fā)的核心思想是: 以人為本，適應(yīng)變化敏捷思想是:一種以人為核心、迭代、循序漸進(jìn)的開發(fā)方法

2、敏捷開發(fā)12個原則

1. 最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意
2. 即使到了開發(fā)的后期，也歡迎改變需求。
3. 經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的 時間間隔越短越好
4. 在整個項(xiàng)目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。
5. 圍繞被激勵起來的個人來構(gòu)建項(xiàng)目。
6. 在團(tuán)隊(duì)內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的 交談。
7. 工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)。
8. 敏捷過程提倡平穩(wěn)的開發(fā)節(jié)奏;發(fā)起人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。
9. 不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強(qiáng)敏捷能力。
10. 簡單化是根本(不做過度設(shè)計和預(yù)測)
11. 最好的構(gòu)架、需求和設(shè)計出自于自組織的團(tuán)隊(duì)。
12. 每隔一定時間，團(tuán)隊(duì)會在如何才能更有效地工作方面進(jìn)行反思并對自己的行為進(jìn)行相應(yīng)調(diào)整。

1.4 敏捷開發(fā)的特征

在敏捷開發(fā)中，軟件項(xiàng)目在構(gòu)建初期被切分成多個子項(xiàng)目，各個子項(xiàng)目的成果都經(jīng)過測試，具備可視、可集成和可運(yùn)行使用的特征。

1、敏捷的方法

敏捷方法包括：Extreme Programming（XP）極限編程、Scrum、Adaptive Software Development (ASD)自適應(yīng)軟件開發(fā)、Crystal Clear and Other Crystal Methodologies水晶方法、Dynamic Systems Development Method (DSDM)動態(tài)系統(tǒng)開發(fā)方法 等等

1、Extreme Programming（XP）極限編程

• XP我們一般稱為極限編程，是最輕量級的開發(fā)流程。每個Sprint的迭代周期大致為1-2周。
• 最主要的精神是：在客戶有系統(tǒng)需求時，給予及時滿意的可執(zhí)行程序、所以最適合需求快速變動的項(xiàng)目
• 它強(qiáng)調(diào)客戶所要的是：
  • workable的執(zhí)行碼，所以把與撰寫程序無關(guān)的工作降至最低，并要求客戶與開發(fā)人員最好以side-by-side的方式一起工作
• XP的實(shí)踐包括：
  • 完整團(tuán)隊(duì)、計劃游戲、客戶測試、簡單設(shè)計、結(jié)對編程、測試驅(qū)動開發(fā)、改進(jìn)設(shè)計、持續(xù)集成、集體代碼所有權(quán)
  • 編碼標(biāo)準(zhǔn)、隱喻、可持續(xù)的速度
    
    2、Scrum整體框架
• Scrum 是用于開發(fā)、交付和持續(xù)支持復(fù)雜產(chǎn)品的一個框架，是一個增量的、迭代的開
  發(fā)過程。
• 在這個框架中，整個開發(fā)過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，每個Sprint的建議長度是2至4周
• 在Scrum中，使用產(chǎn)品Backlog來管理產(chǎn)品的需求，產(chǎn)品backlog是一個按照商業(yè)價值排序的需求列表，列表?xiàng)l目的體現(xiàn)形式通常為用戶故事。Scrum團(tuán)隊(duì)總是先開發(fā)對客戶具有較高價值的需求。
• 在Sprint中，Scrum團(tuán)隊(duì)從產(chǎn)品Backlog中挑選最高優(yōu)先級的需求進(jìn)行開發(fā)。挑選的需求在Sprint計劃會議上經(jīng)過討論、分析和估算得到相應(yīng)的任務(wù)列表，我們稱它為Sprint backlog。在每個選代結(jié)束時，Scrum團(tuán)隊(duì)將遞交潛在可交付的產(chǎn)品增量
  

二、角色與職責(zé)

本節(jié)介紹Scrum開發(fā)方法下的角色與職責(zé)。

• 角色包括：Product Owner(PO)產(chǎn)品負(fù)責(zé)人（所有者），Scrum Master 敏捷教練，Team團(tuán)隊(duì)
• Artfacts工件 ： Product Backlog 產(chǎn)品Backlog（需求清單），Sprint Backlog 迭代Backlog，Increment潛在可交付產(chǎn)品增量
• Ceremonies儀式（敏捷開發(fā)過程中的會議）：PB Refinement 產(chǎn)品需求澄清、Sprint Review 迭代計劃會議、Daily Meeting 每日立會、Sprint Review 評審會議、Sprint Retrospective回顧會議
  特性Features：Courage勇氣，Openness 開放、Commitment 承諾、Focus 專注、Respect 尊重

2.1 Scrum Team

Scrum 的基本單位是小團(tuán)隊(duì)(一般10人以下)，稱為Scrum Team。Scrum Team，一名Scrum MasterProduct Owner 和 Developers 組成。在 Scrum Team 中，沒有子團(tuán)隊(duì)或?qū)哟谓Y(jié)構(gòu)。Scrum Team是具有凝聚力的專業(yè)團(tuán)體，一次專注于一個目標(biāo)，即 Product Goal。
Scrum Team 是跨職能的(cross-functional)，這意味著團(tuán)隊(duì)成員具有在每個 Sprint 中創(chuàng)造價值而所害的全部技能。他們也是自管理的，這意味著他們在團(tuán)隊(duì)內(nèi)部決定誰做什么、何時做以及如何做。
Scrum Team 規(guī)模足夠小以保持靈活，同時足夠大以便可以在 一個 Sprint 中完成重要的工作，通常只有 10 人或更少?？偟膩碚f，我們發(fā)現(xiàn)較小的團(tuán)隊(duì)溝通更好，效率更高。如果 Scrum Team變得太大，則應(yīng)考慮將他們重組為多個具有凝聚力的Scrum Team，每個團(tuán)隊(duì)都專注于同一產(chǎn)品。因此，他們應(yīng)該共享相同的Product Goal、Product Backlog 和 Product Owner。

1、Developers

• 為 Sprint 創(chuàng)建計劃，即Sprint Backlog;
• 通過遵循 Definition of Done 來注入質(zhì)量;
• 每天根據(jù) Sprint Goal 調(diào)整計劃;
• 作為專業(yè)人士對彼此負(fù)責(zé)。

2、Product Owner

• Product Owner 負(fù)責(zé)將Scrum Team 的工作所產(chǎn)生的產(chǎn)品價值最大化
• Product Owner 還負(fù)責(zé)對Product Backlog 進(jìn)行有效管理，包括:
  • 開發(fā)并明確地溝通Product Goal;
  • 創(chuàng)建并清晰地溝通Product Backlog 條目 (items);
  • 對 Product Backlog 條目進(jìn)行排序:
  • 確保 Product Backlog 是透明的、可見的和可理解的。
• Product Ower 可以自己做上述工作，或者也可以將職責(zé)委托他人。然而無論如何，ProductOwner 是負(fù)最終責(zé)任的人。
• 為保證 Product Owner 取得成功，整個組織必須尊重他們的決定。這些決定在Product Backlog的內(nèi)容和順序中可見，并在 Sprint Review 時透過可檢視的 Increment 予以體現(xiàn)。

3、Scrum Master

• 負(fù)責(zé)按照Scrum 指南的游戲規(guī)則來建立Scrum。他們通過幫助Scrum Team 和組織內(nèi)Scrum Master的每個人理解 Scrum 理論和實(shí)踐來做到這一點(diǎn)

• Scrum Master 以多種方式服務(wù)于Scrum Team，包括:

  • 作為教練在自管理和跨職能方面輔導(dǎo)Scrum Team 成員;
  • 幫助 Scrum Team 專注于創(chuàng)建符合 Definition of Done 的高價值 Increment;
  • 促使移除 Scrum Team 工作進(jìn)展中的障礙:
  • 確保所有 Scrum 事件都發(fā)生并且是積極的、富有成效的，并且在時間盒 (timebox)內(nèi)完成。

• 負(fù)責(zé)按照Scrum 指南的游戲規(guī)則來建立Scrum。Scrum Master的每個人理解 Scrum 理論和實(shí)踐來做到這一點(diǎn)

• Scrum Master 以多種方式服務(wù)于Product Owner，包括

  • 幫助找到有效定義Product Goal 和管理Product Backlog 的技巧;
  • 幫助 Scrum Team 理解為何需要清晰且簡明的Product Backlog 條目;
  • 幫助建立針對復(fù)雜環(huán)境的基于經(jīng)驗(yàn)主義的產(chǎn)品規(guī)劃 (empirical product planning);
  • 當(dāng)需要或被要求時，引導(dǎo)利益攸關(guān)者協(xié)作。

• Scrum Master 負(fù)責(zé)按照Scrum 指南的游戲規(guī)則來建立Scrum。他們通過幫助Scrum Team 和組織內(nèi)的每個人理解 Scrum 理論和實(shí)踐來做到這一點(diǎn)

• Scrum Master 以多種方式服務(wù)于組織，包括

  • 帶領(lǐng)、培訓(xùn)和作為教練輔導(dǎo)組織采納Scrum;
  • 在組織范圍內(nèi)規(guī)劃并建議Scrum 的實(shí)施
  • 幫助員工和利益攸關(guān)者理解并實(shí)施針對復(fù)雜工作的經(jīng)驗(yàn)主義方法 (empirical
    approach):
  • 消除利益攸關(guān)者和Scrum Teams 之間的隔閡。

2.2 角色職責(zé)總結(jié)

Scrum團(tuán)隊(duì)總結(jié)出來有：三個角色，四個儀式，三個物件
1、三個角色
- 產(chǎn)品負(fù)責(zé)人
- Scrum Master
- 團(tuán)隊(duì)
2、四個儀式
- Sprint計劃會議
- 每日站會
- Sprint評審會議
- Sprint 回顧會議
3、三個物件
- 產(chǎn)品Backlog
- Sprint Backlog
- 燃盡圖

2.3、研發(fā)階段概覽

1、Sprint計劃會議

• 團(tuán)隊(duì)從產(chǎn)品backlog中挑選他們承諾完成的條目。
• 創(chuàng)建Sprint Backlog
  • 標(biāo)識具體的任務(wù)并為任務(wù)做估算
  • 由團(tuán)隊(duì)協(xié)作完成，而不是Scrum Master
• 考慮了高層設(shè)計
• Sprint 計劃會議會產(chǎn)生一些實(shí)實(shí)在在的成果
  • Sprint目標(biāo)
  • 團(tuán)隊(duì)成員名單(以及他們的投入程度，如果不是 100%的話)
  • Sprint backlog(即 Sprint 中包括的故事列表)
  • 確定好 Sprint 演示日期
  • 確定好時間地點(diǎn)，供舉行每日 Scrum 會議
    

2、產(chǎn)品實(shí)施階段

- 產(chǎn)品實(shí)施階段工作:
	- 開發(fā)、測試、監(jiān)控.
- 方法:
	- 任務(wù)看板、燃盡圖、每日立會
- Sprint backlog的形式
	- Redmine、Jira、禪道、阿里云效等等
	
	**燃盡圖**
> 燃盡圖 (burn down chart) 是在項(xiàng)目完成之前，對需要完成的工作的一種可視化表示。
> 分為：Sprint燃盡圖，迭代燃盡圖
> Sprint燃盡圖展示了以故事點(diǎn)表示的在本輪迭代中剩余的工作量。
> y軸：預(yù)估剩下的故事點(diǎn)
> x軸：日期(非工作日除外)
> y/x=生產(chǎn)率
燃盡圖分板示例：

哪些信息可以從每日燃盡圖中得到，卻不能從迭代燃盡圖中得到?
每日燃盡圖顯示了團(tuán)隊(duì)在某輪迭代中的進(jìn)度，你可以用這個信息判斷計劃的工作能否在迭代結(jié)束時都能完成。

哪些情況下燃盡圖會有向上的趨勢
加新任務(wù)的速度比完成任務(wù)的速度快
有大量的任務(wù)被低估了

每日例會

• 最好在每天早上開，時間一般控制在15分鐘之內(nèi)
• 條件允許的話，會議最好每天都在同一時間同一地點(diǎn)舉行
• 誰都可以參加這個會議，但只有團(tuán)隊(duì)成員發(fā)言，其它人員只能旁聽
• 所有出席者都應(yīng)站立(有助于保持會議簡短)
• 確定更新燃盡圖
• 會議由Scrum Master主持，在會上每個團(tuán)隊(duì)成員需要問3個問題
  • 我昨天完成了哪些工作
  • 我今天將要做什么
  • 我遇到哪些障礙

3、Sprint評審會議

• 在Sprint結(jié)束時召開，會議時間控制在兩小時以內(nèi)
• 開發(fā)團(tuán)隊(duì)展示這個Sprint中完成的功能，不需要PPT，一般是已經(jīng)完成的功能DEMO
• 客戶、管理層、Product Owner以及其它開發(fā)人員都可以參加
• 主要是對項(xiàng)目開發(fā)的進(jìn)度通過對實(shí)際已完成產(chǎn)品功能的審核進(jìn)行控制，由產(chǎn)品負(fù)責(zé)人斷定實(shí)際所發(fā)兩點(diǎn)的功能是否與既定的Sprint目標(biāo)一致

4、Sprint回顧會議

• Sprint結(jié)束后，時間在1-3個小時
• 回顧剛結(jié)束的Sprint，對其進(jìn)行總結(jié)和反思，審視和適應(yīng)的能力是Scrum 的基礎(chǔ)，在Sprint回顧會議期間，項(xiàng)目團(tuán)隊(duì)會分析Sprint中的成功經(jīng)驗(yàn)和所遇到的阻礙，
• 產(chǎn)品負(fù)責(zé)人、Scrum團(tuán)隊(duì)和Scrum Master參加

三、敏捷開發(fā)實(shí)踐

3.1、增量迭代

每個迭代有一個大約為1~4周的時間框，在SCRUM里稱為一次沖刺(超過1個月的詳細(xì)計劃往往偏差很大)
每次迭代都應(yīng)該有明確的目標(biāo)
每次迭代都應(yīng)該有明確的可演示的工作成果
迭代過程中項(xiàng)目團(tuán)隊(duì)?wèi)?yīng)該盡量免受打擾
迭代可以將項(xiàng)目的壓力分解到每個小的階段，風(fēng)險也能同時分解

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

什么是測試驅(qū)動？

• 首先創(chuàng)建測試用例，然后開發(fā)軟件通過測試(在開發(fā)代碼前，首先編寫測試代碼)
• 一種設(shè)計軟件的方法，而不僅僅是一種測試方法
• 所創(chuàng)建的測試用例用來指導(dǎo)和約束項(xiàng)目中的各項(xiàng)工作，對未來的各項(xiàng)工作提供一個安全的保護(hù)
• 不需要測試的工作不需要完成
• 所創(chuàng)建的測試用例通常替代詳細(xì)的業(yè)務(wù)和技術(shù)需求定
• 測試也有效地驅(qū)動設(shè)計，使設(shè)計更加趨向于可行的設(shè)計
• 通常情況下需要自動測試的支持 (EUnit，JUnit etc.).
• 對于UI軟件應(yīng)用TDD方法有一定的困難

3.3、持續(xù)集成

極限編程稱為“每日構(gòu)建”

• 持續(xù)集成一般利用ant,maven,jenkins等工具
• 每日構(gòu)建的好處：
  • 將集成風(fēng)險降到最低
  • 降低質(zhì)量風(fēng)險
  • 提升士氣
• 每日構(gòu)建可以看做是項(xiàng)目的心跳，冒煙測試就像是聽診器
• 每日構(gòu)建必須至少:成功編譯、打包、發(fā)布;不含有任何明顯的缺陷;通過冒煙測試

3.4、面對面交流

• 雖然如今通訊工具花樣繁多，但面對面交流在某些場合下仍然是不可替代的;
• 敏捷開發(fā)把交流缺失問題考慮在內(nèi)，要求團(tuán)隊(duì)成員彼此直接協(xié)作，盡量創(chuàng)造面對面交流的機(jī)會:
• 尤其當(dāng)業(yè)務(wù)分析師和軟件開發(fā)人員一起工作的時候，面對面的交流是很重要的。
• 署名共享需求文檔只會打開曲解和誤解之門更不用說書面信息比口頭交流還要慢很多

其他：文章來源地址http://www.zghlxwxcb.cn/news/detail-698145.html

• 結(jié)對編程、每日立會、用戶故事、團(tuán)隊(duì)工作室、頻繁發(fā)布、自組織團(tuán)隊(duì)、重構(gòu)

3.5、Scrum何時 使用更有效

• 公司和客戶一致認(rèn)為應(yīng)當(dāng)使用敏捷方法，雙方都能理解敏捷方法
• 敏捷方法對需求不完整以及經(jīng)常變換的項(xiàng)目比較有效
• 項(xiàng)目可以劃分成固定時間間隔的迭代，并且可以凍結(jié)正在進(jìn)行的迭代的范圍
• 公司和客戶都有能力擔(dān)當(dāng)角色尤其是Product Owner 和 Scrum Master
• 項(xiàng)目的人員結(jié)構(gòu)能夠分成6到10人的團(tuán)隊(duì)，最好每個工作地點(diǎn)一個小組.(Scrum of
  Scrums，Scrum的擴(kuò)展)
• 才隊(duì)成員能夠以自組織的方式工作
• 項(xiàng)目的合同允許變更：固定價格的項(xiàng)目可以使用敏捷，但應(yīng)當(dāng)盡量避免。最好在按時間和材料付費(fèi)或者按月付費(fèi)的項(xiàng)目中進(jìn)行使用、變更項(xiàng)目的范圍不需要高級管理層的批準(zhǔn)

到了這里，關(guān)于第七章：敏捷開發(fā)工具方法-part1-敏捷開發(fā)基礎(chǔ)的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！