可预测的敏捷交付：管理挑战-InfoQ

关键点

管理者引领变革，变革反映管理者的价值体系

大型组织不能突然转变为敏捷组织，但管理层能发起敏捷变革

在组织中晋升的等级越高则预算就越重要，预算永远是重点

与其他团队类似，管理团队也有自身的弱点

事件和开发周期中的简单数据有助于团队将注意力放在发展与改进上

高层领导和管理者怎样走向敏捷？对于多数位高权重的管理者而言，敏捷开发与他们的个人经历几无关联。想想 RUP 、 ITIL 、 OO 、Java、六西格玛和 Prince ，敏捷看起来不过是又一套改进策略、又一种方法而已。这次又有一帮顾问带着精心绘制的 PPT 和美妙的承诺跑来推销敏捷了。

在我之前关于可预测的敏捷交付的系列文章中，我提到大型组织需要用周而非年来计算交付周期；需要测算交付时间以规划短期和中期计划；还需要敏捷能力以零成本改变短期目标。如今敏捷已经从早年不成熟的孤芳自赏时期发展到了后敏捷时代，“可预测的敏捷交付”对商务主管与开发项目的利益相关者都是一个现实的目标。

本文会分享一些“好，坏，惨不忍睹”的案例，这些案例来源于我过去10 年来帮助大型组织改革的经历。我会介绍一些通常行之有效的实践方法及反面例子，还会谈谈捅了什么马蜂窝时的后果。

赞扬、培养并发展组织文化

试图将Scrum 引入大型组织或者研究过各种敏捷调查结论的人都会告诉你，开发团队很容易接受敏捷方法，问题出在管理者，组织文化亦或是管理流程上。他们迟早会宣读敏捷宣言并断定组织文化“亟待变革，必须接受这些价值观和原则”。身为人父，此情此景让我想起小姑娘抬头望天，跺着脚说着“你根本不理解我，我懂的东西你不懂，你已经老糊涂了，是时候改变自己了”的场面。

年轻人的说法固然有其正确的部分，组织的确需要变革，反思自身的价值观也是一个很好的开头。但讽刺的是他们陷入了与被批评者相同的怪圈——人们看到别人做事不对劲就要求对方改变，却不理解大人的世界中改变习俗有多么困难。

这恰恰就是企业层面的敏捷转型所面对的问题。高层想让组织获得敏捷承诺的收益，所以他们自然会支持转型。但没人敢告诉他们，管理者自身也需要走过一条艰难的道路，而成果是在漫长的路上一点一滴体现出来的。管理者以为自己买到了立即见效的转型灵药，所以满怀信心地认为“我们在圣诞节前就能完全实现敏捷”。

执行主管：“敏捷需要花费多少？”

销售代表：“两年时间，3 百万经费，成功后能节约至少5 百万成本”。

执行主管：“太棒了。你去跟这位经理、这位还有那位交代下细节内容，我下个月就宣布开始改革。好了，那么还有什么需要我操心的？”

当然这里我有些夸张了，但组织的价值观确实是由上而下渗透的。

我是说，明确组织的文化，然后去拥抱它吧。任何组织都因自己的文化而与众不同。到头来，文化才是组织区别于他人的根基。所以看到这种情况也应该欣然接受：CEO 把总部搬到自己最爱的高尔夫球场旁边，用高尔夫优惠门票奖励员工，赞助球赛，乃至为产品开发像高尔夫课程一样的用户界面，招聘高尔夫资深玩家，欢庆组织全面“高尔夫化”。忘掉什么转型吧，那是童话故事里才有的事情。

预算很重要

以软件开发行业为例，有时组织上层的价值观和信念会与下层的经验和现实相冲突。拿我最近遇到的一些案例来说，以下情况中团队的效率是很难提升的：团队想要招来具备所需技能的人员时却不获批准，或者想从美国招聘一位员工时却必须从中国或印度额外招两人，或产品导向的团队却因为项目预算约束而拆分。在这些例子中，团队的效率都会下降，而且再也不能提升到敏捷本应达到的水平上了。引入新的团队成员会在一段时间里拖慢工作节奏；降低团队的平均技能水平会削弱团队能力并拖累优秀成员；限制个体能做的事情则会带来许多成为瓶颈甚至风险的单知识点（single point of knowledge）。

讽刺的是，IT 高管想要提升团队效率，但预算部门却会有意无意地成为阻碍。因为和预算打交道的人看到的只是报表上的开销数字，体会不到团队、个体的节奏与他们创造的机会。指出这一现实不见得能立刻改变现状，但管理者应当意识到自己管理的团队与预算流程间存在的不协调状况。

