内容


Rational Edge

旅程!一个度假者的迭代开发指南

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: Rational Edge

敬请期待该系列的后续内容。

此内容是该系列的一部分:Rational Edge

敬请期待该系列的后续内容。

插图迭代和增量开发过程是建立在 Barry Boehm 的螺旋模型的工作之上的,1并且在过去的二十年里,由许多个人和组织对其进行了增强,包括 IBM Rational 团队。该过程的特点在于不断的发现、创造和实现。对于每次迭代,开发团队推动项目的工件以可预料的且可重复的方式作为迭代的终止。2迭代方法能够应对不断变更的需求,较早地降低风险,并且允许开发人员在理解项目的同时,进行一些策略上的变更。

虽然迭代和增量开发方法已经证明对于大型和小型的开发组织是非常成功的,但是有一些人仍旧相信迭代开发不管用。虽然怀疑未知和没有尝试的东西是人的本性,但是,我们中的许多人,即使不是大多数,已经在软件开发领域之外的生活中实现了一些类似于迭代开发生命周期的内容。那就是,我们驱车进行了很长一段越野旅程 — 许多人还不止一次。

本文例举了迭代开发技术如何应用于日常的活动,例如家庭度假。

很少人会反对生活中涉及不断的发现、创造,和实现。在出生的时候,没有人能够绘制出并明确定义他的职业、目标和成就。我们能够很容易接受的是,随着成长,我们在不断地学习,通过每次经历和观察我们的策略,甚至是目标在发生着改变。但是,当提到软件开发时,我们却很难应用那些概念。我们更倾向于相信,谨慎安排的计划和排得紧凑的进度是开发新软件时的唯一途径。事实上,迭代和增量技术提供了更好的方法来创建软件,使过程中的一些小的步骤得到完成、论证及评估,而从这些步骤中得到发现常常会建议出实现下一个步骤的新方法。

为了说明这一迭代过程,让我们将它与我们中的许多人很熟悉的内容进行比较:管理一个家庭度假。即使您从未有过家庭度假(或者已经过去很长时间了),我也认为您会看到这一越野旅行比喻的意义。

项目

让我们假设 Jane 姐姐将于 6 月 3 日,在美国佛罗里达州的奥兰多结婚,而我们住在圣地亚哥。我们还同意沿途接送其他的家庭成员。

如同在迭代开发项目中的一样,我们已经有了强制需求(到达奥兰多!),版本限定特性(接送其他的亲戚),以及固定的发布日期(不论我们是否到达那里,我们的姐姐都将于 6 月 3 日结婚)。注意,在现实生活中,我们可以接受硬性的截止日期 — 像结婚日期。您有多频繁地听到某人抱怨所选择的结婚日期太过分?我们只是接受邀请,或者发出我们的歉意。

就像在软件开发项目的一开始,我们有许多方法来完成目标。我们可以做飞机、坐火车、租汽车,或组合这些选择。我们可以花三天到三个星期的时间到达那里。与在软件项目中一样,我们使其他人(涉众)参与进来。设想我们的涉众是新墨西哥州圣达菲的 Marian 阿姨、路易斯安那州巴吞鲁日的 Cid 叔叔,以及密西西比州杰克逊的 Tanya 堂兄。

项目特性

起初,每个人都赞同,进行三个星期的家庭度假,主要停留在亲戚住的三个城市会是很有趣的。为了增加价值和乐趣,我们计划在途中进行一些额外的游览。根据我们的进展,这些额外的游览是可选择的,但确实“值得去做”。

迄今为止,这一旅行部分类似于迭代开发项目的初始(Inception)阶段:有一些版本定义的(主要的)特性和若干次要的或看是去很好的特性是很普通的。版本定义的特性集包括强制性的和被高度宣扬的组件。如此题目所暗示的,这些特性确定了关键的路径。根据定义,如果那些所选择的特性不具有约定的质量或完整性,那么我们的发布日期将延迟。开发团队在同样的进度中继续处理次要的特性。但是我们并没打算因为处理那些看上去很好的特性,而影响发布日期。因为次要的特性不是被宣扬的,所以为了确保准时完成主要的特性集,我们可以灵活地重新配置资源,不去处理那些次要的特性。

附加的游览(次要的度假停留)最初是根据到各个家庭成员接送点的路线而选择出来的。如果时间紧张,就可以省去这些看山去很好的里程碑,以回到我们的进度上来。因此,尽管我们不知道沿途的所有停留,但是当我们需要停留在各个接送点(我们的需求、里程碑日期,和迭代阶段)及结婚日期(项目终止日期)时,我们必须有一个路线的纲要(项目计划)。

