SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 4318|回复: 4

[赏析] 流水先生新作《软件集成策略》赏析七

[复制链接]
发表于 2013-9-13 11:26:19 | 显示全部楼层 |阅读模式
第 3章   集成优化的本质

4 ]+ ?( d) q1 r
5 f/ }" M6 t9 v7 @) j) X' a" a! P
前两章我们讲解了集成相关的基本概念,给出了集成的一般过程。我们将要探讨如何以集成的一般过程为框架,根据项目实际情况进行细致的调节,量身打造适合实际情况的集成策略和集成解决方案。
- \7 J0 ?( ]: k
为此,我们先要熟悉思考集成问题的思维方式。既然集成是为软件开发项目服务,让我们从项目管理的角度谈起。
) s, v6 N! K  f
2 P! B2 r+ t5 D. n4 M. Y
 楼主| 发表于 2013-9-13 11:51:01 | 显示全部楼层
3.1 从项目三角形说起
" s5 ~+ ?7 P! ~! Q# z
作为本书的读者,你大概想在项目中做一些关于集成的改进。或许你认同敏捷思想,或许你笃信流程与计划。不论怎样,你都要面对下面的问题:改进的目标是什么?怎么判断一个改进的想法是好主意还是坏主意?如何确定各项改进的优先级?当一项改进完成后,如何判断它是否好用,真正给项目帮了忙而不是帮了倒忙?让我们先来看看项目的目标和约束。

