不久前和同事交流的時候看到這樣一段話，“在經歷敏捷軟體開發方法在中國傳播和發展的過程中，我們深切地感到，缺少對軟體開發日常基礎時間、尤其是與程式設計緊密相關的核心技術實踐的指導，敏捷註定流於形式。缺少完備的軟體設計、開發和質量保障相關實踐，盲目強調快速迭代、接納需求變化，專案只會陷入質量迅速腐化、Bug百出、交付失控的悲慘境地。對於這種只得其形、盡失其神、缺乏核心能力、空談快速響應變化的敏捷，業內將其調侃為中國田園式敏捷”。為什麼會出現這樣的問題呢?因為大家在學習敏捷開發的時候只是做到了形式上的模仿而忽略了對於本質的理解。那麼，今天我們就說說敏捷開發方法的核心目標是什麼，掌握了其神，我們在專案管理中就可以聚焦于敏捷的實質，達到事半功倍的效果。

目標1.更快更早的向客戶交付價值

我們先來看看傳統的瀑布開發模式有什麼問題。傳統的瀑布開發模式軟體會經歷需求分析、概要設計、詳細設計、編碼、單元測試、整合測試、系統測試等階段才能釋出，這一過程少則幾個月半年，大型專案週期長達1年甚至更長，軟體的價值在全部做好之後一次交付。現在VUCA時代(商業和外部環境充滿了易變性，不確定性，複雜性，模糊性)等到產品或者專案正式釋出的時候，商業環境或者使用者的使用場景已經發生了很大的變化，產品或者專案的功能已經不能滿足當時的需求，軟體交付的價值大打折扣。

不同於傳統的瀑布開發模式，敏捷研發模式以迭代的方式持續進行，每個迭代持續收集使用者真實的需求以及上個迭代的反饋資訊，持續的向客戶或者市場交付可以完整執行的產品，持續的向客戶交付價值。

價值又來自於什麼? 應該來自真實的業務痛點以及客戶實際的需求或者問題。不管是敏捷還是瀑布或者其它的軟體開發方法，其產生的價值取決於要解決的問題的價值，微信之所以成為偉大的產品，因為解決了人與人溝通，人與人連線，分享資訊的問題，百度和今日頭條解決了資訊爆炸時代的資訊檢索，獲取問題，一切脫離使用者業務價值的軟體研發活動，都是耍流氓。

目標2.更靈活的響應客戶和市場變化

在瀑布開發模式的需求分析階段，產品設計人員調研需求，設計產品功能這些設計決策活動都是基於假設或者資訊並不是很完備的情況下做出的，這就意味著距離後續的技術實現、真實的使用者需求或者市場前景會有一定的差距，這種差距會導致後續技術實現、投放市場時會有很多非預期的問題出現。在敏捷開發中，決策是以持續增量的方式做出的。在每個迭代釋出後都會收集團隊內部、客戶、市場或者競爭對手等反饋資訊，應用這些資訊做出更正確的決策，在下一個迭代中實現，從而可以更靈活的響應變化。

綜上，敏捷的核心在於提高一個組織更早交付價值，更靈活響應變化的能力，敏捷的一切實踐活動都應該圍繞著這兩個目標來執行。我們再看一個比較形象的例子，有不少朋友都喜歡看美劇，比如很多年前流行的《越獄》，18年的《權利的遊戲》，大家會發現美劇在製作發行的時候有一個特點，是一集一集的構思劇本，拍攝，發行這樣的製作流程，之後收集觀眾的反饋意見，根據大家的投票來決定後續的劇情發展，這其實就是和敏捷的思想是一樣的，儘早儘快交付價值，收回成本，根據反饋資訊最佳化後續產品，這樣才能製作出受大家歡迎的產品。

那對於一個產品或者專案而言，是否應該採用敏捷研發的方式呢？筆者認為，要根據具體的商業和競爭環境，專案特點來分析，不能一概而論。比如網際網路產品，競爭非常激烈，晚幾個月出來就沒機會了，同時技術發展，使用者需求變化很快，就非常適合敏捷。對於一些傳統行業，軟體相對比較穩定，比較大型的專案(需要頂層設計，自頂而下分解後再整合)，產品的一體化程度比較高比如汽車這樣的產品就不太適合持續交付價值，就沒必要採用敏捷研發的模式。決策者一定要回歸到軟體的價值和本質上來思考，不能盲目跟風。

下面推薦一款適合各大團隊使用的敏捷開發工具 CORNERSTONE，它是一款基於智慧化框架，能為企業打造專屬管理體系的專案管理與協作平臺，支援包含研發、缺陷、運營、銷售等多場景專案管理。並且提供檔案共享、wiki知識庫、多功能報表、儀表檢視、彙報等多種協同輔助功能，整合了DevOps、CMDB等多種配套工具。能夠幫助企業科學量化團隊表現，實時把控專案進展，全方位提升管理效能。

敏捷不是銀彈，如果一個組織使用瀑布的方式做不好專案，換成敏捷或者其它方法一定也不行，相反，如果瀑布方式做的很好，換成敏捷只是水道渠成的事情，因為軟體研發本質的方法是一樣的，道理是相通的。這點拿金庸小說裡武功高手打個比方，一個人內功足夠強，他再學什麼招式，都是一個相對簡單的過程，歐陽鋒逆轉經脈，一樣可以練成九陰真經，內功不夠，使用什麼招式都是花架子，行走江湖被人吊打。最後祝各位讀者注重敏捷的神而忘記形，勤加練習內功，早日練成自己的獨門絕技。

如何讓開發變得敏捷起來？

相關文章