1.3对流的关注

1.3对流的关注

价值增加的思维方式的中心思想是对于流的强调。流有2个不同的含义，这两者对于软件项目的计划都是重要的。

首先，流是人类熟练操作的体验，正如米哈伊·柴科金特米哈伊的《Flow: The Psychology of Optimal Experience》（流：最佳体验的心理学）一书中所述：

我们已经了解了人们如何描述最佳体验的共同特征：一个人的技能足以应付手头的挑战的感觉，其所采用的动作系统是目标引导的、遵守规则的，并且能够提供一个清楚的线索来描述一个人的绩效如何。专心度很高，就没有留一点注意力去考虑无关的事情或担心什么问题。自我意识消失了，时间的感觉也变得扭曲。产生这种体验的活动是如此令人愉悦，以至于人们愿意为了活动本身的原因去做它，而根本不考虑能够从中得到什么，即便这一活动是困难的或者是危险的，也是一样。

流的这种含义被极限编程(XP)和其他关注个人能力的实践的拥趸们所极力赞扬。

流的第二个意义是顾客价值作为系统交付物的首要度量。David J Anderson在《Agile Management for Software Engineering》一书中总结了这一观点：

流意味着一种通过系统而稳定移动的价值。具有客户价值的功能在各个转换阶段有规律地移动着，稳定地得到产出，即要交付的工作代码。

按照这种思想，你并不把度量所计划的任务的完成情况作为进度的首要指示器；而是计数所交付的价值的单位。你采用交付价值的产量和价值数量的完成阶段来评定进度，它们也是用于计划和度量的指示器。

相应地，价值流的方法迫使你去理解那些限制了流的约束。对于这一从头到尾的流的调优方法是：标识最严重的瓶颈或最低效的过程，修复它，然后转去处理下一个最严重的问题。Anderson的解释是：

开发经理必须保证价值流在系统中通过各转换过程。他要负责来自系统的产品输出率和通过系统处理一个创意所花的时间。为了理解如何提高生产率和减少交货延迟，开发经理需要理解系统是如何工作的，要有能力标识出约束，以及做出保护、使用、服从和提升系统过程的适当决策。

对于计划和项目管理的基于流的方法要求保持中间的在制品(work in process)的最小化，如图1_3所示。这减轻了较迟发现问题的风险和所需返工引起的意外泡沫。

 



图1-3以日报为基础的方案完成情况的度量流显示了进度的节奏，并且那些能被处理的瓶颈一旦出现，就能很快被识别出来。

图1-3显示了对于流的持续度量如何在瓶颈的形成过程中揭示出瓶颈。此次迭代所计划的工作在开发方面（将状态由活动转为已解决）进展得很好，但是在测试方面（将状态由已解决转为关闭）却日益陷入停滞。这种积累导致了中间那块在制品区域中的凸起。如果仅跟踪开发（活动状态的工作项的减少），你可以根据预期结束日期来预计工作何时完成；但是因为这个瓶颈的存在，你能够看到关闭状态的三角形的倾斜度不够陡峭，不能按时完成工作。这促使你对瓶颈进行研究，以确定问题是源于不充分的测试资源还是源于低质量的开发工作。

1.3.1与工作消减的对比

工作消减的思维方式的象征就是被广泛讲授的项目管理的“铁三角”视图。在这种认识中，项目经理可以运作的只有3个变量：时间、资源（其中最重要的是人员）和功能。如果你承认质量是第4个维度（正如现在很多人所做的），那么就得到了一个四面体，如图1-4所示。

 



图1-4“铁三角”（或者四面体）把项目看作一个固定库存的工作，这是经典的工作消减的词汇。要想伸展四面体的一面的话，你需要同时伸展其他的面

在《Rapid Development》一书中，Steve McConnell对铁三角做了如下的概括：

为了保持三角关系的平衡，你必须平衡进度、成本和产品的关系。如果想要加大三角的产品角，你必须还要加大成本或进度或者成本和进度。对于其他的组合，情形是一样的。如果想要更改三角关系中的任一个角，你必须更改至少一个其他的角，这样才能保持它的平衡。

