标签：
敏捷发展到今天已经在软件行业得到了广泛认可，但大多数敏捷方法都是为了解决某一特定问题而总结出来的特定方法或实践，一直缺乏一个可以将整个开发过程串接起来的成体系的方法。用户故事驱动的敏捷开发（User Story Driving Agile Development – UDAD）就是这样一套方法和实践，希望能够在软件开发的各个过程都提供最有效的方法让希望采用敏捷的团队能够有一个整体的方法论作为指导。
如何你对敏捷还缺乏了解，可以阅读以下文档：
UDAD中采用了以下几个已经被广泛认可的方法和工具：
另外，配合以上方法也提供了可以为团队和方法提供支撑的工具支持，在当前的版本中所使用的是微软的Team Foundation Server作为软件全生命周期管理平台。
相对于传统工业化生产中已经标准化的生产制造过程，大多数人所理解的软件“生产制造”过程其实相当于制造原型车的“设计”过程。这也是为什么使用管理标准化的汽车装配生产线的方法（瀑布模式）来管理一直处于设计阶段的软件开发过程是从根本上错误的。
要让软件开发这个“创造”过程变得靠谱（可管理），我们要解决就是内容-实践-质量这3个维度上的平衡问题，而这种平衡必须是在目标不明确，多快好省的交付的前提之下。
敏捷开发的过程管理方法论都是建立在利用变化来适应变化的方法，让我们在面对“复杂”项目的时候可以提高项目成功的可能性。
用户故事是随着敏捷被提出的一种需求管理方法，它既是一种对需求的描述方法，也是协助团队理解需求和管理后续开发过程的基点。
我们必须牢记的是用户故事不用用来写的，而是用来进行讨论，记忆和跟踪的。人类的大脑从来都不擅长记忆大量繁杂的信息，但是我们却可以对很多的场景记忆犹新。采用可视化的方法来讨论需求，并通过结构化的方法帮助团队成员建立对需求的统一理解才是用户故事的核心。
除了协助我们进行需求的设计和规划，在开发过程中我们也要使用用户故事作为我们跟踪整个过程的线索，来组织后续的所有过程，以及团队成员的写作方式，工具的使用，以及最终用户的反馈。
设计过程中我们主要解决的是如何产生需求的过程，这部分内容可以参考以下文章：
这里主要使用了2个工具：
影响地图：请参考以下这几篇文章
用户故事地图：请参考以下这几篇文章
进入到项目的运作过程中，敏捷中成熟的Scrum和Kanban方法就是团队最好的选择，同时由于之前的规划过程建立的良好基础，后续运行Scrum和Kanban的时候就都有了很好的起点。解决了初次接触这些过程方法的团队不知如何入手的难题。
对这一过程的详细描述可以参考：
关于Scrum和Kanban方法请参考：
开发过程中，各种角色的交互会变得越来越复杂，我们需要有一个可视化的方法来让各种不同的角色清楚知道自己所做的事情与其他人的关系，这里Kanban就成了最好的方法。以上列出了TFS中的电子看板的一些主要特性，但是电子化工具与物理工具之间永远各有优势，建议团队要根据情况酌情使用。
开发过程中的coding flow是影响开发人员效率的关键过程，以上列出了一个使用feature branch结合pull request和CI的coding flow。
关于这个过程可以参考以下这篇文档：
有个持续集成作为基础，我们就可继续建立发布管道。能够将应用快速稳定的进行部署是衡量一个团队DevOps实践的重要能力指标，也是大幅缩短MTTR的重要手段。同时，借助探索测试工具，我们可以让用户/业务人员和开发团队紧密结合，形成快速反馈机制。
关于这一过程可以参考以下文档：
至此，UDAD就完成了一个软件开发的闭环。
请关注微信公众号 【devopshub】，获取更多关于DevOps研发运维一体化的信息
?
标签：
原文地址：http://www.cnblogs.com/ups216/p/5461072.html
