写点什么

敏捷的发展方向

  • 2009-12-14
  • 本文字数:3904 字

    阅读完需:约 13 分钟

在过去几年里,敏捷实践增加了不少,不少人都经历和挑战了敏捷过程的方方面面。通过对敏捷过程的接触和使用,最初倡导要使用敏捷的人开始尝试提出一些不同的解决方案。这是敏捷开发的一个核心组成部分:随着时间的变化对过程精益求精。本文关注敏捷社区内的最新趋势,简要介绍了时下一些众所周知敏捷过程的替换方案。特别关注了估计,预测成果和影响的话题,还有精益生产对敏捷社区的影响。

精益

我不会介绍精益的具体细节,但我会简要介绍一下精益原则,实践和工具,以及一些本文会涉及到得相关过程和工具. 让我们先看一下"精益"在维基百科中的简要说明:

精益软件开发是精益生产的原则和做法在软件开发领域的变通应用. 其改编自丰田生产系统,一个专注于精益的亚文化正在敏捷社区内兴起。

精益在软件开发中最早被提及是在 Mary 和 Tom Poppendieck 的书中,精益软件开发,书中已经覆盖了 7 个原则和 22 个精益软件开发的工具。

下面是精益经常使用的短语名单,阅读本文你应该熟悉它们:

  • 浪费
  • 实时(JIT)
  • 工作在过程中(WIP)
  • 基于“拉”思想的系统

浪费

浪费(又名 muda),它在你的过程中消除人工成本,这些人工并没有给客户带来价值。 Mary Poppendieck 将浪费定义为:

凡是消耗时间,精力,空间,或金钱的资源而又没有给客户带来价值的事物。

将价值定义为:

那些为我们的系统买单, 使用, 支持我们系统,或从我们系统获取价值的人, 从他们的眼中看到的即为价值。

在 Mary 的文章——精益思考的原则 [ Principles of Lean Thinking(PDF)],她识别出了 7 个软件开发中的浪费,Poppendieck 在书中也提到过。这些浪费的描述与他们最初发表的略有变化,以下列出的是我在她最近的演示文稿中所看到的:

  1. 额外的功能
  2. 切换
  3. 在制品
  4. 故障需求
  5. 任务切换
  6. 延误
  7. 缺陷

(限制)在制品(WIP)

Limiting WIP 是和功能相关,这些功能已经已被初始化(完成规格说明,需求收集等)并将在系统中继续走完流程。换句话说,当你的组织第一次开始处理一个功能需求时,限制它发布之前在过程中停留的时间。

实时(JIT)

JIT 是旨在降低在制品存货,避免 / 发现过程中的瓶颈。 JIT 是经常被用来作为意味着减少在制品 WIP(如上所述)。开发清单的一个典型的例子是从需求从规格说明到开发或编码,然后进行测试。JIT 关注改善投资回报(ROI),质量和效率。一个支持 JIT 的过程 / 工具是 Kanban,我会在后文提及。

基于“拉”思想的系统

上面提到的头号浪费就是额外功能。从客户处拉取需求而不是把功能推到客户那里去,给客户一些你认为他们需要的功能(额外功能)。JIT 中已经提到,看板就是一个例子,它就是支持以拉思想为基础系统的工具。

基于迭代的过程

Scrum 极限编程(XP)是两个众所周知的敏捷过程,它们把迭代或冲刺跑作为其规划和交付技术的核心部分。关于估计,你通常会发现是在估计用户故事(XP) 或者 Backlog (Scrum)。本文我将使用用户故事来统一描述用户故事和 Backlog。用户故事通常用于估计理想天数或故事点。任务被描述成为理想的小时内完成。 Mike Cohn 在他的书:《敏捷估计与规划》( Agile Estimating and Planning ),涵盖了估计和预测所使用的不同的方法和技术。

其主要思想是有固定的 1-2 周时间用于迭代。图 1 显示了不同规模的故事积压的 3 次迭代。它还表明,该小组的平均速度是 20 点,这意味着它们每一次迭代能够提供 20 个点的故事。

知道了团队的速度,重要意义在于能够预测一个故事的完成时间,以及这个用户故事何时成为发布版本的一部分。

同等规模用户故事

敏捷团队第一次实践往往始于 Scrum 或 XP。大多数敏捷开发的书籍都会提到这样的做法。新的敏捷团队一个典型的情况可能是这样的:

