僵尸Scrum？都是因为缺少TDD

作者：熊节 《重构》译者

前几天周冰老师组织的教练聚会，有个年轻的敏捷教练说了她的一个困扰：Scrum的几个会议，她的团队不愿意开，说是太忙，没时间。

我说我以前也见过这样的情形。去年辅导过一个团队，每天的站会都召集不起来。非得Scrum Master硬把人叫了起来，会开得也很乏味，人一个个无精打采，说的话也干瘪无物。

“我昨天在做xx功能。”

“我今天接着做xx功能。”

“没什么问题。”

说完自己的三句话，也不再听旁人说些什么，自顾玩手机或是低头出神。只有那个Scrum Master，又得一个个任务挨着确认详细的进度和风险。

今年我看到一个词，把这样的每日Scrum会议、这样的Scrum团队描绘得入木三分，叫做“僵尸Scrum”。人站一圈，个个不走心、不动脑，无精打采地说完模板似的三句话，接着就面无表情站着不动，可不就是一群僵尸么？

我有一个理论：敏捷实施中的一切问题，最后都可以归结到TDD的缺失。僵尸Scrum也一样。只要用5个Why问一问，就会知道。

为什么开发人员每天三句话没有信息量？

因为他手上拿到的任务粒度太大。一个故事要5天、8天，那可不就是一礼拜大部分日子他都会说“我昨天在做这个，我今天接着做这个”么？

为什么任务粒度大？

因为开发团队没有小步前进频繁交付。反正一个迭代两礼拜最后才出一个版本转测试，任务粒度是大是小都一样，开发团队之外谁也看不出区别。

为什么没有频繁交付？

因为测试不愿意开发出版本太频繁。版本出得多，回归的次数就多，测试人力跟不上。

为什么严重依赖测试人员手工回归？

因为没有快速而可靠的自动化测试覆盖。

为什么没有自动化测试覆盖？

因为没有TDD。没有TDD就不会有良好的单元测试。想靠黑盒功能测试达到可靠的覆盖，速度慢、随机失败多，没有一个团队能长期坚持下去。最后质量保障就全落到人肉回归。

为什么开发人员不关心别人的三句话？

因为开发任务都分到人头，就算有人慢了、有问题了，别人也不会帮，想帮也帮不了。

为什么任务分到人头不能互相帮助？

因为每个人一块代码责任田，别人的代码不能去动，动了无功有过。

为什么严格划分代码责任田？

因为不熟悉的代码不敢改，一改就出错，错了还意识不到，意识到了也不知道怎么修。

为什么不熟悉的代码一改就出错？

因为没有快速而可靠的自动化测试覆盖。

为什么没有自动化测试覆盖？

因为没有TDD。没有TDD就不会有良好的单元测试。想靠黑盒功能测试达到可靠的覆盖，速度慢、随机失败多，没有一个团队能长期坚持下去。最后改代码就全是凭运气瞎改，改错了也不知道。

TDD是敏捷核心实践

这个话，大家很熟悉。这个图，大家也很熟悉。

为什么编程方法的实践要放在最中心？因为少了这些东西，其他的一切实践都玩不转啊！

就像僵尸Scrum这个问题。看起来好像就是一个会议的问题，其实它涉及到软件开发四项基本能力：需求管理、项目管理、配置管理、质量保障。没有小颗粒的用户故事（需求管理），没有集体代码所有制和持续集成（配置管理），每日站会这个项目管理的动作就做不出来。而小颗粒的用户故事、持续代码所有制、持续集成，背后都得有快速而可靠的自动化测试这个基本保障。

没有TDD，敏捷就会僵尸化。外围的办法想再多，少了内核的敏捷，终归玩不转。

---