UDAD 用户故事驱动的敏捷开发 – 演讲实录

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

如何你对敏捷还缺乏了解,可以阅读以下文档:

关于敏捷开发

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

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

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

完整版PPT下载

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

相对于传统工业化生产中已经标准化的生产制造过程,大多数人所理解的软件“生产制造”过程其实相当于制造原型车的“设计”过程。这也是为什么使用管理标准化的汽车装配生产线的方法(瀑布模式)来管理一直处于设计阶段的软件开发过程是从根本上错误的。

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

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

2 – 什么是用户故事

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

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

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

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研发运维一体化的信息

?

时间: 2024-11-10 08:32:45

UDAD 用户故事驱动的敏捷开发 – 演讲实录的相关文章

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

本系列的第一篇[用户故事驱动的敏捷开发 – 1. 规划篇]跟大家分享了如何使用用户故事来帮助团队创建需求的过程,在这一篇中,我们来看看如何使用这些用户故事和功能点形成产品backlog.产品backlog是敏捷开发中用来管理需求列表,排定优先级,形成迭代计划,组织开发/测试和交付过程的工具.可以说,产品backlog是一个敏捷团队管理开发过程的核心,所有的活动和交付物都围绕backlog来进行.一旦需求明确,我们就必须在开发过程中持续的跟踪backlog内容的实现和交付过程,确保我们的想法可以按

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

敏捷开发现在已经不是新鲜事物了,我们都从各种渠道听到过不同的团队实施敏捷的胜果,听的时候觉得很美,回到家就发现那都是别人家的团队,结合自己的情况一看就发现问题一大堆.就算是最终打算一试,也经常会不知如何开始.这就是我希望编写这份文档的原因,能够找到一个遵循的敏捷项目管理模型,虽然我们都知道没有一个放之四海而皆准的方法,但在更高的层面上我觉得这仍然是可行的.也就是说,管理模型是一致的,但是其中采用的方法可能各有不同,最终目标是唯一的:打造一支可以快速适应变化的高质量团队,并输出高质量的产品! 今天

敏捷开发的目的不是为了快速交付!

它是一种用来应付需求快速变化的软件开发方法.–          Wiki >许多IT主管或是工程师,都把敏捷开发误以为是一种快速交付的方法,就因为它比传统开发方法快一些,当然:还有它叫做「敏捷」的缘故.因此我们常常听到主管们在会议上抱怨:「不是已经在RUN敏捷开发法了吗,为什么开发速度还是那么慢呢?」. 「敏捷」二字的误导 这一篇文章的目的不在回答上面那个说来话长,必须用听诊器仔细推敲才能回答的问题,而只是想修正一下大家对「敏捷」这二个字的误解.敏捷二字其实是针对需求变化的快速反应而来,而不是

怎么用leangoo做需求管理?(用户故事地图)

用户故事是在敏捷开发中表达需求的主要方式,我们在做敏捷开发的时候都有需求池的概念,在Scrum中这个需求池就是产品backlog,需求池里面是条目化的需求,每一条通常是一个用户故事.按照Scrum的定义,产品backlog是一个基于价值强制排序的队列,团队按照价值的高低,顺序地交付需求. 在开发的过程中,团队会逐步的细化产品backlog,为了保证短平快的交付,高优先级的用户故事会被分解为较小的粒度.但是这样带来了一个问题,对于那些规模稍大一些的产品来讲,故事的数量就会很多,故事拆分后通常会有只

用户故事与敏捷开发方法笔记06

用户故事得到这么多人的肯定,是因为它自身的优势有很多:1.用户故事强调口头沟通,因为传统的通过各种文档进行表达,每个人对于文字的含义的理解都不同,所以在阅读文档的过程中可能会因为理解的不同对项目的完成造成影响:2.人人都可以理解用户故事,并且用户故事可以增强人们对各种事件的记忆:3.用户故事的大小适合做发布规划以及进行编程和测试:4.用户故事适合于迭代开发,项目过程中可以写出一部分故事然后就进行编码和测试5.用户故事鼓励延迟细节:6.用户故事支持随机应变的开发,因为用户故事注重口头交流,而且很容

《用户故事与敏捷开发》阅读笔记04

  <用户故事与敏捷开发>阅读笔记04 今天抽出了两个小时读了<用户故事与敏捷开发>的第十二.十三.十四以及十五章并写了这篇阅读笔记.第十二章标题为"故事不是什么".IEEE 830是一本关于如何编写软件需求规格的指南,最突出的特征是使用短语"系统应该.....",但作者认为以这种方式编写系统的所有需求实际是一个不可能的任务.因为用户看到正在开发的软件时总会有有效和重要的反馈循环.他们会改变之前的想法,而且每个需求的成本是不可见的,会造成分析

菜鸟Scrum敏捷实践系列(一)用户故事概念

敏捷开发对需求规划的要求是很高的,首先需求是打散的,一个大的项目需求会拆分成很多小的功能完整的需求,以便排定优先级去逐个实现,敏捷开发提升了开发效率,但是对需求规划的要求更高了,就是对产品的需求规划能力提出了更高的要求,必须有清晰的思路,很强的需求规划能力才行,这样才能保证敏捷开发可以按照既定的设想去一步一步实现产品的设计. 敏捷开发是通过“用户故事”这个东东来实现传统软件开发所说的需求的. 一.什么是用户故事? 用户故事就是定义用户所需功能的文字描述,简单说就是用户的需求.一个好的用户故事包括

Scrum敏捷实践之旅系列(一)用户故事概念

敏捷开发对需求规划的要求是很高的,首先需求是打散的,一个大的项目需求会拆分成很多小的功能完整的需求,以便排定优先级去逐个实现,敏捷开发提升了开发效率,但是对需求规划的要求更高了,就是对产品的需求规划能力提出了更高的要求,必须有清晰的思路,很强的需求规划能力才行,这样才能保证敏捷开发可以按照既定的设想去一步一步实现产品的设计. 敏捷开发是通过“用户故事”这个东东来实现传统软件开发所说的需求的. 一.什么是用户故事? 用户故事就是定义用户所需功能的文字描述,简单说就是用户的需求.一个好的用户故事包括

读《用户故事与敏捷方法》有感(五)

今天,读到了次本书的第三部分--经常讨论的话题,用户故事不是什么,用户故事的优势与不良征兆. 第一,用户故事不是软件需求规格的指南,这种需求规格指南强调的是"系统应该--",而且对于需求规格指南而言,在写下需求之前,每个需求的成本是不可见的.典型的情况是,一个或几个分析师花两三个月时间(通常更长时间)编写出冗长的需求文档.随后把文档交付给程序员.这时程序员告诉分析师(消息会被转告给用户),完成项目要24个月,而不是分析师所希望的6个月.在这种情况下,分析师在编写团队没有时间开发的四分之