我经历过这种情况。最近我接到要求为六个团队裁员以节省五十万美元。我看了下报表，里面有的人我认识，有的人我正在指导，有的人还没入职，还有一些我没见过。出于本能和认知偏差，我想要留下自己指导的团队与认识的员工。接着我看了下开支情况，意识到低工资国家中的三份“资源”（成本控制术语，指员工）的开销才和欧洲的一位员工的成本相当。那时为了减少一位员工的支出，我安排他在半年中用半数时间从事项目工作。我感觉自己已经过火了。第二次看报表时，我研究了所有团队与他们的职能，结果计算出来的预算需求比开始多了40 万美元！我觉得这个结果虽然超支快200 万美元，但起码是符合实际的。于是我带着结果去找了项目主管，我们一起将预算缩减到了能保证团队正常运作的水平。合作一如既往地成功，我们按照要求节省了经费从而保住了后续的预算。

有些经理喜欢用图表和数字来展示控制权，结果团队想要增加任何开支都得拿出财务上够硬的数据支撑。基础指标应该是“开发周期”，也就是在软件最终版本中进行一项改动所需要的时间，可以用工日来计算。改动一块输入区可能需要三个工日，花费1250 美元（日工资x3），平均缺陷率是10%。用这套计量方法可以评估所有的流程变化，也能算出各种事件将节省或增加的预算：在进度限制内增加工作量；让回归测试自动化；进行利益相关者分析；提前一周审核发布。这种假设驱动的方法与Ash Maurya 在 Running Lean 一书中描述的内容接近，同时也提供了风险管理和实验方法。相比全新的开发项目来说，这种方法更适合已有的产品项目。

在价值观上持开放态度

之前我参加的一个研讨会上有人提到了很有用的观点，说的是高级经理应该相信自己的原则和价值观，同时鼓励他们管理的部门和团队效仿此举。每个专业团队都以宣言的形式展示出自己的价值观，则团队之间就有了一组共享的价值观体系，团队间的合作也就会更加顺利。

我问过一位高级经理，从个人角度而言，在他从事的领域中软件的质量和交付哪个更为重要？那时他给出的答案是前者，并解释说他优先考虑的是建立客户对软件的信任。所以让软件没有错误地运行是更加重要的，即便为此要拖延交付也可以。我们与团队分享了这个价值观，总结为：

相比快速的交付，我们更重视软件的质量

这并不是说应该让需要软件准时交付的客户等待更久，或者不保证最优先事项得到优先处理。这句话的意思是团队应该正确衡量自己的交付速度，并且当团队被施压为软件增加更多内容时能够坚持自己的价值观并反驳：“我们也许能够做到更多，但我们优先考虑的是质量，并且已经在全力为已有的任务努力了”。

在一次研讨会上，一个深受多说少做困扰的团队总结出来的价值观是：

我们重视行动而非空谈

类似地，这也并不意味着团队不制定任何计划，或者不设定任何共同目标。这句话是说团队应该更好地平衡制定计划与实际行动花费的时间。

这些简单而清晰的价值观声明对任务的负责人大有助益，可以帮助他们在团队内部或更高层级上做出决策。这种分发的决策制定流程正是大规模敏捷的关键所在，也是最难实现、最受期待的敏捷成就。没有这种流程，所有事情都要由“上面”做决策，下面的人只能空等。更糟糕的是，不在一线的决策者经常会基于低质量的信息、错误的数据和预测甚至完全的谎话而做出决定。

选出值得信任的人，让他们开始行动

另一个难题是，并不是所有高级管理者都容易信任他人。有些管理者生性多疑，这种性格也难以改变。

如果开发团队的一个成员屡次抗拒 Scrum、影响团队工作或拒绝改进自己的工作，结果是毋庸置疑的：要么他自己不满而离开团队，要么团队不满而把他剔除出去。管理层也会出现这种状况，但类似的结果在某个级别以上就不会出现了。如果管理者升到很高的级别，他就需要负责管理大批员工、大规模的项目和大量的资金，所以不能轻易被上级调离职位。（会被调离的情况只有管理者自己退休，或被董事会撤职，甚至极端情况下因为贪腐而被司法部门逮捕。）

一些管理者学会了对同僚甚至自己的部门主管油嘴滑舌，而主管也可能缺乏与敏捷团队共事的经验，无法看出下属真实的想法和信心的缺失。他们的团队在人前表现一个样，但如果教练或别人与团队共处一段时间就会看到另一种面貌。这才是所有级别的管理者都该做的事情：与团队共处，有时还要成为观察者。参加团队的评审会议，突击出席一些计划制定或回顾会议，偶尔旁听每日 Scrum 会议。亲临一线，仔细倾听，甚至问一两个问题，提出一些深入看法，这些做法能让管理者准确判断团队是值得信任的，还是不具备足够能力，需要管理者暂停工作重新考虑下一步行动。

