什麼是敏捷開發?

敏捷開發(Agile Development)是一種以人為核心、逐步迭代、循序漸進的開發方法。

敏捷開發不是一門技術,是一種開發方法。敏捷思維不僅僅可以用在開發,其實各個行業,各個崗位都可以用到,你可以叫敏捷運營,敏捷銷售,敏捷市場。

敏捷開發注重的是人與人之間,面對面的交流,而不是瀑布型的文檔驅動,不能沒有文檔,但是不用寫大量的文檔,重點寫必要的文檔。

什麼是迭代?

迭代就是按照一定的周期發布可以交付,可以使用的軟件產品,把一個複雜的、開發周期很長的開發任務,分解為很多小周期的任務,這樣的一個周期就是一次迭代的過程,就是將大目標分解成小目標,大任務分解成小任務。

什麼是Sprint?

Sprint是短距離賽跑的意思,這裏面指的是一次迭代,也就是我們要把一次迭代的開發內容以最快的速度完成它,這個過程我們稱它為Sprint。

什麼是產品Backlog,什麼是Sprint Backlog?

產品Backlog指根據初始需求分解出的任務列表,包括功能性和非功能性的所有功能,由Product Owner為Product Backlog中的任務確定優先級別,當開發團隊開始某個任務的時候,再精確定義和分解這個任務。

產品Backlog是產品所要具備的所有功能的總綱。當一個項目剛剛開始時,沒人能夠事先預見到所有的任務和需求,併為之制定一個充分、詳細而包羅萬象的計劃。可行的方式是,先為一個項目寫下所有它該具備的顯著特性和功能,數量不必很多,做好能保證團隊的第一個Sprint衝刺有活可干。

隨着衝刺的進行,生產出可發布的產品增量,客戶對產品的直觀認識也會隨之加深,他們可以據此建議更改或者添加產品Backlog中的任務。

敏捷開發都包括什麼角色?各自的職責是什麼?

產品負責人(Product Owner),簡稱PO。

負責最大化產品以及開發團隊工作的價值。主要職責如下:

1、確定產品的功能;

2、決定發布的日期和發布內容;

3、為產品的ROI負責;

4、根據市場價值確定功能優先級;

5、每個sprint中,根據需要調整功能和優先級(每個sprint開始前調整);

6、接受或拒絕開發團隊的工作成果;

7、參与Scrum Planning Meetings(Sprint計劃會議),Sprint Review Meeting(Sprint評審會)和 Sprint Retrospective Meeting(Sprint回顧會)

一句話總結PO這個角色就是:告訴產品團隊要做什麼,做功能的先後順序是怎樣的,需求有變動時該如何處理。

敏捷管理員(Scrum Master),簡稱SM。

確保Scrum被理解和正確使用並使得Scrum的收益最大化。主要職責如下:

1、保證團隊資源合理利用;

2、保證各個角色及職責良好協作;

3、解決團隊開發中的障礙;

4、作為團隊和團隊外部的接口人,協調解決溝通中的問題;

5、保證開發過程按計劃進行,組織Scrum Planning Meetings(Sprint計劃會議), Daily Stand-up Meeting(每日站會), Sprint Review Meeting(Sprint評審會)和 Sprint Retrospective Meeting(Sprint回顧會)。

一句話總結SM這個角色就是:教整個團隊怎麼做,如何估時,跟進每天進度,風險控制,定期總結,計劃排定。

開發團隊(Scrum Team)簡稱TM。

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

敏捷開發的流程

1. 制定產品需求列表

PO收集來自客戶、市場、領導等渠道的信息,從業務角度和市場價值編製一份按優先級排序的、明確的、可度量的、合理的產品需求列表;

2. 召開計劃會議

PO召集TM和SM(也可邀請其他利益相關者參加)召開計劃會議(發布計劃會議和衝刺會議一塊開),發布計劃主要是說明產品完整交付給客戶的計劃時間和交付物,

Sprint衝刺計劃就是確定該衝刺階段的長度(建議衝刺長度1-4周)、目標和衝刺任務清單及其工作量估算(以理想人天manday=7.5h估算,單位為小時計算),會議時間建議不要超過6小時;

在計劃會議上就需要進行確認,是否需要使用持續集成;若使用持續集成,團隊需要每天下班前至少提交一次私有構建成功的代碼到服務器,並且要求寫詳細的日誌信息;若不使用持續集成,團隊每天有完成任務清單的情況,都需要在svn上以增量形式發包並通知到相關人員;

