敏捷開發，相對傳統軟體開發模式，它主要是針對快速變化的需求，不斷優化管理流程，最終推出優質軟體。
1. 快速迭代
相對那種半年一次的大版本發布來說，小版本的需求、開發和測試更加簡單快速。一些公司，一年僅發布僅2~3 個版本，發布流程緩慢，它們仍採用瀑布開發模式，更嚴重的是對敏捷開發模式存在誤解。
由一年發布 2 個版本轉到乙個月發布 2 個版本，這也不太可能。但是現在來看，快速迭代已經成為事實標準，關鍵是要比目前的版本發布速度更快一些。
快速迭代，可以逼迫團隊不斷優化流程、提公升工作效率，不要在無足輕重的事情上浪費時間。如果離 deadline 還有 6 個月，那麼整個工作節奏必然悠哉。如果每月發布乙個版本，那麼較以前效率必然會更高。如果發布週期過長，導致無法盡快發現使用者需求，進而無法及時改進產品。
2. 讓測試人員和開發者參與需求討論
需求討論以研討組的形式展開最有效率。研討組，需要包括測試人員和開發者，這樣可以更加輕鬆定義可測試的需求，將需求分組並確定優先順序。
同時，該種方式也可以充分利用團隊成員間的互補特性。如此確定的需求往往比開需求討論大會的形式效率更高，大家更活躍，參與感更強。
確定需求時，不要過度盯在細節上。需求報告過於詳細，就是一種不敏捷的習慣，還浪費大家的時間。當然，不能錯過好點子，但就是不要太細，因為專案真正實施起來時需求將會產生很大的變動。
3. 編寫可測試的需求文件
開始就要用「使用者故事」（user story）的方法來編寫需求文件。這種方法，可以讓我們將注意力放在需求上，而不是解決方法和實施技術上。過早的提及技術實施方案，會降低對需求的注意力。
規劃業務需求，可以採用「3w 模板」，也就是：
誰（who）
是什麼（what）
為什麼（why）
誰（who）：使用者
是什麼（what）：希望借助乙個應用程式在不同伺服器間傳輸檔案
為什麼（why）：為了儲存專案資料；為了更加接近「使用者故事」，我們可以改寫為：
誰（who）：消費者/使用者
是什麼（what）：想將歸檔過程數位化
為什麼（why）：為了增強溝通，提高分享效率
敏捷專案中編寫使用者故事有乙個常用模板：作為一名[使用者型別]，我想要[需求]，以便於[原因]。應用到這個例子，就是：作為一名使用者，我想要將歸檔程式數位化，以便於增強溝通、提高分享效率。
多數情況下，需求內容需要更加充實和詳細，這一步要放到後面做，開始不要這樣。使用者故事的方法有時會因過於簡短、不斷重複而受到批評。這裡我們必須明白：需求文件不是散文或詩歌，應該清晰、簡明地描述使用者需求；需求文件的重點也在於此，不要管形式多變或內容是否重複這樣的問題。
4. 多溝通，儘量減少文件
任何專案中，溝通都是乙個常見的問題。好的溝通，是敏捷開發的先決條件。在圈子裡面混得越久，越會強調良好高效的溝通的重要性。
團隊要確保日常的交流，面對面溝通比郵件強得多。
敏捷開發鼓勵日常的協調會議和碰頭會，5~7 人參與的會議盡量控制在 10 分鐘內。碰頭時，要過一遍昨天完成了什麼，今天要做什麼，哪些問題仍待討論。可以用 burndown chart（燃盡圖）來形象展示工作進度。每次迭代的時候也都要開乙個計畫會議和評審會議，一般需要的時間可能會長些，比如半天。這些會議的目的就是對工作查缺補漏。
評審會議很重要，傳統開發模式往往略過該環節，導致一些錯誤做法不斷重複，好的做法無法推廣。
開會時，可以將原先的分組打散，讓整個團隊都參與到專案的需求討論和測試中來，這樣可以突出成員個人，讓大家更樂意參與。
5. 做好產品原型
建議使用草圖和模型來闡明使用者介面。並不是所有人都可以理解乙份複雜的文件，但人人都會看圖。
乙個常見的問題是軟體新的功能與使用者想要的不一致。為了避免這一問題，可以模擬真實操作，改進模擬操作過程中難以理解和不清楚的操作行為。
6. 及早考慮測試
及早地考慮測試在敏捷開發中很重要。傳統的軟體開發，測試用例很晚才開始寫，這導致過晚發現需求中存在的問題，使得改進成本過高。較早地開始編寫測試用例，當需求完成時，可以接受的測試用例也基本一塊完成了。
敏捷開發中乙個常見問題就是開發者沒有對已有的**庫進行充分的回歸測試。迭代週期很短，從開始到交付就是 4 周的時間，這樣可以對迭代的設計、實現和底層測試一塊進行回歸測試。
一系列迭代之後，可以只針對測試活動再補充乙個迭代。這個迭代可以將重點放在系統測試、與其他系統的整合度、效能等方面。敏捷開發過程中，可能會導致過少的測試文件。如果迭代週期為 1 個月左右，可以不必對測試文件過於要求，但要制定好測試策略。
最後
可能大多數公司或團隊還沒有開始嘗試敏捷開發，不過可以開始從點滴做起，比如開碰頭會、為專案管理採用乙個更加高效的管理工具等等。最後，希望上面的建議能夠為大家的軟體開發管理帶來幫助。
光環國際pmi-acp敏捷認證獨家學習培訓方案，敏捷實踐專家親臨授課
課前預習：預習制定學習資料，了解考試範圍和框架；班主任郵件、**指導 預習；qq**流。
實戰精講解階段：敏捷課程donmain i-vi實戰精講學習；組建emba學習小組，互相**，結合老師的案例強化敏捷技術的應用。
全真模考：2
天全真模考體驗，檢測學習成果；系統梳理考試知識點，全面解決考前疑難問題。
光環敏捷認證：
諮詢**：400-7060-559
敏捷方法落地之旅 PMI ACP敏捷認證交流會
會議名稱 pmi acp敏捷認證交流會 票價 免費 參會規模 人數 50 會議主辦方 光環國際 一 會議簡介 1 為什麼客戶的需求在不停的變化，如何應對?2 為什麼小型團隊用專案管理的流程會有些力不從心?3 上線時間越來越短，如何能快速了解市場推出的新產品?4 如何有效溝通和高效運作讓團隊充滿戰鬥力...
敏捷開發 敏捷測試
敏捷測試的定義 首先敏捷測試是敏捷的一種，原有測試定義中通過執行被測系統發現問題，通過測試這種活動能夠提供對被測系統提供度量等概念還是適用的。在傳統的測試定義上，還需要新增 敏捷測試是遵循敏捷宣言的一種測試實踐 強調從客戶的角度，即使用系統的使用者的角度，來測試系統 重點關注持續迭代的測試新開發的功...
敏捷開發 敏捷開發中的質量
有小夥伴就問，我們都敏捷了，我們是在效率和質量中找平衡，說敏捷開發中的質量是不容易控制的，要回答這個問題，我設計了乙個faq，內容如下 敏捷開發是什麼？敏捷開發是以需求為中心，以交付價值為目的，持續增量交付的一種軟體開發方法，至於什麼是敏捷，就去問問度娘吧。對於敏捷團隊來說，是乙個自組織的，有集體目...