内容


安排产品生命周期进度:一种资源分配的多层技术

Comments

illustration在我2005年9月发表的文章中, "在一个软件开发项目中进行实际日程安排的十二点提示," 我阐述了一些技术,可以帮助您保持头脑清楚,它们超出了通常的策略,包括记录、检查单,里程碑日期,指定的书籍。我的12个提示强调了区分优先次序、阐明价值和比较每个活动的相对价值。它们将传统的检查单与保存和增强关联结合在一起以完成期望的结果。

在这篇文章中,我将进一步的讨论现实的进度安排,我们将寻求在长期的和多个产品历时过程中管理共享的资源。这个技术显示了如何在一个真实世界的产品开发周期中使用这12个提示。尽管是在一个软件开发周期中阐述的,但是这些提示可以被任何在同一时间段内、多方面活动中负责多任务处理和管理资源的人来使用。

RUP和产品开发周期

Rational统一过程®, 或是RUP®, 是使用迭代开发方法的软件项目过程。正如图1中所示,RUP产品开发周期包含了4个阶段,分别是先启,精化,构建和产品化。

Figure 1: Rational Unified Process is divided into four phases, each subdivided into iterations

Figure 1: Rational Unified Process is divided into four phases, each subdivided into iterations

图1: Rational统一过程被分为四个阶段:每个阶段都被细分成许多迭代

在先启阶段,能够进行投资决策的产品想法或建议请求被确定下来。在精化阶段,确定产品的远景和它的构架。在构建阶段,软件从一个可执行的结构基线发展到可以被交付到用户团体。在产品化阶段,软件被整体系统测试,并交付到用户。

每个阶段都被分成许多迭代。迭代方法日益增多地整合了需求、设计、编码和测设元素。这是一个将相关的适当交付产品、里程碑和检验标准整合的持续过程。1。 这四个相同的阶段在每种类型的传送机制上被复制,不论是重要的版本或是小的维护服务的版本。唯一重要的不同是每个阶段的长度。

这篇文章并不是想要在Rational统一过程中进行解释或是提供细节。有许多关于迭代开发和RUP的文章和书籍,但是这些资源的多数却没有讨论各种适时版本和它们在开发组织和团队中的影响。这篇文章尝试关注RUP框架的扩展和采用,以创造更加现实的进度表。

考虑一下这个例子。在“开发版本2.0下的产品”的一般版本之前,团队开始为同样的产品进行维护和提供服务。这是因为编码在产品确实被发布前是被冻结的。这给与我们充足的时间来进行最终系统级别的测试,最终的产品制造的活动和部署操作。

但是即使在产品分支的版本中编码被冻结,仍然能够发现和修正瑕疵。2.0版本中的维护周期,将导致2.1版本中包含相同的4个RUP阶段,尽管周期更短了。详见图2。

Figure 2: Example of a Version 2.0 product under current development involves a maintenance cycle before the product is even released.

Figure 2: Example of a Version 2.0 product under current development involves a maintenance cycle before the product is even released.

图2: 当前开发下的2.0版本产品实例,包含了产品发布前的维护周期

对更复杂的事物,试想同样的产品线有一个以前的版本,1.0版本——同样继续交付维护版本(版本1.1,1.2,1.3等等)。这些服务周期正在进行,并与现在开发的2.0版本相平行,图3描述了这一问题。

Figure 3: The service cycles for Version 1.0 are ongoing and in parallel with the current development of Version 2.0.

Figure 3: The service cycles for Version 1.0 are ongoing and in parallel with the current development of Version 2.0.

图3: 1.0版本的服务正在进行,并与现在开发的2.0版本相平行

将下一个重要产品版本(3.0版本)的计划周期加到这个复杂的情景中。下一个重要版本的先启和精化阶段依然在我们完成2.0版本之前开始开展,详见图4。

Figure 4: The Inception and Elaboration phases of the next major release, Version 3.0, also occur prior to the general distribution of Version 2.0.

Figure 4: The Inception and Elaboration phases of the next major release, Version 3.0, also occur prior to the general distribution of Version 2.0.

图4:下一个重要版本——3.0版本的先启和精化阶段依然在2.0版本的整体分配之前开始开展,

正如您所看到的,产品生命周期中的一年不仅包括当前在开发的产品,还包含以前的产品版本的维护周期和下一个版本的设计和原型。在同一个日历时间中有许多活动正在进行。

