不久前和同事交流的時候看到這樣一段話，「在經歷敏捷軟體開發方法在中國傳播和發展的過程中，我們深切地感到，缺少對軟體開發日常基礎時間、尤其是與程式設計緊密相關的核心技術實踐的指導，敏捷注定流於形式。缺少完備的軟體設計、開發和質量保障相關實踐，盲目強調快速迭代、接納需求變化，專案只會陷入質量迅速腐化、bug百出、交付失控的悲慘境地。對於這種只得其形、盡失其神、缺乏核心能力、空談快速響應變化的敏捷，業內將其調侃為中國田園式敏捷」。為什麼會出現這樣的問題呢?因為大家在學習敏捷開發的時候只是做到了形式上的模仿而忽略了對於本質的理解。那麼，今天我們就說說敏捷開發方法的核心目標是什麼，掌握了其神，我們在專案管理中就可以聚焦於敏捷的實質，達到事半功倍的效果。
目標1.更快更早的向客戶交付價值
我們先來看看傳統的瀑布開發模式有什麼問題。傳統的瀑布開發模式軟體會經歷需求分析、概要設計、詳細設計、編碼、單元測試、整合測試、系統測試等階段才能發布，這一過程少則幾個月半年，大型專案周期長達1年甚至更長，軟體的價值在全部做好之後一次**付。現在vuca時代(商業和外部環境充滿了易變性，不確定性，複雜性，模糊性)等到產品或者專案正式發布的時候，商業環境或者使用者的使用場景已經發生了很大的變化，產品或者專案的功能已經不能滿足當時的需求，軟體交付的價值大打折扣。
目標2.更靈活的響應客戶和市場變化
在瀑布開發模式的需求分析階段，產品設計人員調研需求，設計產品功能這些設計決策活動都是基於假設或者資訊並不是很完備的情況下做出的，這就意味著距離後續的技術實現、真實的使用者需求或者市場前景會有一定的差距，這種差距會導致後續技術實現、投放市場時會有很多非預期的問題出現。在敏捷開發中，決策是以持續增量的方式做出的。在每個迭代發布後都會收集團隊內部、客戶、市場或者競爭對手等反饋資訊，應用這些資訊做出更正確的決策，在下乙個迭代中實現，從而可以更靈活的響應變化。
綜上，敏捷的核心在於提高乙個組織更早交付價值，更靈活響應變化的能力，敏捷的一切實踐活動都應該圍繞著這兩個目標來執行。我們再看乙個比較形象的例子，有不少朋友都喜歡看美劇，比如很多年前流行的《越獄》，18年的《權利的遊戲》，大家會發現美劇在製作發行的時候有乙個特點，是一集一集的構思劇本，拍攝，發行這樣的製作流程，之後收集觀眾的反饋意見，根據大家的投票來決定後續的劇情發展，這其實就是和敏捷的思想是一樣的，盡早盡快交付價值，收回成本，根據反饋資訊優化後續產品，這樣才能製作出受大家歡迎的產品。
那對於乙個產品或者專案而言，是否應該採用敏捷研發的方式呢？筆者認為，要根據具體的商業和競爭環境，專案特點來分析，不能一概而論。比如網際網路產品，競爭非常激烈，晚幾個月出來就沒機會了，同時技術發展，使用者需求變化很快，就非常適合敏捷。對於一些傳統行業，軟體相對比較穩定，比較大型的專案(需要頂層設計，自頂而下分解後再整合)，產品的一體化程度比較高比如汽車這樣的產品就不太適合持續交付價值，就沒必要採用敏捷研發的模式。決策者一定要回歸到軟體的價值和本質上來思考，不能盲目跟風。
敏捷不是銀彈，如果乙個組織使用瀑布的方式做不好專案，換成敏捷或者其它方法一定也不行，相反，如果瀑布方式做的很好，換成敏捷只是水道渠成的事情，因為軟體研發本質的方法是一樣的，道理是相通的。這點拿金庸**裡武功高手打個比方，乙個人內功足夠強，他再學什麼招式，都是乙個相對簡單的過程，歐陽鋒逆轉經脈，一樣可以練成九陰真經，內功不夠，使用什麼招式都是花架子，行走江湖被人吊打。最後祝各位讀者注重敏捷的神而忘記形，勤加練習內功，早日練成自己的獨門絕技。
如何實施敏捷開發
如果嚴格按照書本上的 scrum 法則一條條地看，那麼我們隊伍現在的做法也許根本不算 scrum。不過好歹我們也被稱作 scrum 一段時間了，我的資歷比不上前面的資深開發者，只能說一些目前的一點經驗。經驗一 整個團隊必須理解 scrum 的目的和限制。如果管理團隊把 scrum 當作一種新的管理流...
如何理解敏捷開發？
敏捷開發，以使用者的需求進化為核心，採用迭代 循序漸進的方法進行軟體開發。敏捷是以人為中心的軟體開發方法，保持簡潔的 經常性測試以及及時地交付應用的功能模組。正如敏捷宣言所提到的那樣。敏捷宣言強調的敏捷軟體開發的四大宣言是 1.個體與互動高於流程和工具 2 工作軟體高於理解文件 3 客戶協作高於合同...
敏捷開發,如何蒐集故事
你怎麼收集故事？本文章告訴你如何與使用者一起工作，如何和他們溝通來發現故事 下面四個是收集故事最有效的一些方法 一 使用者訪談 1 是許多團隊使用者獲取使用者故事的預設方法，訪談成功的關鍵點是訪問正確的受訪者 2 不要只詢問 你們需要什麼 大多數使用者不太善於理解，更難以表達他們的真實需求 3 最好...