UDAD 用戶故事驅動的敏捷開發 – 演講實錄

時間 2019-11-20

標籤 udad 用戶故事驅動敏捷開發演講實錄简体版

原文原文鏈接

敏捷發展到今天已經在軟件行業獲得了普遍承認，但大多數敏捷方法都是爲了解決某一特定問題而總結出來的特定方法或實踐，一直缺少一個能夠將整個開發過程串接起來的成體系的方法。用戶故事驅動的敏捷開發（User Story Driving Agile Development – UDAD）就是這樣一套方法和實踐，但願可以在軟件開發的各個過程都提供最有效的方法讓但願採用敏捷的團隊可以有一個總體的方法論做爲指導。html

如何你對敏捷還缺少了解，能夠閱讀如下文檔：面試

關於敏捷開發微信

UDAD中採用瞭如下幾個已經被普遍承認的方法和工具：app

影響地圖
用戶故事地圖
視覺引導
Scrum
Kanban
持續集成
探索性測試
自動化部署

另外，配合以上方法也提供了能夠爲團隊和方法提供支撐的工具支持，在當前的版本中所使用的是微軟的Team Foundation Server做爲軟件全生命週期管理平臺。運維

完整版PPT下載ide

1 – 從新認識軟件開發過程

相對於傳統工業化生產中已經標準化的生產製造過程，大多數人所理解的軟件「生產製造」過程其實至關於製造原型車的「設計」過程。這也是爲何使用管理標準化的汽車裝配生產線的方法（瀑布模式）來管理一直處於設計階段的軟件開發過程是從根本上錯誤的。工具

要讓軟件開發這個「創造」過程變得靠譜（可管理），咱們要解決就是內容-實踐-質量這3個維度上的平衡問題，而這種平衡必須是在目標不明確，多快好省的交付的前提之下。測試

敏捷開發的過程管理方法論都是創建在利用變化來適應變化的方法，讓咱們在面對「複雜」項目的時候能夠提升項目成功的可能性。設計

2 – 什麼是用戶故事

用戶故事是隨着敏捷被提出的一種需求管理方法，它既是一種對需求的描述方法，也是協助團隊理解需求和管理後續開發過程的基點。code

咱們必須牢記的是用戶故事不用用來寫的，而是用來進行討論，記憶和跟蹤的。人類的大腦歷來都不擅長記憶大量繁雜的信息，可是咱們卻能夠對不少的場景記憶猶新。採用可視化的方法來討論需求，並經過結構化的方法幫助團隊成員創建對需求的統一理解纔是用戶故事的核心。

除了協助咱們進行需求的設計和規劃，在開發過程當中咱們也要使用用戶故事做爲咱們跟蹤整個過程的線索，來組織後續的全部過程，以及團隊成員的寫做方式，工具的使用，以及最終用戶的反饋。

3 – 設計與規劃過程

設計過程當中咱們主要解決的是如何產生需求的過程，這部份內容能夠參考如下文章：

用戶故事驅動的敏捷開發 – 1. 規劃篇

這裏主要使用了2個工具：

影響地圖：請參考如下這幾篇文章

用戶故事地圖：請參考如下這幾篇文章

4 – 計劃過程

進入到項目的運做過程當中，敏捷中成熟的Scrum和Kanban方法就是團隊最好的選擇，同時因爲以前的規劃過程創建的良好基礎，後續運行Scrum和Kanban的時候就都有了很好的起點。解決了初次接觸這些過程方法的團隊不知如何入手的難題。

對這一過程的詳細描述能夠參考：

用戶故事驅動的敏捷開發 – 2. 建立backlog

關於Scrum和Kanban方法請參考：

5 – 迭代開發過程

開發過程當中，各類角色的交互會變得愈來愈複雜，咱們須要有一個可視化的方法來讓各類不一樣的角色清楚知道本身所作的事情與其餘人的關係，這裏Kanban就成了最好的方法。以上列出了TFS中的電子看板的一些主要特性，可是電子化工具與物理工具之間永遠各有優點，建議團隊要根據狀況酌情使用。

開發過程當中的coding flow是影響開發人員效率的關鍵過程，以上列出了一個使用feature branch結合pull request和CI的coding flow。

關於這個過程能夠參考如下這篇文檔：

持續交付 – 持續集成，自動化發佈和自動化測試

6 – 持續交付及反饋過程

有個持續集成做爲基礎，咱們就可繼續創建發佈管道。可以將應用快速穩定的進行部署是衡量一個團隊DevOps實踐的重要能力指標，也是大幅縮短MTTR的重要手段。同時，藉助探索測試工具，咱們可讓用戶/業務人員和開發團隊緊密結合，造成快速反饋機制。

關於這一過程能夠參考如下文檔：

快速修復生產問題

總結

至此，UDAD就完成了一個軟件開發的閉環。

請關注微信公衆號【devopshub】，獲取更多關於DevOps研發運維一體化的信息

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。