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大會(huì)上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ì)會(huì)在此期間內(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立會(huì) |
| 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ì)劃會(huì) 沖刺訂單 沖刺結(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ì)劃會(huì)議的輸出，包含開發(fā)團(tuán)隊(duì)在迭代周期內(nèi)所要完成的工作列表。 (1)、任務(wù)被分解為以小時(shí)為單位，沒有任務(wù)可以超過16個(gè)小時(shí)。如果一個(gè)任務(wù)超過16個(gè)小時(shí)，那么它就應(yīng)該被進(jìn)一步分解。 (2)、沖刺訂單上的任務(wù)不會(huì)被分派，而是由團(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會(huì)—scrum基本流程
| 四個(gè)會(huì)議 | 具體內(nèi)容 |
| 產(chǎn)品發(fā)布計(jì)劃會(huì)議 | 產(chǎn)品負(fù)責(zé)人負(fù)責(zé)講解us，對其進(jìn)行估算和排序，發(fā)布計(jì)劃會(huì)議的產(chǎn)出就是制定出這一期迭代要完成的story列表，sprint backlog。 |
| 沖刺計(jì)劃會(huì) | Sprint Planning Meeting，在每個(gè)沖刺/迭代之初，由產(chǎn)品負(fù)責(zé)人PO講解需求(要完成的工作的內(nèi)容)，并由開發(fā)團(tuán)隊(duì)進(jìn)行估算的計(jì)劃會(huì)議。 |
| 每日立會(huì) | Daily Standup Meeting，每日站立會(huì)議，經(jīng)常被稱為“scrum”，即項(xiàng)目狀況會(huì)議。團(tuán)隊(duì)每天進(jìn)行溝通的內(nèi)部短會(huì)，因一般只有15分鐘且站立進(jìn)行而得名。 周期：每天，所有出席者都應(yīng)站立； 會(huì)議時(shí)間限制：15分鐘。 目的：開發(fā)團(tuán)隊(duì)和產(chǎn)品負(fù)責(zé)人都要進(jìn)行一個(gè)短暫的溝通。 團(tuán)隊(duì)成員，回答昨天做了什么？ 今天計(jì)劃做什么？ 遇到了什么問題？即完成你的目標(biāo)是否存在什么障礙，Scrum主管需要記下這些障礙。 |
| 評審會(huì) | Review Meeting，在沖刺結(jié)束前給產(chǎn)品負(fù)責(zé)人演示并接受評價(jià)的會(huì)議。 在迭代周期結(jié)束時(shí)，開發(fā)團(tuán)隊(duì)向產(chǎn)品負(fù)責(zé)人及所有干系人進(jìn)行演示，并接受反饋。 |
| 回顧會(huì)議 | Retrospective Meeting，在沖刺結(jié)束后召開的關(guān)于自我持續(xù)改進(jìn)的會(huì)議。 周期：迭代周期結(jié)束時(shí)，每一個(gè)沖刺完成后，都會(huì)舉行一次沖刺回顧會(huì)議； 會(huì)議時(shí)間限制：4小時(shí)； 目的：通過會(huì)議來對迭代的過程進(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是不允許這樣做的，一旦迭代開工會(huì)完畢, 任何需求都不允許添加進(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ā)者自覺保證。 |
