面對敏捷開發(fā)、快速迭代這些看似洋氣的詞語時，一定要看是否與自己的實際情況相匹配，不能為了追趕時尚就概念先行。
敏捷開發(fā)6點原則：
快速迭代
相對那種半年一次的大版本發(fā)布來說，小版本的需求、開發(fā)和測試更加簡單快速。一些公司，一年發(fā)布僅2~3個版本，發(fā)布流程緩慢，它們?nèi)圆捎?strong>瀑布開發(fā)模式，更嚴(yán)重的是對敏捷開發(fā)模式存在誤解。讓測試人員和開發(fā)者參與需求討論
需求討論以研討組的形式展開最有效率。
研討組，需要包括測試人員和開發(fā)者，這樣可以更加輕松定義可測試的需求，將需求分組并確定優(yōu)先級。 同時，該種方式也可以充分利用團(tuán)隊成員間的互補(bǔ)特性。如此確定的需求往往比開需求討論大會的形式效率更高，大家更活躍，參與感更強(qiáng)。編寫可測試的需求文檔
開始就要用“用戶故事”（User Story）的方法來編寫需求文檔。這種方法，可以讓我們將注意力放在需求上，而不是解決方法和實施技術(shù)上。過早的提及技術(shù)實施方案，會降低對需求的注意力。多溝通，盡量減少文檔
任何項目中，溝通都是一個常見的問題。好的溝通，是敏捷開發(fā)的先決條件。在圈子里面混得越久，越會強(qiáng)調(diào)良好高效的溝通的重要性。團(tuán)隊要確保日常的交流，面對面溝通比郵件強(qiáng)得多。做好產(chǎn)品原型
建議使用草圖和模型來闡明用戶界面。并不是所有人都可以理解一份復(fù)雜的文檔，但人人都會看圖。及早考慮測試
及早地考慮測試在敏捷開發(fā)中很重要。傳統(tǒng)的軟件開發(fā)，測試用例很晚才開始寫，這導(dǎo)致過晚發(fā)現(xiàn)需求中存在的問題，使得改進(jìn)成本過高。較早地開始編寫測試用例，當(dāng)需求完成時，可以接受的測試用例也基本一塊完成了。
對比上述的幾條原則，逐一自檢自身的這個小團(tuán)隊，是否符合敏捷開發(fā)？
我們大概兩周左右做一次版本發(fā)布；需求文檔和產(chǎn)品原型一應(yīng)俱全，通常在這兩份文檔具備的情況下，與測試和開發(fā)人員一起進(jìn)行需求同步，以需求為主線，進(jìn)行技術(shù)實現(xiàn)的溝通和安排。
之后，技術(shù)開始進(jìn)行框架搭建和開發(fā)準(zhǔn)備，與此同時測試人員根據(jù)需求編寫測試用例。在這個過程中，有任何問題隨時交流，面對面的日常交流比文檔傳遞更便捷，有改動的地方統(tǒng)一更新做標(biāo)記。最后就是測試、bug修復(fù)及上線。
迭代與規(guī)劃之分
我們一直在宣揚(yáng)敏捷開發(fā)快速迭代，看著一個個版本號的更新，覺得很欣慰。
可在某次聽一位嘉賓分享時，才發(fā)現(xiàn)，原來上述這樣的情況并不屬于快速迭代，老師主要講了2方面：
快速迭代和整體規(guī)劃的選擇關(guān)鍵在于：是否能提前知道用戶的準(zhǔn)確需求，以及是否能快速得到用戶反饋？
而在這一方面，to C和to B產(chǎn)品是有區(qū)別的：
to C產(chǎn)品受眾多，需求確認(rèn)難，上線后反饋快，相對于適合快速迭代；
to B產(chǎn)品受眾少，業(yè)務(wù)穩(wěn)定，但使用后的反饋路徑長，反饋意愿低，相對適合整體規(guī)劃。
讓我印象最深的一句話是：如果你們計劃做10個模塊，每次上線一個，那不叫快速迭代，而是屬于分期交付。所以說，于我們而言，一般是立項時做了排期，然后先做什么再做什么，一部分一部分分期進(jìn)行，所幸我們屬于to B產(chǎn)品，還算是符合大的規(guī)律。
快速迭代的判定
那么，如何判定快速迭代與否呢？
其實，快速迭代是一種產(chǎn)品研發(fā)理念，在這個理念支持下的產(chǎn)品研發(fā)是“上線-反饋-修改-上線”這樣反復(fù)更新內(nèi)容的過程。形式非常適合互聯(lián)網(wǎng)產(chǎn)品或者移動端，通過收集數(shù)據(jù)或用戶反饋迅速知道改進(jìn)的結(jié)果，此種方式以極強(qiáng)的時效性讓產(chǎn)品越來越靠近用戶的需求，比如小米最初的時候。
因此，透過“上線-反饋-修改-上線”這個流程也可以看出，是否屬于快速迭代，判定點在于是否有反饋和修改這一環(huán)節(jié)。如果是做完1接著做2，這不屬于迭代，迭代一定是在原有基礎(chǔ)上進(jìn)行了優(yōu)化更新，所以我們常常說把一些小問題放在下一個版本迭代中。
快速迭代雖好，但也有一定的實施前提：
一是環(huán)境，周圍環(huán)境在快速變化、產(chǎn)品沒有足夠的時間來進(jìn)行需求分析及相關(guān)測試；
二是用戶，用戶不知道自己真正想要什么，產(chǎn)品需要通過迭代的方式進(jìn)行試錯；
三是成本，一般情況下可迭代產(chǎn)品的成本都很低，并且可以快速的進(jìn)行版本更新。
結(jié)束語
綜上可以看出，其實快速迭代更適用于C端的互聯(lián)網(wǎng)產(chǎn)品，而不太適用于B端的客戶型產(chǎn)品。因為B端來說產(chǎn)品過重，用戶有相對清晰的業(yè)務(wù)需求，不需要憑空去試錯，再加上B端的產(chǎn)品若是進(jìn)行迭代升級，大部分時候成本都不低，對于技術(shù)的架構(gòu)、代碼邏輯等都是一個考驗，靈活型標(biāo)準(zhǔn)化產(chǎn)品除外。
所以，敏捷開發(fā)、快速迭代這些看似洋氣的詞語一定要看是否與自己的實際情況相匹配，不能為了追趕時尚就概念先行。所謂“小步快跑，快速迭代”，只有恰當(dāng)把握快速迭代的核心才能真正實現(xiàn)產(chǎn)品的優(yōu)化。
一起加油，共勉！