第一次规划会议需要相当长的时间,有许多讨论和思考,目的是来做尽可能最好的估计。首先为每个故事,然后是任务,并在最后决定此次迭代要交付多少成果。过了一段时间(反复几次迭代之后)团队获得了更多的经验,他们几乎本能地知道单次迭代可以交付多少成果,估计故事和任务也快得多。有一些团队在这方面做到了另一个水平,他们跳过了整个估算过程。他们把用户故事分成同等规模而不是花费时间用于估计(见图 2)。它们的主要区别是,你不必估计每一个故事,但你必须调整每一个故事有一个固定的规模。

有了这些固定规模的故事,团队可以在迭代中交付一定数量的成果。他们的速度,其实就是他们交付的故事数,而不故事点数或理想天数。这大大简化了规划过程。

想想你怎样才能知道按照任务优先级,一个小组将在 3 个月的时间内能完成多少故事(或哪些故事)。利用团队速度(故事数),乘以三个月内的迭代数,你就能得到预测结果。

固定规模的故事,消除了用户花费在估计上的时间,让团队把重点放在最重要的细节上:故事的实现。

有人会说你还是在估计,因为你必须让所有的故事同样规模。怎么做才能避开估计?我觉得这里有两件事:

  1. 让每一个故事的规模都足够小
  2. 平均规模的故事是最重要的

对于第一点,非常重要的是尽可能的将故事做小,这些故事可以增加商业价值并可交付。为期两天的故事,更容易发现问题和调整其规模。比起一个更大的故事,你可能认为需要 8-10 天,但实际上需要 15 天。

对于第二点,如果一个故事的规模不是过大或者过小。通常您会时常发现一些发现异常情况,但你的速度并不十分波动。

裸规划

裸规划,由 Arlo Belshee 创造,采取了不同的方法,不仅仅是从过程中消除了估计,也消除了迭代。Arlo Belshee 问了自己一个关于估计的问题:

有没有必要用估计的方法来决定优先级,并猜出需要多长时间才能完成某项事情?

在做了业务交流之后,他发现这不是必须的,可以通过别的渠道得到同样的成果。

受到精益实践的启发,Arlo 使用了最小市场化功能队列(MMF’s)。使用这个队列的开发团队能够抓住在具有MMF 特征的工作并开始实践。一旦完成,他们再从顶部抓下一个,周而复始。像精益这样就是以“拉”思想为基础的系统。队列是由业务决定的,在顶部的任务一直保持是最重要且最有价值的。队列维护7 项任务,这个数量是人大脑能够一次性记录事情的数量,也是能够进行良好的优先级管理的数量。

他们使用历史数据来估计MMF 何时可以交付。当从队列中拉取一个MMF 或者完成了这个MMF,就会给它打上一个时间戳。 每隔3 至5 个星期,他们计算出平均的时间,给业务部门一个数据用来做规划。如果队列中的MMF 过大或者过小,估计过程所用的时间也会随之做一个调整。

看板

维基百科的描述:

看板(汉字:看板 片假名:カンバン,看/カン,意思是“视觉”。板,板/バン,意思是“卡(Card)”或“板子(board)”)。看板是和精益, 准时生产(JIT)相关的一个概念。

这个描述可能让你认为看板就是敏捷团队用来做任务管理的。这种情况并非如此。看板作为一种工具是利用白板可视化展示“事物”流转,不要和板子本身的概念混淆了。

看板是用来控制(限制)WIP 和保持工作流转。你可以使用白板可视化展示一个项目在部署之前需要经过不同阶段。通过监测工作流,可以比较容易发现拖慢过程的瓶颈所在。通常通过观察哪些部分在排队等候就可得出结果。通常会有一列数字来规定有多少个任务项可以并行。这个数字就是专门用来限制并行工作数。

我们在敏捷团队中经常看到的一个简单的“看板”会有以下列:待办事项和已完成(见图4)。

看板提供不同层次和可视化的工作流,可供组织内使用,而不仅仅是开发团队(见图5)。

你可以在看板上跟踪一个功能从概念到走完组织内流程的各个阶段融入到系统中。 Henrik Kniberg 有一个非常棒的漫画可以作为小型看板系统在这一点的进一步说明。

看板不使用迭代,但往往有规律的发布周期。例如,发布周期为两周,你会按时把可发布功能放到产品中。

然而,没有什么可以剥夺你发布已完成功能的权利,只要你的过程支持一键式部署,任何敏捷团队都应该这么做。然而,没有什么可以阻止释放后继续生产内容的权利,只要你的进程的支持,一键式部署,任何敏捷团队应该做的。关于看板,有一点需要注意:没有可以适用于每个人的完美看板系统。这是由每一个组织的不同造成的,因为各个组织有本质上的不同。

David Anderson 是敏捷社区中使用和记录在软件开发过程中使用看板人之一。我鼓励你看看他的著作和专题介绍。

Scrumban

