一，什麼是敏捷開發

1，敏捷開發的概念

敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。把一個大專案分為多個相互聯絡，但也可獨立執行的小專案，並分別完成，在此過程中軟體一直處於可使用狀態。

2，遵循的基本原則

個體和互動 勝過 過程和工具可以工作的軟體 勝過 面面俱到的文件客戶合作 勝過 合同談判響應變化 勝過 遵循計劃雖然右項也有價值，但是我們認為左項具有更大的價值。

3，實際有效的建議

快速迭代讓測試人員和開發者參與需求討論編寫可測試的需求文件多溝通，儘量減少文件做好產品原型及早考慮測試

二，敏捷開發的具體實現形式

1，站會

每天工作開始前，小團隊聚一起少時溝通。確定每個人工作的大致情況，是否在預期的進度內；發現是否有異常情況，對異常情況進行管理，整理備用方案。一切都是為了按照預定進度進行，在適當的時間提供可用的版本。

2，看板

應用泳道圖的樣式，將任務的進度明顯的展示出來。應用及時的狀態反饋，能夠看到整體情況，也能夠看到自己任務所處的狀態，便於團隊進度管控，以及適當的促進個人的工作效率。

三，敏捷開發的個人理解

1，敏捷開發的意義

敏捷開發通過各個形式，在不斷的迭代，快速的提交可用軟體的情況下，能夠較好的適應使用者需求，且整體進度的管控相對比較合理何時。看板的應用也確實能夠促進個人使用者的工作激情，也能夠便於管理人員掌控全體。

2，敏捷開發實現的誤區規避

敏捷開發是一個理念，在具體執行時不能生搬硬套（1）溝通因為參與人員多少，所消耗的成本區別，造成大團隊不適用；溝通進度及問題反饋，需要相關人員或者通才，或者更高層次的人才能理解與產生有效溝通，對於精於一個小方向或者一線執行人員，意義並不明確；（2）在軟體規模較小的時候，版本之間的修改影響面較廣，而在軟體較大的時候，版本升級次數過多，對於使用者很不好，對於測試人員，為了保證產品質量的迴歸測試資源浪費明顯；且版本修改內容過少時，版本更新的意義就失去；（3）客戶合作不合作不是最大的問題，最大的問題在於協同辦公，甚至是異地協同辦公，所以在沒有有些資料收集與反饋渠道，客戶合作再好也仍是解決不了新修改版本具體承載意義的反饋；在現在時時變化的社會潮流中，客戶也很難把我自己真實的需求。若是你能夠做好需求規劃，滿足客戶，客戶也是很滿意的；若是客戶自己定義需求，那就開始隨著客戶需求的變更整個團隊無限輪轉吧！若是使用者能夠很好的定義需求，那自己家的產品幹嘛呢？！不是不要求變化，而是在變化中，需要遵循自己的規則，有自己的重心。看過一篇文章，描述傳統的瀑布研發流程是火炮，敏捷開發是導彈。這個從某種意義上已經闡明瞭瀑布研發和敏捷研發的特點。在個人的認知中，應該結合兩種方式，各取其長，構建屬於每個公司自己的工作模式。火炮的造價低，火力猛，在快速定位目標後，集火幹掉目標；這裡的關鍵在於目標的瞄準 和 彈道發射的速度。大目標的確定，這是最關鍵的問題，及時研發最初是導彈，直接瞄準目標，也比胡亂開一個目標，不斷調整到目標來的更快，成本更低。若是發現目標發生重大偏離不管是什麼模式，都是需要新投入，進行調整的。市場的表現即是，若是新一項突破性的技術形成，整體的產品方向必須調整。

個人建議，在傳統的瀑布模型上，增加產品的管控；在研發的過程中使用敏捷模式，快速的交付產品，驗證產品的效益，及時調整。形成良性的迴圈，不斷反思，不斷試錯，進行成長。

參考資料：

敏捷開發
要是在第一個產品版本中，只能有3個功能，你要選哪一個？書中給出的建議是，一定要有使用者反饋和留言功能。因為，在一個產品的驗證階段和不成熟期時，使用者的反饋永遠是讓產品朝正確方向迭代的重要決策依據。