# M. J4 L6 `% q  R! k; ~: v% u1 n. I项目管理三角形是一个广为人知的概念。它有好几个相似的版本,我们在这里看一下昀正宗的那个:范围、成本和时间。如图3-1所示。
3 n/ K( w: i6 q- t" B

3 b% a8 L2 o7 a/ `
范围是指项目的目标成果:一些对客户有价值的东西。它意味着,给客户的软件,要具有一些对客户有价值的功能,能够满足客户的需求;同时存在的问题足够少,也就是说,具有一定的质量。
: O" Y' c2 l- X3 |% T
成本是指项目的资源投入。对于软件开发,昀重要的资源投入是软件开发人员的劳动。项目用了多少个人日?哦,一般来说,是多少个人月或者人年。除了人力成本,还要考虑物力成本:服务器的成本,支持开发的软件成本,等等。稍后我们会展开讨论。
/ X4 e7 j* a6 ^: ^, r: g

1 N! y9 b4 @2 K4 p% Y) d时间是指完成一个项目所需时间。对于相当多的软件研发项目,时间都是一个特别关键的事情。如果竞争对手赶在我们之前研制出了类似的软件,那么我们就会损失掉很大的市场,昀终可能会是赢者通吃。即便是一些内部使用的软件,没有这样的竞争压力,时间也仍然是很重要的。早一天完成,使用者就能早一天用上,早一天让它发挥价值。晚一天完成,就要多忍受一天没有它的不便。
* c0 E, J- j5 C" T/ ~6 o# W- f& J
: z/ w) [  [$ R* G4 k1 L
《PMBOK指南》①将项目三角形扩展为(但不限于)六个相互竞争的因素:范围、质量、进度、预算、资源和风险。

8 z/ ]2 Z: m9 \其中,质量从范围中被提取出来,作为一个明确的单独的项。的确,功能和质量是需要同时强调的。资源从预算(成本)中被提取出来,作为一个明确的单独的项。的确,项目所受的约束,可能是缺乏关键资源,比如熟悉业务的程序员,或者特定的测试设备。另外,风险也成为一个明确的单独的项。4 ^# d. O# i$ Z% K; D
$ s, _8 W, q: r8 A' W, a
软件项目也是项目,也是要考虑这六个相互竞争的因素。
6 n  M1 j9 S. W* A# k0 X4 u
当进行多次甚至持续的软件发布时,也同样需要从类似的六方面考虑。只是从以项目为单位考虑,变成了以功能(以及缺陷修复)为单位考虑。我们想在一定的时间里(比如每个季度或每年)发布更多的市场期待的功能,也就是说,我们关注吞吐量(throughput)。而对于每一项功能,我们期望它发布时具有足够的质量。我们也期望这项功能够比较快地开发出来并且发布:我们希望自己的反应足够快,在意识到某项功能需求后,能够赶在竞争对手之前开发和发布出来。换句话说,我们希望周期时间(cycle time)尽量短。同时,我们只有有限的人手;我们期望算下来开发各项功能的成本比较低,等等。" B" `- J4 u3 C' ^, a5 H
" x/ ^, ^& \4 V# _5 g, \: T. n
不同的项目、不同的开发情境,有其不同的特点。比如,有些项目对发布质量的要求非常高,而完成时间相对宽松。有些项目,功能好商量,但必须在规定的时间以高质量发布。有些项目,跟程序员的数量相比,严重缺乏测试人员,并且这个问题很难解决,等等。
" E# b0 C8 f/ Y; Y
也就是说,在具体项目中,有些因素是硬性的、强制的、必须满足的约束条件,而有些相对好商量些。在具体项目中,有些因素要尽可能的压低或抬高,而有些因素的优化则并不重要。在具体项目中,有些因素的需求超乎寻常,有些因素的供给非常有限。这些都是具体项目的特定外部要求的特点。
/ O( R; D. x2 p5 ]; ~+ j. L: |- T9 O
9 n% H  `. G. [( U+ x! C* B8 h我们在制定集成策略时,在推动集成相关的改进时,常常需要与项目管理者甚至更高层管理者之间进行沟通。管理者常常没有时间关注所有的细节、没有时间理解所有的原理和实践。管理者昀终关心的是,对应于以上六个元素,某个策略、某项改进,究竟带来哪些、带来多少看得见摸得着的好处,而它的代价是什么。这样才能知道,在具体的企业中,在具体的项目情境下,是不是值得做。用这一套语言与管理者交流,便于他们理解,也便于他们指导和决策。8 N1 q: p1 |# l; f* k/ x9 _

- n) w- n; `2 v; S/ x# R) N①《PMBOK指南》,即《项目管理知识体系指南》,《A Guide to ProjectManagement Body of Knowledge》。参见附录参考文献部分。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-13 12:30:34 | 显示全部楼层
3.2 集成优化的目标

/ G9 r) k0 c( I0 T) S( B7 f: C3 B1 t* n* N  S
具体项目内部运作的规划、模式、流程、方式方法,作为整体,要适应该项目的特定外部要求,以便在特定的约束条件下,使重要的因素和指标向好的方向尽量偏移。在制定其中的集成相关的策略时,也不例外。
. v% B) }2 P+ u, B9 V
在实际工作中,我们通常已经有当前项目或过去项目的已经使用的运行方法和已经获得的运行经验,基于此,再考虑如何调整。或者是,我们已经有了一些集成方案和策略的设计和计划,现在考虑如何进一步优化。一般来说,我们是基于已有的东西,进一步调整完善。也就是说,我们要考察某一项调整或者说是变化,将会对上节中提到的六个因素,各起到什么样的影响,让它们如何变化。进而判断,这样的影响是不是我们想要的。
$ I0 H( g' f) b- C, c0 q  a* F1 f. l
  Z+ |6 f! k+ u/ c4 |3 T: M0 `
那么,我们想要什么?如果一项集成方面的改进,与改进前相比,预期将使得研发团队更早发布产品,且发布更多的功能,且发布的产品具有更高质量,且使用了较少资源、节约了成本,且降低了项目风险,哦,这肯定是我们想要的!
# O1 o% b  i- f* R, R
遗憾的是,这样的让所有的指标都向好的方向发展的改进,实在是不多见。常见的是,某个提议,将使某些指标向好的方向发展的同时,预期总是有另一些因素向相反的方向移动。比如使项目提前完成的同时,预期将增加成本。比如在使用较少资源的同时,将降低发布产品的质量,等等。对于这种有利有弊的情况,这是不是我们想要的呢?8 q" ]7 _& A# u% [0 W
! j* t* A& {( {- B, ?! d. M% O$ ?
考察项目当前(打算)使用的规划、模式、流程、方式方法,所(将)达到的各项因素的指标,与该项目对各项因素的特定外部要求对应着看,看看各个因素的(将来)实现情况。对于某个因素,如果外部要求它必须满足,当前我们是否能满足?如果还不能满足,那么将使之趋于满足的改进方案就特别受欢迎。对于某个因素,如果外部非常看重它,那么我们的这个改进方案能不能在对其他因素的负面影响不算很大的情况下,对该因素有较多的正面影响?如果可以,那么这个改进方案就很不错。对于某个因素,如果外部的要求很高,不易满足,那么使该项指标趋于满足的改进方案也将被格外看重。总的来说,那些重要的、关键的、不易满足的因素,应该是改进关注的重点。
. a/ c- W$ F" @+ b
然而,也并不总是必须头痛医头,脚痛医脚。因为多项改进可以一起发生作用,互相取长补短,作为整体使得项目的外部要求得到更好的满足。举例来说,现在总体改进的需求是要在范围和成本基本不变的情况下,尽力缩短项目时长。而某个集成相关的改进方案是,在范围不变,时间略有延长的情况下,大幅降低某项资源占用。那么,不要因为这个改进方案没有直接满足改进需求而轻易否定这个改进方案。看看有没有其他配合它的方案,不论是不是集成相关的,是否能够用资源换时间?也就是说,在范围不变的情况下,使用富余出来的资源,减少项目时长。如果有,那么两方案配合使用,就能起到在其他因素基本不变的情况下,大幅缩短项目时长的作用。如图3-2所示。
4 m! W! ], A+ E) |5 ^2 {6 N8 Z$ O  h: q0 |
一般来说,如果某项集成相关的改进方案,能够在相对大幅度地对一个或多个因素产生正面影响的同时,只对其他因素项多有相对小幅度的负面影响,那么就比较容易找到相配合的方法,把改进的总体效果调整到期望的方向。

3 r% F2 L/ ?* J8 R* g$ [- B5 ?最后要强调的是,我们要做的优化,不是局部的优化,不是单个因素的优化,而是整体的优化。举例来说,要求程序员提交的代码具有一定的质量,是合情合理的。早发现问题,早解决问题,会让集成工程师的工作好做,会让测试工程师与程序员间的交互减少,等等。但如果一味地要求提交的代码尽善尽美,那么就会显著地延长程序员检测的时间,增加他的工作量,减缓项目进展。这样就不好了。我们需要兼顾多个方面,找到最佳平衡点。; Q' K4 h- Y$ R; h; G
% {( C5 f) U( M( v5 L. m! u- {8 Z

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-13 12:42:41 | 显示全部楼层
3.3 资源及其成本. G3 n* X' Q! [8 C2 q' V8 u
! S& d  O/ F" W7 \. _: j: s

+ r3 B, L2 U' A* B- ^4 r本节对软件开发项目中的资源及其成本做进一步的介绍。软件开发需要人力资源和物力资源。相应的,存在着人力资源成本和物力资源成本。6 _6 S+ b5 @, b. T$ `& l! y7 H

) \# T4 n7 G! }+ L9 H  N" P, v" q人力资源成本通常是软件开发中的主要成本。人力成本通常以投入人数和工作时间的乘积来计算,比如人月。注意,10 个人月的项目,并不意味着300 个人可以在一天完成。随着人员投入的增加,边际效用递减,甚至人多盖塌了房。还要注意,按工资来计算人力成本只是非常粗略的算法,因为实际人力成本要高得多:福利、场地、管理。" J* _" B/ v; `0 \8 A: {- L$ K

