今天跟大家分享的是“敏捷開發、快速迭代”。我們大都採用的是“瀑布開發模式”，有了問題，就得返工，雖然最終的產品會比較齊全完善，但是開發週期太長，開發人員會產生排斥，甚至厭惡的心理。經過YH系統的開發，也且生體會到了這一弊端。

有問題就要去解決它！於是我想到了“敏捷開發”。借鑑敏捷開發模式，來改善軟體開發過程，提高專案的開發效率。

要想借鑑，首先得弄懂以下3個問題。

1. 什麼是敏捷開發
   百度百科中是這樣解釋的：敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟體專案的構建被切分成多個子專案，各個子專案的成果都經過測試，具備整合和可執行的特徵。換言之，就是把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。

我們可以這樣認為，敏捷開發是一種面臨迅速變化的需求快速開發的能力。要明確幾點：
敏捷不僅僅是一個專案快速完成、而是對整個產品領域需求的高效管理；
敏捷不僅僅是簡單的快，而是短週期的不斷改進、提高和調整；
敏捷不僅僅是一個版本只做幾個功能，而是突出重點、果斷放棄當前的非重點；
敏捷不僅僅是隨時增加需求，而是每個迭代週期對需求的重新稽核和排序。

2.如何進行敏捷開發？
敏捷開發的體系建設主要有如下六個方面：
1、組織建設
也就是團隊建設，建立以產品經理為主導，包含產品、設計、前後臺開發和測試的team，快速進行產品迭代開發；扁平化的團隊管理，大家都有共同目標，更有成就感；

2、敏捷制度
要找準適合自身的敏捷開發方式，主要是制定一個完善的效率高的設計、開發、測試、上線流程，制定固定的迭代週期，讓使用者更有期待；

3、需求收集
這個任何方式下都需要有，需求一定要有互動稿，評審通過後，一定要確定功能需求列表、責任人、工作量、責任人等；

4、工具建設
是指能夠快速完成某項事情的輔助工具，比如開發環境的一鍵安裝，各種底層的日誌、監控等平臺，釋出、打包工具等；

5、系統架構
略為超前架構設計：支援良好的擴容性和可維護性；元件化基礎功能模組：程式碼耦合度低，模組間的依賴性小；外掛化業務模組：降低營銷活動與業務耦合度，自升級、自維護；客戶端預埋邏輯；技術預研等等；

6、資料運營與灰度釋出
點選率分析、使用者路徑分析、渠道選擇、渠道升級控制等等。

有幸拾得某位牛人的敏捷開發經驗，再結合自己的理解，一起拿出來與大家分享一下：
1 、 重點明確，及時調整。
通過分析需求的緊急性和重要性，做出優先順序的判定，優先順序從1排到10，沒有重複；
迭代中嚴格按照優先順序順序開發，即使最後時間不夠，也能保證最需要的功能開發完成；
每次迭代前重新調整需求的重要性，及時加入重要的業務需求和使用者需求，將重要性不高的需求往後調整。

2、傾聽使用者的聲音、相信使用者的直覺。
在迭代中充分關注線上版本使用者的反饋，並且主動聯絡使用者瞭解困擾，在當個迭代或下個迭代快速優化；通過對使用者反饋的及時響應獲得使用者的認可和口碑。
這裡就提到一個名叫“AB test”的開發模式，一個問題有A、B兩種解決方案，不知道哪個更符合使用者的需求，那麼就讓使用者去選擇，根據使用者的反饋去迅速調整。
有興趣的話，可以看看這個視訊，是我在找資料時看到的，裡面講到了這個問題，即小米MIUI產品經理許斐演講的“快速迭代的網際網路開發模式 ”。

3、勇於創新、小步快跑。
在迭代中勇於創新，快速實現創新想法，並在後續的迭代中不斷優化。
一直遠離媒體視線的騰訊CEO馬化騰，在“合作伙伴大會一週年”的活動上，也給合作伙伴和同行們“小步快跑，快速迭代”的建議，被賦予“一直在模仿，從未被超越”稱號的騰訊開發團隊，其實創新也是國內最多的。

