工具和指标

组织敏捷性离不开即兴创作，这需要人们不受约束的地使用工具和访问信息，大多数组织只向员工分享必须让他们知道的信息。然而，对于某一名员工来说，真正必须要知道的信息相对很少，对于一些非必须知道，但有可能有用的信息，员工可能会被屏蔽在外。在传统模式下，我们考虑员工日常工作需要哪些信息，并只赋予他们获取这部分信息的权限。在鼓励模式下，我们可以考虑哪些信息需要被限制访问，除了限制的信息，其他的内容全部公开给员工。只有组织与员工自由分享信息，员工才会彼此之间自由分享。如果组织相信要基于严格的要求才能分享信息，那么组织中的人自然也会对他们的同事采取相同的策略。

在一个团队中，如果不同的角色选用不同的工具来完成类似的活动，就会形成一个个“仓囱”的状况。如果在一个团队中，在工具和权限层面，员工是相互隔离的，产品分析人员不能访问CMS来查看潜在客户的信息，市场和销售团队不能访问产品待办管理工具来查看最新的功能列表和优先级，开发人员不能访问监控仪表盘来了解服务器的运行情况，那这个团队必将陷入混乱。没有访问权限会产生很多方面的阻碍，例如这样会减少我们对同事活动的了解，会因为无法自主获取信息或意识不到这些信息的存在而做出糟糕的决策。

另外，如果人们使用不同的工具进行相似的活动，他们就会围绕着工具使用形成阵营。因此在操作系统上就出现了Linux和Windows阵营，在编译器上又出现了各种不同的工具偏好。人们在特定工具上投入越多，就越有可能从这个工具及其生态系统中获得身份认同感。我们的自尊源于各种身份之间的对比，因而可能会在工具的影响下形成身份认同感的“仓囱”。据我观察，在项目管理工具的层面，用jira的人大多瞧不起用TAPD的，用TAPD的人往往也看不上用禅道的，这就是一个工具引发的价值认同。

当我们使用工具的时候，其实工具也在塑造我们，拿email和即时聊天工具举例，因为电子邮件的成本低廉，所以我们会大量的收发邮件，因为社交软件会让人成瘾，在公司内部即时聊天工具就会变成一个社交工具，电子邮件也孕育了文档泛滥的文化，轻松的将事务记录在案的功能，促使人们将邮件变成一个工作留痕的文件柜，所以最终会产生很多无意义的文档。

指标也是一种抽象的工具，利用指标来扩大管理半径，也是组织设计中经常遇到的现象，但是扩大管理半径不能保证更多的业务成果。我们可以度量很多关于软件开发的指标，但永远不能认为一组给定的指标能描述出软件开发过程中的全貌。在实践中，我们只能通过度量来获得一部分图景，但是很难根据度量去做出一些预测。软件开发是一个设计的过程，它不适用于定量的度量，也不适用于预测。

速率是一个度量团队在给定冲刺或迭代中交付功能数量的指标，它通常用于跟踪软件交付的进展，通常用燃尽图来跟踪截止至当前日期累计完成的交付量以及相对于预定目标尚完成的距离。然而，很多组织无法正确使用速率，最常见的原因是对“完成”的定义不好。理想情况下，只有当一个故事完成开发，并在功能、回归、端到端集成、跨平台、跨浏览器、跨设备能力、性能、可操作性和安全性等所有方面都通过测试后，才能把点数计入团队速率。人工对每个故事进行所有测试是不切实际的，除非有持续交付流水线的自动化协同，但是目前国内很少有团队能够达到这种水平。

因此，很多团队对“完成”的定义进行了取舍，认为只要对其进行功能测试、回归测试和集成测试并由测试人员和产品负责人签字，就可以算作完成。这种行为会损害指标的效用，因为一旦团队简单的将开发完成定义为“完成”，结果就是他们报告的速率就会毫无价值。还有另外一种糟糕的情况就是，团队将用户故事分解成任务，然后针对每个任务评估工作量点数，按照任务完成来计算速率。在敏捷开发实践中，故事是独立且有价值的，而任务不是，如果按照任务完成来计算速率，就可以看到一个版本开发完成70%，而没有任何一个故事完成开发。还有另外一个度量指标是测试覆盖率，很多宣称自己的测试覆盖率是100%，然而仔细一看，这些测试并没有断言。

不假思索地给所有度量指标设置目标，可能会适得其反，我们可以用数据来提醒自己，但是不能盲目依赖指标数据来驱动自己，改善指标体系可以从指标、目标和奖励三个方面着手。可以取消奖励措施，逐步放宽目标，让团队逐渐从被动接受目标走向更大的自主权，设计更好的指标可以遵循如下原则：

• 成果导向的指标优于职能导向的指标。
• 聚合的指标优于特定细粒度的指标。
• 适应性指标优于预测性指标。