我们得到了朋友的 RV 作为旅行方法。我么认为这会是放松且舒服的。RV 增加了灵活性 ,因为我们每晚不需要待在酒店里。但是 RV 确实空间有限。所以为了成功实现旅程,我们需要让每个人遵守特定的旅行标准,例如限制行李、对团队费用的承诺、他们需要为旅行提供的东西,以及我们的各种时间表。如果在沿途的任何位置,我们没有满足所商定的旅行标准,那么我们需要停下来,评估我们的情况,并进行调整。

旅行的每一个阶段

在迭代开发方法中,存在可以控制开发旅行中的每一阶段是否能够开始的入口和出口标准。这些目标用于指导并验证被开发产品的稳定性、可靠性,及准确性。这些所商定的标准是在项目的开始时创建的,并且要理解这些标准在沿途中是可以适当地改变的。3 一个迭代的出口或入口标准的实例是:

  1. 对于此次迭代,所有计划的特性都被交付了
  2. 对于此次迭代,所有的涉众审查并认可所计划的测试覆盖
  3. 所有计划的测试都执行了,并且百分之 95 通过
  4. 没有已知的阻塞或高优先级的问题

依照沿途的这些标准我们不断地监控项目。如果在开发生命周期的任何位置,我们确认我们已经偏离了航线,那么我们就应该停下来,评估情况,并进行调整。理解“调整”意味着修改入口或出口标准也是重要的。

因为在每个迭代的里程碑,我们将处于旅行的不同位置(参见图 1),所以对于每一段旅行的入口和出口标准对每个参与者将是不同的。举例来说,您和我将旅行三个星期。因此,我们的行李配置将比旅行中最后几天加入的人要多。

起初,我们为旅行确定了一般性的计划和重要的标准。在对计划进行一些修改之后,每个人都赞同此期限、条件和时间表。

我们上路了。

地图

地图

图 1:迭代旅行终点之前的三个里程碑:圣达菲、巴吞鲁日和杰克逊。

虽然我们知道我们需要在旅行中停留三次,但是我们并不会太关心在杰克逊的第三次停留。在我们开始旅行时,我们关注于到达圣达菲的 Marian 阿姨那里。我们为这段旅行(第一次迭代)细化出更详细的路线。由于我们在菲尼克斯有些朋友,所以我们突然到那里进行了短暂的拜访。我们不太确定他们为我们准备了什么,但是我们知道他们计划带我们到他们的故乡观光。我们提前打电话说明了我们的时间表和约束条件。我们在菲尼克斯的朋友安排他们的活动以符合我们的需求。我们还确定在路途中定期地与他们联系。

注意,给我们在菲尼克斯的朋友留下一些时间的计划类似于在开发项目中约定或外包一个特性或组件。我们建立一定的时间表、约束条件、检查点,和通信程序,但我们将细节留给第三方。

我们在菲尼克斯度过了快乐的时光,并成功地准时到达圣达菲。

第一次耽搁

当我们到达圣达菲时,Marian 已经准备好,我们检查我们的状态。Marian 满足了所商定的行李标准,他预对需要花费的现金做了适当预算,并且她把要带到婚礼上的物品列表中的物品打好了包。唯一的耽搁是她坚持带上她的小狗,Dogma。我们最初没有对此进行计划,因此我们需要评估需要进行什么类型的调整。虽然您和我对此没有特殊的问题,但是我们需要与所有的涉众进行确认(类似于进行变更管理审查)。我们遗憾地发现堂兄 Sid(下一段旅行的对象)对狗过敏。Dogma 不能与我们一同旅行了。

在许多样式的软件开发中,向已经审定的项目计划中添加特性称为“特性蔓延”。但在迭代开发生命周期中,我们认同需求和请求中的变更。我们倾向于不断地从先前的迭代中了解事情。由于逐步地需求细化是迭代开发中必要的概念之一,在每次迭代的开始或结束时管理需求审查是关键的。