Scrumban 由 Corey Ladas 发明。根据他丰富的 Scrum 经验,他在书中用同样的名称来表达如何在Scrum 中通过看板实践精益思想。 Scrumban 很有趣,因为它不只是解释看板,还通过对从Scrum 到看板一步一步地迁移的步骤。 Scrumban 既不是Scrum 也不是看板,但如果你一路走下去最终你就是在敏捷团队中使用看板。

结论

显然还有敏捷的其它一些方面在这里没有给出例子,但我发现这些已经讲述了一个敏捷发展方向的故事。许多小组发现了迭代可能成为一个限制因素和并开始寻求方法消除这一壁垒。有些人想改变敏捷过程的范围,不仅包括开发团队和那些与开发团队密切合作的小组,还包括该组织其它部分。还有人发现,花费在估计的时间虽然被认为是浪费但交付的软件还是能够解决问题满足业务需求。

但总的来说,我认为这表明软件业正在走向成熟。软件开发团队看到敏捷过程的价值,但他们要不断改进,希望这有助于我们获得更好地和更有效的过程以及优质的软件。软件开发仍然是一个年轻的行业, 在这个有趣的时代,我们在路上!

查看英文原文: The Current Direction of Agile


译者简介:李高任(网名“坚强 2002”),重度架构模式沉迷,关心.net 和敏捷开发的发展,安静下来喜欢听着音乐码字。他的博客内容 = 技术 + 影评 + 乐评,地址为: http://cnblogs.com/me-sa

感谢霍太稳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。

2009-12-14 02:113918

评论

发布
暂无评论
发现更多内容

嘉为蓝鲸入选《信息技术服务运维工具名录》及《IT服务工具图谱》

嘉为蓝鲸

运维 信息技术 ITSS

Python开发中自动化构建项目结构样式

华为云开发者联盟

Python 开发 华为云 华为云开发者联盟 企业号 6 月 PK 榜

一分钟学一个 Linux 命令

高端章鱼哥

Linux

共筑数字化未来 金山办公携手华为云完成文档中心和GaussDB适配

YG科技

实践讲解强化学习之梯度策略、添加基线、优势函数

华为云开发者联盟

人工智能 华为云 华为云开发者联盟 企业号 6 月 PK 榜

华为云低代码来啦,好奇心满满的开发者们快来体验!

华为云PaaS服务小智

低代码 华为云 华为开发者大会2023

数智底座必备能力之轻松驾驭新技术

用友BIP

数智底座 Pass平台

如何加强数据资产管理?专家共话分级分类实战宝典

说山水

宝兰德应用服务器软件与华为云GaussDB完成兼容互认证

YG科技

全量通过!华为云GaussDB首批完成信通院全密态数据库评测

YG科技

数字化转型与架构-规划篇|满足用户期望和用户需求说:“不”

数字随行

数字化转型

华为云能力中心开业暨项目签约活动圆满举办!

新消费日报

V8是如何执行JavaScript代码的?

快乐非自愿限量之名

Java 编程语言

“息壤”引领首个算力互联互通验证平台建设,天翼云开启算力互联网新纪元!

天翼云开发者社区

人工智能 云计算

低代码开发平台选型教程

高端章鱼哥

低代码 技术选型 可视化开发 JNPF

路径万千,华为云数据库选择珠峰北坡登顶,给世界一个更优选择

YG科技

从新手游上线看游戏数据库选型

YG科技

即时通讯系统为什么选择GaussDB(for Redis)?

YG科技

和鲸助力中国大学生计算机设计大赛国赛作品评审标准落实研讨会召开,专家平台首发布

ModelWhale

人工智能 专家 数据科学 研讨会 中国计算机设计大赛

低代码平台对程序员友好吗?

互联网工科生

低代码 可视化 JNPF

掌握Python文件操作:从基础到高阶的全方位探索

快乐非自愿限量之名

Python 教程

详解数据库中的索引和视图

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 6 月 PK 榜

inBuilder今日分享丨RPM包制作入门

inBuilder低代码平台

精选Golang高频面试题和答案汇总

王中阳Go

golang 面试八股文 go面试题 Go面试宝典

中国高校最大云上科研智算平台上线!

新云力量

智能 计算 复旦大学

Redis跳跃表是如何添加元素的?

王磊

java面试

鲸鸿动能对话汽车之家,全链路营销助力新增长

最新动态

赋能政企深度用云,华为云数据库大咖有话说

YG科技

这场世界级的攻坚考验,华为云GaussDB稳过

华为云开发者联盟

数据库 后端 华为云 华为云开发者联盟 企业号 6 月 PK 榜

敏捷的发展方向_研发效能_Jon Arild Tørresdal_InfoQ精选文章