什么是敏捷開發(fā)？
敏捷開發(fā)(Agile Development)是一種以人為核心、逐步迭代、循序漸進(jìn)的開發(fā)方法。
敏捷開發(fā)不是一門技術(shù)，是一種開發(fā)方法。敏捷思維不僅僅可以用在開發(fā)，其實各個行業(yè)，各個崗位都可以用到，你可以叫敏捷運(yùn)營，敏捷銷售，敏捷市場。
敏捷開發(fā)注重的是人與人之間，面對面的交流，而不是瀑布型的文檔驅(qū)動，不能沒有文檔，但是不用寫大量的文檔，重點寫必要的文檔。
什么是迭代？
迭代就是按照一定的周期發(fā)布可以交付，可以使用的軟件產(chǎn)品，把一個復(fù)雜的、開發(fā)周期很長的開發(fā)任務(wù)，分解為很多小周期的任務(wù)，這樣的一個周期就是一次迭代的過程，就是將大目標(biāo)分解成小目標(biāo)，大任務(wù)分解成小任務(wù)。
什么是Sprint？
Sprint是短距離賽跑的意思，這里面指的是一次迭代，也就是我們要把一次迭代的開發(fā)內(nèi)容以最快的速度完成它，這個過程我們稱它為Sprint。
什么是產(chǎn)品Backlog，什么是Sprint Backlog？
產(chǎn)品Backlog指根據(jù)初始需求分解出的任務(wù)列表，包括功能性和非功能性的所有功能，由Product Owner為Product Backlog中的任務(wù)確定優(yōu)先級別，當(dāng)開發(fā)團(tuán)隊開始某個任務(wù)的時候，再精確定義和分解這個任務(wù)。
產(chǎn)品Backlog是產(chǎn)品所要具備的所有功能的總綱。當(dāng)一個項目剛剛開始時，沒人能夠事先預(yù)見到所有的任務(wù)和需求，并為之制定一個充分、詳細(xì)而包羅萬象的計劃?？尚械姆绞绞?，先為一個項目寫下所有它該具備的顯著特性和功能，數(shù)量不必很多，做好能保證團(tuán)隊的第一個Sprint沖刺有活可干。
隨著沖刺的進(jìn)行，生產(chǎn)出可發(fā)布的產(chǎn)品增量，客戶對產(chǎn)品的直觀認(rèn)識也會隨之加深，他們可以據(jù)此建議更改或者添加產(chǎn)品Backlog中的任務(wù)。
敏捷開發(fā)都包括什么角色？各自的職責(zé)是什么？
產(chǎn)品負(fù)責(zé)人（Product Owner），簡稱PO。
負(fù)責(zé)最大化產(chǎn)品以及開發(fā)團(tuán)隊工作的價值。主要職責(zé)如下：
1、確定產(chǎn)品的功能；
2、決定發(fā)布的日期和發(fā)布內(nèi)容；
3、為產(chǎn)品的ROI負(fù)責(zé)；
4、根據(jù)市場價值確定功能優(yōu)先級；
5、每個sprint中，根據(jù)需要調(diào)整功能和優(yōu)先級（每個sprint開始前調(diào)整）；
6、接受或拒絕開發(fā)團(tuán)隊的工作成果；
7、參與Scrum Planning Meetings（Sprint計劃會議），Sprint Review Meeting（Sprint評審會）和 Sprint Retrospective Meeting（Sprint回顧會）
一句話總結(jié)PO這個角色就是：告訴產(chǎn)品團(tuán)隊要做什么，做功能的先后順序是怎樣的，需求有變動時該如何處理。
敏捷管理員（Scrum Master），簡稱SM。
確保Scrum被理解和正確使用并使得Scrum的收益最大化。主要職責(zé)如下：
1、保證團(tuán)隊資源合理利用；
2、保證各個角色及職責(zé)良好協(xié)作；
3、解決團(tuán)隊開發(fā)中的障礙；
4、作為團(tuán)隊和團(tuán)隊外部的接口人，協(xié)調(diào)解決溝通中的問題；
5、保證開發(fā)過程按計劃進(jìn)行，組織Scrum Planning Meetings（Sprint計劃會議）, Daily Stand-up Meeting（每日站會）, Sprint Review Meeting（Sprint評審會）和 Sprint Retrospective Meeting（Sprint回顧會）。
一句話總結(jié)SM這個角色就是：教整個團(tuán)隊怎么做，如何估時，跟進(jìn)每天進(jìn)度，風(fēng)險控制，定期總結(jié)，計劃排定。
開發(fā)團(tuán)隊（Scrum Team）簡稱TM。
主要負(fù)責(zé)軟件產(chǎn)品在Scrum規(guī)定流程下進(jìn)行開發(fā)工作，人數(shù)控制在5~10人左右，每個成員可能負(fù)責(zé)不同的技術(shù)方面，但要求每成員必須要有很強(qiáng)的自我管理能力，同時具有一定的表達(dá)能力；成員可以采用任何工作方式，只要能達(dá)到Sprint的目標(biāo)。
敏捷開發(fā)的流程
注意：初步的需求調(diào)研在每周迭代計劃會議之前就已經(jīng)和客戶完成，PO需要去和客戶進(jìn)行溝通，了解需求。
1. 制定產(chǎn)品需求列表
PO收集來自客戶、市場、領(lǐng)導(dǎo)等渠道的信息，從業(yè)務(wù)角度和市場價值編制一份按優(yōu)先級排序的、明確的、可度量的、合理的產(chǎn)品需求列表；
2. 召開計劃會議
PO召集TM和SM（也可邀請其他利益相關(guān)者參加）召開計劃會議（發(fā)布計劃會議和沖刺會議一塊開），發(fā)布計劃主要是說明產(chǎn)品完整交付給客戶的計劃時間和交付物，
Sprint沖刺計劃就是確定該沖刺階段的長度（建議沖刺長度1-4周）、目標(biāo)和沖刺任務(wù)清單及其工作量估算（以理想人天manday=7.5h估算，單位為小時計算），會議時間建議不要超過6小時；
在計劃會議上就需要進(jìn)行確認(rèn)，是否需要使用持續(xù)集成；若使用持續(xù)集成，團(tuán)隊需要每天下班前至少提交一次私有構(gòu)建成功的代碼到服務(wù)器，并且要求寫詳細(xì)的日志信息；若不使用持續(xù)集成，團(tuán)隊每天有完成任務(wù)清單的情況，都需要在svn上以增量形式發(fā)包并通知到相關(guān)人員；
項目計劃會議上可以確定每天站立會時間及其規(guī)則要求（建議會議時間在15-20分鐘左右），每個人回答3個問題：昨天做了什么，遇到什么問題，今天要做什么。具體問題討論及其解決，在私下進(jìn)行溝通，不要在會議上討論。站立會上只有TM人員有發(fā)言權(quán)，其他人員不要干預(yù)，SM主要是維護(hù)秩序、規(guī)則及其引導(dǎo)作用。
3. 需求分析、設(shè)計、編碼和測試
計劃會議結(jié)束后，TM團(tuán)隊成員獲取各自的沖刺任務(wù)單進(jìn)行后面的需求分析、設(shè)計、編碼和測試；
這里特別要說明的是，開發(fā)和測試是并行工作，必要的文檔還是需要輸出（如：討論次數(shù)較多的功能點、備選方案很多但最后確認(rèn)一種、重要功能、業(yè)務(wù)邏輯復(fù)雜的等等）。具體情況，需要項目組根據(jù)實際情況決定，但客戶要求交付的文檔必須要輸出；
4. 沖刺任務(wù)單和燃盡圖更新
每天SM需要根據(jù)每日站會上TM反饋的情況，進(jìn)行更新沖刺任務(wù)單和燃盡圖或SM和TM之間達(dá)成共識，TM各自完成后進(jìn)行更改狀態(tài)，這里涉及到的文檔都會有相對應(yīng)的模板供參考使用。
5. 迭代周期結(jié)束點
已到迭代周期結(jié)束點，只有那些經(jīng)過測試通過的沖刺需求列表才能算是真正的完成，其他未經(jīng)過測試或測試不通過的不能算是完成。
這里要特別注意，所謂的測試通過不是說要把所有的問題都解決才算是通過，這個要根據(jù)項目具體的要求和規(guī)定來定。還沒有達(dá)到迭代結(jié)束點，該沖刺任務(wù)需求列表就完成，可以從產(chǎn)品需求列表中挑選優(yōu)先級高的繼續(xù)進(jìn)行開發(fā)。
6. 沖刺評審會議
TM需要召開沖刺評審會議，邀請PO、客戶或客戶代表來參加，由這些客戶或客戶代表來表決是否滿足需求和期望目標(biāo)。一般會議時間建議不要超過2個小時，參加人員除PO及其相關(guān)利益人來參加外，TM全體成員，也可以邀請其他相關(guān)人員參加。
7. 沖刺回顧會議
迭代輸出的增量交付可能會引起原產(chǎn)品需求列表的改變，可能需要更新原產(chǎn)品需求列表；最后TM需要開展本次迭代的好的實踐和不足的改進(jìn)機(jī)會，最終稿由SM整理匯總，作為下一次的迭代的經(jīng)驗參考?；仡檿h建議時間不用太長，一般15-30分鐘即可，全體人員都需要參加，包括：PO、SM、TM，其他相關(guān)人員也可以參加。
這里要說明的是在每次的計劃會議上要注意安排時間做沖刺評審會議和沖刺回顧會議。下一次迭代的計劃會議建議在上一次迭代的沖刺回顧會議結(jié)束后再開展。
8. 重復(fù)2-7步驟
直到所有列入本版本規(guī)劃的任務(wù)都完成，最后發(fā)布版本；特別說明：通常最后一個迭代可能是全量進(jìn)行驗證的周期。
注意事項
一、每日站會不是匯報會議，不是向PO或者SM進(jìn)行進(jìn)展匯報，PO不需要參加，甚至SM也可以不參加。TM不能有是向SM進(jìn)行匯報情況的想法，雖然現(xiàn)實感覺上往往如此。怎么解決呢？通過不與陳述發(fā)言的隊員有眼神交流這種微妙的途徑，Scrum Master可以避免大家的發(fā)言變成了對他個人的單線情況匯報。
就是說，如果SM要參加每日站會，不要和成員進(jìn)行眼神交流。還有一個更激進(jìn)的想法，讓Scrum Master幾天不去參加每日站立會議，從而鼓勵團(tuán)隊自己組織會議。
為了強(qiáng)化大家的ownership意識，每個人都是team的主人，也可以輪流進(jìn)行組織。
二、任務(wù)估算時間不能公開，每個人都寫下自己的時間之后，如果差別較大，最大和最小估算者進(jìn)行闡述和辯論，最后達(dá)成一個共同認(rèn)可的任務(wù)完成時間。這里要注意，如果參與的人不懂該任務(wù)流程，參與估算就會影響準(zhǔn)確率。
三、如果團(tuán)隊遇到問題，盡量自己先花1個小時進(jìn)行解決，找到方向，如果1個小時還沒有思路，問題解決不了，就抓緊反饋。你遇到的問題可能其他成員已經(jīng)有解決方案了。
四、PO未參加計劃會議，應(yīng)與PO提前協(xié)商時間，若PO沒有時間需調(diào)整時間，PO一定要參加計劃會議；
五、如果產(chǎn)品backlog優(yōu)先級發(fā)生變動，需要和PO一起決定；
六、任務(wù)的拆分及工時的評估需要和團(tuán)隊共同確定，不是SM一個人說了算。