4、持續不斷地發現問題，解決問題。
通過每天的版本釋出來檢驗團隊在每日立會上做出的承諾；
測試和驗證功能的開發程度；
對於功能的實現第一時間給出反饋，並能快速調整,而不會像瀑布式等到開發末期才發現實現上的問題。

5、持續提升整個團隊的產品能力。
專門的團隊面向一個產品領域；
持續優化使用者體驗和產品流程；
通過產品迭代的心跳保持產品團隊的使用者和市場敏感度；
提升產品經理的產品感覺、提高技術團隊的產品意識；
團隊伴隨業務而成長，獲得更高的成就感。

更多具體的實施和經驗分享，可以參考“專案管理專欄”。

說了這麼多，歸結起來就是，產品通過不斷的獲取使用者新需求，不斷的更新迭代而愈加成熟。而快速迭代，則能提升團隊的市場競爭力，從而快速佔領市場。
看過一幅圖片：快速迭代，越變越美。那麼如何快速迭代呢？

3.如何快速迭代
其實這個問題已經在第二個問題中回答過了，這裡再單拿出來說，是為了強調一下。
現在是網際網路的時代，網際網路產品的更新速度可謂是日新月異。網際網路的開發模式也是主要圍繞“快速迭代”的主題來開發產品的　在飛速發展的網際網路行業裡，產品是以使用者為導向在隨時演進的。因此，在推出一個產品之後要迅速收集使用者需求進行產品的迭代——在演進的過程中注入使用者需求的基因，完成快速的升級換代，裂變成長，才能讓你的使用者體驗保持在最高水平。不要閉門造車以圖一步到位，否則你的研發速度永遠也趕不上需求的變化。

可能我們做的不是網際網路的專案，但是如果是大專案，依舊推薦使用敏捷開發。分級需求，快速迭代產品。讓使用者能在短時間內使用者用上你的產品，短時間內使用到新功能。

採用“短週期迭代法”，可以壓縮專案開發實施週期，減少專案風險，簡化管理，提高各個環節達成率，有效推進專案建設。

快速迭代，版本更新快，所以要考慮降低專案風險，確保正確的方向。

敏捷開發能夠縮短專案的反饋週期，因其將專案分成了若干個迭代週期，每個迭代週期結束都能立即反饋。且通過不斷的溝通，還能減少理解上的偏差，配合反饋，減少誤解，從而降低修正錯誤的代價。且每個迭代週期的結束都能接受驗證，從而能快速的適應變化，及時的適應新的需求，保證產品的正確性。

那麼迭代週期設定為多少合適呢，“小步快跑、快速迭代”，當然系統大小也會影響到迭代週期，所以把迭代週期一般設定為1-6周為佳。

曾經跟QQ安全管家的一個開發人員聊過天，得知QQ安全管家是一星期一個beta版本，一月一個正式版。小米的MIUI更新週期，每天都有更新給榮譽開發組，每週都更新ROM包，提供給使用者下載。百度每天都會有上百次更新升級上線，網頁搜尋的結果頁每一天都有幾十個等待測試上線的升級專案。可見快速迭代是多麼許多公司都推薦的一種開發模式。

還有一點要注意，快速迭代，不是說一定要做好了，才能上線，半成品也能上線。

在沒有上線之前，你怎麼知道哪好那不好。所以半成品也是可以出門的，一定不要吝惜在家，醜媳婦才需要儘早見公婆。儘早的讓使用者去評判你的想法，你的設計是否可以贏得使用者的喜愛。快速發出，緊盯使用者反饋。百度完成了第一版的搜尋引擎，也是讓使用者去做的選擇。用百度CEO李彥巨集（Robin）的話來說“你怎麼知道如何把這個產品設計成最好的呢？只有讓使用者儘快去用它。既然大家對這版產品有信心，在基本的產品功能上我們有競爭優勢，就應該抓住時機儘快將產品推向市場，真正完善它的人將是使用者。他們會告訴你喜歡哪裡不喜歡哪裡，知道了他們的想法，我們就迅速改，改了一百次之後，肯定就是一個非常好的產品了。”

簡單地分享了一下對敏捷開發，快速迭代的理解。這裡再給大家一個連線，51CTO的《專題:初探敏捷開發》，供大家參閱。