敏捷的发展方向

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

精益

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

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

精益在软件开发中最早被提及是在 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 中文站用户讨论组中与我们的编辑和其他读者朋友交流。