敏捷發展到今天已在軟件行業得到了廣泛認可，但大多數敏捷方法都是為了解決某1特定問題而總結出來的特定方法或實踐，1直缺少1個可以將全部開發進程串接起來的成體系的方法。用戶故事驅動的敏捷開發（User Story Driving Agile Development – UDAD）就是這樣1套方法和實踐，希望能夠在軟件開發的各個進程都提供最有效的方法讓希望采取敏捷的團隊能夠有1個整體的方法論作為指點。
如何你對敏捷還缺少了解，可以瀏覽以下文檔：
關于敏捷開發
UDAD中采取了以下幾個已被廣泛認可的方法和工具：
另外，配合以上方法也提供了可以為團隊和方法提供支持的工具支持，在當前的版本中所使用的是微軟的Team Foundation Server作為軟件全生命周期管理平臺。
完全版PPT下載
相對傳統工業化生產中已標準化的生產制造進程，大多數人所理解的軟件“生產制造”進程其實相當于制造原型車的“設計”進程。這也是為何使用管理標準化的汽車裝配生產線的方法（瀑布模式）來管理1直處于設計階段的軟件開發進程是從根本上毛病的。
要讓軟件開發這個“創造”進程變得靠譜（可管理），我們要解決就是內容-實踐-質量這3個維度上的平衡問題，而這類平衡必須是在目標不明確，多快好省的交付的條件之下。
敏捷開發的進程管理方法論都是建立在利用變化來適應變化的方法，讓我們在面對“復雜”項目的時候可以提高項目成功的可能性。
用戶故事是隨著敏捷被提出的1種需求管理方法，它既是1種對需求的描寫方法，也是協助團隊理解需求和管理后續開發進程的基點。
我們必須牢記的是用戶故事不用用來寫的，而是用來進行討論，記憶和跟蹤的。人類的大腦歷來都不善于記憶大量復雜的信息，但是我們卻可以對很多的場景記憶猶新。采取可視化的方法來討論需求，并通過結構化的方法幫助團隊成員建立對需求的統1理解才是用戶故事的核心。
除協助我們進行需求的設計和計劃，在開發進程中我們也要使用用戶故事作為我們跟蹤全部進程的線索，來組織后續的所有進程，和團隊成員的寫作方式，工具的使用，和終究用戶的反饋。
設計進程中我們主要解決的是如何產生需求的進程，這部份內容可以參考以下文章：
用戶故事驅動的敏捷開發 – 1. 計劃篇
這里主要使用了2個工具：
影響地圖：請參考以下這幾篇文章
用戶故事地圖：請參考以下這幾篇文章
進入到項目的運作進程中，敏捷中成熟的Scrum和Kanban方法就是團隊最好的選擇，同時由于之前的計劃進程建立的良好基礎，后續運行Scrum和Kanban的時候就都有了很好的出發點。解決了初次接觸這些進程方法的團隊不知如何入手的困難。
對這1進程的詳細描寫可以參考：
用戶故事驅動的敏捷開發 – 2. 創建backlog
關于Scrum和Kanban方法請參考：
開發進程中，各種角色的交互會變得愈來愈復雜，我們需要有1個可視化的方法來讓各種不同的角色清楚知道自己所做的事情與其他人的關系，這里Kanban就成了最好的方法。以上列出了TFS中的電子看板的1些主要特性，但是電子化工具與物理工具之間永久各有優勢，建議團隊要根據情況酌情使用。
開發進程中的coding flow是影響開發人員效力的關鍵進程，以上列出了1個使用feature branch結合pull request和CI的coding flow。
關于這個進程可以參考以下這篇文檔：
延續交付 – 延續集成，自動化發布和自動化測試
有個延續集成作為基礎，我們便可繼續建立發布管道。能夠將利用快速穩定的進行部署是衡量1個團隊DevOps實踐的重要能力指標，也是大幅縮短MTTR的重要手段。同時，借助探索測試工具，我們可讓用戶/業務人員和開發團隊緊密結合，構成快速反饋機制。
關于這1進程可以參考以下文檔：
快速修復生產問題
至此，UDAD就完成了1個軟件開發的閉環。
請關注微信公眾號 【devopshub】，獲得更多關于DevOps研發運維1體化的信息
?
上一篇 Linux 計劃任務布控
下一篇 sql: 臨時表與表變量的區別
程序員人生，我編程，我富裕，記住wfuyu網，php教程，php學習，php手冊，CMS模版制作
聲明：本站大部分內容是作者原創，少部分收集于互聯網供大家一起學習，原版權很多不明，如有侵權請聯系本站，謝謝！
粵ICP備14040726號-1?? 2015-2020 程序員人生 版權所有
