不久前和同事交流的時候看到這樣一段話,「在經歷敏捷軟件開發方法在中國傳播和發展的過程當中,咱們深切地感到,缺乏對軟件開發平常基礎時間、尤爲是與編程緊密相關的核心技術實踐的指導,敏捷註定流於形式。缺乏完備的軟件設計、開發和質量保障相關實踐,盲目強調快速迭代、接納需求變化,項目只會陷入質量迅速腐化、Bug百出、交付失控的悲慘境地。對於這種只得其形、盡失其神、缺少核心能力、空談快速響應變化的敏捷,業內將其調侃爲中國田園式敏捷」。爲何會出現這樣的問題呢?由於你們在學習敏捷開發的時候只是作到了形式上的模仿而忽略了對於本質的理解。那麼,今天咱們就說說敏捷開發方法的核心目標是什麼,掌握了其神,咱們在項目管理中就能夠聚焦于敏捷的實質,達到事半功倍的效果。編程
目標1.更快更早的向客戶交付價值微信
咱們先來看看傳統的瀑布開發模式有什麼問題。傳統的瀑布開發模式軟件會經歷需求分析、概要設計、詳細設計、編碼、單元測試、集成測試、系統測試等階段才能發佈,這一過程少則幾個月半年,大型項目週期長達1年甚至更長,軟件的價值在所有作好以後一次性交付。如今VUCA時代(商業和外部環境充滿了易變性,不肯定性,複雜性,模糊性)等到產品或者項目正式發佈的時候,商業環境或者用戶的使用場景已經發生了很大的變化,產品或者項目的功能已經不能知足當時的需求,軟件交付的價值大打折扣。框架
不一樣於傳統的瀑布開發模式,敏捷研發模式以迭代的方式持續進行,每一個迭代持續收集用戶真實的需求以及上個迭代的反饋信息,持續的向客戶或者市場交付能夠完整運行的產品,持續的向客戶交付價值。工具
價值又來自於什麼? 應該來自真實的業務痛點以及客戶實際的需求或者問題。不論是敏捷仍是瀑布或者其它的軟件開發方法,其產生的價值取決於要解決的問題的價值,微信之因此成爲偉大的產品,由於解決了人與人溝通,人與人鏈接,分享信息的問題,百度和今日頭條解決了信息爆炸時代的信息檢索,獲取問題,一切脫離用戶業務價值的軟件研發活動,都是耍流氓。單元測試
目標2.更靈活的響應客戶和市場變化學習
在瀑布開發模式的需求分析階段,產品設計人員調研需求,設計產品功能這些設計決策活動都是基於假設或者信息並非很完備的狀況下作出的,這就意味着距離後續的技術實現、真實的用戶需求或者市場前景會有必定的差距,這種差距會致使後續技術實現、投放市場時會有不少非預期的問題出現。在敏捷開發中,決策是以持續增量的方式作出的。在每一個迭代發佈後都會收集團隊內部、客戶、市場或者競爭對手等反饋信息,應用這些信息作出更正確的決策,在下一個迭代中實現,從而能夠更靈活的響應變化。開發工具
綜上,敏捷的核心在於提升一個組織更早交付價值,更靈活響應變化的能力,敏捷的一切實踐活動都應該圍繞着這兩個目標來執行。咱們再看一個比較形象的例子,有很多朋友都喜歡看美劇,好比不少年前流行的《越獄》,18年的《權利的遊戲》,你們會發現美劇在製做發行的時候有一個特色,是一集一集的構思劇本,拍攝,發行這樣的製做流程,以後收集觀衆的反饋意見,根據你們的投票來決定後續的劇情發展,這其實就是和敏捷的思想是同樣的,儘早儘快交付價值,收回成本,根據反饋信息優化後續產品,這樣才能製做出受你們歡迎的產品。測試
那對於一個產品或者項目而言,是否應該採用敏捷研發的方式呢?筆者認爲,要根據具體的商業和競爭環境,項目特色來分析,不能一律而論。好比互聯網產品,競爭很是激烈,晚幾個月出來就沒機會了,同時技術發展,用戶需求變化很快,就很是適合敏捷。對於一些傳統行業,軟件相對比較穩定,比較大型的項目(須要頂層設計,自頂而下分解後再集成),產品的一體化程度比較高好比汽車這樣的產品就不太適合持續交付價值,就不必採用敏捷研發的模式。決策者必定要回歸到軟件的價值和本質上來思考,不能盲目跟風。優化
下面推薦一款適合各大團隊使用的敏捷開發工具CORNERSTONE,它是一款基於智能化框架,能爲企業打造專屬管理體系的項目管理與協做平臺,支持包含研發、缺陷、運營、銷售等多場景項目管理。而且提供文件共享、wiki知識庫、多功能報表、儀表視圖、彙報等多種協同輔助功能,集成了DevOps、CMDB等多種配套工具。可以幫助企業科學量化團隊表現,實時把控項目進展,全方位提高管理效能。編碼
敏捷不是銀彈,若是一個組織使用瀑布的方式作很差項目,換成敏捷或者其它方法必定也不行,相反,若是瀑布方式作的很好,換成敏捷只是水道渠成的事情,由於軟件研發本質的方法是同樣的,道理是相通的。這點拿金庸小說裏武功高手打個比方,一我的內功足夠強,他再學什麼招式,都是一個相對簡單的過程,歐陽鋒逆轉經脈,同樣能夠練成九陰真經,內功不夠,使用什麼招式都是花架子,行走江湖被人吊打。最後祝各位讀者注重敏捷的神而忘記形,勤加練習內功,早日練成本身的獨門絕技。