ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 为什么时间盒迭代提倡删减需求任务?

为什么时间盒迭代提倡删减需求任务?

原创 Linux操作系统 作者:张恂 时间:2009-05-19 16:06:23 0 删除 编辑
 
本文的最新版在《敏捷 FAQ》:http://www.zhangxun.com/entry.aspx?sname=AgileFAQ
 
 
问:

时间盒迭代(timeboxing/timeboxed iterations)是国际上流行的开发方式,它的特点是每次迭代的结束时间点是固定的,一旦确定,就不允许推迟或变更这个时间。到点时,开发团队必须提交一个稳定的、通过了系统测试的版本,以便参加评审或向客户演示。

如果在迭代进行中,开发团队发现进度落后,无法完成全部的迭代开发任务和计划的需求功能时,敏捷方法通常允许或要求开发团队与客户协商,减少开发任务或需求(可以放入下一次迭代中),以保证在既定的时间点提交高质量的成果(尽管这个成果可能不完整)。

这是为什么?

也有人担心,如果因进度紧张,计划的需求任务老是被推迟到下一次迭代中,那么是否会导致开发团队在既定的工期内,永远都无法实现既定的完整客户需求?

答:

简答

当进度滞后的情况发生时,为了确保开发进度,保证按时交付系统,增加人手、提高加班强度、降低质量以及删减需求任务是一些人们常用的手段。

敏捷方法提倡在一个迭代(固定时间片)内删减需求任务,这主要是因为其他手段(增加人手、提高加班强度、降低质量等)不适用,或者已采用但仍不能满足要求。

原理



根据项目管理的基本原理,我们在从事一个软件开发项目时,往往需要在时间、资源、质量和范围(需求、内容)等 4 个要素之间进行权衡。



这 4 个因素/因子之间存在着相互制约、相互依赖、相互影响(拉动)的关系。

例如,对于给定的范围(比方 100 个明确、固定的软件需求项),如果要获得较高的软件质量,往往需要我们在时间和资源上作出更多的投入,即花更多的时间和资源,包括资金、设备、工具和人力上的投入等等。也就是说,一旦范围(内容)固定,那么为了在原有基础上提高质量,往往需要我们增加时间,或者资源。

假设有一个 10 人的开发团队,计划在 6 个月内完成 100 项需求的软件开发。迭代长度为 1 个月。

如果交付时间固定,比方要求必须在 6 个月内交付,那么剩下范围、资源和质量 3 个因素可供调节。如果范围也固定,必须交付这 100 个需求项,那么就需要我们在资源和质量这两个因素之间进行权衡。

在国内外的软件工程实践中,普遍存在着大量固定工期、固定费用(比如招投标中)的合同项目。如果开发团队在项目过程中发现,难以在某次迭代中完成既定计划中的所有需求项的开发,该怎么办?

办法一

第一种办法是增加资源(人力等),也就是通常所说的增加人手。著名的《人月神话》告诉我们,简单地依靠增加人手,来确保 deadline 往往是不可行的,增加新人的结果往往会导致项目延期。

当然,对于那些简单的、比较确定的项目和任务(比如“电脑打字”类的),增加人手和加班时间,显然能够解决问题。通常这类的项目具有线性特征。如果 1 个人 1 天能完成一件标准工作,而对于以上 10 人的团队,在 dealine 之前还有 120 件工作需要完成,而剩余的时间只有 10 天,那么再增加 2 个人就可以了。

然而,实践表明,大量的软件研发项目具有非线性、非确定特征,无法按照以上简单、理想的计算结果来确保进度。

办法二

与加人相关的另一个常用办法是,增加加班时间,可以与加人办法一同采用。

尽管 dealine 是不能修改的,工期也有限,总共只有 6 个月,那么最好是向黑夜要时间,在有限的工期内挤出更多的可用工作时间来。原来规定每人工作 12 个小时(加班 4 小时),如果进度来不及,还可以尝试进一步延长加班时间,比如让每人的工作时间为 14 到 16 个小时等。当然,最好是三班倒,不分白天黑夜地干,这样每天 24 小时都被充分利用了。

事实上,加人、加班的确是业界(尤其劳动密集型产业)常见的对付进度滞后、工期偏紧的办法。

然而,加人、加班共有的一个缺陷是,它们都有一个上限。加人意味着企业成本的增加,需要拆东墙补西墙,无法无限制地增加人数;而加班超出限度,会导致员工疲劳,生产力下降,进而导致质量下降,反而无法实现进度目标。

办法三

如果不能加人、加班,或者即使加人、加班也不能满足要求,那么降低质量也是一个办法。我确实听说国内外有不少团队为了实现 deadline 目标,获得客户/用户和领导们的最大满意度,或者赢得最佳的 time-to-market,宁愿牺牲或降低质量,也要按时准点交付。

降低质量有很多种手段。实在来不及了,省略测试,或者干脆不做测试,或者放弃修正以有的 bug 就交付,是常见的做法。

这种做法有一个明显的缺陷,就是可能会带来质量后遗症。表面上是按时交付了,各种需求都满足了,可以使用,但由于隐藏着质量问题,开发团队不得不在发布之后继续花更多的时间一边开发新功能,一边修正以前残留的质量问题。

另一方面,任何发布的软件都不可避免的存在一些或大或小的错误,即使经过了严密的测试。要避免质量后遗症,如何把握、掐准发布/交付的质量门槛是一个关键。

办法四

如果资源、质量都不能变动,或者加班、加人、降低质量都无济于事,那么还剩下一个因素可以调节,也就是范围。减少范围,在迭代中删减或不再增加新的开发任务,同时不删减质保活动,集中团队的精力解决现有问题、完成现有任务,就能保证在规定时间内不断地交付较高质量的产品(或其一部分/增量)。

通常以上 4 种办法可以结合起来运用。在进度滞后、既定任务计划完不成的情况下,为了确保进度/赶进度,人们通常想到的办法首先是加班,也就是增加现有人员的有效工作时间;如果加班不行,那么就加人,增加人手;如果加班、加人还不行,那么可以降低质量,减少精雕细琢的行为,把主要精力放在主要任务上;可是,如果降低质量还不能满足进度,怎么办?

在时间、进度紧迫的情况下,交付一个功能、需求可能不完整但是质量较高的系统,与交付一个功能、需求完整但是质量较低的系统,哪一种结果更好?客户会更喜欢哪一个?恐怕我们不能一概而论。

以上就是为什么开发团队遇到此类情况时,以时间盒迭代为特点的当代敏捷方法通常推荐我们在迭代的进行过程中,减少计划完成的需求或任务,并根据迭代中可用的时间片来安排、填充迭代任务的原因。

总之,为了保证开发进度,当既不能加班、加人,也不能降低开发质量时,与客户或产品经理等需求管理者进行协商,减少迭代中待开发的需求任务是更为合理的选择。当然,如果开发团队发现进度超前,自己还有余力接受更多的任务时,敏捷方法也鼓励增加需求任务。

不管增加还是减少需求任务,都是敏捷方法进行适应性计划、灵活和 just-in-time 任务调度的一个选项。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/13633641/viewspace-600465/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2008-03-27

  • 博文量
    32
  • 访问量
    486234