“满身漏洞”的Scrum（3）

虽然并不想把它列为第一项，但是实在找不到其他可以放在第一项的了。

敏捷从那句“个人与互动 高于 流程和工具”开始，人员能力就已经注定成为最核心的因素，没有之一。也直接奠定了敏捷需要高级人才的基调。

在绝大多数的情况下，这个说法是对的。敏捷本身就是“利用更复杂的系统（人员与团队）来对抗复杂系统（产品研发）”，人员能力的重要性不言而喻。这里面的能力包括硬技能与软技能两块。

硬技能不谈，所有与完成工作直接相关的、具有输出物的都属于硬技能。软技能相对而言不明显，但是对敏捷成败也至关重要。包括但不限于沟通、协作、创造力、主观能动性等各方面。

恐怕到这里你也就看出来了，人的问题一般不会是硬技能的问题（这部分可以通过流程或者工程实践来弥补），而更多是在人的软技能方面，这决定了如何配合、协调、从而达到1+1>2 的要求。

很多团队，就栽在了人的问题上。

这个本身也是人的问题，但是我还是喜欢把它单独拎出来。因为实在是太重要了。

信任这东西，是一种很奇妙的东西，它可以直接击破你所谓的理性思考，让你可以义无反顾相信一个人，甚至不惜损害自身的利益。

这在理性上是不可理解的，但是在敏捷中是一定需要的。这决定了你是否可以形成所谓的自组织团队，并与这个团队一起前进，变得更加美好。

人性本就是趋利避害，信任却告诉我们不要相信你暂时看到的，而是需要相信你的队友是为了大家都好。这是什么精神？这本质是个人性挑战问题。很难。

真的很难。

但我们依然需要想尽一切办法让团队信任我们、让团队互相信任。只有这样子，我才能相信“队友可以做的跟我一样好”，才能相信“我向队友求救，他们会救我”，才能相信“我告诉队友我的缺点，他们会帮我改进”。如果这点都做不到，就不要谈所谓的自组织团队，也不要谈所谓的透明化。成天都想着如何防着别人，这种环境下的敏捷，闻所未闻。

从客户角度来说，一次性交付一定是更好的，因为可以让客户在一瞬间拥有诸多的能力。但也许是真的太“满足客户要求”，现在的客户是被宠坏的，他们希望可以一次性获得所有他们“真正”想要的功能。一旦没有满足，立马就会对这个产品展开嘲讽、吐槽，甚至会带动新一轮的抵制活动。

这一方面是因为我们与客户的信任度没有建立起来，我们无法用刷脸的方式来让客户相信我们可以逐步的交付好的东西，另一方面也是因为客户被宠坏了，无法接受“延迟满足”这种交付方式。因此这就形成了一个怪异的反馈环，我们每次都希望一次性满足客户需求，但是每次大发布后客户都不满意，进而加强了客户对我们的不信任，然后下一次发布前，客户又给我们更苛刻的要求，而后我们会在更大的压力下搞砸，然后又一次加强了客户心中“你们不行”的认知。

1-3 恶性循环

到这个时候，如何破局就颇具意味。

一般我们会认为一次性给客户很多东西，这里面一定会有“一部分工作”客户会满意的。但殊不知这种做法，有以下几个肉眼可见的问题：

因此增量交付就成了破局的工具。从前期将客户作为开发的一部分，将过去“我为你服务”转变成“我们一起完成交付”的方式，尽早让客户参与到产品的设计、反馈工作中，并且进行持续反馈，从而做到一个“大家都满意”的产品。只有这样我们才可以更好向着对客户有价值的方向前进，降低我们研发成本的同时，也提高客户满意度。

但这里有一个破局点需要找到，那就是“如何改变客户对分批次交付”的接受度。就我们过去的经验看来，所谓客户不接受分批次交付，绝大多数是脑补出来，另一部分是真的交付出来的结果客户无法使用。对于前者，我们需要尝试的是通过沟通、展示的方式，让客户建立分步骤交付的信心；对于后者，我们能做的，就是下一节需要说的，PO 技能问题。

