說透如何學(xué)習(xí)敏捷開發(fā)流程和運(yùn)用
敏捷開發(fā)是目前很流程的開發(fā)方式，通過版本迭代能快速的更新升級(jí)產(chǎn)品，今天就講講敏捷。
前言：
我的敏捷開發(fā)經(jīng)歷
什么是敏捷開發(fā)流程？
敏捷開發(fā)方法有哪些？
從哪些方面做到敏捷開發(fā)流程？
項(xiàng)目怎么開始使用敏捷開發(fā)？
傳統(tǒng)的開發(fā)模式
傳統(tǒng)模式踩過的坑
敏捷開發(fā)的概念
敏捷宣言
什么是 Scrum？
需求澄清會(huì)
計(jì)劃分析會(huì)
站立會(huì)
評(píng)審會(huì)
回顧會(huì)
快速迭代
讓測(cè)試人員和開發(fā)者參與需求討論
多溝通，盡量減少文檔
做好產(chǎn)品原型
怎么才能評(píng)估團(tuán)隊(duì)是否已經(jīng)敏捷了？
敏捷開發(fā)可謂是產(chǎn)品快速迭代的規(guī)范化流程，所謂敏捷開發(fā)？就是快速靈活的意思？并不是這樣，其實(shí)敏捷開發(fā)是以用戶的需求進(jìn)化為中心，采用快速迭代、循序漸進(jìn)的方法進(jìn)行軟件產(chǎn)品的開發(fā)。
在敏捷開發(fā)中，一個(gè)軟件項(xiàng)目在構(gòu)建時(shí)被細(xì)分成多個(gè)子項(xiàng)目（故事），各個(gè)子項(xiàng)目（故事）的成果都經(jīng)過測(cè)試，是獨(dú)立的，可以獨(dú)立運(yùn)行的，而又是可以合在一起變成整體的。
通過這點(diǎn)來看，敏捷開發(fā)便比普通開發(fā)多了很多優(yōu)勢(shì)。
在本場(chǎng) Chat 中，會(huì)講到如下內(nèi)容：
什么是敏捷開發(fā)流程？
敏捷開發(fā)方法有哪些？
從哪些方面做到敏捷開發(fā)流程？
項(xiàng)目怎么開始使用敏捷開發(fā)？
怎么才能評(píng)估團(tuán)隊(duì)是否已經(jīng)敏捷了？
我的敏捷開發(fā)經(jīng)歷
首先我先講一下我接觸敏捷開發(fā)的經(jīng)歷，2010 年到 2015 年工作期間，所在的幾家公司一直都是做移動(dòng)互聯(lián)網(wǎng)產(chǎn)品的，當(dāng)時(shí)還沒有接觸敏捷開發(fā)的概念，還是使用傳統(tǒng)的開發(fā)模式。
傳統(tǒng)的開發(fā)模式
這里我簡(jiǎn)單說一下傳統(tǒng)的開發(fā)模式，以及我使用的開發(fā)模式的缺陷。
傳統(tǒng)開發(fā)模式包括：
傳統(tǒng)的瀑布式開發(fā)
原型模型
螺旋模型
可能有些人看到上面的三種傳統(tǒng)開發(fā)模式還是不太清楚，具體指什么？
下面我們一一介紹一下，相信大家就能更具體的明白，并且知道你深處什么開發(fā)模式下。
1. 傳統(tǒng)的瀑布流開發(fā)模式
流程如下：
從需求到設(shè)計(jì) -> 從設(shè)計(jì)到編碼 -> 從編碼到測(cè)試 -> 從測(cè)試到交付
大概這樣的流程，要求每一個(gè)開發(fā)階段都要做到最好。特別是前期階段，設(shè)計(jì)得越完美，提交后的成本損失就越少。這樣就是典型的瀑布模型。
瀑布模型式是最典型的預(yù)見性的方法，嚴(yán)格遵循預(yù)先計(jì)劃的需求、分析、設(shè)計(jì)、編碼、測(cè)試的步驟順序進(jìn)行。
步驟成果作為衡量進(jìn)度的方法，例如需求規(guī)格、設(shè)計(jì)文檔、測(cè)試計(jì)劃和代碼審閱等等。
瀑布流式的主要的問題是，它的嚴(yán)格分級(jí)導(dǎo)致的自由度降低，項(xiàng)目早期即作出承諾，導(dǎo)致對(duì)后期需求的變化難以調(diào)整，代價(jià)高昂。
瀑布流式方法在需求不明，且在項(xiàng)目進(jìn)行過程中可能變化的情況下，基本是不可行的。
有統(tǒng)計(jì)它是造成 70% 軟件開發(fā)失敗的原因。
哪些情況導(dǎo)致項(xiàng)目失??？
需求前期不明確后期變化大
開發(fā)的功能和客戶預(yù)期要的功能不一致
項(xiàng)目做好才能有一個(gè)可以演示的版本（開發(fā)期間無法保證版本的正常使用）
項(xiàng)目進(jìn)度無法保證
上面這些情況我相信 90% 的小伙伴都親身經(jīng)歷過，并且有些小伙伴還在這種水深火熱中煎熬著。
2. 原型模型
原型模型第一步就是創(chuàng)建一個(gè)快速原型，能夠滿足項(xiàng)目干系人與未來的用戶可以與原型進(jìn)行交互，再通過與相關(guān)干系人進(jìn)行充分的討論和分析，最終弄清楚當(dāng)前系統(tǒng)的需求，進(jìn)行了充分的了解之后，在原型的基礎(chǔ)上開發(fā)出用戶滿意的產(chǎn)品。
所謂原型模型：說的直接一點(diǎn)就是 需要有一個(gè)原型效果，這種可以是一些建模圖形，或者快速開發(fā)出來的簡(jiǎn)單靜態(tài)界面效果流程，或者一些原型圖的快速創(chuàng)建。
比如我們可以通過一些開源平臺(tái)提供的支持，做一些需求流程的原型圖，通過原型圖來展示所需項(xiàng)目的需求，通過原型圖呈現(xiàn)出來產(chǎn)品的流程。
比如下面的一個(gè)開源平臺(tái)，可以創(chuàng)建不同平臺(tái)（手機(jī)、Web 等等）的原型圖。
https://www.xiaopiu.com/
我可以通過一個(gè)效果給想伙伴們展示一下，該平臺(tái)的好處，這里我只展示手機(jī)端的原型圖效果，當(dāng)然需要其他的小伙伴可以自行去看，學(xué)習(xí)。
3. 螺旋模型
螺旋模型就是，將瀑布模型和快速原型模型結(jié)合，并特別強(qiáng)調(diào)項(xiàng)目風(fēng)險(xiǎn)。
通常分為四個(gè)階段組成：
制定計(jì)劃
風(fēng)險(xiǎn)分析
實(shí)施工程
客戶評(píng)估
一般第一個(gè)版本原型只是雙方交流的參考，隨著后面的版本添加和完善，最終達(dá)到目標(biāo)。這種螺旋模型開發(fā)，比較適合大型項(xiàng)目。
傳統(tǒng)模式踩過的坑
好了，上面說了這么多，主要就是講述了，傳統(tǒng)的開發(fā)模式存在的一些弊端，這些模式也是在未使用敏捷管理之前所使用的，當(dāng)然也踩了很多坑。
當(dāng)時(shí)我在開發(fā)中主要就是使用的瀑布流模式，每次拿到一個(gè)新項(xiàng)目，幾乎很難理解該項(xiàng)目的整體流程和使用場(chǎng)景，首先要做的就是分析需求，分析明白需求文檔，才能去嘗試開發(fā)功能，為什么說是嘗試呢，因?yàn)榧词刮覀兺ㄟ^文檔也不一定理解的和客戶想要的一致。當(dāng)時(shí)沒有更多的會(huì)議，需求確認(rèn)會(huì)議都沒有正式開過一次。
打個(gè)比方，需求是客戶與項(xiàng)目經(jīng)理溝通產(chǎn)生的，那么項(xiàng)目經(jīng)理的理解有可能和客戶理解有一定的偏差，但是需求就是這么多，沒有具體的細(xì)節(jié)，我們又無法針對(duì)每一個(gè)細(xì)節(jié)和客戶面對(duì)面溝通，這樣會(huì)導(dǎo)致，開發(fā)中一直按照的是文檔表述的開發(fā)的，但是真正到項(xiàng)目開發(fā)完成才發(fā)現(xiàn)，和客戶預(yù)想的結(jié)果不一樣，不一樣。
這種項(xiàng)目可以想象一下成功的幾率有多低。
舉個(gè)很典型的例子：
記得做一個(gè)電商項(xiàng)目的時(shí)候，前期開發(fā)是比較困難的，因?yàn)樾枨蟛幻鞔_，動(dòng)不動(dòng)都需要和客戶開會(huì)討論確認(rèn)需求，客戶每次都是，口頭表達(dá)他們的預(yù)期功能和效果，但是開過幾次會(huì)議發(fā)現(xiàn)，上次開會(huì)說的客戶不認(rèn)賬了，比如：上次他們明明說的一個(gè)需求點(diǎn)就做成 1，但是這次他們說應(yīng)該是做成 2，因?yàn)闆]有明確需求，所以也無法和客戶過多地辯論。
最后我們?yōu)榱吮苊膺@種事情的發(fā)生，考慮做會(huì)議記錄，并且會(huì)議上核客戶一一確認(rèn)，會(huì)議后再通過郵件全部發(fā)送有關(guān)人員知曉，這種做法也在一定程度上減少了這種事情的發(fā)生。
不難想象這種開發(fā)是盲目的，也是無法避免的，所以在這幾年時(shí)間里，我真正做好，做成功的項(xiàng)目 寥寥無幾，即使有一些小小的成功，也是在耗費(fèi)預(yù)期時(shí)間的幾倍 才勉強(qiáng)換來的。
正是因?yàn)橛羞@些弊端和缺陷，并且有些是致命的，才有一種新的東西的產(chǎn)生：敏捷開發(fā)流程。
在這樣的情況下我開始了解敏捷開發(fā)的流程。
我當(dāng)時(shí)入手敏捷開發(fā)的時(shí)候國(guó)內(nèi)還沒有幾家了解和實(shí)行敏捷流程的（最起碼我一家都沒有聽說過），當(dāng)時(shí)所在公司也是很看好這一塊，覺得這是一個(gè)空白區(qū)，當(dāng)然這也是一個(gè)很大的調(diào)整，因?yàn)闆]有參考，沒有對(duì)比，鑒于國(guó)內(nèi)沒有在做的企業(yè)，所以想著能不能參考國(guó)外一些企業(yè)的敏捷理念和一些敏捷資料做一個(gè)自己的敏捷流程平臺(tái)。
開始動(dòng)手做敏捷流程，我們想到的就是從兩點(diǎn)做起：
如何高效處理問題
如何組織有效的會(huì)議
為什么從這兩方面入手呢，這也是根據(jù)我們公司當(dāng)時(shí)的現(xiàn)狀。
問題 1，就是當(dāng)項(xiàng)目中遇到問題時(shí)沒有人主動(dòng)去處理，和追蹤這些問題，不了了之，導(dǎo)致有一些問題在出版本或者項(xiàng)目上線的時(shí)候才發(fā)現(xiàn)。
故事：記得很清楚的一次，我們做的一個(gè)視頻播放器，在開發(fā)中其實(shí)已經(jīng)出現(xiàn)了一些資源的無法加載問題，播放不了，但是開發(fā)人員和測(cè)試人員都認(rèn)為是公司網(wǎng)絡(luò)問題，理想地認(rèn)為其他網(wǎng)絡(luò)可以播放，一點(diǎn)都沒有在意，也沒有做任何記錄，結(jié)果在上線的時(shí)候很多類似視頻資源無法播放，導(dǎo)致客戶對(duì)我們產(chǎn)品一下失去了信心。
雖然最終找到是客戶提供視頻資源轉(zhuǎn)換的問題，但是這也反應(yīng)出了我們的問題，產(chǎn)品開發(fā)和測(cè)試中發(fā)現(xiàn)了問題沒有人去處理和追蹤，也導(dǎo)致客戶對(duì)我們的開發(fā)能力大打折扣。
問題 2，另一個(gè)就是很少組織會(huì)議，平常的項(xiàng)目需求討論會(huì)議都很少，即使開了也是很少有人發(fā)言。
這種情況直接影響到了公司同事之間的溝通，因?yàn)闆]有會(huì)議的溝通，會(huì)下他們也很少溝通，有時(shí)候遇到問題的同事去跟蹤問題，和其他同事討論的時(shí)候很不暢通，時(shí)不時(shí)出現(xiàn)“這塊不是我做的，我不知道”這樣的話語(yǔ)字眼。
當(dāng)時(shí)做了這兩部分以后，發(fā)現(xiàn)工作效率提高了不少。
工作中我們要求公司開發(fā)和測(cè)試人員每天都要提出來兩到三個(gè)問題，這些問題都是在自己名下，并且自己要一直追蹤，直到完成。
這樣做提高了問題的處理效率，這時(shí)候會(huì)發(fā)現(xiàn)，每個(gè)人會(huì)開始關(guān)心和自己有關(guān)的問題，并主動(dòng)，愿意去處理。
我們還要求每周有一次周會(huì)，每天有一個(gè)站立會(huì)議。
周會(huì)是說一下我們本周的工作、整體情況 （比如：本周哪個(gè)項(xiàng)目出版本了，下一步要做到什么？）當(dāng)然這些不是匯報(bào)，是同步我們的工作情況，這點(diǎn)很重要，有些公司很容易把會(huì)議開成匯報(bào)會(huì)議，這樣就沒有任何意義了。
站立會(huì)議，我們當(dāng)時(shí)主要是說兩方面 ：
昨天完成了什么？
今天做什么？
其實(shí)說到這里有些小伙伴就會(huì)說，這不是現(xiàn)在敏捷中站立會(huì)議的內(nèi)容嗎？
其實(shí)不是，當(dāng)時(shí)我們只做了這兩點(diǎn)，至于問題，我們還是會(huì)單獨(dú)拉會(huì)議去說，會(huì)議時(shí)間很短，主要是大家說一下自己的工作進(jìn)度和情況，讓團(tuán)隊(duì)成員互相了解一下項(xiàng)目進(jìn)度。
會(huì)議的主持人我們采取每個(gè)人主持一周，每周主持的人員，不僅要提前準(zhǔn)備好開會(huì)的設(shè)備設(shè)施，還要主持好這次會(huì)議，比如當(dāng)會(huì)議被其他無關(guān)的問題打斷的時(shí)候，主持人一定及時(shí)制止，可以記錄一下問題，幫助他們組織另一個(gè)會(huì)議，或者讓他們自己組織一個(gè)會(huì)議單獨(dú)討論。
過了大概三個(gè)月時(shí)間，發(fā)現(xiàn)團(tuán)隊(duì)溝通明顯順暢了很多，之前每次開會(huì)都是沉默不語(yǔ)，現(xiàn)在每個(gè)人都會(huì)發(fā)表自己的意見和想法。
每個(gè)人的會(huì)議組織能力也明顯提高，遇到問題會(huì)及時(shí)拉起會(huì)議來溝通，很少有拖拖拉拉的。
通過這兩點(diǎn)我也是發(fā)現(xiàn)了敏捷的好處和前景，也開始整體和系統(tǒng)的入手敏捷開發(fā)流程，當(dāng)時(shí)從用戶故事、迭代……一直到現(xiàn)在的整理流程的把控。
上面說了一下我的經(jīng)歷，為什么使用敏捷和解決了我當(dāng)時(shí)企業(yè)的什么問題，可能有很多小伙伴也有類似問題，下面我們說重點(diǎn)。
什么是敏捷開發(fā)流程？
敏捷開發(fā)的概念
敏捷軟件開發(fā)又稱敏捷開發(fā)， 是一種從 1990 年代開始逐漸引起廣泛關(guān)注的一些新型軟件開發(fā)方法，是一種應(yīng)對(duì)快速變化的需求的一種軟件開發(fā)能力。它們的具體名稱、理念、過程、術(shù)語(yǔ)都不 盡相同，相對(duì)于“非敏捷”，更強(qiáng)調(diào)程序員團(tuán)隊(duì)與業(yè)務(wù)專家之間的緊密協(xié)作、面對(duì)面的溝通（比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團(tuán)隊(duì)、能夠很好地適應(yīng)需求變化的代碼編寫和團(tuán)隊(duì)組織方法，也更注重軟件開發(fā)中人的作用。
簡(jiǎn)單說，敏捷開發(fā)就是以人為核心、迭代、循序漸進(jìn)的開發(fā)方法。在敏捷開發(fā)中，軟件項(xiàng)目的構(gòu)建被切分成多個(gè)子項(xiàng)目，每個(gè)子項(xiàng)目在分割成多個(gè)用戶故事，各個(gè)子項(xiàng)目的成果都經(jīng)過測(cè)試，具備集成和可運(yùn)行的特征（就是每天或者每個(gè)迭代的版本都是可隨時(shí)運(yùn)行，隨時(shí)出版本）。
換言之，就是把一個(gè)大項(xiàng)目分為多個(gè)相互聯(lián)系，但也可獨(dú)立運(yùn)行的小項(xiàng)目，并分別去完成，在此過程中軟件一直處于可使用狀態(tài)。
敏捷最大的特色是迭代式開發(fā)。
通過下面了解敏捷的開發(fā)階段：
敏捷宣言
2001 年 2 月，敏捷宣言發(fā)表，敏捷聯(lián)盟成立。敏捷宣言中所表述的價(jià)值觀分為四個(gè)方面：
個(gè)體和互動(dòng)高于流程和工具
工作的軟件高于詳盡的文檔
客戶合作高于合同談判
響應(yīng)變化高于遵循計(jì)劃
敏捷開發(fā)方法有哪些？
和其它一些項(xiàng)目管理方式一樣，敏捷開發(fā)也有一定的方式。
前面說了很多主要講述，敏捷它其實(shí)是一種指導(dǎo)思想，或者說是一種開發(fā)方式，但是它沒有明確告訴我們，到底采用什么樣的流程進(jìn)行開發(fā)，更沒有告訴我們，怎么做才能是敏捷開發(fā)流程。
敏捷管理也有自己的流程方式，而 Scrum 和 XP 就是敏捷開發(fā)的具體方式了，我們可以采用 Scrum 方式，或者采用 XP 方式。
那么這兩種方式的區(qū)別是什么呢？
Scrum 偏重于過程
XP 則偏重于實(shí)踐
兩種方式，一個(gè)偏于過程，一個(gè)偏于實(shí)踐，但是實(shí)際工作中，兩者結(jié)合一起應(yīng)用才是最好的方式，當(dāng)然我們這里只說偏好的一種，這里主要講 Scrum。
什么是 Scrum？
Scrum 是一個(gè)敏捷開發(fā)框架流程模式，是一個(gè)增量的、迭代的開發(fā)過程。通常使用于敏捷軟件開發(fā)。
Scrum 原詞來自于橄欖球運(yùn)動(dòng)里面的一個(gè)專業(yè)術(shù)語(yǔ)。在橄欖球比賽的每次沖刺前。都將有一個(gè)計(jì)劃安排的過程，但沖刺開始后則由隊(duì)員在原計(jì)劃的基礎(chǔ)上隨機(jī)應(yīng)發(fā)。
在傳球的過程中需要所有成員的認(rèn)真配合，信念一致并且目標(biāo)明確。
這個(gè)過程體現(xiàn)了對(duì)一個(gè)高效合作團(tuán)隊(duì)的所有要求。
說到底，敏捷開發(fā)就像是一場(chǎng)瘋狂的橄欖球比賽。
Scrum 的組成：
一個(gè)開發(fā)過程
幾種角色
一套規(guī)范的實(shí)施方法
在 Scrum 中，產(chǎn)品需求就是產(chǎn)品需求列表（Product Backlogs）。所有的產(chǎn)品需求列表都是 從一個(gè)簡(jiǎn)單的想法開始，并逐步被細(xì)化（簡(jiǎn)單到復(fù)雜），梳理出來多個(gè)故事線，并且每個(gè)故事線就是一個(gè)單獨(dú)的模塊，可以被開發(fā)。
Scrum 將開發(fā)過程分為多個(gè) Sprint 周期，每個(gè) Sprint 代表一個(gè) 2~4 周的開發(fā)周期，有固定的時(shí)間長(zhǎng)度。
Scrum 敏捷流程圖
從哪些方面做到敏捷開發(fā)流程？
上面講到了敏捷開發(fā)的方式 Scrum 以及 Scrum 的概念，并且梳理了敏捷流程圖。那我們需要從哪些方面去做到敏捷開發(fā)流程呢？
要使用或者實(shí)踐敏捷開發(fā) 開始就要從 5 個(gè)會(huì)議入手，完全掌握了這 5 個(gè)會(huì)議，才能算真正地掌握 Scrum 敏捷開發(fā)實(shí)戰(zhàn)。
這里我們說一下 Scrum 的項(xiàng)目成員組成：Scrum 中有三個(gè)角色，分別由 PO（Product Owner）、Scrum Master、項(xiàng)目成員組成。
一般情況下產(chǎn)品經(jīng)理在需求分析、確定需求之后就需要開始做原型設(shè)計(jì)和寫一些需求文檔了。但是在 Scrum 開發(fā)模式下，不需要寫過多需求文檔的，我們會(huì)把所有想法體現(xiàn)在原型上，必須加上相應(yīng)的備注說明，如果在開發(fā)中，開發(fā)人員有什么疑問可以面對(duì)面溝通交流。
這也是 Scrum 的最關(guān)鍵的點(diǎn)就是多溝通，用溝通來替代文檔?？梢宰龅缴傥臋n，但是不能沒有溝通。
如果開始就丟給開發(fā)一個(gè)原型圖，或者原型流程，那他們肯定一臉茫然，甚至不知道如何開始工作，那么這種怎么解決呢？
為了項(xiàng)目負(fù)責(zé)人工作能夠更有效，團(tuán)隊(duì)能夠更和諧，所以這就涉及到接下來要說的 Scrum 五個(gè)會(huì)議：
需求澄清會(huì)
計(jì)劃分析會(huì)
站立會(huì)
評(píng)審會(huì)
回顧會(huì)
下面我們舉例一一說明一下這五種會(huì)議，搬起小板凳坐好，聽好。
需求澄清會(huì)
需求澄清會(huì)議就是澄清需求的，有些小伙伴可以會(huì)問，不是有原型圖嗎？講一下流程就行了，還澄清什么呢？當(dāng)然不是這樣的，澄清會(huì)議需要通過“用戶故事”的方式來澄清。
表達(dá)方式例如：
如果我是這個(gè)產(chǎn)品的用戶，我要實(shí)現(xiàn)什么功能，我需要怎么做？怎么做對(duì)用戶更好。
這邊的功能描述可能就是“作為用戶或者作為體驗(yàn)者，我想要什么樣的功能”，而不是詳細(xì)到“我要點(diǎn)擊那個(gè)操作怎么放置”。
簡(jiǎn)單點(diǎn)說，就是這個(gè)用戶故事是有多種體現(xiàn)方式的，每個(gè)人的理解不一樣就會(huì)導(dǎo)致實(shí)現(xiàn)不正確。這時(shí)候需要溝通，只有項(xiàng)目團(tuán)隊(duì)都確定了，要做的就是這樣的一個(gè)東西，這樣才算沒有問題的需求。
對(duì)一個(gè)項(xiàng)目來說，每個(gè)項(xiàng)目幾乎都要細(xì)分用戶故事，我們可以把用戶故事排一下優(yōu)先級(jí)，然后根據(jù)優(yōu)先級(jí)把用戶故事分成幾次不斷地迭代。
保證每次迭代的周期很短，一般是兩周或者是三周，還有迭代出來的一定是一個(gè)可以使用的產(chǎn)品，可能功能有點(diǎn)缺陷，但一定是可以正常使用的產(chǎn)品。
澄清會(huì)議需要大家的參與，功能溝通和討論出沒有異議的需求。一定要達(dá)到共識(shí)。
澄清會(huì)議需要項(xiàng)目經(jīng)理或者項(xiàng)目負(fù)責(zé)人，知道會(huì)議的進(jìn)行，首先講解大體的需求，然后就行劃分和討論。
計(jì)劃分析會(huì)
計(jì)劃分析會(huì)，就是根據(jù)上一步的澄清會(huì)議的結(jié)果，原型還有用戶故事再細(xì)分成任務(wù)。
這個(gè)會(huì)議一般由項(xiàng)目經(jīng)理或者項(xiàng)目負(fù)責(zé)人來主持。
在此會(huì)議之前，開發(fā)人員也知道了需要開發(fā)什么樣的產(chǎn)品，這時(shí)候就可以根據(jù)每個(gè)用戶故事對(duì)著原型分任務(wù)。
當(dāng)然這些任務(wù)的劃分，一般都是有開發(fā)來分配的，并且時(shí)間也是開發(fā)來評(píng)估的，一般我們會(huì)根據(jù)敏捷的版本迭代，拿出來一個(gè)或者多個(gè)故事線，進(jìn)行時(shí)間安排和劃分。
比如：
前端開發(fā)看到這個(gè)頁(yè)面，需要展示數(shù)據(jù)對(duì)接幾個(gè)接口，每個(gè)接口大概需要多少小時(shí)，需要后臺(tái)人員如何配合，這都是需要在這個(gè)會(huì)議搞清楚。所以為了后續(xù)的正常開發(fā)，這個(gè)會(huì)議將會(huì)是一個(gè)漫長(zhǎng)的過程，大概需要 3~4 個(gè)小時(shí)左右。建議 前后端的開發(fā)工作分開進(jìn)行，這樣更有針對(duì)性。
當(dāng)然這個(gè)會(huì)議要營(yíng)照一個(gè)和諧，舒服的環(huán)境，不要讓團(tuán)隊(duì)成員感到有壓力，不能太拘謹(jǐn)，建議團(tuán)隊(duì)成員通過電視或者影像投屏，把計(jì)劃讓大家都看到，并且大家圍在一起。每個(gè)成員要踴躍發(fā)言和溝通。最主要的非暴力溝通，對(duì)于自己的任務(wù)，要事實(shí)求是的評(píng)估時(shí)間，不要斷章取義，更不要胡亂評(píng)估。
站立會(huì)
站立會(huì)議是每天都需要開的會(huì)議，每個(gè)項(xiàng)目成員都需要依次發(fā)言，內(nèi)容一下：
昨天完成了什么？
今天需要做什么？
是否遇到難以推進(jìn)的問題？
當(dāng)然要強(qiáng)調(diào)的是這個(gè)會(huì)議不是匯報(bào)會(huì)議，團(tuán)隊(duì)成員不要從心理上認(rèn)為是給 Leader 匯報(bào)工作，站立會(huì)議主要是為了同步自己的工作情況，目的是讓團(tuán)隊(duì)其他成員知道，你做了什么？他們會(huì)根據(jù)你的工作情況來調(diào)整自己的工作情況，也方便團(tuán)隊(duì)負(fù)責(zé)人安排其他計(jì)劃和工作。
這個(gè)會(huì)議主要目的是：同步工作，互相配合，就是為了避免工作阻塞。
舉一個(gè)很簡(jiǎn)單的例子：
張三和李四做功能開發(fā)，兩個(gè)功能快有一定的關(guān)聯(lián)，在開發(fā)的時(shí)候需要配合才能進(jìn)行，當(dāng)張三遇到問題，或者有計(jì)劃變動(dòng)的時(shí)候，無法完成自己的本次迭代工作，需要及時(shí)讓李四知道并且調(diào)整，站立會(huì)議就能很好地做到及時(shí)的同步這些問題，避免障礙。
評(píng)審會(huì)
主要是進(jìn)行本次迭代的功能進(jìn)行演示、評(píng)審，對(duì)照用戶故事評(píng)審，我們是不是已經(jīng)完成了這幾個(gè)用戶故事所說的內(nèi)容。
評(píng)審會(huì)議需要團(tuán)隊(duì)成員一起參加，最好是各個(gè)有關(guān)領(lǐng)導(dǎo)和老板也一起參加，針對(duì)本次迭代的功能進(jìn)行一一演示，演示完成后，要針對(duì)該版本的功能做評(píng)審，最好每個(gè)人都發(fā)言，說一下自己的理解和感受，要做好會(huì)議記錄，最終做如下結(jié)果確認(rèn)：
哪些需要調(diào)整
需要怎么調(diào)整
調(diào)整需要時(shí)間
需要做會(huì)議記錄，通過上面的幾點(diǎn)記錄，用于下次版本的優(yōu)化迭代。評(píng)審會(huì)議就是反復(fù)迭代更新過程的一部分。
回顧會(huì)
回顧會(huì)議主要是，分析這次迭代我們團(tuán)隊(duì)有什么優(yōu)點(diǎn)、有什么缺點(diǎn)、可以怎樣改進(jìn)，產(chǎn)出對(duì)應(yīng)的改進(jìn)措施。
可以做出如下幾個(gè)點(diǎn)的說明：
哪些做得好的事情
哪些做得不好的事情
有什么建議或者意見
值得高興的事情
值得反思的事情
回顧會(huì)議的主要宗旨還是敏捷宣言：
個(gè)體和互動(dòng)高于流程和工具
工作的軟件高于詳盡的文檔
客戶合作高于合同談判
響應(yīng)變化高于遵循計(jì)劃
回顧會(huì)議主要就是不斷地改進(jìn)團(tuán)隊(duì)和不斷優(yōu)化工作流程。
上面五個(gè)重要的會(huì)議講完，小伙伴應(yīng)該都能很好地運(yùn)用這幾個(gè)會(huì)議了，這里我再說一下這五個(gè)會(huì)議的準(zhǔn)備工作。
環(huán)境：
準(zhǔn)備好投屏設(shè)備 （最好是電視）
演示設(shè)備 （演示使用的手機(jī)，或者鏈接電腦的軟件等）
會(huì)議面板（一個(gè)可移動(dòng)畫板最好，用于記錄會(huì)議中的重點(diǎn)）
計(jì)劃：
計(jì)劃好每個(gè)會(huì)議需要的內(nèi)容點(diǎn)
計(jì)劃好每一個(gè)會(huì)議的時(shí)間
計(jì)劃好每次主持會(huì)議的主持人
計(jì)劃好每次參與的成員
項(xiàng)目怎么開始使用敏捷開發(fā)？
敏捷管理，大家主要更關(guān)注在項(xiàng)目中怎么實(shí)踐敏捷開發(fā)的流程，具體有哪些工作可以用于敏捷？下面通過幾點(diǎn)說明一下，如何使用敏捷。
快速迭代
和傳統(tǒng)開發(fā)模式比較，那種半年一次的大版本發(fā)布或者項(xiàng)目完成才發(fā)布來說，小版本的需求、開發(fā)和測(cè)試更加簡(jiǎn)單快速。
有些公司，一年才發(fā)布 3~4 個(gè)版本，發(fā)布的整個(gè)流程很緩慢、很不暢通，采用的還是傳統(tǒng)瀑布開發(fā)模式，并且這些公司對(duì)敏捷開發(fā)模式的好處并沒有挖掘出來，一直誤解敏捷開發(fā)的好處。
這些公式任務(wù)一年發(fā)布 3~4 個(gè)版本是正常的，如果做到半個(gè)月發(fā)布 1 個(gè)版本，是不可能的事情。
但是現(xiàn)在來看，快速迭代已經(jīng)成為事實(shí)標(biāo)準(zhǔn)，關(guān)鍵是要比目前的版本發(fā)布速度更快一些。
敏捷管理是提高團(tuán)隊(duì)效能的方式之一，要讓團(tuán)隊(duì)發(fā)揮最高的效能，一定要讓團(tuán)隊(duì)小而精。
在敏捷開發(fā)中要設(shè)置沖刺周，按照每周一個(gè)沖刺，來進(jìn)行任務(wù)的迭代，這樣更高效，能更快地調(diào)整、優(yōu)化。
讓測(cè)試人員和開發(fā)者參與需求討論
需求討論以研討組的形式展開最有效率。
參與人員包括測(cè)試人員和開發(fā)者，這樣可以更加輕松定義可測(cè)試的需求，將需求分組并確定優(yōu)先級(jí)。
同時(shí)，該種方式也可以充分利用團(tuán)隊(duì)成員間的互補(bǔ)特性。如此確定的需求往往比開需求討論大會(huì)的形式效率更高，大家更活躍，參與感更強(qiáng)。
不要太重于細(xì)節(jié)
確定需求時(shí)，不要過度盯在細(xì)節(jié)上。需求報(bào)告過于詳細(xì)，就是一種不敏捷的習(xí)慣，還浪費(fèi)大家的時(shí)間。當(dāng)然，不能錯(cuò)過好點(diǎn)子，但就是不要太細(xì)，因?yàn)轫?xiàng)目真正實(shí)施起來時(shí)需求將會(huì)產(chǎn)生很大的變動(dòng)。
敏捷項(xiàng)目中編寫用戶故事有一個(gè)常用模板：
作為一名 [用戶類型]，我想要 [需求]，以便于 [原因]。
應(yīng)用到這個(gè)例子，就是：作為一名用戶，我想要將歸檔程序數(shù)字化，以便于增強(qiáng)溝通、提高分享效率。
可以通過 Excel 的模板形式提供大家，不斷更新需求。
多溝通，盡量減少文檔
任何項(xiàng)目中，溝通都是一個(gè)常見的問題。好的溝通，是敏捷開發(fā)的先決條件。敏捷強(qiáng)調(diào)良好高效的溝通的重要性。
團(tuán)隊(duì)要確保日常的交流，面對(duì)面溝通比郵件強(qiáng)得多。
上面說的每日站立會(huì)議就是溝通所必需的，每天團(tuán)隊(duì)成員的幾個(gè)人參與，時(shí)間控制在 15 分鐘內(nèi)。
每個(gè)人都依次說一下：
昨天完成了什么？今天要做什么？哪些問題仍待討論？
對(duì)于一些問題阻塞在另開會(huì)議討論。
所以這里強(qiáng)調(diào)敏捷的五個(gè)會(huì)議是非常重要的，溝通是根本。敏捷管理建議善于溝通。
做好產(chǎn)品原型
建議使用草圖和模型來闡明用戶界面。并不是所有人都可以理解一份復(fù)雜的文檔，但人人都會(huì)看圖。
文檔會(huì)導(dǎo)致無法把一個(gè)功能或者故事線 鏈接到一起。為了避免這一問題，可以模擬真實(shí)操作，改進(jìn)模擬操作過程中難以理解和不清楚的操作行為。這樣就可以使用原型圖的操作，這個(gè)繪制原型圖 可以使用如下：
比如下面的一個(gè)開源平臺(tái)，可以創(chuàng)建不同平臺(tái)的原型圖。
https://www.xiaopiu.com/
怎么才能評(píng)估團(tuán)隊(duì)是否已經(jīng)敏捷了？
敏捷開發(fā)是沒有標(biāo)準(zhǔn)的可供參考的實(shí)踐過程，所以很難通過某個(gè)過程而斷定其開發(fā)過程是否使用敏捷了，那么如何來評(píng)估團(tuán)隊(duì)是敏捷的呢？
根據(jù)團(tuán)隊(duì)呈現(xiàn)出來的氛圍、項(xiàng)目運(yùn)作狀態(tài)、團(tuán)隊(duì)成員的感性認(rèn)識(shí)等方面來評(píng)估團(tuán)隊(duì)和其開發(fā)過程是否敏捷，常見評(píng)估項(xiàng)目團(tuán)隊(duì)是否已經(jīng)敏捷的方法如下：
團(tuán)隊(duì)有共同的目標(biāo)，當(dāng)然這個(gè)目標(biāo)和公司的目標(biāo)一致，并且對(duì)這個(gè)目標(biāo)充滿信心；
團(tuán)隊(duì)有明確的階段目標(biāo)計(jì)劃并且為每個(gè)成員所知曉；
團(tuán)隊(duì)成員知曉當(dāng)前計(jì)劃，做什么、何時(shí)完成、預(yù)期效果等；
團(tuán)隊(duì)任務(wù)是低耦合的，并且緊密協(xié)作；
重點(diǎn)需要看，每次迭代版本發(fā)布過程是否是順利并且輕松愉快的，構(gòu)建版本并不斷測(cè)試是常態(tài)行為之一。
要從最基礎(chǔ)的工作做到敏捷開發(fā)。
當(dāng)然敏捷是一個(gè)慢慢實(shí)踐和優(yōu)化的過程，需要我們大家齊心協(xié)力，共同做到、做好，否則一切都是空談。
當(dāng)我們個(gè)人做任何事情的時(shí)候，會(huì)主動(dòng)溝通，不做被動(dòng)者，就有效提高了自己的工作效率，然而當(dāng)一個(gè)團(tuán)隊(duì)中人人都主動(dòng)溝通，相互配合，主動(dòng)承擔(dān)責(zé)任和任務(wù)，就是敏捷的最好體現(xiàn)。
千里之行，始于足下。
好了，這里關(guān)于敏捷的幾點(diǎn)就講到這里了，關(guān)鍵是在項(xiàng)目中實(shí)踐敏捷開發(fā)的流程，先做到自己工作的敏捷，慢慢和團(tuán)隊(duì)共同達(dá)到敏捷，實(shí)踐敏捷的工作，接下來要靠大家的行動(dòng)了，沒有行動(dòng)一切都是枉然，大家可以銘記敏捷宣言，從每天的一部分工作做起。
推薦閱讀
利用 Python 分析了一波月餅，我得出的結(jié)論是？
史上講解最好的 Docker 教程，從入門到精通（建議收藏的教程）
