第二章：相關(guān)的術(shù)語解釋
不了解術(shù)語放棒，你就不懂團隊溝通在說些什么死讹。精確的運用術(shù)語可以提高溝通的效率推励，平時可能需要四五句話才能講明白的東西，通過專業(yè)術(shù)語的運用城豁，可能一句話對方就明白了苟穆。當然，前提是對方也得熟悉唱星。既然作為團隊的一員雳旅，團隊的工作方式采用的是敏捷法，那就必須對相關(guān)的術(shù)語要有所了解魏颓，了解完了之后岭辣，在平時的工作中進行運用，加深體會甸饱。
和敏捷有關(guān)的術(shù)語整理如下：
什么是敏捷開發(fā)？
敏捷開發(fā)(Agile Development)是一種以人為核心仑濒、逐步迭代叹话、循序漸進的開發(fā)方法。
敏捷開發(fā)不是一門技術(shù)墩瞳，是一種開發(fā)方法驼壶。敏捷思維不僅僅可以用在開發(fā)，其實各個行業(yè)喉酌，各個崗位都可以用到热凹，你可以叫敏捷運營泵喘，敏捷銷售，敏捷市場般妙。
敏捷開發(fā)注重的是人與人之間面對面的交流躏嚎，而不是瀑布型的文檔驅(qū)動檀轨，不能沒有文檔，但是不用寫大量的文檔，重點寫必要的文檔婆殿。
但是，哪些是必要的瓜富？哪些不是必要的珊肃？這個后面在詳細展開了來講。本篇主要了解術(shù)語绒极。
什么是迭代骏令？
迭代就是按照一定的周期發(fā)布可以交付，可以使用的軟件產(chǎn)品垄提，把一個復雜的伏社、開發(fā)周期很長的開發(fā)任務，分解為很多小周期的任務塔淤，這樣的一個周期就是一次迭代的過程摘昌，就是將大目標分解成小目標，大任務分解成小任務高蜂。這里一定要記状侠琛：發(fā)布的是可以交付，可以使用的軟件產(chǎn)品备恤！而不是堆砌了一大堆功能稿饰，東一點，西一點露泊，看著做了很多喉镰，但是一個完整的功能都不能用，無法交付惭笑，無法使用侣姆。
什么是Sprint？
Sprint是短距離賽跑的意思沉噩，這里面指的是一次迭代捺宗，也就是我們要把一次迭代的開發(fā)內(nèi)容以最快的速度完成它，這個過程我們稱它為Sprint川蒙。每次Sprint的長短蚜厉，有的團隊喜歡一周，有的兩周畜眨，有的一個月昼牛。Sprint不能太長了术瓮，太長失去意義，搞不好就成了瀑布了贰健。
什么是產(chǎn)品Backlog胞四，什么是Sprint Backlog？
產(chǎn)品Backlog指根據(jù)初始需求分解出的任務列表霎烙，包括功能性和非功能性的所有功能撬讽，由Product Owner為Product Backlog中的任務確定優(yōu)先級別，當開發(fā)團隊開始某個任務的時候悬垃，再精確定義和分解這個任務游昼。
產(chǎn)品Backlog是產(chǎn)品所要具備的所有功能的總綱。當一個項目剛剛開始時烘豌，沒人能夠事先預見到所有的任務和需求标锄，并為之制定一個充分、詳細而包羅萬象的計劃竣贪〔梗可行的方式是艘蹋，先為一個項目寫下所有它該具備的顯著特性和功能惹盼，如果實在寫不完，做好能保證團隊的第一個Sprint沖刺有活可干就可以懦窘。
隨著沖刺的進行，生產(chǎn)出可發(fā)布的產(chǎn)品增量帅戒，客戶對產(chǎn)品的直觀認識也會隨之加深腻贰，他們可以據(jù)此建議更改或者添加產(chǎn)品Backlog中的任務。
我們內(nèi)部將Product Backlog簡稱為PB扒秸，將Sprint Backlog播演，簡稱為SB。
什么是燃盡圖伴奥？
燃盡圖（burn down chart）是在項目完成之前写烤，對需要完成的工作的一種可視化表示。燃盡圖有一個Y軸（任務）和X軸（時間）渔伯。理想情況下顶霞，該圖表是一個向下的曲線，隨著剩余工作的完成锣吼，“燒盡”至零选浑。如下是大概的一個樣子。
敏捷開發(fā)都包括什么角色玄叠？各自的職責是什么古徒？
產(chǎn)品負責人（Product Owner），簡稱PO读恃。
負責最大化產(chǎn)品以及開發(fā)團隊工作的價值隧膘。主要職責如下：
1、確定產(chǎn)品的功能寺惫；
2疹吃、決定發(fā)布的日期和發(fā)布內(nèi)容；
3西雀、為產(chǎn)品的ROI負責萨驶；
4、根據(jù)市場價值確定功能優(yōu)先級艇肴；
5腔呜、每個sprint中，根據(jù)需要調(diào)整功能和優(yōu)先級（每個sprint開始前調(diào)整）再悼；
6核畴、接受或拒絕開發(fā)團隊的工作成果；
7冲九、參與Scrum Planning Meetings（Sprint計劃會議）谤草，Sprint Review Meeting（Sprint評審會）和 Sprint Retrospective Meeting（Sprint回顧會）
一句話總結(jié)PO這個角色就是：告訴產(chǎn)品團隊要做什么，做功能的先后順序是怎樣的，需求有變動時該如何處理咖刃。
敏捷主管（Scrum Master）泳炉，簡稱SM憾筏。
確保Scrum被理解和正確使用并使得Scrum的收益最大化嚎杨。主要職責如下：
1、保證團隊資源合理利用氧腰；
2枫浙、保證各個角色及職責良好協(xié)作；
3古拴、解決團隊開發(fā)中的障礙箩帚；
4、作為團隊和團隊外部的接口人黄痪，協(xié)調(diào)解決溝通中的問題紧帕；
5、保證開發(fā)過程按計劃進行桅打，組織Scrum Planning Meetings（Sprint計劃會議）, Daily Stand-up Meeting（每日站會）, Sprint Review Meeting（Sprint評審會）和 Sprint Retrospective Meeting（Sprint回顧會）是嗜。
一句話總結(jié)SM這個角色就是：教整個團隊怎么做，如何估時挺尾，跟進每天進度鹅搪，風險控制，定期總結(jié)遭铺，計劃排定丽柿。
開發(fā)團隊（Scrum Team）簡稱ST。
主要負責軟件產(chǎn)品在Scrum規(guī)定流程下進行開發(fā)工作魂挂，人數(shù)控制在5~10人左右甫题，每個成員可能負責不同的技術(shù)方面，但要求每成員必須要有很強的自我管理能力涂召，同時具有一定的表達能力坠非；成員可以采用任何工作方式，只要能達到Sprint的目標芹扭。
敏捷開發(fā)的流程
注意：初步的需求調(diào)研在每周迭代計劃會議之前就已經(jīng)和客戶完成麻顶，PO需要去和客戶進行溝通，了解需求舱卡。
1. 制定產(chǎn)品需求列表
PO收集來自客戶辅肾、市場、領(lǐng)導等渠道的信息轮锥，從業(yè)務角度和市場價值編制一份按優(yōu)先級排序的矫钓、明確的、可度量的、合理的產(chǎn)品需求列表新娜；也就是說赵辕，PO進行產(chǎn)品Backlog的編寫。
2. 召開計劃會議
PO召集ST和SM（也可邀請其他利益相關(guān)者參加）召開計劃會議（發(fā)布計劃會議和沖刺會議一塊開）概龄，發(fā)布計劃主要是說明產(chǎn)品完整交付給客戶的計劃時間和交付物还惠，
Sprint沖刺計劃就是確定該沖刺階段的長度（建議沖刺長度1-4周）、目標和沖刺任務清單及其工作量估算（以理想人天manday=7.5h估算私杜，單位為小時計算）蚕键，會議時間建議不要超過6小時；
在計劃會議上就需要進行確認衰粹，是否需要使用持續(xù)集成锣光；若使用持續(xù)集成，團隊需要每天下班前至少提交一次私有構(gòu)建成功的代碼到服務器铝耻，并且要求寫詳細的日志信息誊爹；若不使用持續(xù)集成，團隊每天有完成任務清單的情況瓢捉，都需要在svn上以增量形式發(fā)包并通知到相關(guān)人員频丘；
項目計劃會議上可以確定每天站立會時間及其規(guī)則要求（建議會議時間在15-20分鐘左右），每個人回答3個問題：昨天做了什么泊柬，遇到什么問題椎镣，今天要做什么。具體問題討論及其解決兽赁，在私下進行溝通状答，不要在會議上討論。站立會上只有TM人員有發(fā)言權(quán)刀崖，其他人員不要干預惊科，SM主要是維護秩序、規(guī)則及其引導作用亮钦。
計劃會議上將產(chǎn)品Backlog變成Sprint Backlog馆截，簡單的說就是，將PB拆分成SB蜂莉。
3. 需求分析蜡娶、設計、編碼和測試
計劃會議結(jié)束后映穗，ST團隊成員獲取各自的沖刺任務單進行后面的需求分析窖张、設計、編碼和測試蚁滋；
這里特別要說明的是宿接，開發(fā)和測試是并行工作赘淮，必要的文檔還是需要輸出（如：討論次數(shù)較多的功能點、備選方案很多但最后確認一種睦霎、重要功能梢卸、業(yè)務邏輯復雜的等等）。具體情況副女，需要項目組根據(jù)實際情況決定蛤高，但客戶要求交付的文檔必須要輸出；
4. 沖刺任務單和燃盡圖更新
每天SM需要根據(jù)每日站會上ST反饋的情況肮塞，進行更新沖刺任務單和燃盡圖或SM和ST之間達成共識襟齿，ST各自完成后進行更改狀態(tài)，這里涉及到的文檔都會有相對應的模板供參考使用枕赵。
5. 迭代周期結(jié)束點
已到迭代周期結(jié)束點，只有那些經(jīng)過測試通過的沖刺需求列表才能算是真正的完成位隶，其他未經(jīng)過測試或測試不通過的不能算是完成拷窜。
這里要特別注意，所謂的測試通過不是說要把所有的問題都解決才算是通過涧黄，這個要根據(jù)項目具體的要求和規(guī)定來定篮昧。還沒有達到迭代結(jié)束點，該沖刺任務需求列表就完成笋妥，可以從產(chǎn)品需求列表中挑選優(yōu)先級高的繼續(xù)進行開發(fā)懊昨。
6. 沖刺評審會議
SM需要召開沖刺評審會議，邀請PO春宣、客戶或客戶代表來參加酵颁，由這些客戶或客戶代表來表決是否滿足需求和期望目標。一般會議時間建議不要超過2個小時月帝，參加人員除PO躏惋、ST全體成員及其相關(guān)利益人來參加外，也可以邀請其他相關(guān)人員參加嚷辅。
7. 沖刺回顧會議
迭代輸出的增量交付可能會引起原產(chǎn)品需求列表的改變簿姨，可能需要更新原產(chǎn)品需求列表；最后ST需要開展本次迭代的好的實踐和不足的改進機會簸搞，最終稿由SM整理匯總扁位，作為下一次的迭代的經(jīng)驗參考〕每。回顧會議建議時間不用太長域仇，一般15-30分鐘即可，全體人員都需要參加则酝，包括：PO殉簸、SM闰集、ST，其他相關(guān)人員也可以參加般卑。
這里要說明的是在每次的計劃會議上要注意安排時間做沖刺評審會議和沖刺回顧會議武鲁。下一次迭代的計劃會議建議在上一次迭代的沖刺回顧會議結(jié)束后再開展。
8. 重復2-7步驟
直到所有列入本版本規(guī)劃的任務都完成蝠检，最后發(fā)布版本沐鼠；特別說明：通常最后一個迭代可能是全量進行驗證的周期。
注意事項
一叹谁、每日站會不是匯報會議饲梭，不是向PO或者SM進行進展匯報，PO不需要參加焰檩，甚至SM也可以不參加憔涉。ST團隊成員不能有是向SM進行匯報情況的想法，雖然現(xiàn)實感覺上往往如此析苫。怎么解決呢兜叨？通過不與陳述發(fā)言的隊員有眼神交流這種微妙的途徑，SM敏捷主管可以避免大家的發(fā)言變成了對他個人的單線情況匯報衩侥。
就是說国旷，如果SM要參加每日站會，不要和成員進行眼神交流茫死。還有一個更激進的想法跪但，讓Scrum Master幾天不去參加每日站立會議，從而鼓勵團隊自己組織會議峦萎。
為了強化大家的ownership意識屡久，每個人都是team的主人，也可以輪流進行組織骨杂。
二涂身、任務估算時間不能公開，每個人都寫下自己的時間之后搓蚪，如果差別較大蛤售，最大和最小估算者進行闡述和辯論，最后達成一個共同認可的任務完成時間妒潭。這里要注意悴能，如果參與的人不懂該任務流程，參與估算就會影響準確率雳灾。
三漠酿、如果團隊遇到問題，盡量自己先花1個小時進行解決谎亩，找到方向炒嘲，如果1個小時還沒有思路宇姚，問題解決不了，就抓緊反饋夫凸。你遇到的問題可能其他成員已經(jīng)有解決方案了浑劳。
四、PO未參加計劃會議夭拌，應與PO提前協(xié)商時間魔熏，若PO沒有時間需調(diào)整時間，PO一定要參加計劃會議鸽扁；
五蒜绽、如果產(chǎn)品backlog優(yōu)先級發(fā)生變動，需要和PO一起決定桶现；
六躲雅、任務的拆分及工時的評估需要和團隊共同確定，不是SM一個人說了算巩那。就是說吏夯，在將PB拆分成SB，并進行時間估算的時候即横，不能是SM一個人說了算。