被我放到第二位的，是PO 技能不过关。

我一直将需求管理视作能否实现敏捷的重要因素之一。需求管理不仅仅确保了需求的全生命周期的管理，也包含了敏捷交付重要的概念——增量、迭代、适应性。

当PO 业务能力不过关，无法将业务进行原子化拆分，并统合成MMF这种概念时，基本上就注定了需求拆分的不确定性。需求过大、牵扯较多、边界不清晰，直接导致了“迭代结束无法交付可用功能”的结果，更不要说在这个基础上再通过适应性来进行迭代改良等工作。这又进一步的削弱了Scrum 可以带来的优势，最终“Scrum 毫无作用”继续喧嚣尘上。

这里至少包含了用户故事、用户故事地图、用户故事拆分、优先级排序、MMF 设计等方面，当然还必须包含专门的行业知识，否则上述所有的内容，PO 都不可能处理，毕竟这是PO 的基本要求。如果做不到这一点，PO 连如何将“相关方需求”写成“用户故事”或者其他形式都做不到，无法产生合理的Product Backlog（简称PBL），也就更不要说后续步骤了。

工程实践我放到这里，主要原因是工程实践本身是一个锦上添花的工作。

先说一句很多做工程化敏捷工作的人不太喜欢听的。工程实践做不到的最大结果就是需要投入额外的人力进行测试、bug修复，进而导致交付速度慢。抛开是否敏捷、是否Scrum 而言，这并非不能接受，只是会慢一点。有了工程化，本质是从自动化、流程化来减少重复劳动以及尽早的暴露问题，从而可以在交付的过程中提升质量与速度，交付更多。

但工程实践也有明显的问题，就是如何实施。现有各种DevOps 、CI/CD工具一定程度上可以自动化的工作，这部分并不难，甚至已经有成熟的解决方案。但越往底层去，越接近于代码层的工程实践，就会更加繁杂，比如如何编写TDD，这是所有自动化中基础的基础。而这个能力并非一朝一夕可以养成，需要长时间的训练，以及业务层面的功能拆分（参见上面PO的部分），所以见效极慢，且前期有可能产生负的生产力。而多少公司可以接受这种行为犹未可知，因此在推动这部分工作中，我们经常能看到“在高层级上，各种工具做的飞起，看似一片繁荣，但是在底层代码以及最小业务单元上，根本不能看”的冰火两重天。然后更进一步就导致满足于表层的形式，而继续忽略底层的实践，最终再次形成恶性循环。

这个原因不用说太多，弄不明白Scrum 到底是干什么的SM大有人在，尤其是某联盟将认证授权给个人后，国内神魔乱舞的情形，一度让人眼花缭乱。我见过一些认证的SM 搞不明白计划会怎么弄的，我也见过认证的SM 主动表示回顾会没用的，更不要说各种一小时站会的SM。

之所以将行政管理放到这么迟才说出来，一方面是因为这个部分我们能做的很有限，另一方面也是因为其实这种阻碍是可以跳过去的。

说我们能做的有限，你一定懂的。在大部分没有经过专业的管理训练的管理者中，对“不确定”的避讳是超出你的想象的。而敏捷却利用不确定性来争取更大的收益，这在部分管理者眼中是不能接受的，因为输出不可预期。如果相关管理者再是一个典型的风险规避型的话，在各种行政手段上给与约束也就是预期之内的了。这种行为典型代表有以下几种：

说这种阻碍是可以跳过去的，原因是在于，你可以通过自己的能力，将开发团队进行黑盒化处理，真正领导关心的，并非是你到底怎么做，而是“在表面，或者汇报方面有没有按照SOP来做”，这就给了我们一定的操作空间，可以在我们的权力天花板上形成一个真空，将管理与团队隔离开，为团队创造一个可以运行敏捷的环境。对这部分有兴趣的，可以参照我的偶像Mike Cohn 的《Succeeding with Agile》（国内译名《Scrum敏捷软件开发》相关章节。