* `4 q, r! T9 Z
在很多具体项目中,是人力资源而非人力成本构成了约束。人力资源是指在特定时间内参与项目的,且具备项目所需要的素质和技能,能够做出贡献的人的总体。例如,还是那个10 个人月的项目,如果由两个人配合完成改为三个人配合完成,项目时长能有明显的缩短。然而,由于种种原因,公司短期内只能给这个项目找到两个人,其中一个还是没多少经验的初级程序员。这就构成了人力资源的约束。) U" J( x) {  G; s. D/ X

) b# v9 |8 Y' {+ K3 W' B物力资源大体包括硬件资源和软件资源。硬件资源包括程序员个人使用的计算机,也包括各类服务器、网络设备等。按硬件的购买价格来计算硬件资源成本只是粗略的算法。除了这样的一次性投入,硬件还有需要持续投入的运行费用,维护费用等。) n8 S, B1 y& Y+ B) K7 i
* W! a, {% X7 |1 @8 g- Y8 v- ?5 S( R
与硬件成本相比,在有些项目中,更重要的是硬件资源及其约束。比如,在一个大型公司里要完成一个研发时间为两个月的短期项目。这个项目如果再增加一台构建服务器,会对项目的运作效率的提升有很大帮助。然而,公司目前没有闲置的服务器,也没有其他项目或部门可以分享现有的服务器。如果新购买一台,全部流程走下来要三个月①。公司也没有租服务器或者利用云计算平台的政策。于是,务实起见,这个项目只能把构建服务器资源看做是硬性约束。0 V% m. G' A) y6 Q( ?) y

# b3 X1 x/ Y( ]6 L, w软件资源成本主要指支持软件开发的软件的许可证的成本②。比如操作系统、编译器、版本控制工具等,都有可能是收费的。如果是免费软件,通常就不必计算了,除非你为相关的支持服务付费。而如果是企业内部开发了一些简单的工具和脚本供自己使用,那么通常按人月算作人力资源成本。就像硬件资源、人力资源一样,软件资源本身也可能构成项目的(暂时的)约束。$ w$ j6 |6 r) ^# e

+ a" E2 H* I9 ]1 ^- n6 F: @
总结如下,如图3-3 所示。
/ B- J$ v1 C* C1 D6 p4 E$ `
% u9 {, @+ ^* k, u: f; P
注意,在一个项目中,对资源的一次性投资,比如培训员工以掌握新工具、新方法、新流程,购买新计算机,购买或研制新脚本新工具等,常常具有外部性:这些投资,将不止在本项目中发挥效用,还将在未来其他项目中发挥效用。不仅是为此付出的资源和成本具有外部性,学习适应新环境、新方法所需要的项目时长的一次性额外耗费,也具有外部性:在日后漫长的时间里,将在本项目和其他项目中持续不断的产生好处。
% }5 |8 ?- e; H
. Y+ c( |8 N, ^9 G/ v. R也就是说,这样的改进本身,是跨项目的,需要通盘考虑。若只为本项目计较,从成本,从资源占用,从对项目时长的影响看,可能不值得做这样的改进。但若从长期效果来看,从全局着眼,却很重要很有意义。因此,在做相关决策时,要充分考虑这一点。而在组织结构上也要充分保证,有适当的人在驱动类似的跨项目的改进,以免形成公地悲剧①。
/ a- }1 J- ]& J6 R9 v