項目計劃會議上可以確定每天站立會時間及其規則要求(建議會議時間在15-20分鐘左右),每個人回答3個問題:昨天做了什麼,遇到什麼問題,今天要做什麼。具體問題討論及其解決,在私下進行溝通,不要在會議上討論。站立會上只有TM人員有發言權,其他人員不要干預,SM主要是維護秩序、規則及其引導作用。

3. 需求分析、設計、編碼和測試

計劃會議結束后,TM團隊成員獲取各自的衝刺任務單進行後面的需求分析、設計、編碼和測試;

這裏特別要說明的是,開發和測試是并行工作,必要的文檔還是需要輸出(如:討論次數較多的功能點、備選方案很多但最後確認一種、重要功能、業務邏輯複雜的等等)。具體情況,需要項目組根據實際情況決定,但客戶要求交付的文檔必須要輸出;

4. 衝刺任務單和燃盡圖更新

每天SM需要根據每日站會上TM反饋的情況,進行更新衝刺任務單和燃盡圖或SM和TM之間達成共識,TM各自完成後進行更改狀態,這裏涉及到的文檔都會有相對應的模板供參考使用。

5. 迭代周期結束點

已到迭代周期結束點,只有那些經過測試通過的衝刺需求列表才能算是真正的完成,其他未經過測試或測試不通過的不能算是完成。

這裏要特別注意,所謂的測試通過不是說要把所有的問題都解決才算是通過,這個要根據項目具體的要求和規定來定。還沒有達到迭代結束點,該衝刺任務需求列表就完成,可以從產品需求列表中挑選優先級高的繼續進行開發。

6. 衝刺評審會議

TM需要召開衝刺評審會議,邀請PO、客戶或客戶代表來參加,由這些客戶或客戶代表來表決是否滿足需求和期望目標。一般會議時間建議不要超過2個小時,參加人員除PO及其相關利益人來參加外,TM全體成員,也可以邀請其他相關人員參加。

7. 衝刺回顧會議

迭代輸出的增量交付可能會引起原產品需求列表的改變,可能需要更新原產品需求列表;最後TM需要開展本次迭代的好的實踐和不足的改進機會,最終稿由SM整理匯總,作為下一次的迭代的經驗參考。回顧會議建議時間不用太長,一般15-30分鐘即可,全體人員都需要參加,包括:PO、SM、TM,其他相關人員也可以參加。

這裏要說明的是在每次的計劃會議上要注意安排時間做衝刺評審會議和衝刺回顧會議。下一次迭代的計劃會議建議在上一次迭代的衝刺回顧會議結束后再開展。

8. 重複2-7步驟

直到所有列入本版本規劃的任務都完成,最後發布版本;特別說明:通常最後一個迭代可能是全量進行驗證的周期。

注意事項

一、每日站會不是彙報會議,不是向PO或者SM進行進展彙報,PO不需要參加,甚至SM也可以不參加。TM不能有是向SM進行彙報情況的想法,雖然現實感覺上往往如此。怎麼解決呢?通過不與陳述發言的隊員有眼神交流這種微妙的途徑,Scrum Master可以避免大家的發言變成了對他個人的單線情況彙報。

就是說,如果SM要參加每日站會,不要和成員進行眼神交流。還有一個更激進的想法,讓Scrum Master幾天不去參加每日站立會議,從而鼓勵團隊自己組織會議。

為了強化大家的ownership意識,每個人都是team的主人,也可以輪流進行組織。

二、任務估算時間不能公開,每個人都寫下自己的時間之後,如果差別較大,最大和最小估算者進行闡述和辯論,最後達成一個共同認可的任務完成時間。這裏要注意,如果參与的人不懂該任務流程,參与估算就會影響準確率。

三、如果團隊遇到問題,盡量自己先花1個小時進行解決,找到方向,如果1個小時還沒有思路,問題解決不了,就抓緊反饋。你遇到的問題可能其他成員已經有解決方案了。

四、PO未參加計劃會議,應與PO提前協商時間,若PO沒有時間需調整時間,PO一定要參加計劃會議;

五、如果產品backlog優先級發生變動,需要和PO一起決定;

六、任務的拆分及工時的評估需要和團隊共同確定,不是SM一個人說了算。