面對敏捷開發、快速迭代這些看似洋氣的詞語時，一定要看是否與自己的實際情況相匹配，不能為了追趕時尚就概念先行。
“敏捷開發”這個詞一直不過時，在很多公司，不論是老闆還是項目自身人員，一提到這個詞似乎都帶有一種優越感，可能是因為這意味著節約資源，亦或是一種先進的開發模式。
何為敏捷開發
百度百科中關於“敏捷開發的原則”提到了以下幾點：
1. 快速迭代
相對那種半年一次的大版本發佈來說，小版本的需求、開發和測試更加簡單快速。一些公司，一年發佈僅2~3個版本，發佈流程緩慢，它們仍採用瀑布開發模式，更嚴重的是對敏捷開發模式存在誤解。
2. 讓測試人員和開發者參與需求討論
需求討論以研討組的形式展開最有效率。
研討組，需要包括測試人員和開發者，這樣可以更加輕鬆定義可測試的需求，將需求分組並確定優先級。 同時，該種方式也可以充分利用團隊成員間的互補特性。如此確定的需求往往比開需求討論大會的形式效率更高，大家更活躍，參與感更強。
3. 編寫可測試的需求文檔
開始就要用“用戶故事”（User Story）的方法來編寫需求文檔。這種方法，可以讓我們將注意力放在需求上，而不是解決方法和實施技術上。過早的提及技術實施方案，會降低對需求的注意力。
4. 多溝通，儘量減少文檔
任何項目中，溝通都是一個常見的問題。好的溝通，是敏捷開發的先決條件。在圈子裡面混得越久，越會強調良好高效的溝通的重要性。團隊要確保日常的交流，面對面溝通比郵件強得多。
5. 做好產品原型
建議使用草圖和模型來闡明用戶界面。並不是所有人都可以理解一份複雜的文檔，但人人都會看圖。
6. 及早考慮測試
及早地考慮測試在敏捷開發中很重要。傳統的軟件開發，測試用例很晚才開始寫，這導致過晚發現需求中存在的問題，使得改進成本過高。較早地開始編寫測試用例，當需求完成時，可以接受的測試用例也基本一塊完成了。
自測敏捷與否
對比上述的幾條原則，逐一自檢自身的這個小團隊，不禁覺得每一條都符合。
我們大概1個月左右做一次版本發佈；需求文檔和產品原型一應俱全，通常在這兩份文檔具備的情況下，與測試和開發人員一起進行需求同步，以需求為主線，進行技術實現的溝通和安排。
之後，技術開始進行框架搭建和開發準備，與此同時測試人員根據需求編寫測試用例。在這個過程中，有任何問題隨時交流，面對面的日常交流比文檔傳遞更便捷，有改動的地方統一更新做標記。最後就是測試、bug修復及上線。
迭代與規劃之分
我們一直在宣揚敏捷開發快速迭代，看著一個個版本號的更新，覺得很欣慰。
可在某次聽一位嘉賓分享時，才發現，原來上述這樣的情況並不屬於快速迭代，老師主要講了2方面：
快速迭代和整體規劃的選擇關鍵在於：是否能提前知道用戶的準確需求，以及是否能快速得到用戶反饋？
而在這一方面，to C和to B產品是有區別的：to C產品受眾多，需求確認難，上線後反饋快，相對於適合快速迭代；而to B產品受眾少，業務穩定，但使用後的反饋路徑長，反饋意願低，相對適合整體規劃。
讓我印象最深的一句話是：如果你們計劃做10個模塊，每次上線一個，那不叫快速迭代，而是屬於分期交付。所以說，於我們而言，一般是立項時做了排期，然後先做什麼再做什麼，一部分一部分分期進行，所幸我們屬於to B產品，還算是符合大的規律。
快速迭代的判定
那麼，如何判定快速迭代與否呢？
其實，快速迭代是一種產品研發理念，在這個理念支持下的產品研發是“上線-反饋-修改-上線”這樣反覆更新內容的過程。形式非常適合互聯網產品或者移動端，通過收集數據或用戶反饋迅速知道改進的結果，此種方式以極強的時效性讓產品越來越靠近用戶的需求，比如小米最初的時候。
因此，透過“上線-反饋-修改-上線”這個流程也可以看出，是否屬於快速迭代，判定點在於是否有反饋和修改這一環節。如果是做完1接著做2，這不屬於迭代，迭代一定是在原有基礎上進行了優化更新，所以我們常常說把一些小問題放在下一個版本迭代中。
快速迭代雖好，但也有一定的實施前提：一是環境，周圍環境在快速變化、產品沒有足夠的時間來進行需求分析及相關測試；二是用戶，用戶不知道自己真正想要什麼，產品需要通過迭代的方式進行試錯；三是成本，一般情況下可迭代產品的成本都很低，並且可以快速的進行版本更新。
結語
綜上可以看出，其實快速迭代更適用於C端的互聯網產品，而不太適用於B端的客戶型產品。因為B端來說產品過重，用戶有相對清晰的業務需求，不需要憑空去試錯，再加上B端的產品若是進行迭代升級，大部分時候成本都不低，對於技術的架構、代碼邏輯等都是一個考驗，靈活型標準化產品除外。
所以，敏捷開發、快速迭代這些看似洋氣的詞語一定要看是否與自己的實際情況相匹配，不能為了追趕時尚就概念先行。所謂“小步快跑，快速迭代”，只有恰當把握快速迭代的核心才能真正實現產品的優化。
一起加油，共勉！
#專欄作家#
慕斯姑娘，公眾號：產品那些年，人人都是產品經理專欄作家。關注金融科技和大數據領域，擅長產品規劃和落地。
本文原創發佈於人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議
相關推薦
