第3章

形神兼具

——实现敏捷的核心价值

你读完第2章后会觉得Scrum描述了一个并不复杂的开发模式，但许多企业在导入Scrum时忽略了一个重要事实：这些实践是有关联性的。也就是说，随意选择部分实践而忽略其他关联活动不会将Scrum的价值潜力真正发挥出来。

近几年来，中国实施敏捷的IT企业越来越多，我也有机会和很多“敏捷”团队有所接触，得到了一个也许有些人不以为然的结论：大部分所谓敏捷团队及企业都没有真正理解敏捷的真谛，他们在做法上有一个共同点，即只引入一些相对比较容易的实践，对一些他们认为较难实施的Scrum实践则采取了视而不见的态度。另外一个大的问题是，敏捷只在团队层面实施，而整个公司的文化、理念和敏捷格格不入，“敏捷”团队无法得到组织层面的支持，使得一些重要的敏捷原则无法落地。

形似神不似只能让敏捷团队获得有限的提升，很难把团队打造成一个高效率的团队。Jeff Sutherland对Scrum的实施现状有下列的结论：

支离破碎实施Scrum的实践现状让人不可思议！哪怕是这样，大部分宣称和旧的过程比，还是看到了提高。我们还要做很多工作让大家回归到基本Scrum要求上面来。

他同时观察到，支离破碎的Scrum带来的效率提升在35%左右，而完整的Scrum有可能带来300%～400%的提升，可惜这样做的组织太少。

在Scrum的架构下，如何实施工程活动是所有团队面临的一个问题。Scrum中超短的迭代及部署上线周期给开发团队带来了极大的挑战，按部就班的传统开发方法不可能满足质量及进度的要求。增量开发下的架构设计、代码优化如何做变得格外重要，团队必须将代码库不断扩张带来的技术风险降到最低。我们需要引入能将技术变更、代码库增加的成本降下来的工程实践。极限编程是一个很好的选择，它能有效地支持Scrum的执行，让团队真正实现敏捷价值。在3.4节，我会探讨极限编程的价值观、原则及实践，并讨论如何将其和Scrum自然结合。在第6章，我会深入探讨一些能够有效支持Scrum架构的优秀工程实践，包括极限编程的一些有价值的实践。

3.1　形似神不似的Scrum实施

形似神不似的Scrum有一个特点，那就是把在本组织难以实施的敏捷Scrum实践忽略不计，仅实施自己喜欢做、容易做的内容。如大部分国内企业在实施Scrum时，往往不做团队的自我管理实践，也不强求明确定义迭代完成（Done）标准。

另一个常见的问题是，在通过Scrum实施敏捷时，不考虑敏捷宣言及敏捷12原则。支离破碎的Scrum往往意味着放弃一些敏捷原则。知其然不知其所以然，没有理解敏捷带来的价值，为做敏捷而做敏捷，不可能达到形神兼具的境界。

3.1.1　Scrum不能保证解决问题，但能保证暴露问题

当一个组织在“我特殊所以不适用”的借口下绕开一个Scrum实践时，很有可能这个实践触到了该组织的痛处：这个实践所指正是问题所在。变革需要勇气，正视自己的问题需要勇气，放弃习惯需要勇气。可惜勇气是很多组织缺乏的东西。

当管理者习惯地对一个Scrum团队说：“放下手中的工作，这边有更重要的任务需要你们去做。”这就是说Scrum过程经理没有办法保护团队在迭代中不受外界干扰，一条Scrum实践被放弃了。借口是“我们特殊，因为我们会常常碰到更紧急的任务需要团队处理”。

当一个管理者在无形中要求Scrum团队放弃这个实践时，他同时把危害团队效率的一个问题埋在了地毯下。同时做多件事，虽然貌似让团队成员一直在忙，但并不意味高效率。业界共识是同时做多件事是效率的杀手，从一个任务转到另一个任务需要转换成本，让专注变得困难。在放弃这个Scrum实践的同时，组织也失去了纠正这个问题的机会。