敏捷发展到今天已在软件行业得到了广泛认可，但大多数敏捷方法都是为了解决某1特定问题而总结出来的特定方法或实践，1直缺少1个可以将全部开发进程串接起来的成体系的方法。用户故事驱动的敏捷开发（User Story Driving Agile Development – UDAD）就是这样1套方法和实践，希望能够在软件开发的各个进程都提供最有效的方法让希望采取敏捷的团队能够有1个整体的方法论作为指点。

如何你对敏捷还缺少了解，可以浏览以下文档：

关于敏捷开发

UDAD中采取了以下几个已被广泛认可的方法和工具：

• 影响地图
• 用户故事地图
• 视觉引导
• Scrum
• Kanban
• 延续集成
• 探索性测试
• 自动化部署

另外，配合以上方法也提供了可以为团队和方法提供支持的工具支持，在当前的版本中所使用的是微软的Team Foundation Server作为软件全生命周期管理平台。

完全版PPT下载

1 – 重新认识软件开发进程

相对传统工业化生产中已标准化的生产制造进程，大多数人所理解的软件“生产制造”进程其实相当于制造原型车的“设计”进程。这也是为何使用管理标准化的汽车装配生产线的方法（瀑布模式）来管理1直处于设计阶段的软件开发进程是从根本上毛病的。

要让软件开发这个“创造”进程变得靠谱（可管理），我们要解决就是内容-实践-质量这3个维度上的平衡问题，而这类平衡必须是在目标不明确，多快好省的交付的条件之下。

敏捷开发的进程管理方法论都是建立在利用变化来适应变化的方法，让我们在面对“复杂”项目的时候可以提高项目成功的可能性。

2 – 甚么是用户故事

用户故事是随着敏捷被提出的1种需求管理方法，它既是1种对需求的描写方法，也是协助团队理解需求和管理后续开发进程的基点。

我们必须牢记的是用户故事不用用来写的，而是用来进行讨论，记忆和跟踪的。人类的大脑历来都不善于记忆大量复杂的信息，但是我们却可以对很多的场景记忆犹新。采取可视化的方法来讨论需求，并通过结构化的方法帮助团队成员建立对需求的统1理解才是用户故事的核心。

除协助我们进行需求的设计和计划，在开发进程中我们也要使用用户故事作为我们跟踪全部进程的线索，来组织后续的所有进程，和团队成员的写作方式，工具的使用，和终究用户的反馈。

3 – 设计与计划进程

设计进程中我们主要解决的是如何产生需求的进程，这部份内容可以参考以下文章：

用户故事驱动的敏捷开发 – 1. 计划篇

这里主要使用了2个工具：

影响地图：请参考以下这几篇文章

• 看见的气力 – (II) 影响地图
• Impact Mapping 影响地图 读书与演练心得

用户故事地图：请参考以下这几篇文章

• 用户故事地图(User Story Mapping)之初体验
• 创建用户故事地图(User Story Mapping)的8个步骤

4 – 计划进程

进入到项目的运作进程中，敏捷中成熟的Scrum和Kanban方法就是团队最好的选择，同时由于之前的计划进程建立的良好基础，后续运行Scrum和Kanban的时候就都有了很好的出发点。解决了初次接触这些进程方法的团队不知如何入手的困难。

对这1进程的详细描写可以参考：

用户故事驱动的敏捷开发 – 2. 创建backlog

关于Scrum和Kanban方法请参考：

• 解析精益产品开发 – 看板方法的5大核心实践
• Scrum Master 面试题 – 你必须知道的22个Scrum基础知识
• 这个毛病，每一个ScrumMaster都犯过

5 – 迭代开发进程

开发进程中，各种角色的交互会变得愈来愈复杂，我们需要有1个可视化的方法来让各种不同的角色清楚知道自己所做的事情与其他人的关系，这里Kanban就成了最好的方法。以上列出了TFS中的电子看板的1些主要特性，但是电子化工具与物理工具之间永久各有优势，建议团队要根据情况酌情使用。

开发进程中的coding flow是影响开发人员效力的关键进程，以上列出了1个使用feature branch结合pull request和CI的coding flow。

关于这个进程可以参考以下这篇文档：

延续交付 – 延续集成，自动化发布和自动化测试

6 – 延续交付及反馈进程

有个延续集成作为基础，我们便可继续建立发布管道。能够将利用快速稳定的进行部署是衡量1个团队DevOps实践的重要能力指标，也是大幅缩短MTTR的重要手段。同时，借助探索测试工具，我们可让用户/业务人员和开发团队紧密结合，构成快速反馈机制。

关于这1进程可以参考以下文档：

快速修复生产问题

总结

至此，UDAD就完成了1个软件开发的闭环。

请关注微信公众号 【devopshub】，获得更多关于DevOps研发运维1体化的信息

​