【編者按】本文作者@朱軍華ronzhu 敏捷開發越來越火熱，但在實際應用當中很多時候都是只有敏捷的「形」，卻缺少敏捷的「神」，還只是在摸索中。
在《scrum：兼顧計畫與靈活的敏捷開發》一文中，作者最後也提到過，借鑑一種新的模式的時候，最好能夠批判性的吸收其精華的部分，不能全部照搬，照搬了反而會出問題。
其實敏捷對產品經理的要求是很高的，需要安排至少兩個迭代的任務，兩個迭代的規劃。
對程式設計師的要求也很高，當所有的任務都拆散了之後，最終做出來的東西要形成乙個產品，技術人員的整體意識要比較強，且一開始就得熟知產品的整個規劃，否則到最後就會出現所有任務都已完結，合併出來的最終產物卻是什麼都不是。
並且敏捷開發不僅僅是it部門的事情，還需要各個業務部門對敏捷的理解和支援，形成合力，從而提公升開發效率和業務滿意度。
執行一段時間的敏捷之後，發現最容易接受敏捷這種方式的是開發團隊，不管是瀑布式還是敏捷，只是做工作的形式不一樣了，進度更容易把握了，更能適應需求的變化了，實質其實並沒有變化。
對測試團隊來講，測試資源調配會更加的緊張，敏捷要求做完一條側一條，與原先的整體專案排期完全不一樣；對產品經理來說，敏捷能讓自身更好的掌握整個產品的進度。
但需求分析與產品設計階段的敏捷拆分還是較為頭疼的，究竟要不要寫文件了，是不是有什麼做什麼，還是說要規劃完整體設計之後才進行拆分？疑問很多，蒐集了部分資料，結合敏捷實踐的經驗，分享如下：
軟體或者系統產品終歸是人來維護的，業務知識和技能的傳遞就成為產品可持續發展的乙個重要因素，這就需要有知識性的沉澱，需要有文件的產出。
實際情況是大多數人都不喜歡編寫文件、也不太喜歡研讀文件，因此太多的文件只會消耗團隊有限的時間，並不能帶來多大的好處；敏捷開發照樣重視文件的作用，也重視文件的維護。
但文件宜少且精煉，一般情況下建議維護三份文件：
《產品需求規格說明書》
也即prd：定義產品應該具有的功能、邊界描述等，它作為產品團隊之間共同的討論基礎，並在設計和開發過程中不斷的更新維護，並記錄所有的需求變更；
《系統設計說明書》
開發人員編寫的技術設計，包含資料庫e-r圖，架構設計等：說明產品如何實
《測試用例和測試報告》
由測試人員編寫：記錄所有功能點的測試計畫、過程和測試結果；
前面也提到過，敏捷開發對開發人員來講實質差異不大，只是以小週期代替大週期。
小週期包括：需求、設計、開發、測試、發布，這個過程中的設計環節是指要做產品設計和系統設計；由於做完整的設計需要有相對完整的資料和比較長的時間，與小週期是相對立的。
因此敏捷開發不主張高度細化和完整的設計，提倡做出乙個大粒度的框架性設計，一般指架構設計或者系統設計，避免在以後的重構中發生架構級別的變化，然後在逐步實現的過程中逐漸深入展開、細化。
傳統的一些設計方法比如結構化設計、快速原型法都是可以融入敏捷開發過程中加以使用的。
敏捷開發只是把整體拆分成許多個體，產品的開發實現過程對產品的功能完整性、穩定性、即時性等都有較高的要求。
它是一種有組織有目標的行為，往往我們都將其作為乙個專案來管理，這就是討論為什麼有產品經理的同時還要有專案經理，為什麼要求產品經理要有專案管理的能力，因此它需要專案計畫。
但這個計畫是乙個短程計畫，根據未實現的功能情況、前乙個版本的反饋和組織目標制定開發計畫；唯有這樣才能不斷的融入新的需求變更；
敏捷開發的迭代週期沒有硬性的規定，結合專案里程碑、目標、功能實現情況、產品穩定性綜合決定，如果產品使用者活躍、功能實現難度小、維護複雜度低，建議以週為週期。
對於規模比較大、維護複雜度高的產品，考慮以2周-6週為週期發布較為合適；頻繁的發布會降低使用者的期望並提高使用者成本，給使用者心理上帶來額外的負擔：他會認為產品質量低，質量控制不嚴謹等；
小版本的目的就是分解複雜度、降低風險，改善團隊士氣等；小版本有眾多優勢：
3、測試和開發高效協作：開發和測試可以並行工作，當開發實現第乙個版本時，測試設計測試方案和用例；發布第乙個版本後，開發就進入下乙個版本輪 次，測試就應用測試方案測試剛才發布的版本，提交bug；開發在下乙個版本結束時修正所有上一輪發現的bug，然後發布新版本，如此迴圈往復，開發和測試 實現高效協作；
敏捷開發以重構為基礎，時時刻刻處於重構過程中；
敏捷強調團隊成員的高度參與就是要統一認識，把團隊的目標變成每個人的工作目標，使之為每個團隊成員的認同，形成高度的凝聚力，以達到群策群力、高效協作的效果。
由於沒有高度細化的文件，成員之間交換資訊的唯一渠道就是面對面溝通，良好的團隊氛圍和協作關係促進這種溝通，並使訊息有效傳達。
使用者由於缺乏專業訓練，無法清晰、準確的表達其意圖，導致需求的歧義和模糊；使用者的參與使模糊、邊界不確定的需求在互動的過程中得到確認和完善；在使用者參與過程中，我們常常可以聽到這樣的話：
「是的，就是這樣的」
「這正是我想要的......」
「這裡需要修改一下......」
「我的想法是這樣的......」
這個過程中，使用者承擔了一部分測試人員的角色。我們努力做的事情就是實現使用者需要的東西，並最終讓使用者喜歡它，唯有使用者喜歡它才能用好它，那麼我們怎能不認真聽取使用者的意見呢？一句話總結就是：使用者參與幫助我們做正確的事情！
由於敏捷開發沒有標準的可供參考的實踐過程，所以很難通過某個過程而斷定其開發過程敏捷了，那麼如何來評估團隊是敏捷的呢？一般採用的辦法是根據團 隊呈現出來的氛圍、專案運作狀態、團隊成員的感性認識等方面來評估團隊和其開發過程是否敏捷，常見評估專案團隊是否已經敏捷的方法如下：
以上是一些敏捷開發過程當中的疑問，其實還有很多，目前我這邊還只是主推讓開發和測試團隊敏捷，pd團隊還在摸索當中。
敏捷開發之產品級經驗分享
如何決定產品路線圖？如何快速驗證核心使用者需求？如何快速反饋，隨需而變？如何為客戶帶來最大價值服務？基於價值驅動的敏捷專案管理，用有限的時間和資源，先把重心放在對客戶價值最大的20 功能上。然後酌情開發剩餘的80 功能 團隊必須信守承諾，且軟體質量為第一原則，否則，破窗理論會告訴你其後果由多嚴重。個...
敏捷開發專案管理 通過敏捷開發管理專案的硬體方面
存檔日期 2019年5月14日 首次發布 2011年10月12日 瀑布式開發因無法處理快速變化的需求而在軟體行業中享有盛譽，在最先進的軟體開發中這一點變得越來越明顯。但是，在硬體開發等某些領域，瀑布仍然是更流行的開發方法。在本文中，我們介紹了如何使用ibm rational team concert...
嵌入式專案的開發經驗
define board addr uint16 t 0 1 8 巨集定義只能定義常量不可定義變數 define board addr board id 10 0 board id 10 0 8 board id為變數，所以不成功 receive flag 1 定義標誌位，if 語句常用標誌位為1來...