根据这种观点，项目经理有一个资源和时间的初始库存。任何对于功能或质量的变更，都要求在时间或资源方面有相应的增加。你不能伸展一面而不伸展其他面，因为它们是彼此相连的。

这种思维方式虽然已广泛地运用到实践中，但并不能很好地工作。正如牛顿物理学在现在看来只是个特定情况，铁三角也只是一个特定情况，它假设了过程的流动首先是平滑的。换句话说，它假设了资源的生产力分布得非常均匀，以致于在任务完成的效率方面偏差很小，并且整个系统始终都没有多余的生产能力。这种情况有时也存在，特别是对于低风险的项目。不幸的是，对于通常所要着手的项目来说，并不具备这样的条件。

很多敏捷方法的使用者都有一些愉快的经历，这些经历是对这一观点的否定。例如，在很多情况下，如果你改进了服务质量，比如可靠性，就能够缩短时间。在现有的资源和时间的条件下，也可能显著地改进流。

1.3.2透明度

大多数的软件项目都延迟了，在执行和发现上它们都延迟了，这并不是个秘密。这一现象有很多后果，本书的每一章都将会对此进行讨论。其后果之一就是团体迷思（groupthink） 和否认的恶性循环，它破坏了有效流。延迟交付导致需要重计划，这又会导致压力，这一压力迫使在重计划时做出更乐观的估计，当然这又会导致交付进一步延迟，这样就循环下去。在这些项目中，大多数参与者都是乐观地计划、重计划、再重计划，而效果的可见性却很少。当然，通常的结果就是一条死亡之路。

这不是因为人们不能计划或管理他们的时间。更普遍的问题是不同团队成员之间的期望和优先级是不一致的。大多数软件工程的方法有很多地方都在对工作进行跟踪，包括电子表格、Microsoft Project计划、需求数据库、缺陷数据库、测试管理系统、优先分配会议记录等等。当信息以这样的方式散布在各处时，为了得到项目的总体情况，你需要在很多个数据源中寻找，这是相当困难的，同样困难的是还要将所有信息平衡到一个进度表中。同时，因为存在这么多的数据源，当你找到信息时，它往往也都过时了。

事情并不一定是这样。一些社区项目把他们的开发进度贴在网上，这种做法有效地帮助了每个贡献者在其社区同行中间建立起对于其任务的期望。让项目中的所有工作都可见，这能够建立起一个良性循环。当然，这要假定项目的结构是迭代的，假定进度安排和估计都是在正确的粒度上做出的，并且优先分配对于在一个迭代中保持工作项的优先级和可用资源的协调是很高效的。

SCRUM是敏捷过程的一种，它所支持的是一种透明可视的产品待处理队列（backlog）的创意，如图1-5所示。这里是SCRUM的创始人Ken Schwaber和Mike Beedle对于产品待处理队列的定义：

产品待处理队列是由需要开发到系统当中的业务和技术功能所组成的进化的和有优先级的队列。产品待处理队列代表了产品或过程中所有让人感兴趣的东西，它们被认为是产品中的必需部分或一个好创意。它是一个列表，包括了所有的特性、功能、技术、增强和缺陷修复等，它们组成了在未来的发布中将被建造到产品中的变更。任何代表了需要在产品上做到的工作的东西都被包括在产品待处理队列中。

  

图1-5 SCRUM方法的中心图是对管理意义上的流的非常好的图示。不要惊讶，SCRUM是把一个产品待处理队列的概念作为管理技术的先驱

透明性非常有效，这有几个原因。它创造了“账簿的单一集合”，或者换句话说，一个唯一的、可维护的关于已完成工作和剩余工作的信息源；结合图1-3所示的流度量，它创造了团队中的信任，因为每个人看到的都是同样的数据和计划；最后，它创造了团队职责与个人问责之间的良性循环。毕竟，当一个人确切地知道谁在期待着一项工作的完成时，他就最有可能完成这项工作。