时间盒与进度压力

某大型企业，传统的发布周期为两年，采用的是瀑布模型。在实施Scrum的过程中，时间盒是争论的焦点之一，多数情况下，时间盒概念被漠视，产品负责人及若干利益相关人依然会迫于进度的压力，向开发团队施压，要求必须完成过量的特性开发，以及接受不完全满足Done Definition的特性。

类似的行为导致企业自认为在实施“Scrum”，其行为模式其实和过去一模一样，换汤不换药，无非是挂着自组织团队以及跨职能团队的旗号，进一步压榨开发团队的血汗而已。无助于达到企业实施敏捷迁移的初衷，更无法获取所期待的收益。

传统模式中，其发布被分割为需求分析、设计、开发、测试、系统测试，以及应用层的开发等阶段，每个阶段耗时以月计，例如某个模块的测试可能持续三个月之久。此时，进度可能出现的延迟、逐渐显露的风险等等问题，都在接近完成任务的预计日期时暴露出来。各个阶段的进度压力叠加到发布上，就更加难以解决，且也会在临近发布日期时达到最高点。管理者的应对手段无非是加人、加班、赶工降质量标准等等，幸运的是，往往还足以让可以接受。而之后客户发现的软件缺陷则被当做单独的处理，至于它们和那两年期间以及发布日期临近时的加班加点之间的联系，则已无人问津。

遗憾的是，采用Scrum的组织往往会发现，这种赶工现象有增无减。原因在于，以往要三个月或是一年之后才感受到的进度压力，如今每一个sprint都可以感受得无比真切。产品负责人或是具有实权的管理者若是延续过往思路，企图采取措施挽救进度危机，要求开发团队“使命必达”，“务必在某年某月某日前完成xxx一系列功能”。对进度的追求换来的是对质量的牺牲，以及欠下的技术债务。让形势变本加厉的恰恰是Scrum自身时间盒以及增量式的特点，每一个sprint，技术债务就累积一次，臭虫就多几个，开发就慢一些，进度就更紧一点。团队无法按期完成任务的表象，会侧面地验证自组织团队的荒谬性，传统思维管理者们会更自信项目需要他们的介入，从而引入更多的命令与控制。

时间盒与进度压力，你要哪一个？