+ i% N2 \4 k1 t! j# A1 T- G' B) o* }① 这是在某个大公司里的真实案例。② 当然还可能包括从第三方购买源代码等。
' P: e. N+ p+ @% S. w7 M① 公共牧场里有好多家在放羊。每家都拼命增加羊的数量,想多卖些钱。于是牧场的草不够吃,羊全都瘦骨嶙峋或者干脆饿死了。也就是说,每个人都顾着自己的利益的话, 就全都受损失。公地悲剧( tragedy of thecommons)是西方人的说法,类似于咱们说的三个和尚没水喝。, C0 v( N& Z% m# t! [

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复 支持 反对

使用道具 举报

 楼主| 发表于 2013-9-13 18:01:30 | 显示全部楼层
3.4 什么决定了项目时长

' _2 u- ~9 w$ s
5 F5 L2 j2 R& c& C( h2 }8 @. H
当考虑一项集成相关的改进的时候,对资源和成本的变化的估算,是相对容易的。对项目时长的变化的估算则比较困难。即便如此,我们也要尽力为之。

5 x- ^8 J9 ^" A/ c我们把软件开发项目中的工作分解为活动(activity)。一项活动动用一定的资源,并且需要一定的时间来完成。在软件开发项目中,有不同类型的活动,比如程序员编写代码,测试人员测试,等等。我们常常关心的是,当一个活动实例,或某类活动中的各个活动实例,所消耗的时间增加或减少一定的幅度时,项目完成时间是否会跟着增加或减少,增加或减少多大幅度?如何计算呢?
6 c1 J! v+ B8 Y; A. y: }1 b$ [( D8 z) \8 S. L" S9 U
一般来说,为了尽早完成项目,需要尽量并行地安排活动。在满足如下两个条件时,不同的活动可以并行进行,互不制约,相互影响:
; }# H7 u" @/ O7 R) i, I
条件一,打算并行进行的多个活动实例之间,没有逻辑依赖关系。而在现实中,活动实例间经常有逻辑依赖关系。不仅不同类型的活动间可能有依赖关系,比如需要先编写代码再进行测试;而且相同类型的活动间也有依赖关系,比如某项上层功能的开发,依赖于系统底层功能的支持,因此先要实现底层功能。
" f* S9 h6 C/ S2 j, W- m) n# d( E' u8 r0 n
条件二,打算并行进行的多个活动实例,对某项资源的占用数量的总和,不会超出该项目动用该项资源的总数量限制。比如,若在项目规划时,把开发工作分解为各个开发活动实例,每个开发活动实例都是由一个程序员用几天的时间完成,共5名程序员,那么在不改变分解方式的情况下,就不能有 5个以上的开发活动实例并行进行①。
, X/ E/ K. k7 U) q  x
当项目的各项资源相对来说比较充沛,以至于不受条件二的制约时,条件一中的逻辑依赖关系,决定了项目完成时间。此时,项目完成时间是项目的关键路径(critical path)的时长。关键路径是各条反映各活动间逻辑依赖的路径中,时长昀长的那一条。! G7 F* M6 P' Y1 c. w' Y# Z; B1 e
这是一种理想情况。我们来看看在这种理想情况下,当某类活动中的各个活动所消耗的时间增加或减少一定的幅度时,如何估算项目时长的变化。看一个具体的例子。

