UDAD 用戶故事驅(qū)動(dòng)的敏捷開發(fā) – 演講實(shí)錄

敏捷發(fā)展到今天已在軟件行業(yè)得到了廣泛認(rèn)可，但大多數(shù)敏捷方法都是為了解決某1特定問題而總結(jié)出來的特定方法或?qū)嵺`，1直缺少1個(gè)可以將全部開發(fā)進(jìn)程串接起來的成體系的方法。用戶故事驅(qū)動(dòng)的敏捷開發(fā)（User Story Driving Agile Development – UDAD）就是這樣1套方法和實(shí)踐，希望能夠在軟件開發(fā)的各個(gè)進(jìn)程都提供最有效的方法讓希望采取敏捷的團(tuán)隊(duì)能夠有1個(gè)整體的方法論作為指點(diǎn)。

如何你對(duì)敏捷還缺少了解，可以瀏覽以下文檔：

關(guān)于敏捷開發(fā)

UDAD中采取了以下幾個(gè)已被廣泛認(rèn)可的方法和工具：

• 影響地圖
• 用戶故事地圖
• 視覺引導(dǎo)
• Scrum
• Kanban
• 延續(xù)集成
• 探索性測(cè)試
• 自動(dòng)化部署

另外，配合以上方法也提供了可以為團(tuán)隊(duì)和方法提供支持的工具支持，在當(dāng)前的版本中所使用的是微軟的Team Foundation Server作為軟件全生命周期管理平臺(tái)。

完全版PPT下載

1 – 重新認(rèn)識(shí)軟件開發(fā)進(jìn)程

相對(duì)傳統(tǒng)工業(yè)化生產(chǎn)中已標(biāo)準(zhǔn)化的生產(chǎn)制造進(jìn)程，大多數(shù)人所理解的軟件“生產(chǎn)制造”進(jìn)程其實(shí)相當(dāng)于制造原型車的“設(shè)計(jì)”進(jìn)程。這也是為何使用管理標(biāo)準(zhǔn)化的汽車裝配生產(chǎn)線的方法（瀑布模式）來管理1直處于設(shè)計(jì)階段的軟件開發(fā)進(jìn)程是從根本上毛病的。

要讓軟件開發(fā)這個(gè)“創(chuàng)造”進(jìn)程變得靠譜（可管理），我們要解決就是內(nèi)容-實(shí)踐-質(zhì)量這3個(gè)維度上的平衡問題，而這類平衡必須是在目標(biāo)不明確，多快好省的交付的條件之下。

敏捷開發(fā)的進(jìn)程管理方法論都是建立在利用變化來適應(yīng)變化的方法，讓我們?cè)诿鎸?duì)“復(fù)雜”項(xiàng)目的時(shí)候可以提高項(xiàng)目成功的可能性。

2 – 甚么是用戶故事

用戶故事是隨著敏捷被提出的1種需求管理方法，它既是1種對(duì)需求的描寫方法，也是協(xié)助團(tuán)隊(duì)理解需求和管理后續(xù)開發(fā)進(jìn)程的基點(diǎn)。

我們必須牢記的是用戶故事不用用來寫的，而是用來進(jìn)行討論，記憶和跟蹤的。人類的大腦歷來都不善于記憶大量復(fù)雜的信息，但是我們卻可以對(duì)很多的場(chǎng)景記憶猶新。采取可視化的方法來討論需求，并通過結(jié)構(gòu)化的方法幫助團(tuán)隊(duì)成員建立對(duì)需求的統(tǒng)1理解才是用戶故事的核心。

除協(xié)助我們進(jìn)行需求的設(shè)計(jì)和計(jì)劃，在開發(fā)進(jìn)程中我們也要使用用戶故事作為我們跟蹤全部進(jìn)程的線索，來組織后續(xù)的所有進(jìn)程，和團(tuán)隊(duì)成員的寫作方式，工具的使用，和終究用戶的反饋。

3 – 設(shè)計(jì)與計(jì)劃進(jìn)程

設(shè)計(jì)進(jìn)程中我們主要解決的是如何產(chǎn)生需求的進(jìn)程，這部份內(nèi)容可以參考以下文章：

用戶故事驅(qū)動(dòng)的敏捷開發(fā) – 1. 計(jì)劃篇

這里主要使用了2個(gè)工具：

影響地圖：請(qǐng)參考以下這幾篇文章

• 看見的氣力 – (II) 影響地圖
• Impact Mapping 影響地圖 讀書與演練心得

用戶故事地圖：請(qǐng)參考以下這幾篇文章

• 用戶故事地圖(User Story Mapping)之初體驗(yàn)
• 創(chuàng)建用戶故事地圖(User Story Mapping)的8個(gè)步驟

4 – 計(jì)劃進(jìn)程

進(jìn)入到項(xiàng)目的運(yùn)作進(jìn)程中，敏捷中成熟的Scrum和Kanban方法就是團(tuán)隊(duì)最好的選擇，同時(shí)由于之前的計(jì)劃進(jìn)程建立的良好基礎(chǔ)，后續(xù)運(yùn)行Scrum和Kanban的時(shí)候就都有了很好的出發(fā)點(diǎn)。解決了初次接觸這些進(jìn)程方法的團(tuán)隊(duì)不知如何入手的困難。

對(duì)這1進(jìn)程的詳細(xì)描寫可以參考：

用戶故事驅(qū)動(dòng)的敏捷開發(fā) – 2. 創(chuàng)建backlog

關(guān)于Scrum和Kanban方法請(qǐng)參考：

• 解析精益產(chǎn)品開發(fā) – 看板方法的5大核心實(shí)踐
• Scrum Master 面試題 – 你必須知道的22個(gè)Scrum基礎(chǔ)知識(shí)
• 這個(gè)毛病，每一個(gè)ScrumMaster都犯過

5 – 迭代開發(fā)進(jìn)程

開發(fā)進(jìn)程中，各種角色的交互會(huì)變得愈來愈復(fù)雜，我們需要有1個(gè)可視化的方法來讓各種不同的角色清楚知道自己所做的事情與其他人的關(guān)系，這里Kanban就成了最好的方法。以上列出了TFS中的電子看板的1些主要特性，但是電子化工具與物理工具之間永久各有優(yōu)勢(shì)，建議團(tuán)隊(duì)要根據(jù)情況酌情使用。

開發(fā)進(jìn)程中的coding flow是影響開發(fā)人員效力的關(guān)鍵進(jìn)程，以上列出了1個(gè)使用feature branch結(jié)合pull request和CI的coding flow。

關(guān)于這個(gè)進(jìn)程可以參考以下這篇文檔：

延續(xù)交付 – 延續(xù)集成，自動(dòng)化發(fā)布和自動(dòng)化測(cè)試

6 – 延續(xù)交付及反饋進(jìn)程

有個(gè)延續(xù)集成作為基礎(chǔ)，我們便可繼續(xù)建立發(fā)布管道。能夠?qū)⒗每焖俜€(wěn)定的進(jìn)行部署是衡量1個(gè)團(tuán)隊(duì)DevOps實(shí)踐的重要能力指標(biāo)，也是大幅縮短MTTR的重要手段。同時(shí)，借助探索測(cè)試工具，我們可讓用戶/業(yè)務(wù)人員和開發(fā)團(tuán)隊(duì)緊密結(jié)合，構(gòu)成快速反饋機(jī)制。

關(guān)于這1進(jìn)程可以參考以下文檔：

快速修復(fù)生產(chǎn)問題

總結(jié)

至此，UDAD就完成了1個(gè)軟件開發(fā)的閉環(huán)。

請(qǐng)關(guān)注微信公眾號(hào) 【devopshub】，獲得更多關(guān)于DevOps研發(fā)運(yùn)維1體化的信息

?

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對(duì)您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈(zèng)