在我们的情况下,Marian 很失望,但是她能够理解。因为它预先做了风险评估,并且认识到可能不允许 Dogma 与我们同行,所以她的应急计划已经就位了。她的朋友(来自几个镇远)已经同意照看小狗。送走小狗会花去我们若干小时,这使我们偏离所计划的路线,因此我们在心中审视我们一日的安排,并进行相应的调整。我们决定可以很容易地在没有副作用的情况下加入路线变更。Marian 照顾小狗的朋友也为我们提供了那个地区的专业观光旅行。该变更的结果是微不足道,甚至是有益的:也就是,因为我们调整到此次变更,所以我们拥有了更加令人兴奋的交互旅行(比预先计划的里程碑)。

在迭代开发中,这类似于随着我们不断地了解我们的项目和客户的需求,用一个可选特性来替代另一个。尽管从先前的迭代中获取的知识可能会改变下一次迭代的内容或过程,但是我们的主要目标和最终日期是稳定的。

我们成功地送走了 Dogma。我们非常愉快地见到并拜访了 Darla。我们还了解到 Darla 的儿子和女儿将进入我们的儿子 Josh 所在的同一所高中。我们做出了未来的计划,对于不同的学校的活动中能够一同旅行,甚至研究孩子们住在同一间屋的可能性。总之,我们能够制定一些未来的试验性计划,所有都是因为构建于迭代过程中的灵活性允许我们适当地偏离原来的计划。

实际的停滞

我们下一个主要的迭代里程碑是巴吞鲁日的堂兄 Sid。在途中,我们想要在得克萨斯州的三个城市停留:奥斯汀、圣安东尼和休斯顿。我们在奥斯汀和圣安东尼度过了愉快的几天。每件事都按照计划进行,直到 RV 在圣安东尼以外抛锚了。不知道的是要花费多少钱,以及修理 RV 要多久。利观的估计是几天,但是直到机械师在 RV 上花费了更多时间,他才能确定的告诉我们(非常像调查代码中的缺陷)需要多长时间。不幸的是,我们没有预见到类似此事情的发生。这有潜在的可能将我们的时间表后退几天。

在任何软件开发项目中,团队试图识别风险、发生的可能性、对整个项目的影响以及应急计划。在迭代的开发周期中,风险管理和识别在每次迭代中不断地被检查。

因此,正如在软件项目中一样,我们与所有的涉众开了一个电话会议。由于我们不能确切地知道 RV 什么时候能修好,所以我们需要一个新的计划。我们不能变更终止日期:不论我们在不在,Jane 都将结婚。如果我们固守当前的项目计划,很可能我们会错过婚礼。由于 Marian 是伴娘,所以她会不高兴。她非常强烈地要求立即采取行动以保证我们能准时地到达。

我们讨论了许多选择。我们商定的计划是让 Tanya(在杰克逊)飞到巴吞鲁日见 Sid。当 RV 修好之后,我们将直接到巴吞鲁日,在那个迭代里程碑处接他们两个。取消到杰克逊的附加游览给我们七天的缓冲。

Tanya 赞同新的飞机票的花费。当然,她不是唯一负担未预料的花费的人:我们修理 RV,而每个人对新的花费应该如何处理都有不同的意见。在进行一些讨论之后,我们最终达成了一个团队能够接受的解决方案(这类似于发现软件项目中的附加设备和资源需求来从未预料的延滞中恢复回来)。

细化应急计划

因为 RV 的修理时间仍旧是未知的,所以 Marian 对准时到达最终的目的地感到不安。因此她建议细化以更好地补偿风险:限制我们等待修理 RV 的时间。例如,如果修理时间超过五天,那么她建议我们放弃 RV 并使用不同的旅行方法。在软件开发中,这称为限定“等待”或“延迟”周期的时间。此方法使我们能够控制未知的细节,这可以排除使大多数项目偏离进度的日常的浮动。Marian 考察了各种旅行方法,像飞机、火车和汽车。考虑到每个人的预算、旅行进度、舒适度和其他利害关系,她推荐,如果 RV 在五天内还不能修好,那么我们坐火车去奥兰多。Tanya 和 Sid 会离开巴吞鲁日,我们会直接从圣安东尼走。我自愿与 RV 在一起,并且认识到我可能会错过婚礼。因此现在我们有了一个应对 RV 可能不能及时修好的风险的迭代和细化了的应急计划。

Marian 想知道我们是否应该打电话给 Jane 并告诉她我们目前的情况。Jane 非常像软件开发项目中我们的客户,是对软件应用程序的最终交付感兴趣的人。在讨论之后,我们确定,Jane 有太多要担心的其他事情。如果我们不得不施行应急计划,我们可能要给她个提前说明。但现在,我们认为我们可以控制这些事件。任何时候,我们中的任何人都可以坐火车(甚至坐飞机)直接到奥兰多,摆脱对家庭其他人的依赖性。虽然在项目的开始,一起旅行是重要的“需求”,但是我们知道有时候优先级会发生变更。

