时间盒与进度压力

传统组织向敏捷开发方式的迁移中,容易延续以往的行为模式,
例如对待进度压力的方式。

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

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

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

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

时间盒与进度压力,你要哪一个?

About Kaveri, Yi XU

Agile Coach & Consutlant
This entry was posted in Agile&Scrum&Testing&TA. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s