典型的,我们的项目计划安排在一段时间集中于一个产品,但是这会带来一个很大的问题:项目计划安排是单层的,软件开发组织通常不是。如果是这样的话,软件开发团队(包括开发、测试、技术作家、技术支持等等)就是缺乏能力的组织。开发、测试、文档化和其他团队共享所有的产品版本。这是因为我们需要相似的提示和知识来支持每一个“编码分支”——与每个产品版本相关的开发活动——上的产品。由于不同版本要求水平随着阶段和活动而变化,一个特定的资源不是在每个分支在所有时间需要被100%的利用。这使得我们相信我们可以在所有相同产品线上的不同分支中共享资源,不需要其他的了。

例如,一个拥有用户界面编码经验的编码人员只有在1.0版本的支持分支上、 当出现了与用户界面相关的瑕疵时才被需要。因此,在1.0版本的先启、精化和产品化阶段,这种编码人员得不到充分的利用。因此,同样的编码人员可以在2.0版本中需要相同技能的相似的任务中工作,而不是在每个分支中的同样功能的重复资源中。

只要不同的和相似的活动在创建共享程序计划安排被考虑进去,这就是一个合理的策略。

让我们来关注一下在单线程或是单层空间创建项目计划安排是发生的事。

单层计划安排

在典型的生产年中,在工作级别中,对于一些角色有许多不同的峰值。这部分在图5中展示(和图1的图相同),各项细则列在左侧,工作在开发阶段过程中增长或是降低。例如,编码人员的工作在每个版本分支可能在构建阶段达到最高点。一个业务分析人员的工作在先启阶段和精化阶段的开端达到最高点。测试人员的工作高峰可能出现在构建和产品化阶段的末尾。由于不同的阶段发生在不同的时间,同样的编码人员、业务分析师或是测试人员不需要再当前的分支的每个阶段被100%的利用是可行的。因此,这些资源可以在其他构建、先启或是产品化阶段,个别的,在不同版本或是产品分支上被重新定位方向和共享。

Figure 5: Different activities and roles peak at different times in a product delivery cycle.  Therefore, it's feasible that a specific actor or role isn't 100 percent utilized 100 percent of the time.

Figure 5: Different activities and roles peak at different times in a product delivery cycle. Therefore, it's feasible that a specific actor or role isn't 100 percent utilized 100 percent of the time.

图5:在产品交付周期中,不同活动和角色在不同的时间达到峰值,因此,具体的参与者或是角色不需要在100%的时间里被100%的使用,这一点是可行的。

在单层安排计划中,不考虑工作的其他分支。这种安排计划的形式只考虑了特定分支需要的工作和被假设的100%通过分支的个人工作级别。迭代的大小也用相同长度被作了典型的安排计划。例如,一个项目安排计划可能有三个连续的构建迭代,每个六周时间。一旦一个团队获得了这样一个安排计划,他们离开去计划他们的特定交付。

考虑接下来发生什么。适当的迭代项目管理说明从业者从事的工作应当是决定他们在给定量的时间里能完成多少。在这个例子中,编码人员被问到在六周的时间里他们能够完成多少特性。他们可能还要能够精确的定义他们在这六周迭代中的工作水平。但是在一个单层安排计划环境中,他们独立于所给的六周时间来衡量他们的工作。图6展示了3个工作的独立层和它们在预期工作中的相关的峰值和低谷。

Figure 6: Solid lines depict the natural peaks and valleys in effort for one role -- in this case, the coding team -- in the product's lifecycle.

Figure 6: Solid lines depict the natural peaks and valleys in effort for one role -- in this case, the coding team -- in the product's lifecycle.

图6: 实线描述了一个角色工作中的自然峰值和谷值。在这个例子中,是编码团队在产品生命周期中的情况。

接下来发生的是每天的生活。他们可能会为分配的六周时间正确的评估2.0版本中的特征数量;但是,这六周的时间在他们需要完成各自计划好的1.0版本流的维护任务的时间内逝去了。因此,他们在这六周里为了照顾其他的事情从一个任务拖到另一个任务。尽管他们正确的评估了他们六周里的工作量,2.0版本的一些特征依然没有完成。这些没有完成的特征掉进了下一次迭代中,这个趋势一直持续到最后的迭代过程被沉重的加载。通常是在最有一次迭代中体现了团队最多的冲突和时间限制,假设它的重叠包括以前的发布维护周期、当前的发布维护周期和下一个发布设计周期。这些冲突在图7中用加亮的黄色显示。

