敏捷開發不是口號,是時候分清快速迭代與整體規劃了
面對敏捷開發、快速迭代這些看似洋氣的詞語時,一定要看是否與自己的實際情況相匹配,不能為了追趕時尚就概念先行。
“敏捷開發”這個詞一直不過時,在很多公司,不論是老板還是項目自身人員,一提到這個詞似乎都帶有一種優越感,可能是因為這意味著節約資源,亦或是一種先進的開發模式。
何為敏捷開發
百度百科中關于“敏捷開發的原則”提到了以下幾點:
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端的產品若是進行迭代升級,大部分時候成本都不低,對于技術的架構、代碼邏輯等都是一個考驗,靈活型標準化產品除外。
所以,敏捷開發、快速迭代這些看似洋氣的詞語一定要看是否與自己的實際情況相匹配,不能為了追趕時尚就概念先行。所謂“小步快跑,快速迭代”,只有恰當把握快速迭代的核心才能真正實現產品的優化。
一起加油,共勉!
#專欄作家#
慕斯姑娘,微信號:musiguniang,公眾號:產品那些年,人人都是產品經理專欄作家。關注金融科技和大數據領域,擅長產品規劃和落地。
本文原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
B端需要更多規劃性,表示認同。不作規劃容易導致系統架構有大問題
作為一個2B的產品,目前公司開始實行的是“敏捷開發”,但是按照目前公司開發流程,只能算作是快速交付需求,因為做的是支持公司自身物流業務的產品,所有用戶故事,需求都比較明確,沒有幾乎不需要試錯,只是目前在一些報表的功能上面,用戶也不是很清楚需要什么樣的東西,。個人覺得這種快速交付需求是容易導致整體的產品架構混亂。
說的甚是,目前剛剛參與朋友公司研發,發現了這個問題,做的toB(企業內部業務管理應用),采用敏捷方式,用戶故事太離散,追求快速實現迭代,后果就是功能不成體系,嚴重缺乏整體規劃。實際過程應該是需求調研-分析設計-開發-測試-發布,在平臺總體規劃下基本是按照模塊展開開發測試,結果他們全部是離散的一個一個用戶故事方式,又追求快速迭代,目前一方面積累了大量的用戶故事,一方面開發進展緩慢,質量不高需要經常反復,我在考慮建議改變方式,根據總體需求情況按照模塊進行推進。
非常理解!加油ヾ(?°?°?)??