敏捷是局部优化的吗?

 

据我对敏捷社区中人们扩张敏捷边界的建议的审视，我认为敏捷正逐渐进入到局部优化的危险之中。

在继续下去之前，让我先回顾一下对优化系统和局部优化系统的定义：

“优化系统是在整个系统的价值流之上对系统的优化或对浪费的消除的系统。”

“局部优化系统是在系统的部分价值流对系统的优化或对浪费的消除的系统。这有可能会导致整个系统效率降低。”

项目价值流

敏捷专注于项目价值流，这很正确，我认为没人会质疑：以敏捷的方式执行项目时项目价值流是很大化的。

那项目之外的价值呢？项目集和公司价值呢？

项目集价值流

如果我通过所听到的被最频繁提及的一致的意见来遵循敏捷，那么就会缺乏下面两种项目信息：

项目记忆 —— 关于项目是如何规划和执行的信息。

解决方案记忆 —— 关于项目的技术或功能的解决方案

如果我在便条上写用户故事，通过看板进行管理，我的回顾记录、应用程序和自动化测试用例是后面主要的文档，那我能回答一下这些问题么？

1. 我怎么才能查找之前的项目以充分利用机会？我非得先通读代码和测试，然后再通过某种方法才能决定如何充分利用机会么？
2. 我怎样才能回顾之前的项目历史，查看之前是怎样进行估算的，以帮助我这次作出很好的估算？
3. 既然我们认识到永远也没有足够的时间去创建出所有的自动化测试用例，我怎么才能知道如果一个新需求变更是否正在实现某种设计之外的功能，并将产生我无法预期的副作用呢？因为我还没有自动化测试来确保这个需求变更当前的正确性。
4. 我怎样才能确保我的解决方案能够符合多个相互没有高层认识的项目呢？
5. 如果公司雇员已经完全换血，我有足够的文档在未来十年中来维护这些应用程序么？
6. 如果部门中的现实是，在项目进行时部门中许多人都不能专注在项目上。那我怎样才能管理这样的部门呢？对于这类情况我需要很多的文档么？

从本质上说，敏捷软件开发项目是独立的项目，主要由全职成员组成，且几乎没有跨越项目的监管。这导致了对项目集价值流关注的更大的需求。

公司价值流

或许近期最麻烦的倾向之一是这样的说法：不应再进行任何估算了，因为它们必然是错误且浪费时间的。建议直接启动项目，在项目进行两三个迭代之后就可以确认速度了，据此速度给出完成项目的精确估算，并通知客户。

这一说法是从整个项目的角度来看的。每个启动的项目都需要商业案例的支持：投入X美元将获得价值Y的回报，并且这在商业上是可接受的。如果我们不再对项目进行估算，我们将会冒后面这些风险：启动错误的项目；消耗项目的投资，直到我们确定花太多钱了，或是回报的价值太小了。

如果我们真的关心公司长远的生存能力，那么宣称我们不再需要进行估算是荒谬的。这其中隐含了我的信念：用户故事点必须转换为小时数。在我与开发人员的讨论中，他们要求每个用户故事都有小时数，以确保他们走在正轨上。

虽然我喜欢拿用户故事和用户故事点数来进行估算，但如果我们不把用户故事点转换为小时数，那我们就是局部优化的。我们在把开发过程置于满足商业案例之前。不把与项目的商业案例相关的估算的上下文告诉开发人员，就相当于我们在商业案例和开发人员之间形成一个隔离层。我们会让项目迭代非常高效，但同时也可能牺牲了满足商业案例的能力。

但商业案例不正是项目存在的理由吗？

三种确保敏捷项目不是局部优化的方法

1. 对项目进行估算 —— 确保对项目进行了估算，确保估算被纳入了让项目有存在的理由的商业案例之中。这些估算必须给予它们应有的关心和关注，而不仅仅是为了让项目通过审批而估算。我对如何对敏捷项目进行估算的建议改天另行探讨。
2. 创建轻量级的解决方案架构交付物 —— 确保项目的解决方案架构的定义在高层次上进行，确保所有人都对这一解决方案有统一的认识。而后，这些交付物能用于项目监管，确保一致性并能充分利用项目集中跨项目的机会。
3. 把用户故事估算转换为小时数并对时间进行追踪 —— 将用户故事转换为小时数，与开发人员一起设定预期时长，也为业务案例提供信息以确保项目走在正规之上。追踪时间，这可能会给每个人的日常工作生活带来不便，但实际上确实对项目集和公司有很大的价值。虽然了解项目的速度可以很好地进行预测和规划，但无法让我了解下面这些：

• 何种类型的工作是我们估算不充分的或是花了比预期更长时间的？
• 何种类型的工作是我们估算良好或是只花了比预期更短时间的？
• 何种类型的工作是我们忘了估算的？
• 我们遇到的什么问题增加了我们完成任务的时间？

总结

“我们以敏捷方式运作项目，是否在牺牲企业长远目标？”我认为没人会认为敏捷不是很好的执行项目的方式。但我确实认为有时敏捷仅仅关注项目和项目内的客户的价值，这可能会导致缺乏对项目集和公司价值的关注。

在对过程进行优化时，我们要确保时刻把整个价值流铭记于心。否则，会有一堆非常成功的项目存在于许多失败的公司之中。

关于作者

Terry Bunio目前是Protegra的首席顾问。Terry从未想过成为一名项目经理。他的主要职业生涯都是在数据架构方面。随着时间的推移，Terry发现他喜欢上了帮助建立团队，增加客户信赖，促进个人成长，从事项目工作和帮助指导解决方案。这些似乎就是一些人眼中的项目管理。作为一名有实践经验的项目经理，Terry以挑战惯性思维和打破书本上理论的敏捷和现实世界的方法间的平衡而为大家所熟知。Terry致力于遵循精益原则来实现敏捷。

---