Figure 7: In this example, a yellow stripe highlights the resource conflicts for the coding team in a single-tier scheduling solution.

Figure 7: In this example, a yellow stripe highlights the resource conflicts for the coding team in a single-tier scheduling solution.

图7: 在这个例子中,黄色条强调了编码团队在单层安排计划解决中的资源冲突。

对资源冲突的一般解决方法包含增加资源,降低质量或是简化“对当前安排计划增加时间”。4 一种典型的情况是资源被从其他项目重新定向(创建延迟和冲突会危害这些项目的计划),并且这个项目的构建周期会延迟以至于它和更多的之前产品流(1.0版本)的维护周期、这些产品(2.0版本)和下一个产品线(3.0版本)的构建周期相重叠。这创造了更多的冲突和任务交换,图8中用点画线和黄色条显示,暗示了一个更长的资源冲突时期。

Figure 8: Adding time to a single-tier schedule extends the conflict periods as illustrated by the dotted lines and enlarged yellow highlights.

Figure 8: Adding time to a single-tier schedule extends the conflict periods as illustrated by the dotted lines and enlarged yellow highlights.

图8: 图中用点画线和用黄色放大的加亮条显示了为扩大冲突周期的单层安排计划增加时间

让我们来看看一个多层的安排计划解决方法是如何提供帮助的。

多层时序安排的分析

通常,通过共享资源来适应类似的项目,管理者选择把资源分成百分比。他们可能分配一个人的20%或是30%给维护分支,剩余的给当前开发分支。尽管这种方法适应平衡每年的资源冲突,它仍然存在问题。例如,尽管对整年的维护工作来说,一个资源可能是均分的30%;但当维护分支需要同样的资源时,就需要100%的工作。根据这一峰值的时间,资源可能已经被当前分支预订了70%到80%。在这样的时刻,资源可能已经被分配到180%。底线是很清晰的:我们在资源上创建了一个可以预见的、可以避免的瓶颈和一个时间计划上的延迟。因此,就算资源分配每年都是平均的,在确实需要重要工作的关键时刻仍然无法达到很好的效果。

一个对资源需求的多层分析会产生更多现实时间安排。正如之前提到的,编码人员的工作峰值水平在每个项目分支的构建阶段是很高的。5 正如在之前的图标中所示的,我们可以用实线来真实的描述那些在每层上出现的峰值。一旦您用您的实际里程的日期代替了一般的蓝色时间线,您就得到了一个显著的工具来帮助您精确的鉴别在哪个日历周内瓶颈和约束将会发生。6

Figure 9: Pink highlighted areas show where the spikes in resources will appear.

Figure 9: Pink highlighted areas show where the spikes in resources will appear.

图9: 用粉色突出的区域显示了资源峰值将会出现的地点。

利用这个多层的知识,我们现在来创建单层程序时间安排。

在单层时间安排上结合多层分析解决方法

收到一个顶层的纲要是很正常的,来自合作计划者的单层项目时间安排略述了行销承诺和时间期限。这个纲要时间表是您的基础。您需要通过塑造和定型将它变成实际的时间表。尽管这些日期比其他“更固定”(例如,产品行销和销售团队发布的结束时间),这个时间表本身意味着是一个起点。这是一个需要被包含进去的重要概念。您的团队对结束时间基本没有控制能力,但是您能够影响您的团队实际如何达到终点。

例如,图10中单层的综合图表将整个构建阶段分为三个六周的周期。在每个六周重复的末尾,都需要重要的可交付使用的和从属品。明显的,在这些点上提交是非常重要的。

Figure 10: Sample master schedule that has the overall construction phase divided into three six-week periods, with important delivery dates at the end of each iteration.

Figure 10: Sample master schedule that has the overall construction phase divided into three six-week periods, with important delivery dates at the end of each iteration.

图10: 用每个迭代最后的重要的交付日期对整个构建阶段分成三个六周周期的综合时间表进行采样。

正如我们在前一个部分回顾的,通常在一个单层的时间表中,管理者问我们从业者在每个六周的迭代中可以提交多少成果。我们在前面展示了只利用这些方法我们将如何陷入困难。因此让我们利用多层时间表在相似的场景中浏览一下。

