Computer：敏捷開發(fā)Scrum方法的簡介、發(fā)展歷程、開發(fā)流程之詳細(xì)攻略
敏捷開發(fā)Scrum方法的簡介
Scrum是迭代式增量軟件開發(fā)過程，是敏捷方法論中的重要框架之一，通常用于敏捷軟件開發(fā)。Scrum包括了一系列實(shí)踐和預(yù)定義角色的過程骨架，是一種流程、計(jì)劃、模式，用于有效率地開發(fā)軟件。
Scrum 是當(dāng)前最流行的敏捷軟件開發(fā)方法論和實(shí)施框架。Scrum 是一種團(tuán)隊(duì)管理工作的方式，其將工作分解為較小的工作單元，并在周期性固定的時(shí)間段內(nèi)持續(xù)地交付工作單元。
名詞解釋
周期性固定的時(shí)間段：稱為迭代(Iteration)或者沖刺(Sprint)。
較小的工作單元：稱為用戶故事(us)。用戶故事可以使用特定的格式來描述，其描述了一個(gè)對于客戶有價(jià)值的工作，而且可以在一個(gè)迭代周期內(nèi)完成。
Scrum的一個(gè)關(guān)鍵原則是承認(rèn)客戶可以在項(xiàng)目過程中改變主意，變更他們的需求，而預(yù)測式和計(jì)劃式的方法并不能輕易地解決這種不可預(yù)見的需求變化。同樣，Scrum采用了經(jīng)驗(yàn)方法-承認(rèn)問題無法完全理解或定義，而是關(guān)注于如何使得開發(fā)團(tuán)隊(duì)快速推出和響應(yīng)不斷出現(xiàn)的需求的能力最大化。
Scrum作為一個(gè)極佳的敏捷項(xiàng)目開發(fā)管理方法，讓過程項(xiàng)目管理變得更加有形，而可控軟件的自我組織和自我管理工作方式，也能讓所有成員積極配合并參與到全過程當(dāng)中。
雖然Scrum最初只應(yīng)用于軟件開發(fā)，它也可以被成功地應(yīng)用于其他產(chǎn)業(yè)。當(dāng)前Scrum通常被認(rèn)為是一種用于開發(fā)任何產(chǎn)品或管理人和工作的迭代式的，增量的過程。
1、Scrum發(fā)展歷程
1993年，Sutherland與Easel公司的John Scumniotales和Jeff McKenna一起開發(fā)了一套方法，取名為Scrum(來源于橄欖球術(shù)語，不是縮寫)。
1995年，OOPSLA大會上Sutherland和Schwaber第一次向世人介紹了Scrum。
2001年，Schwaber與Mike Beedle合著了《敏捷軟件開發(fā)-使用Scrum過程》一書，介紹了Scrum方法。
進(jìn)入新世紀(jì)，互聯(lián)網(wǎng)帶來的巨變使敏捷方法受到了更多開發(fā)團(tuán)隊(duì)的歡迎，而其中Scrum以其擴(kuò)展性、門檻低、名字和術(shù)語更容易被項(xiàng)目經(jīng)理接受等因素，逐漸成為最受歡迎的敏捷流派。
2、Scrum敏捷開發(fā)流程334
沖刺(Sprint)：可理解為迭代，一個(gè)時(shí)間周期(通常在2周到1個(gè)月之間)，開發(fā)團(tuán)隊(duì)會在此期間內(nèi)完成所承諾的一組訂單項(xiàng)的開發(fā)。
沖刺訂單(sprint backlog)
用戶故事(user story，us)
產(chǎn)品負(fù)責(zé)人/產(chǎn)品經(jīng)理(Product Owner)
敏捷教練(Scrum Master)
開發(fā)團(tuán)隊(duì)(Scrum Team)
產(chǎn)品訂單(product backlog)
產(chǎn)品負(fù)責(zé)人PO負(fù)責(zé)整理用戶故事us，形成左側(cè)的product backlog。
The Agile：Scrum Framework at a glance
Inputs from Executives,Team,Stakeholders,Customers,Users
敏捷：Scrum框架概覽
來自高管、團(tuán)隊(duì)、利益相關(guān)者、客戶、用戶
Scrum Master, Burndown/up Chars, Daily Scrum Meeting
敏捷教練，每日Scrum立會
Product Owner, The Team
Product Backlog, Sprint Planning Meeting
Sprint backlog
Sprint end date and team deliverable do not change
產(chǎn)品經(jīng)理，開發(fā)團(tuán)隊(duì)
產(chǎn)品訂單，沖刺計(jì)劃會
沖刺訂單
沖刺結(jié)束日期和團(tuán)隊(duì)可交付成果不變
Sprint Review
Finished Work
Sprint Retrospective
沖刺評審
完成的工作
沖刺回顧
3角
三個(gè)角色
具體工作內(nèi)容
產(chǎn)品經(jīng)理
(Product Owner)
主要負(fù)責(zé)確定產(chǎn)品功能和達(dá)到要求標(biāo)準(zhǔn)，指定軟件的發(fā)布日期和交付內(nèi)容，同時(shí)有權(quán)力接受或拒絕開發(fā)團(tuán)隊(duì)的工作成果。
敏捷教練
(Scrum Master)
主要負(fù)責(zé)保證整個(gè)Scrum流程在項(xiàng)目中的順利實(shí)施和進(jìn)行，以及清除擋在客戶和開發(fā)工作之間的溝通障礙，使得客戶可以直接驅(qū)動(dòng)開發(fā)。
開發(fā)團(tuán)隊(duì)
(Scrum Team)
主要負(fù)責(zé)軟件產(chǎn)品在Scrum規(guī)定流程下進(jìn)行開發(fā)工作，人數(shù)控制在5~10人左右。
3物—文檔
文檔
過程產(chǎn)出文檔說明
產(chǎn)品訂單
產(chǎn)品訂單(product backlog)是整個(gè)項(xiàng)目的概要文檔。
產(chǎn)品訂單包括所有所需特性的粗略的描述。產(chǎn)品訂單是關(guān)于將要?jiǎng)?chuàng)建的什么產(chǎn)品。根據(jù)初始需求分解出的任務(wù)列表，包括功能性和非功能性的所有功能。
沖刺訂單
沖刺訂單(sprint backlog)是大大細(xì)化了的文檔，包含團(tuán)隊(duì)如何實(shí)現(xiàn)下一個(gè)沖刺的需求的信息。
這是一個(gè)迭代計(jì)劃會議的輸出，包含開發(fā)團(tuán)隊(duì)在迭代周期內(nèi)所要完成的工作列表。
(1)、任務(wù)被分解為以小時(shí)為單位，沒有任務(wù)可以超過16個(gè)小時(shí)。如果一個(gè)任務(wù)超過16個(gè)小時(shí)，那么它就應(yīng)該被進(jìn)一步分解。
(2)、沖刺訂單上的任務(wù)不會被分派，而是由團(tuán)隊(duì)成員簽名認(rèn)領(lǐng)他們喜愛的任務(wù)。
燃盡圖
燃盡圖(burn down chart)是一個(gè)公開展示的圖表，向項(xiàng)目組成員和企業(yè)主提供工作進(jìn)展的一個(gè)公共視圖。顯示當(dāng)前沖刺中未完成的任務(wù)數(shù)目，或在沖刺訂單上未完成的訂單項(xiàng)的數(shù)目。在項(xiàng)目完成之前，對需要完成的工作的一種可視化表示。
(1)、燃盡圖有一個(gè)Y軸(工作)和X軸(時(shí)間)。理想情況下，該圖表是一個(gè)向下的曲線，隨著剩余工作的完成，“燒盡”至零。
4會—scrum基本流程
四個(gè)會議
具體內(nèi)容
產(chǎn)品發(fā)布計(jì)劃會議
產(chǎn)品負(fù)責(zé)人負(fù)責(zé)講解us，對其進(jìn)行估算和排序，發(fā)布計(jì)劃會議的產(chǎn)出就是制定出這一期迭代要完成的story列表，sprint backlog。
沖刺計(jì)劃會
Sprint Planning Meeting，在每個(gè)沖刺/迭代之初，由產(chǎn)品負(fù)責(zé)人PO講解需求(要完成的工作的內(nèi)容)，并由開發(fā)團(tuán)隊(duì)進(jìn)行估算的計(jì)劃會議。
每日立會
Daily Standup Meeting，每日站立會議，經(jīng)常被稱為“scrum”，即項(xiàng)目狀況會議。團(tuán)隊(duì)每天進(jìn)行溝通的內(nèi)部短會，因一般只有15分鐘且站立進(jìn)行而得名。
周期：每天，所有出席者都應(yīng)站立；
會議時(shí)間限制：15分鐘。
目的：開發(fā)團(tuán)隊(duì)和產(chǎn)品負(fù)責(zé)人都要進(jìn)行一個(gè)短暫的溝通。
團(tuán)隊(duì)成員，回答昨天做了什么？
今天計(jì)劃做什么？
遇到了什么問題？即完成你的目標(biāo)是否存在什么障礙，Scrum主管需要記下這些障礙。
評審會
Review Meeting，在沖刺結(jié)束前給產(chǎn)品負(fù)責(zé)人演示并接受評價(jià)的會議。
在迭代周期結(jié)束時(shí)，開發(fā)團(tuán)隊(duì)向產(chǎn)品負(fù)責(zé)人及所有干系人進(jìn)行演示，并接受反饋。
回顧會議
Retrospective Meeting，在沖刺結(jié)束后召開的關(guān)于自我持續(xù)改進(jìn)的會議。
周期：迭代周期結(jié)束時(shí)，每一個(gè)沖刺完成后，都會舉行一次沖刺回顧會議；
會議時(shí)間限制：4小時(shí)；
目的：通過會議來對迭代的過程進(jìn)行總結(jié)，促使團(tuán)隊(duì)自我持續(xù)改進(jìn)。提倡所有團(tuán)隊(duì)成員坐在一起工作，進(jìn)行口頭交流，以及強(qiáng)調(diào)項(xiàng)目有關(guān)的規(guī)范(disciplines)。
3、極限編程(XP)和 Scrum區(qū)別
對比指標(biāo)
XP
Scrum
迭代長度的不同
XP的一個(gè)Sprint的迭代長度大致為1~2周
Scrum的迭代長度一般為?2~ 4周
在一個(gè)迭代中—是否允許修改需求
在XP在一個(gè)迭代中，如果一個(gè)us(用戶素材, 也就是一個(gè)需求)還沒有實(shí)現(xiàn)， 則可以考慮用另外的需求將其替換， 替換的原則是需求實(shí)現(xiàn)的時(shí)間量是相等的。
Scrum是不允許這樣做的，一旦迭代開工會完畢, 任何需求都不允許添加進(jìn)來，并有Scrum Master嚴(yán)格把關(guān)，不允許開發(fā)團(tuán)隊(duì)受到干擾。
迭代中—us是否嚴(yán)格按照優(yōu)先級別來實(shí)現(xiàn)
XP是務(wù)必要遵守優(yōu)先級別的。
Scrum比較靈活，可以不按照優(yōu)先級別來做。
(1)、因?yàn)槿绻麅?yōu)先問題的解決者，由于其它事情耽擱，不能認(rèn)領(lǐng)任務(wù)，那么整個(gè)進(jìn)度就耽誤了。
(2)、如果按優(yōu)先級排序的User Story #6和#10，雖然#6優(yōu)先級高，但是如果#6的實(shí)現(xiàn)要依賴于#10，則不得不優(yōu)先做#10。
軟件實(shí)施過程中—是否采用嚴(yán)格的工程方法—保證進(jìn)度或者質(zhì)量
XP對整個(gè)流程方法定義非常嚴(yán)格，規(guī)定需要采用TDD、自動(dòng)測試、結(jié)對編程、簡單設(shè)計(jì)、重構(gòu)等約束團(tuán)隊(duì)的行為。
Scrum沒有對軟件的整個(gè)實(shí)施過程開出工程實(shí)踐的處方，要求開發(fā)者自覺保證。