5 `) ]+ k7 z$ U1 Z为了简化分析,我们假定每个开发任务都需要相同的时间,比如 4天,这属于一类活动。然后需要相同时间的检测,比如1天,这是另外一类活动。检测是完全自动化的,并且检测总是不会遇到任何问题。这之后,依赖于它的其它开发任务就可以开始了。假定一共有30个任务。; N9 M# ]3 p4 E
+ l, H6 k2 L# i
在理想情况里,我们有充足的人手,随叫随到。这时候,影响项目时长的关键,就是各个开发任务,准确地讲是各个活动之间的依赖关系。假定昀多有3个开发任务的内容相互依赖,需要依次开发,那么相应的 3个开发活动和3个检测活动就形成关键路径,其长度是 (4+1)X3=15天,这就是项目总时间。如图 3-4所示。

- ]% K( A3 P; V# X' o- o在这样的理想情况里,如果各个检测活动的时长能够从一天缩短至0.5 天,那么就能节约(1-0.5)X3=1.5 天。如图3-5 所示。
! q2 Z$ g3 D. _! X: x; _
' e& ^. ]1 s% M细心的读者可能会产生这样一个疑问,随着各检测活动时间的缩短,会不会关键路径本身发生变化呢?也就是说,会不会另一条路径成为关键路径呢?在这个例子里,是不会发生的。因为这个例子中的各条路径都是由开发-检测这一对儿活动反复出现链接而成。当关键路径上的各检测活动的时长缩短时,其他路径上的各检测活动的时长也缩短,因而不会取而代之成为关键路径。事实上,只要各条路径上,这两类活动的比例都差不多,并且各检测活动的时长都缩短,那么即使某条原先近乎关键路径的路径成为了关键路径,这个取代对项目时长的影响也不大,仍可以用上述估算方法。  X( \' P, r( t, K' L
2 y3 p/ u; h. p3 f6 p) u) C0 u+ P
以上是一种理想情况,资源充沛,由活动间依赖关系决定项目时长。此时,某类活动的时长的增减,在关键路径上的累加,即成为项目时长的增减。当然也可以按照相对值来算。比如在上面的例子中,原先检测活动所消耗的时间,在关键路径上占的比重是20%。当它的时长缩减 50%时,项目时长就会缩减 50% X 20%=10%。
如果资源并不充沛时,会怎么样?与前面讨论的一种理想情况相对应,另一种理想情况是某种资源不充沛,制约项目,但项目不受活动间依赖关系制约。我们来看看在这种理想情况下,当某类活动中的各个活动所消耗的时间增加或减少一定的幅度时,如何估算项目时长的变化。下面是一个接近于这种理想情况的例子。

- a9 W0 H; K  L6 v假定该项目是个接续项目,要基于 2.0发布版本开发 2.1发布版本,因此项目的主要开发任务是修复一些缺陷,再做一些小的功能增强。于是,项目的各个开发任务之间,相对来说没有多少依赖关系。但是项目人手有限,一共5个人。要完成 30个开发活动,那么每个人要完成 6个开发活动。考虑到检测是完全自动化的,并且有充分的资源,一个人在用 4天时间完成一个开发活动后,就可以让随后的检测活动自动跑着,而自己开始做下一个开发活动了。当然,昀后一个开发活动完成后,还要等上一天自动检测活动,项目才算完成。也就是说,项目时长还是稍微受一些活动间逻辑依赖关系的影响。这样的话,项目的总时间是4X6+1=25天。如图 3-6所示。( k# o! z0 {' L* b7 E. ]
4 ~  ~- ~: x: r& {) |8 J( [% a0 f

( c2 \0 Y* @6 a0 f% w
在这样的理想情况里,如果检测活动的时长能够从一天缩短至 0.5天,那么一共能节约0.5天,也就是说,项目只节省了 2%的时间。这一点儿时间,还是因为活动间的逻辑依赖关系引入的。如果没有开发活动和检测活动间的逻辑依赖关系,项目不会因为检测活动的时长的缩短而缩短。如图3-7所示。

( Q( E! W7 ?) m8 V8 L* Y) Q" C$ ?1 k2 M# |1 v
为什么会这样呢?因为在这个例子中,项目时长几乎完全由使用关键资源的那类活动决定。关键资源是程序员,使用关键资源的那类活动是开发活动。而用于检测活动的资源很充沛,于是每个检测活动的时长的变化几乎不会影响到项目时长。

! c+ ?, ]$ c4 @3 h! h而如果这个例子中,是使用关键资源的那类活动的时长发生了变化,各开发活动的时长从4天变为 2天,减少 50%,那么项目时长也会相应减少大约 50%。
+ s- o% s+ @; I  x" h4 x
* P- n" @5 W8 b3 j1 T
回顾一下两种情况。第一种理想情况,各项资源充沛,但因为活动间依赖关系,所以总是资源等事儿做。影响项目时长的关键因素是活动间依赖关系。分析某类活动的时长的变化对项目时长的影响,重点是考察依赖关系,考察关键路径含有多少该类活动。

$ H% p* _6 h, ]& M6 X+ k' O* Y第二种理想情况,从依赖关系上分析,随时可以开始做的事儿很多,但因为某项资源紧缺,所以总是事儿等着资源。影响项目时长的关键因素是有限的关键资源。此时,只有关键资源对应的活动的时长的变化,会对项目时长产生影响。非关键资源对应的活动的时长变化,不会影响项目时长。活动间依赖关系,也不会影响项目时长。; }6 @8 z# D' r& A+ C$ I

% |5 b0 |/ y" q* h$ j( n
至于实际的情况,一般来说,是介于两者之间。可能偏第一种情况多一点,也可能更像是第二种,这要看具体项目。此外,在项目的不同阶段,这种偏向也会有变化。一般来说,一款产品在研发初始时和研发大规模进行时,活动间依赖相对比较强。而到维护期,活动间依赖关系就会相对变弱。

4 f2 u1 s% y9 U4 C# K4 r如果项目是采用关键链法①而非关键路径法进行规划,那么能够做出比较准确的估算,因为关键链上既反映关键资源的制约,也反映活动间依赖的制约。在关键链上,某类活动的时长变化的累加,即大致对应与对项目时长的影响。前面讨论的两种理想情况,是关键链的两种极端情况。
$ ?3 t7 ]# O; Q+ q' X, }, M' g$ o) E2 \5 Q  f  a
而如果项目不是采用关键链法规划,那么可以由项目管理人员通过考察资源约束情况和活动间依赖情况,大致估计具体项目的具体阶段偏向于哪种理想情况,以及偏向的程度。据此可大致估算某类活动的时长变化对项目时长的影响。

. L( h% b0 W8 g3 d. |我们这里用大致估计、大致估算这样的词,是因为软件开发活动是创造性的活动,而不是重复性的劳动。因此在实际的软件项目中,很难精确预计,精确计划。要务实,不要一味较真儿。而得到个大致的估算,就会对项目多一些了解,多一些把握。制定集成策略、集成解决方案,就能更符合实际情况一些。我们多从这个积极的角度看。" }  J- F% j) n  Y% t+ a

5 M6 V/ g* d' g8 |8 [* c! F$ M
从这节的分析中,我们得到什么启示呢?如果活动间依赖关系对项目时长的影响较大,那么除了减少关键路径上和接近关键路径上的各类活动的时长外,减少不必要的相互等待,也会对项目时长的减少比较有好处。比如,看似功能A的开发依赖于功能 B开发的完成,但仔细分析可能会发现,完成功能 B的一小部分开发,功能 A就可以开始了。因此可以考虑完成功能 B的一小部分后就提交,及早集成,以便让功能 A开始开发,而不要等到完全完成功能 B再一股脑提交。

$ o" p- Q! w' z; Z/ y- l+ J而如果是有限的资源对项目时长影响较大,那么使用增加资源、降低工作量等方法,减少关键资源所在活动的时长,将有效减少项目时长。而减少不需要关键资源的活动的时长,则对减少项目时长没多少帮助。
7 B& z9 q) O. ^$ Y" t4 ^$ }9 p: u4 U; c2 x
①当然,往细了看,程序员可以在等待编译构建或者自动测试结果的几分钟或者几十分钟时间里,干点儿别的。但这常常没什么效率,因为开发工作间来回转换的成本是比较高的。想象一下,在 B活动里刚进入情况,正准备大干一场,可还没等干什么呢,就又被 A活动里的编译失败拽回来了。当然,如果编译构建或者自动测试需要挺长的时间,那就另当别论了,这时候,就应当把编译构建或者自动测试单独算作一个活动,常常可以跟开发活动并行。
4 y5 Y  X+ e+ }! {* n: `. ?, ]7 J( @4 s  x0 Q8 k, ^
①关键链项目管理( Critical Chain Project Management,CCPM)是由高德拉特博士创造的一种项目规划和管理方法。关键链与关键路径有若干不同之处,我们这里关注的是,关键链上不仅体现了任务间的逻辑依赖关系,也体现了由于资源受限而导致的依赖关系。

2 t; z: _7 Y/ ?

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

SCMLife推荐上一条 /5 下一条

QQ|小黑屋|手机版|无图版|SCMLife.com ( 京ICP备06056490号-1 )

GMT+8, 2020-7-11 19:45 , Processed in 0.095923 second(s), 10 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

快速回复 返回顶部 返回列表