靈活開發越來越火熱，但在實際應用當中很多時候都是隻有靈活的“形”，卻缺少靈活的“神”，還隻是在摸索中。借鑒一種新的模式的時候，最好能夠批判性的吸收其精華的部分，不能全部照搬，照搬了反而會出問題。
其實靈活對産品經理的要求是很高的，需要安排至少兩個疊代的任務，兩個疊代的規劃。對程式員的要求也很高，當所有的任務都拆散了之後，最終做出來的東西要形成一個産品，技術人員的整體意識要比較強，且一開始就得熟知産品的整個規劃，否則到最後就會出現所有任務都已完結，合并出來的最終産物卻是什麼都不是。并且靈活開發不僅僅是IT部門的事情，還需要各個業務部門對靈活的了解和支援，形成合力，進而提升開發效率和業務滿意度。運作一段時間的靈活之後，發現最容易接受靈活這種方式的是開發團隊，不管是瀑布式還是靈活，隻是做工作的形式不一樣了，進度更容易把握了，更能适應需求的變化了，實質其實并沒有變化。對測試團隊來講，測試資源調配會更加的緊張，靈活要求做完一條側一條，與原先的整體項目排期完全不一樣；對産品經理來說，靈活能讓自身更好的掌握整個産品的進度。但需求分析與産品設計階段的靈活拆分還是較為頭疼的，究竟要不要寫文檔了，是不是有什麼做什麼，還是說要規劃完整體設計之後才進行拆分？疑問很多，搜集了部分資料，結合靈活實踐的經驗，
分享如下：靈活開發最少需要維護哪些文檔？軟體或者系統産品終歸是人來維護的，業務知識和技能的傳遞就成為産品可持續發展的一個重要因素，這就需要有知識性的沉澱，需要有文檔的産出。實際情況是大多數人都不喜歡編寫文檔、也不太喜歡研讀文檔，是以太多的文檔隻會消耗團隊有限的時間，并不能帶來多大的好處；
靈活開發照樣重視文檔的作用，也重視文檔的維護。但文檔宜少且精煉，一般情況下建議維護三份文檔：《産品需求規格說明書》也即PRD：定義産品應該具有的功能、邊界描述等，它作為産品團隊之間共同的讨論基礎，并在設計和開發過程中不斷的更新維護，并記錄所有的需求變更。《系統設計說明書》開發人員編寫的技術設計，包含資料庫E-R圖，架構設計等：說明産品如何實作，内部之間是什麼關系。《測試用例和測試報告》由測試人員編寫：記錄所有功能點的測試計劃、過程和測試結果。
靈活開發是否需要系統設計？
前面也提到過，靈活開發對開發人員來講實質差異不大，隻是以小周期代替大周期。小周期包括：需求、設計、開發、測試、釋出，這個過程中的設計環節是指要做産品設計和系統設計；由于做完整的設計需要有相對完整的資料和比較長的時間，與小周期是相對立的。是以靈活開發不主張高度細化和完整的設計，提倡做出一個大粒度的架構性設計，一般指架構設計或者系統設計，避免在以後的重構中發生架構級别的變化，然後在逐漸實作的過程中逐漸深入展開、細化。
傳統的一些設計方法比如結構化設計、快速原型法都是可以融入靈活開發過程中加以使用的。靈活開發是否需要系統設計？靈活開發隻是把整體拆分成許多個體，産品的開發實作過程對産品的功能完整性、穩定性、即時性等都有較高的要求。它是一種有組織有目标的行為，往往我們都将其作為一個項目來管理，這就是讨論為什麼有産品經理的同時還要有項目經理，為什麼要求産品經理要有項目管理的能力，是以它需要項目計劃。但這個計劃是一個短程計劃，根據未實作的功能情況、前一個版本的回報群組織目标制定開發計劃；唯有這樣才能不斷的融入新的需求變更。靈活開發的疊代周期大概多長？靈活開發的疊代周期沒有硬性的規定，結合項目裡程碑、目标、功能實作情況、産品穩定性綜合決定，如果産品使用者活躍、功能實作難度小、維護複雜度低，建議以周為周期。對于規模比較大、維護複雜度高的産品，考慮以2周-6周為周期釋出較為合适；頻繁的釋出會降低使用者的期望并提高使用者成本，給使用者心理上帶來額外的負擔：他會認為産品品質低，品質控制不嚴謹等。
靈活開發為何提倡小版本？小版本的目的就是分解複雜度、降低風險，改善團隊士氣等、小版本有衆多優勢：
1、總體風險比較少：小版本變化小，總是在上一個版本基礎上局部調整和增加，技術複雜度低；由于規劃的功能較少，工作量也易于估算，是以其總體風險比較少，常常能如期釋出。
2、需求的接納能力強：由于小版本快速實作并釋出測試，然後就進入下一個版本的規劃實作周期，這樣新需求一旦提出就能快速進入開發視野，就能盡快實作。
3、測試和開發高效協作：開發和測試可以并行工作，當開發實作第一個版本時，測試設計測試方案和用例；釋出第一個版本後，開發就進入下一個版本輪次，測試就應用測試方案測試剛才釋出的版本，送出Bug；開發在下一個版本結束時修正所有上一輪發現的Bug，然後釋出新版本，如此循環往複，開發和測試實作高效協作。
靈活開發與重構的關系如何？靈活開發以重構為基礎，時時刻刻處于重構過程中。靈活開發為何強調團隊人員參與？靈活強調團隊成員的高度參與就是要統一認識，把團隊的目标變成每個人的工作目标，使之為每個團隊成員的認同，形成高度的凝聚力，以達到群策群力、高效協作的效果。由于沒有高度細化的文檔，成員之間交換資訊的唯一管道就是面對面溝通，良好的團隊氛圍和協作關系促進這種溝通，并使消息有效傳達。使用者由于缺乏專業訓練，無法清晰、準确的表達其意圖，導緻需求的歧義和模糊；使用者的參與使模糊、邊界不确定的需求在互動的過程中得到确認和完善；在使用者參與過程中，我們常常可以聽到這樣的話：“是的，就是這樣的”“這正是我想要的......”“這裡需要修改一下......”“我的想法是這樣的......”這個過程中，使用者承擔了一部分測試人員的角色。我們努力做的事情就是實作使用者需要的東西，并最終讓使用者喜歡它，唯有使用者喜歡它才能用好它，
那麼我們怎能不認真聽取使用者的意見呢？一句話總結就是：使用者參與幫助我們做正确的事情！如何評估團隊是否已經靈活？由于靈活開發沒有标準的可供參考的實踐過程，是以很難通過某個過程而斷定其開發過程靈活了，那麼如何來評估團隊是靈活的呢？一般采用的辦法是根據團隊呈現出來的氛圍、項目運作狀态、團隊成員的感性認識等方面來評估團隊和其開發過程是否靈活，常見評估項目團隊是否已經靈活的方法如下：● 團隊有共同的願景，并且對這個願景充滿信心● 團隊有明确的階段目标并且為每個成員所知曉● 團隊知曉目前計劃：做什麼、何時完成、預期效果等● 團隊任務是低耦合的，并且緊密協作● 釋出過程是輕松愉快的，建構版本并不斷測試是常态行為之一靈活能縮短項目時間并提高品質嗎？從我的實踐經驗來看是可以的，但目前無法提供量化的資料做參考，隻能從幾個方面評估和推斷：● 使用者的參與幫助團隊把功能一次性完成并做正确，縮減了返工的時間；● 不斷的重構和測試釋出能把問題發現在早期，整體品質顯著提高；● 過程目标導向，使團隊高度集中于項目目标，提高了生産力；● 不斷的釋出對團隊是種正向激勵，榮譽感和成功欲使團隊保持持續的激情。