在危机时刻,可以改变需求来适应当前的情况或需要。在此实例中,我们所有人到达婚礼地点的需求仍旧不变。但是由于目前的情形,我们变更了一点 — 也就是,不再强制我们一起或同一时间到达那里。最终的目标仍旧能实现,但是以稍微不同的方式实现。在迭代开发生命周期中,根据目前的情况或需要对需求的修改不只是可接受的,而且也是实际被期望的。

Marian 赞同,如果她对时间感到不安,她总是可以自己直接到奥兰多去。在迭代开发中,这类似于在举起影响外部团队的红旗之前,确定在您的小组中有多少变更您能够完全控制。

既然我们让针对目前情况的计划就位,以及有了一个针对风险的应急计划,我们就可以放松一点了。我们将有几天没有 RV,所以我们推选找一个好的供应早餐的旅馆。旅馆招到很亲切、喜欢开玩笑,并对该地区很了解。他们对我们的经历表示同情并且承诺让我们几天的停留尽可能愉快。我们以扩展知识的方式创造性地利用了这一点。

调整及机会

在迭代开发中,我们经常遇到项目中的延迟,这给我们时间来减少缺陷并稳定该迭代的可交付内容,因此帮助我们令整个任务处于正轨。在等待设计项目的其他部分与主干同步时,常常出现延迟。但是这些延迟可以为其他团队成员提供机会,他们有了意外的时间稳定并减少基线代码中的缺陷。

您不知道吗?RV 实际上三天内就修好了,我们再次踏上旅途,但是由于我们对 RV 的稳定性有了一点谨慎,所以我们直接到巴吞鲁日了。实际上,我们提前到达了,直到第二天 Tanya 的航班才从杰克逊到达这里。因此我们拜访了 Sid,直到 Tanya 赶上我们。

这里,我们非常接近最终阶段了。让我们更细致地看看迭代开发的度假事件。随着我们回头审视旅行的进度,我们可以绘制出如图 2 和 3 中所示的迭代(计划的和实际的)。图 2 描绘了度假项目开始时的度假计划。通过恒定的策略审查、适应性和迭代任务计划,我们实际的旅行计划成功地产生了如图 3 所示。

图 2

图 2

图 2:假期开始时原始的迭代计划

图 3

图 3:假期中实际的迭代活动,由图 2 所示的内容调整而来

持续的测试

正如先前的接送点(迭代里程碑),我们进行测试以确保我们满足适当的行李限制和预算,并带有我们需要带到婚礼上的所有东西。啊!我们发现,在保证备选的旅行计划的匆忙中,Tanya 忘记了她打算为婚礼而带的东西。但幸亏我们在每个迭代点处的进行了迭代测试,我们在最终的截止日期(婚礼本身)之前发现了这一疏忽。不是个大问题。我们进行了一些易处理的购物,使 Tanya 回到正轨。(这说明了在每次迭代中持续测试,以及随着软件项目的发展验证迭代的入口和出口标准的重要性。)

现在还剩下十小时的旅行就到达奥兰多了。我们从容地开着车,游览着阿拉巴马州的墨比尔和佛罗里达州的塔拉哈西。我们取消了其他的观光旅行,并且提前到达奥兰多。我们中的一些人在迪斯尼世界玩了一天,而 Marian 利用她的时间,花在伴娘的职责上。

迭代冒险

如您在本迭代旅行的简单实例中所见到的,对于软件风险、特性蔓延、超出控制的未预料的崩溃,和恢复计划,我们遇到了相似的事件。就像我们的旅行计划一样,可以有效地使用迭代开发和测试来提高满足软件进度的可能性。

注释

1 Barry W Boehm,“A Spiral Model of Software Development and Enhancement,”IEEE Computer,1988 年 5 月,61-72 页。

2 Philippe Kruchten,The Rational Unified Process An Introduction,7-8 页。

3 根据不断的认知和项目细化,应该不断地对验收标准,例如入口出口标准,进行检查和评估。如果适当,甚至可以根据新的经验或过程变更来改变它们。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=159937
ArticleTitle=Rational Edge: 旅程!一个度假者的迭代开发指南
publish-date=09142006