天天看點

架構之道之軟體開發過程的scrum原理

       軟體開發是一項複雜行為,它的一個顯著的特點是:構造成品的過程中所使用的材料極不穩定,客戶的需求是來自于還沒有體驗過的程式設想,沒有經過驗證的其它程式與本程式的互操作性,以及最複雜的人與人之間的互動。

      諸此種種,造成了軟體項目管理變得非常複雜和困難,長期以來,人們緻力于研究提高軟體成功率的管理方法,Scrum 項目管理是這些探索中的一種,它是專門為解決複雜問題、擷取可用産品而設計的,在過去 10 年中,Scrum 已經成功運用于數千個企業,均取得了良好的成果。軟體開發工作的性質決定了複雜問題的大量湧現,解決這些問題離不開努力工作、智慧與勇氣。

    Scrum 的特點是并不排除經典軟體工程學的一系列規則,但是針對其中的問題加以改進,這就比較适合大型複雜項目,也比較容易被大型軟體企業接受。

一、Scrum的核心

架構之道之軟體開發過程的scrum原理

該骨架運作方式如下:每一疊代初期,團隊評審必辦事項,挑選出他們認為在該疊代結束的時候,能轉化成相應完整功能增量的部分。疊代其餘時間,團隊不受幹涉、努力工作。疊代結束的時候,團隊展示完成的功能增量,請利益相關者進行檢查,以對項目進行及時調整。

Scrum  的核心在于疊代:團隊首先浏覽開發需求,考慮可用技術,并且對自身擁有的技術做出評估。然後共同确定建構功能的方案,并且每日調整方法,以應對新的複雜問題、困難和出乎意料的情況。團隊找出并且選擇最佳方案去完成任務。這個創造性過程,就是 Scrum 生産力的核心。

二、Scrum的三種角色

   Scrum 方法中隻有三種角色:産品負責人(Product Owner)、團隊和 ScrumMaster。

  1. 産品負責人 ( (Product Owner) ) ):産品負責人代表項目中每位利益相關者的權益,并且為項目産出的軟體系統負責。産品負責人規劃項目初始總體要求、投資回報(ROI)目标和釋出計劃,進而為項目赢得啟動以及後續資金。軟體開發需求清單又稱作“Product Backlog”(産品待辦事項表),産品負責人的職責是利用産品 Backlog,督促團隊優先開發最具價值的功能,并且在這個基礎上繼續開發。要想達到這個目标,産品負責人必須頻繁檢視産品待開發需求的優先秩序,把最具價值的開發需求安排在下一個疊代中完成。
  2. 團隊:團隊的責任是開發軟體功能。他們是自我管理、自我組織和跨職能的。他們負責找出可以在一個疊代中把産品待開發事項轉化為功能增量的方法,并且管理自身工作。團隊成員對每一次疊代和整個項目共同負責。
  3. ScrumMaster:ScrumMaster 需要對 Scrum 過程負責,向所有項目參與者講授 Scrum 方法,負責實施 Scrum,確定它既符合企業文化,又能傳遞預期利益,還需要督促全體成員遵從Scrum 規則和實踐。

   擔任上述角色的人對項目承擔責任,我們稱之為“管理者”角色。其它人或許對項目感興趣,但不承擔責任,我們稱之為“旁觀者”角色。Scrum利用三種角色實施疊代和增量骨架。

三、Scrum的過程

架構之道之軟體開發過程的scrum原理

1. 最初的願景:

        一個 Scrum 項目的起點是待開發系統的願景。最初,願景比較模糊。可能更多使用市場化的語言(多于系統語言)來描述。但是随着項目的進展,願景逐漸清晰。産品負責人需要對項目投資者負責,以投資回報最大化實作願景。

2. 産品計劃:

      産品負責人依據上述目标制定出計劃,該計劃包括産品 Backlog。這個表是一張關于功能性需求和非功能性需求的清單,它一旦轉換成功能,就可以實作願景。産品 Backlog 排列出不同優先等級并把事項分成多個建議釋出組,最容易産出價值的事項擁

有最高優先級。分出優先等級以後的産品 Backlog 是項目的起點,而項目一旦開始,該表的内容、優先等級和釋出組就會不斷變化,對這一情況應該有所預料。産品 Backlog 的變化反映出不斷變化的商業需求,以及團隊把待開發事項轉化為功能的速度。

3. Sprint疊代周期:

   所有的工作都在 Sprint 疊代周期内完成,每個 Sprint 疊代周期為連續的 30 個月曆日。

4. Sprint計劃會議:

      在周期開始的時候,均需要召開 Sprint 計劃會議,産品負責人與開發團隊共同探讨該 Sprint的工作内容。産品負責人從最優先的待開發事項中進行篩選,告知團隊他的預期目标,團隊則提出來在接下來的 Sprint 内,預期目标可以實作的程度。Sprint 計劃會議的長度不超過 8 小時,它有限定時間是為了避免糾纏不确定的預期。會議的目的是為了展開實際工作,而不是隻想不做!

Sprint 計劃會議包括兩個部分:

第一部分 4 個小時,産品負責人向團隊展示最高優先等級的的産品 Backlog。團隊則向他詢問産品 Backlog 的内容、目的、含義及意圖。當團隊了解了足夠的資訊以後,前 4 個小時仍然有剩餘,團隊可以确定在本 Sprint 内,哪些部分可以轉化為完整的産品功能增量。團隊向産品負責人承諾将全力工作。

後半部分 4 個小時,團隊計劃本 Spring 的安排,團隊負責管理自身的工作,因而需要一個初步的計劃,以開展本 Spring 的工作。Sprint Backlog(Sprint 待辦事項表)将包含這個計劃的任務。這個表内的任務随着 Sprint 周期的進展而不斷湧現,一旦 Sprint 計劃會議進入後 4 個小時,這個 Sprint 周期就正式開始,周期固定的 30 天時間從此刻開始倒計時。

5. 每日 Scrum 簡會(Daily Scrum):

每天,團隊集合召開 15 分鐘的會議,稱為“每日 Scrum 簡會”,每個成員回答三個問題:自上次 Scrum 簡會之後的 1 天裡你做了什麼?從現在到下次 Scrum 簡會的一天裡你準備做什麼?在實作 Scrum 及其項目目标的工作中,你遇到了哪些困難?會議的目的是保持團隊全體成員每日工作步調一緻,并且安排有必要的其它會議,促進團隊工作。

6. Sprint評審會議:

Sprint 周期結束的時候,需要召開 Sprint 評審會議。該會議限定時間為 4 個小時,由團隊向産品負責人和其他與會利益相關者展示該 Sprint 周期内的産品開發情況。此展示功能的非正式會議,旨在召集相關人員,共同決定團隊接下來的工作。

7. Scrum評審會議:

在 Sprint 評審會議和下一次 Sprint 計劃會議之間,ScrumMaster 和開發團隊需要召開一次限時 3 個小時的 Scrum 評審會議。ScrumMaster 将鼓勵團隊在 Scrum 過程架構和實踐範圍内,對開發過程作出修改,以使它在下一個 Sprint 周期中更加有效和更加愉快。

   Sprint 計劃會議、每日 Sprint 簡會、Sprint 評審會議和Scrum 評審會議共同構成 Scrum 方法中的經驗性檢查及适應調整部分。

繼續閱讀