今天跟大家分享的是「敏捷開發、快速迭代」。我們大都採用的是「瀑布開發模式」，有了問題，就得返工，雖然最終的產品會比較齊全完善，但是開發周期太長，開發人員會產生排斥，甚至厭惡的心理。經過yh系統的開發，也且生體會到了這一弊端。
有問題就要去解決它！於是我想到了「敏捷開發」。借鑑敏捷開發模式，來改善軟體開發過程，提高專案的開發效率。
要想借鑑，首先得弄懂以下3個問題。
1. 什麼是敏捷開發
我們可以這樣認為，敏捷開發是一種面臨迅速變化的需求快速開發的能力。要明確幾點：
敏捷不僅僅是乙個專案快速完成、而是對整個產品領域需求的高效管理；
敏捷不僅僅是簡單的快，而是短週期的不斷改進、提高和調整；
敏捷不僅僅是乙個版本只做幾個功能，而是突出重點、果斷放棄當前的非重點；
敏捷不僅僅是隨時增加需求，而是每個迭代週期對需求的重新審核和排序。
2.如何進行敏捷開發？
敏捷開發的體系建設主要有如下六個方面：
1、組織建設也就是團隊建設，建立以產品經理為主導，包含產品、設計、前後臺開發和測試的team，快速進行產品迭代開發；扁平化的團隊管理，大家都有共同目標，更有成就感；
2、敏捷制度
要找準適合自身的敏捷開發方式，主要是制定乙個完善的效率高的設計、開發、測試、上線流程，制定固定的迭代週期，讓使用者更有期待；
3、需求收集
這個任何方式下都需要有，需求一定要有互動稿，評審通過後，一定要確定功能需求列表、責任人、工作量、責任人等；
4、工具建設
是指能夠快速完成某項事情的輔助工具，比如開發環境的一鍵安裝，各種底層的日誌、監控等平台，發布、打包工具等；
5、系統架構
略為超前架構設計：支援良好的擴容性和可維護性；元件化基礎功能模組：**耦合度低，模組間的依賴性小；外掛程式化業務模組：降低營銷活動與業務耦合度，自公升級、自維護；客戶端預埋邏輯；技術預研等等；
6、資料運營與灰度發布
點選率分析、使用者路徑分析、渠道選擇、渠道公升級控制等等。
1 、 重點明確，及時調整。更多具體的實施和經驗分享，可以參考「專案管理專欄」。通過分析需求的緊急性和重要性，做出優先順序的判定，優先順序從1排到10，沒有重複；
迭代中嚴格按照優先順序順序開發，即使最後時間不夠，也能保證最需要的功能開發完成；
每次迭代前重新調整需求的重要性，及時加入重要的業務需求和使用者需求，將重要性不高的需求往後調整。
2、傾聽使用者的聲音、相信使用者的直覺。
在迭代中充分關注線上版本使用者的反饋，並且主動聯絡使用者了解困擾，在當個迭代或下個迭代快速優化；通過對使用者反饋的及時響應獲得使用者的認可和口碑。
這裡就提到乙個名叫「ab test」的開發模式，乙個問題有a、b兩種解決方案，不知道哪個更符合使用者的需求，那麼就讓使用者去選擇，根據使用者的反饋去迅速調整。
3、勇於創新、小步快跑。
在迭代中勇於創新，快速實現創新想法，並在後續的迭代中不斷優化。
4、持續不斷地發現問題，解決問題。
通過每天的版本發布來檢驗團隊在每日立會上做出的承諾；
測試和驗證功能的開發程度；
對於功能的實現第一時間給出反饋，並能快速調整,而不會像瀑布式等到開發末期才發現實現上的問題。
5、持續提公升整個團隊的產品能力。
專門的團隊面向乙個產品領域；
持續優化使用者體驗和產品流程；
通過產品迭代的心跳保持產品團隊的使用者和市場敏感度；
提公升產品經理的產品感覺、提高技術團隊的產品意識；
團隊伴隨業務而成長，獲得更高的成就感。
說了這麼多，歸結起來就是，產品通過不斷的獲取使用者新需求，不斷的更新迭代而愈加成熟。而快速迭代，則能提公升團隊的市場競爭力，從而快速占領市場。
看過一幅：快速迭代，越變越美。那麼如何快速迭代呢？
3.如何快速迭代
其實這個問題已經在第二個問題中回答過了，這裡再單拿出來說，是為了強調一下。
現在是網際網路的時代，網際網路產品的更新速度可謂是日新月異。網際網路的開發模式也是主要圍繞「快速迭代」的主題來開發產品的 在飛速發展的網際網路行業裡，產品是以使用者為導向在隨時演進的。因此，在推出乙個產品之後要迅速收集使用者需求進行產品的迭代——在演進的過程中注入使用者需求的基因，完成快速的公升級換代，裂變成長，才能讓你的使用者體驗保持在最高水平。不要閉門造車以圖一步到位，否則你的研發速度永遠也趕不上需求的變化。
可能我們做的不是網際網路的專案，但是如果是大專案，依舊推薦使用敏捷開發。分級需求，快速迭代產品。讓使用者能在短時間內使用者用上你的產品，短時間內使用到新功能。
採用「短週期迭代法」，可以壓縮專案開發實施週期，減少專案風險，簡化管理，提高各個環節達成率，有效推進專案建設。
快速迭代，版本更新快，所以要考慮降低專案風險，確保正確的方向。
敏捷開發能夠縮短專案的反饋週期，因其將專案分成了若干個迭代週期，每個迭代週期結束都能立即反饋。且通過不斷的溝通，還能減少理解上的偏差，配合反饋，減少誤解，從而降低修正錯誤的代價。且每個迭代週期的結束都能接受驗證，從而能快速的適應變化，及時的適應新的需求，保證產品的正確性。
那麼迭代週期設定為多少合適呢，「小步快跑、快速迭代」，當然系統大小也會影響到迭代週期，所以把迭代週期一般設定為1-6週為佳。
還有一點要注意，快速迭代，不是說一定要做好了，才能上線，半成品也能上線。
簡單地分享了一下對敏捷開發，快速迭代的理解。這裡再給大家乙個連線，51
cto的《
專題:初探敏捷開發
》，供大家參閱。
騰訊敏捷開發及快速迭代
整個實施階段大概分成幾個階段 團隊非常多，每個團隊特點都不一樣，比如規模不一樣，應用方法不一樣 一些長週期的專案，比如qq客戶端，乙個版本的發布可能要半年到1年的時間，像這樣乙個產品怎樣去做敏捷開發，也許它就不適合敏捷開發。一 整體的框架結構 1 產品 fdd的核心是面向產品的功能點，但這個功能點是...
敏捷質疑 迭代開發
迭代在於我們明確的承認資訊和知識的不完備性,不可完備性.而專案的成功,需要某種程度的完備性.這種認知的侷限與成功的條件之間的矛盾,促成了人們解決這類問題的通用方法 漸進的試錯法 試錯法參考一 試錯法參考二 是解決問題 獲得知識常用的方法，即根據已有經驗，採取系統或隨機的方式，去嘗試各種可能的答案。當...
敏捷質疑 迭代開發
迭代在於我們明確的承認資訊和知識的不完備性,不可完備性.而專案的成功,需要某種程度的完備性.這種認知的侷限與成功的條件之間的矛盾,促成了人們解決這類問題的通用方法 漸進的試錯法 試錯法參考一 試錯法參考二 是解決問題 獲得知識常用的方法，即根據已有經驗，採取系統或隨機的方式，去嘗試各種可能的答案。當...