敏捷發展到今天已經在軟體行業得到了廣泛認可，但大多數敏捷方法都是為了解決某一特定問題而總結出來的特定方法或實踐，一直缺乏一個可以將整個開發過程串接起來的成體系的方法。使用者故事驅動的敏捷開發（User Story Driving Agile Development – UDAD）就是這樣一套方法和實踐，希望能夠在軟體開發的各個過程都提供最有效的方法讓希望採用敏捷的團隊能夠有一個整體的方法論作為指導。
如何你對敏捷還缺乏瞭解，可以閱讀以下文件：
UDAD中採用了以下幾個已經被廣泛認可的方法和工具：
- 影響地圖
- 使用者故事地圖
- 視覺引導
- Scrum
- Kanban
- 持續整合
- 探索性測試
- 自動化部署
另外，配合以上方法也提供了可以為團隊和方法提供支撐的工具支援，在當前的版本中所使用的是微軟的Team Foundation Server作為軟體全生命週期管理平臺。
1 – 重新認識軟體開發過程
相對於傳統工業化生產中已經標準化的生產製造過程，大多數人所理解的軟體“生產製造”過程其實相當於製造原型車的“設計”過程。這也是為什麼使用管理標準化的汽車裝配生產線的方法（瀑布模式）來管理一直處於設計階段的軟體開發過程是從根本上錯誤的。
要讓軟體開發這個“創造”過程變得靠譜（可管理），我們要解決就是內容-實踐-質量這3個維度上的平衡問題，而這種平衡必須是在目標不明確，多快好省的交付的前提之下。
敏捷開發的過程管理方法論都是建立在利用變化來適應變化的方法，讓我們在面對“複雜”專案的時候可以提高專案成功的可能性。
2 – 什麼是使用者故事
使用者故事是隨著敏捷被提出的一種需求管理方法，它既是一種對需求的描述方法，也是協助團隊理解需求和管理後續開發過程的基點。
我們必須牢記的是使用者故事不用用來寫的，而是用來進行討論，記憶和跟蹤的。人類的大腦從來都不擅長記憶大量繁雜的資訊，但是我們卻可以對很多的場景記憶猶新。採用視覺化的方法來討論需求，並通過結構化的方法幫助團隊成員建立對需求的統一理解才是使用者故事的核心。
除了協助我們進行需求的設計和規劃，在開發過程中我們也要使用使用者故事作為我們跟蹤整個過程的線索，來組織後續的所有過程，以及團隊成員的寫作方式，工具的使用，以及終端使用者的反饋。
3 – 設計與規劃過程
設計過程中我們主要解決的是如何產生需求的過程，這部分內容可以參考以下文章：
這裡主要使用了2個工具：
影響地圖：請參考以下這幾篇文章
使用者故事地圖：請參考以下這幾篇文章
4 – 計劃過程
進入到專案的運作過程中，敏捷中成熟的Scrum和Kanban方法就是團隊最好的選擇，同時由於之前的規劃過程建立的良好基礎，後續執行Scrum和Kanban的時候就都有了很好的起點。解決了初次接觸這些過程方法的團隊不知如何入手的難題。
對這一過程的詳細描述可以參考：
關於Scrum和Kanban方法請參考：
5 – 迭代開發過程
開發過程中，各種角色的互動會變得越來越複雜，我們需要有一個視覺化的方法來讓各種不同的角色清楚知道自己所做的事情與其他人的關係，這裡Kanban就成了最好的方法。以上列出了TFS中的電子看板的一些主要特性，但是電子化工具與物理工具之間永遠各有優勢，建議團隊要根據情況酌情使用。
開發過程中的coding flow是影響開發人員效率的關鍵過程，以上列出了一個使用feature branch結合pull request和CI的coding flow。
關於這個過程可以參考以下這篇文件：
6 – 持續交付及反饋過程
有個持續整合作為基礎，我們就可繼續建立釋出管道。能夠將應用快速穩定的進行部署是衡量一個團隊DevOps實踐的重要能力指標，也是大幅縮短MTTR的重要手段。同時，藉助探索測試工具，我們可以讓使用者/業務人員和開發團隊緊密結合，形成快速反饋機制。
關於這一過程可以參考以下文件：
總結
至此，UDAD就完成了一個軟體開發的閉環。
請關注微信公眾號 【devopshub】，獲取更多關於DevOps研發運維一體化的資訊