一个很好的例子来自于一个最近开始 Scrum 的团队。团队的经理也是他们的产品负责人。虽然经理与团队不在同一地点工作，但他也每天参加每日 Scrum 会议，结果发现团队承担了太多零碎的任务（工作优先级混乱），低估了正在优化的脚本的复杂度（导致太多的 WIP ），因此遭遇了瓶颈。为了解决这一问题，经理开始和团队领导为接下来的迭代重新安排工作优先级，要求团队成员根据自己掌握的信息详细描述已有的故事。他还观察到团队开始自我管理，当一位成员在 Scrum 中说他会等待别人给自己分配工作时另一位成员纠正了他的态度。经理也注意到了那些表现不佳的成员，搞清楚了他们是需要额外的支持还是应该被裁撤以节约预算。

需要注意的是，向敏捷迁移只是高级经理职责范围的一小部分，甚至在更高层面上不怎么重要。从我的经历来看，有些经理喜欢同教练共事，听取反馈并讨论管理团队的进展。还有些经理习惯于传统的方法，命令下属的经理和团队实施敏捷，并坚决捍卫自己的做法。两种情况下让数据公开都是很有用的。

一家大型投资公司的 CIO 使用两个简单的 KPI 来追踪进展，一个是新增事件的数量，另一个是发布完成的数量。这些指标能通过趋势和差异很好地反映一组应用的健康度。它们能揭示项目的哪些部分（每个部分都有团队负责人）在前进，哪些则在原地踏步。在团队内部，一个简单的白板可以展示端到端进程与进程完成的事项比例，它能自然地帮助团队关注进展，揭示瓶颈所在并展示循环次数。

“用真相回应权力”——贵格教派习语

最近和一位高级商务经理打交道时我遇到了麻烦。我跟他说我们的所有计划都是在 Scrum 中做出的。一次开会快结束时他参与进来，会议内容是弥合 IT 与商务部门之间的裂痕，而他不知道我们正在从整体上讨论 Scrum。与此同时，我也不知道他过去曾每年花两个月的时间规划 IT 改进事宜，以为这些改进是同僚需要的。接下来十个月时间他又得设法把工作扳回正轨，而其他人则要努力让日常商务活动正常运转。为了显示自己的地位，他站起来说“我不管你们怎么做，我只要看到成果”。那时我应该把这当作是明确的价值观声明，并建议我的 IT 团队做出相应的反应。不过我们的确是在努力改进与商务部门的互动，所以我的回答是“但你应该关心我们的行动，这直接关系到你的饭碗”。当然了，他咆哮着要炒掉我，接下来我用了整整 72 小时来解决这个麻烦。

当然，我知道他不习惯从下属那里听到自己不想听到的观点，当 IT 部门的人这样做时他尤其生气。大多数员工对此都心知肚明，所以不曾招惹过他，从而免于被炒鱿鱼的风险。通常来说，经理听到的都是自己想听到的东西，正因为这些信息是他们喜欢的，他们很难去质疑信息本身。他们不会深入挖掘是否有可靠的数据佐证这些信息，也不会亲自下场看看团队正在做什么。事后一想，我要表达的观点就是商务部门应该非常关注我们 IT 部门在开发什么东西（what）。下次发生同样的事情，我还会坚持优先谈论商务部门的角色，这是为了产品本身着想。我甚至可能会赞同他的一种观点，也就是商务部门不需要关心 IT 部门的实现方法（how）。

总结

对于拥有数以千计雇员的组织来说，敏捷是一项意义深远的挑战。这类组织发展出了一套防御机制，以风险管理机制的形式阻碍了变革，使之缓慢而艰难。管理者与高级经理是变革的发起人，所以必须准备好进行一些个人方面的改变。相比改变组织文化，管理者应该明确自身的价值观，赞扬自己所在组织的文化。我们正身处变革的浪潮中，机械的商业模式正在让位于目的驱动的商业模式。高级经理应该意识到软件开发工作为职场带来了新的秩序，经理现在是驱动者，而团队是创意和高价值的脑力成果的输出者。信任依旧重要，它是建立在开放与沟通的基础之上的。

关于作者

Russ Lewis（@ConsultStorm）为一些全球最大的组织担任教练，指导组织实现可预测的敏捷交付。他是一位具备大局观的技术导向管理培训师，现在致力于帮助团队经理和成员走向成功。他的方法是深入所有层级并促进沟通交流以实现进步。Russ 构建并主导了伦敦交通网非接触支付系统的建设，并将 Oyster 卡扩展到了英国铁路系统中；他还帮助 Amadeus SAS 实现了敏捷转型，现在则在帮助一家投资银行运营一个全球 DevOps 项目，同时在许多论坛进行演讲。