限时软件开发

限时开发

　　限时开发是指软件项目的进度是固定的，不能改变的。这种限时开发项目有什么好处？哪些项目可以采用限时开发？限时开发的风险是什么？如何保证成功的限时开发？

1．好处
1.1它提高进度的优先级别
　　进度绝对不变就是强调进度的极端重要性。时间限定的重要性要凌驾与其他任何相关因素之上。如果项目范围与时间限制有冲突，你就要缩小范围，服从时间限制的要求。而时间限制本身是不允许改变的。
1.2它避免了90-90问题
　　很多项目都遇到这样的问题，当他们的项目有90%已经完成的时候，接下来项目就停止不前，这样的状态甚至维持几个月到几年时间。很多项目花费了很多时间，却没有使项目向前发展，而且还消耗了大量的资源。你应该开始是先建造一个小的版本，然后很快完成，接着可以继续建造版本2。不要在第一个版本中规定太多的特性，这样可以很快地得到一个运行的基础版本，从中获取经验，然后建立版本2。
1.3分清性能的优先等级
　　项目可能会花费较多的时间去争辩那些对提高产品功效没有什么意思的问题，例如，我们是否需要多花费4周的时间，来实现全色的打印预览，还是黑白的就足够了？按钮上的浮雕是一个像素好，还是两个像素好？不要将时间花费去讨论优先级"非常低"或"相对低"的特性上。
1.4它限制了开发者对产品的镀金
　　在指定的范围之内，你通常可以用不同的方法来实现某个特定的性能。也常常存在着两天、两周以及两个月的不同版本。如果不指定时间限制的话，开发者常常会按照他们自己的兴趣或者按照他们对质量、可用性以及易用性的要求来实现特性。而限时开发则向开发者宣布这一点。如果有一个2天的版本的话，那就是所需要的版本，不必考虑别的。
1.5它可以防止目标偏移
　　目标的偏移是时间的函数，在大多数项目中大约每月偏移1%(Jones,1994)。限时开发可以通过两种方式来控制目标偏移：首先，如果你缩短开发周期的话，便可减少人们等待新功能出现的时间；其次，由于有些长期项目的目标偏移源于市场状况或操作环境的改变，因此，通过缩短开发时间，你就可以减少市场或操作环境的改变，进而减小软件的变化。
1.6它有助于激励开发者和最终用户
　　人们希望别人认为他所做的工作是非常重要的，而紧迫感可以增强这种重要性感受。因此，这种迫切感是一种强有力的激励者。

2．使用限时开发的最低要求
　　限时开发并非适用于所有类型的开发。以下是一些指导原则，你可以判断你的项目是否适用这种方法。
2.1各功能的优先等级列表
　　在进行限时开发之前，系统的功能和总体设计必须已被确定。最终用户需要把系统的各功能按优先级别进行排序，以便让开发者知道哪些是必须的，哪些是任选的。他们应当定义一个最小的核心功能，你确信可以在限定的时间内完成它。如果系统的优先等级不能被确定的话，它就不适合使用限时开发这种方法。
2.2切合实际的进度估计
　　对开发时间的估计应该由开发人员来完成。他们需要估计一下所需的时间（通常是60到120天）以及在这个期限内能够完成多少功能。从激励的角度来看，让他们自己进行估计是非常重要的。限时开发是一种激励型的开发方法，如果只是把进度和目标不切实际地组合在一起告诉开发者的话，很难成功。
2.3适用的项目类型
　　限时开发最适于开发内部商业软件的开发（IS软件）。限时开发是一种渐进型方法，应当使用快速开发语言、CASE工具或其他支持快速代码生成的工具。那些需要大量手工代码的高度定制系统通常不适合使用限时开发方法。在开始一个开发项目以前，需要确保你现有的工具和人员能够完成该项目。
2.4最终用户的充分介入
　　与其他基于原型的开发方法一样，限时开发的成功取决于最终用户的反馈。如果你不能保证用户的充分介入的话，就不要使用限时开发。

3. 限时开发小组
　　一个限时开发小组可以由1到5个成员组成。对于完成的"限时开发小组"来说，也可以包含最终用户，他们承担建设阶段的辅助工作。最终用户通常要完全参与他们的角色，为开发人员提供支持。
　　限时开发小组必须熟练地运用快速开发软件来开发系统。因为在限时开发项目中没有时间让他们学习新的软件。
　　限时开发小组需要得到鼓励。时间限制所产生的紧迫感有助于提高这种激励。具有公司内很少人能够达到的生产力水平也是一种激励。

4.控制限时开发的风险
4.1限时开发应用于不合适的产品
　　我不主张将限时开发用于上游活动，如项目规划，需求分析或设计等，因为这些行为牵连到下游活动。在需求分析中如果有100美元的错误的话，就有可能以后要花2000美元来更正（Boehm和Papaccio,1998）。在失败的软件产品的墓道中，充满了这类项目的尸骨，他们总是想缩短上游活动的时间，害怕软件产品不能及时交付。而上游的一点小失误就导致了下游大量的损失。因此，在早期阶段中"节省时间"通常是个错误的节省。
　　相反，限时开发在下游活动中常常是很有效的，因为单个工作的不合格会被限制在时间范围内，并且不会对其他工作产生影响。
4.2牺牲质量换取功能
　　如果你的客户不能牢记先质量后功能的原则的话，就不要使用限时开发。开发者很难同时满足多个相互矛盾的目标，如果客户坚持要求工期紧、质量高和数量多的功能的话，开发者根本不可能同时满足所有的要求，在这种情况下，质量必然会受到影响。
　　一旦质量遭受影响，进度也将不可避免地遭受影响。开发小组为了在有限的时间内完成所有要求的功能，必然会影响工程质量，质量一旦出现问题，就需要花费好几个星期来完善产品以使它们的质量满足要求。
　　对于一个真正的限时开发者而言，在到达最后期限时，软件产品要么被接受要么被丢弃。这意味着在开发的任何过程，必须首先保证产品的质量。成功的限时开发取决于能否同意限制产品的广度，而不是降低产品的质量来满足紧张的时间要求。

5. 成功使用限时开发的关键
● 只对可以规定期限内（通常是60-120天）完成的项目使用限时开发。
● 确保最终用户和管理层对系统核心功能已达成一致，而开发小组相信能够在规定时间内完成。确保所有的功能都已排定了优先级，当需要赶上进度时，可以剔除其中的部分功能。
● 确保限时开发小组的成员为项目进行签约，并采取各种措施激励士气。
● 在限时开发的全过程中保证质量。
● 如果需要的话，宁可减少功能也要保证进度，决不延长工期。