Jim Highsmith 在敏捷澳大利亚大会的发言——给经理们的建议

Jim Highsmith ，敏捷宣言的原始作者之一，咨询师和作家，在本周的敏捷澳大利亚大会上发言，他在管理人员早餐会上针对管理人员和经理们帮助敏捷转变的途径进行了讲演，此后还举行了开场主题演讲，谈到了重新思考绩效指标的必要性，还谈到当组织采纳敏捷技术时，项目管理“铁三角”的维度需要如何修改。

他同时也宣布了他将加入 Thoughtworks ，担任 Executive 咨询师。

他在管理人员早餐会上的演讲主题是经理们和管理人员需要做什么来支持敏捷团队，并且使得敏捷转变在他们的组织里成为可能。

他指出认识和了解组织策略和方法的重要性。他列举了位于响应能力两极的两个组织——沃尔玛和谷歌。沃尔玛的竞争战略是基于效率和可预测性；而谷歌的竞争优势则来自于其迅速响应变化的能力。

当组织制定了商业敏捷度的战略目标，如谷歌，敏捷实践就需要成为企业 DNA 的一部分。他建议设立一个“首席敏捷官（Chief Agility Officer）”的角色，任务是创造和培育贯穿整个组织的敏捷文化。

他讨论了组织实现“成熟敏捷（Adult Agility）”的必要性——超越对基于规则的流程的遵循，在组织范围内推动促进响应能力、盈利能力、市场份额和客户满意度的变革。

他对比了“成熟敏捷”和他所谓的“敏捷 101（Agile 101）”——学习基础的敏捷实践和技巧，创造使敏捷成为可能的团队环境。他强调，组织需要先通过敏捷 101，不先学习和应用敏捷基础，是不可能达到成熟敏捷的。

成熟敏捷是关于把组织的目标与交付办法的选择（敏捷、Scrum、XP、精益、看板、水晶方法等）结合在一起。经理们及管理人员需要找到组织级别的杠杆手段，把产品交付方法与战略目标联系起来。

对于推动组织变革和实现战略性转变，管理层有四个主要的杠杆：

• 做更少的事情
• 质量
• 激励
• 交付价值的速度

做更少的事情

他提到自己正在进行的关于“多任务对工作吞吐量的影响”的研究：如果一个工程师同时工作在五个不同的项目枝上，并且需要为其中一个项目完成一项两周（80 小时）的任务，那么，这项工作将延误 48 周才能完成。经理们需要抵制“允许多任务”的冲动，并且帮助他们的团队关注于做更少的事情以及变得更有效率。

做更少的事情同样也与消除不必要的功能有关——他引用了 Standish Group 的研究，该研究发现软件产品 64% 的特性是很少或者从未使用过，一份美国国防部（DOD）针对 $350 亿美元项目的研究表明：编写的代码只有 2% 被使用到了，而另一份报告也指出在 400 个商业产品之中，只有少于 5% 的代码被用到了。

做更少的事情对于使得工作流动起来、保持未完工工作的可控以及容许团队变得富于生产率和富于效率非常重要。

质量

“质量对于从软件产品处获得长期的价值是最重要的因素”

他引述了他和 Michael Mah 在加拿大的一家科学仪器公司所进行的一项调查结果。通过检视敏捷转变前后的六个项目，他们发现了以下的区别：

此前指标 当前指标 改进百分比 项目成本 $280 万美元 $110 万美元 -$170 万（-61％） 项目日程安排 18 个月 13.5 个月 -4.5 个月（-24％） 累计缺陷 2270 381 -1889（-83％） 人员数目 18 11 -7（-39％）他又引述了另一项研究，缺陷水平降低 11% 会导致上市时间（time-to-market）改善了 58%。

这些改善是由于缺陷减少所带来的。

他热衷于集中精力研究质量对项目结果（缺陷水平的降低导致更快的交付价值的速度）的影响。

他讨论了质量作为交付价值重要动力的两方面：可靠性（产品在多大程度上能有效和一贯地完成它应该做到的事情）和适应性（修改产品以响应变化的需求有多容易）。

他谈到技术债如何在产品达到根本难以维护的地步以前，在短时间内增加。在产品的生命周期里，不尽早地、持续地解决技术债将迅速导致产品的功能遭到破坏，产品不能以有效的成本去维护和修改，以满足不断变化的业务需求。

他指出，敏捷经理最重要的职责之一就是监控产品技术债的状况，并且实行政策和方法，阻止和减少技术债的出现程度。

激励

激励是内在的、非外在的——传统的激励方法在敏捷的环境中不奏效。他讨论了正确激励因素的重要性，并提到 Daniel Pink 的著作《驱动力（Drive）》。在书中，Daniel 明确指出三个因素会导致更好的绩效和个人满意度：

• 自治
• 精通
• 目的

Highsmith 把卓有成效的敏捷团队的工作方式与这些激励因素对应起来——

• 自组织团队展示和促进自治
• 对做好质量工作的关注促进了精通
• 拥有一个清晰定义的项目愿景，并将其关联到更高目标，这为工作提供了目的

敏捷经理们需要创建项目和团队环境，使得这些激励因素能够脱颖而出，并且改进团队绩效。

交付价值的速度

交付价值的速度是组织快速将产品上市的能力。对于一个敏捷团队，构建了一个可以在每两周的迭代之后就能够部署的产品，却要等待为期 6 个月的 DevOps【译注 1】部署流程，这实在谈不上尽善尽美。端到端的组织流程需要变得更加敏捷，才能使针对载有业务价值的系统的快速部署和集成成为可能。

他谈到了业务响应能力的三个层次:

• 持续开发——敏捷团队一般都掌握了这一能力，迭代和增量开发方法允许频繁地交付软件产品
• 持续集成——许多组织都面临着持续集成早已解决的技术挑战，并正在拥抱全面的测试自动化（60000 个测试，而不是 60！）
• 持续部署——前沿组织能够通过“单击”将系统直接部署到生产环境，并向商业需求提供几乎即时的响应

他谈到，管理者需要停止“实做敏捷（doing Agile）”，开始“融入敏捷（being Agile）”——自顶向下地在组织里面拥抱敏捷哲学和方法，管理成为变革的一部分，并且向他们的客户和利益相关者交付价值。

他说，有效的敏捷经理们清楚平衡的必要性，帮助团队克服（找出适当的平衡以处理含糊、不确定性和风险）挑战，找到可预测性和适应性之间的平衡。

卓有成效的敏捷经理们做出明确的决定，他们促进和授权自组织的团队，并提供团队必须适应的约束。

如何才能成为一位卓有成效的敏捷经理，他们如何使得他们的组织“与敏捷融为一体（be Agile）”？

译注 1：DevOps，指开发、运营和 QA 等部门之间沟通、协作和集成等的繁琐流程，详见 http://en.wikipedia.org/wiki/DevOps

查看英文原文： Jim Highsmith at Agile Australia - advice for managers