Scrum中的重构：如何为它腾出时间

重构是在不改变代码外部行为的前提下改善其内部结构的实践。问题在于：重构几乎从来都不紧急，因此它总是被功能需求挤出优先级，代码库则随着每个迭代悄然累积结构性债务。

重构为何总被挤占

三股力量联合阻碍重构：对干系人不可见；与产品负责人能看到并衡量的功能直接竞争；从不处于危急状态。结果是代码库随时间推移愈发难以维护，团队速度下降，缺陷随迭代增多。

四种有效策略

1. 童子军原则。 让代码比你发现时更整洁。开发人员在触及某模块时顺手进行小幅改进，无需单独创建任务，作为正常工作的一部分吸收。数个迭代后，渐进式改进将累积出明显更整洁的代码库。

2. 在待办列表中添加明确的重构故事。 针对较大的结构性改进，以待办事项形式写明问题、拟议变更及预期收益，用产品负责人能理解的业务语言表述：缩短未来开发时间、降低缺陷风险、加速新成员上手。

3. 将重构纳入完成定义。 若某故事涉及已知技术债的模块，可在该故事的完成定义中包含特定改进项，使重构与交付保持关联，而非孤立进行。

4. 预留10%至20%的容量缓冲。 在迭代计划时与产品负责人商定，保留一定比例的容量用于技术工作。团队将其用于当前迭代中最迫切的改进：重构、测试覆盖、依赖更新或工具优化。

对于非技术型产品负责人，将重构定位为对未来交付速度的投资，而非单纯的「代码清理」，往往更容易获得认可。结构性债务最终总会以延误和缺陷的形式被用户感知。

如果您的Scrum团队在应对技术债和迭代可持续性方面遇到困难，XNM的项目与方案交付实践可以帮助您建立在速度压力下依然能保障质量的团队纪律与待办列表习惯。