因为我提前完成了我的多层分析,我知道在图9种用粉色加亮的点上我的资源将会被拖延去做维护。因此,我需要在我的时间表中提前修改我的工作水平去适应维护峰值。我们如何来完成呢?

利用多时间表分析,我实现了在2.0版本、迭代2和迭代3时间周期中,我的资源需要集中于维护分支(用来支持那些已经拥有1.0版本的顾客)。7

记住主要的2.0版本时间表仅仅是一个架构,我意识到我并不需要三个六周连续的迭代。我可以定义更多的适当的迭代长度去适应我所了解的和非常实际的维护任务,正如图11种所示。

Figure 11: Define and schedule your iteration lengths for Version 2.0 around the expected maintenance spike for Version 1.0.

Figure 11: Define and schedule your iteration lengths for Version 2.0 around the expected maintenance spike for Version 1.0.

图11: 在1.0版本的期望维护峰值周围确定2.0版本的迭代时间。

在这点上,在1.0版本的期望维护峰值周围,我确定了2.0版本的迭代时间。我让我的从业者们去估计他们在六周迭代、五周迭代和四周迭代中能完成的成果。为了确认团队中的每个人都理解了我的“完成”的含义,我给每个人提供了一个详细的任务表模版作为一个评估的工作表。8 利用了这个技术,我基本上完成了一个“工作范围”,因为我减少了那些其他人可以完成他们工作的时间安。这个“工作范围”在实际编码和设计之前就已经完成,因此,在这阶段消除这些工作不会产生错误,也不会浪费时间。9 这同样消除了在创建那些我们无法发布的工作成果时所浪费的时间。通过提前完成这些,我降低了增减资源(从其他项目拖延它们并影响它们的发布时间表)或是给顾客时间表增加时间以及1.0版本和3.0版本中额外的资源冲突的风险性。

在迭代2和迭代3种的强制缓冲可以被其他队友用来减少瑕疵,巩固产品,获得早期顾客反馈。10

在这些重要目标之上,我还照做了每个六周的整体综合时间表定义的重要里程碑。事实上,我在没有高层任务开关时早就发布了迭代2里程碑。11

总结

如果多层时间安排技术看起来简单,这是因为它确实简单。多层时间安排技术并不致力于在真空中使用。它需要和其他的工具一起工作,并依照您的经验来使用。尽管这个和我以前的12点时间安排的提示都不是对改进时间安排的详尽的方法列表,我相信用这种方法来承认和测绘并发的任务可以为那些负担增加工作负荷的组织提供一些方便。我非常高兴能够听到您关于这些想法的任何意见,特别是能够帮助您和您的团队的看法。

注释

1 这与策略7项结合:严格地制定合理的强制功能。

2 例如,您可以在Philippe Kruchten的书《Rational统一过程:介绍》中的Rational统一过程中发现确定的信息。

3 这个版本没有其他被提交的编码改变。

4 尽管在一个开发周期的初期删除一些特征也是一个可行的解决方法,在构建阶段的最后1/4中删除那些已经整合到产品设计中的特征更加浪费时间和冒险。其他特征这时依附于那些控件的存在。因为将会花费更长的时间来移除和修正这些影响,在开发的最后1/4阶段很少尝试删除特征。

5 一个项目的不同角色(编码人员、测试者、业务分析师等等)成就趋势(高峰和低谷)的水平可能在左右有轻微的转换,这取决于角色的活动。但是趋势略述了存在的相似性。这些方法也可以在个人水平上使用,或是在您计划利用但资源的一个多流的活动的任何地方使用。

6 这个合并在策略3中:在早期确定重要路径和瓶颈。

7 这个合并在策略3中:在早期确定重要路径和瓶颈。

8 这个合并在策略2中:文档详细任务列表。

9 这个合并在策略9中:接受累计的改进,这些改进接受了较少的有争议的“最佳成果”特征列表结合在一起的特征承诺。

10 这个合并在策略10中:减少可能的目录。

11 这个合并在策略1中:使用突发和缓冲的技术。


相关主题

  • 您可以参阅本文在 developerWorks 全球站点上的 英文原文

评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Rational
ArticleID=161865
ArticleTitle=安排产品生命周期进度:一种资源分配的多层技术
publish-date=12152005