敏捷开发中对进度的把握_项目进度，范围，成本管理版_国内最热门的项目管理经验交流论坛_国内PMP聚集社区

项目管理者联盟 | 中国工程管理网 | 中国研发管理网

会员中心

资料库

适合敏捷开发项目
敏捷项目管理最佳实践

重视项目商业分析
商业价值与需求分析能力

产品管理国际认证
全球产品管理最佳实践

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

大型复杂项目全球标准
定位高级项目管理层

链接战略与项目
实现组织资源投资回报

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

论坛
	价值源于交流与分享

会员区：

功能区：公告建议 | 帖子搜索 | 管理团队 | 荣誉版主 | 帮助手册

论
坛
导
航
区

项目型组织	项目管理	工程项目	科技项目	项目化管理	管理软件	资格认证	职业休闲
EPM体系与流程	综合集成管理	总承包管理	IT软件开发	项目型制造	P3E/P6	PMP \| PgMP	职业发展探讨
组织与人力资源	进度,范围,成本	国际工程	生物制药	专业服务	微软PROJECT	IPMP \| PRINCE2	管理学堂
项目管理信息化	团队建设与沟通	房地产	汽车设计开发	生活项目	PowerOn专版	软考项目管理	英语角\|读书版
多项目与大项目	质量与风险	监理与咨询	手机数码	文体娱乐		注册建造师	房车吃游
PMO建设与管理	采购与合同	工程设计				项目管理硕士	闲聊版\|商务版

俱乐部：北京 | 大连 | 福州 | 广州 | 杭州 | 南京 | 山东 | 上海 | 深圳 | 四川 | 天津 | 武汉 | 西安 | 郑州 | 申请成立

TOP榜：精华 | 最新 | 最热 | 会员

版面信息

说明：项目活动定义、活动排序、活动的时间估计、进度编制和进度控制；项目的启动，项目范围规划，范围定义、范围核实和范围变化控制；项目资源规划，成本计划、成本预算和成本控制

	精华区		发表帖子
	投票区		发起投票
	资料区		上传资料

本版版主

zhangt7
登录：2024/2/25
次数：94
注册：2003/11/13
发帖：60

俱乐部导航

北京	大连	福州	广州	杭州
南京	山东	上海	深圳	四川
天津	武汉	西安	郑州

联盟·近期活动

社区热点

精彩专题

如何做好项目沟通计划

软件项目质量管理

国际工程索赔与反索赔

社区圈子

软件项目经理水.
圈主：camer
行业：IT软件

集团企业生态体.
圈主：ETPPM
行业：综合应用

深圳IT项目管理
圈主：lshcom
行业：综合应用

项目管理知识宝.
圈主：wenyu2010
行业：工程设计安装

项目经理职业生.
圈主：zhenjm
行业：综合应用

联系社区管理员

咨询电话 010-82273401/11
斑竹申请 admin@mypm.net

版权所有 © 2003-2004
京ICP证070584号
BBS业务许可2007第353号
最佳显示模式：1024*768像素

敏捷开发中对进度的把握 [发表于 2014/2/11]

状态开放帖精华贴 浏览量 6197

复制该帖链接收藏本帖

[回复] [引用]

该帖子同步发自圈子：企业项目管理体系 (访问该圈子)

项目经理被问到最多的问题就是，“这个项目什么时候才能完成?”
　　被问的时候，可能项目才定下来，仅仅知道大概的功能模块，非功能性需求还模糊不清，甚至团队成员都没到位。但是上级、销售、客户急切地要知道，这个项目什么时候才能完成?
　　被问的时候，也可能项目已临近结束，或者说临近当初计划的交付日期。然而待完成的功能还有一堆，测试出来的bug有一大堆，客户又提出了新的需求，团队正有人要离职 …。但是上级、销售、客户非常急切地要知道，这个项目到底什么时候才能完成?
　　这还不算糟糕。更头疼的问题是：“再有三周，项目应该完成了吧?”
　　因为后者根本不是问题，而是命令。项目经理必须要能够合理解释为什么三周不能够完成项目;或者说明在三周内，能够完成什么。
　　我们都用过MS Project，但是那上面的漂亮表格对这样的困境毫无帮助。相反，正是Project 中的甘特图和日程表，埋下了陷阱。因为，在Project 中无法预估需要多少工作日才能完成模糊不清的需求，也无法体现实际情况发生变化后对进度的影响。
　　当我们讨论进度的时候，其实包含了两个未知的变量。第一是完成需求所要的工作量，包括需求定义、开发内容边界;第二是团队的工作能力，包括成员的行业知识专业技能，成员之间、成员和外部的沟通能力，等等。
　　关键就在于，这两项都是变量。如果任务是搬一千块砖头，每分钟每人能搬10块，那么结果是显而易见的。
　　在敏捷开发中，采用相对估算和迭代求精的方法来处理项目进度的问题。
　　首先是工作量。用估算代码行数或者界面元素的方式，就像论斤卖书一样，只适用于粗制滥造的软件生产过程。用户需要的并不是代码或者按钮，而是可靠易用的功能。
　　在敏捷开发方式中，先由用户和设计人员粗略估计各个功能模块的相对规模和难度，给出一定的分值。分值不代表具体人月，起相对比较的作用。例如有查询、显示、修改三个模块，如果实现显示模块的工作量是10分，那么查询模块可能是15分，而修改为20分。
　　下一步，选择一个工作量估分最低的模块，例如这里是显示模块，然后进一步考量其工作量。例如要准备数据库、设计界面、执行查询，显示内容等等。假设这轮估算得出此模块需要10人天，从而得出单位分值对应的人天为1;那么，整个项目就需要45人天。
　　这个估算建立在对项目的初步了解上，主要依赖项目经理的经验。有偏差?没关系。接下来通过迭代来求精。先来实现显示模块，如果事实上花费了12人天，那么根据比例关系，剩余内容的估算大约就是42人天。
　　当然，比例关系也不是一成不变的。随着模块的逐个完成，项目经理对项目的认识也在加深，他可以再调整剩余模块的相对分值。
　　在实际操作中，项目经理首先按照优先级排列功能模块。然后把高优先级的模块尽可能地细分，再选择分值最小的模块开始开发。统计总工作量时，按比例累加其他模块的工作量，并加一定的调整系数，因为模块的复杂度不是线性增长的。每次迭dai开发完成后，逐步降低调整系数。通常4~5次迭代后，可以将调整系数归零。
　　在上面的例子中，第一次估算的初步结果是45人天，因为完全是凭经验，因此要给较大的调整系数，比如说0.4，因此给出的估算工作量区间为[45*0.6,45*1.4],即27到63人天之间。为保险起见，项目经理上报的工作量为70人天。
　　第二次估算，剩余内容的初步估算为42，调整系数下降为0.3，因此给出估算区间为30到50人天之间。依此类推，通过不断迭代，对剩余工作量的估算将越来越精确。
　　这样估算的好处在哪里?
　　首先，工作量变量的很大一部分因素，存在于非功能需求，例如界面的美观程度。而同一项目的不同模块之间，非功能需求往往是一致的，相对估算法过滤了这一层复杂度。团队能力这一变量因素也是如此。当然，随着项目的进展，成员的开发能力应该有一定的上升，但随着加班出差等因素，投入程度也可能下降，因而会相互抵消。总之在周期6个月以内的项目中，很少出现团队工作能力戏剧性变化的情形。因此相对估算也过滤了这个复杂度。
　　其次，迭代求精的方式让项目经理对估算时间更有把握。最初出现偏差是必然的，但只要团队稳定，没有大的需求变动，估算范围将迅速收缩。这比一次性报数更准确。
　　它的额外好处是，敏捷开发是遵循优先级的，即使对剩余时间(即低优先级模块的开发时间)的估算不十分准确，影响也不是非常大。
　　对比一下甘特图方式，在开发初期就要把各个模块的开发时间估算出来以统计总量，这就是瀑布开发的模式。
　　进度问题的另一方面，是项目经理如何了解团队以及每个开发人员的开发速度。当任务分配之后，项目经理如何做到心中有数，估算任务实际完成时间。
　　敏捷开发过程中，由开发人员自己来估算完成该任务所需要的时间。当然，每个人的能力不同;每个人的心态也不同，有的人保守，有的人乐观。没关系，还是靠迭代来逐步求精。
　　在每天的例会上，开发人员被要求对当前任务的剩余开发时间做重估。不同于Project 统计每人每天在任务中花费了多少时间，敏捷方式只关心这项任务还需要多少时间去完成，直到归零，然后再来统计实际的工作时间。
　　为什么?因为统计开发过程中的花费时间是毫无意义的。这和搬砖头不同，也许昨天用了8个小时没有一点进展，今天一旦想通了就事半功倍。我们真正关心的，就是到底还需要多少时间来完成任务，而不是已经花费掉不可恢复的时间成本。
　　在每天例会中，项目经理需要注意时间曲线保持水平的成员，他是不是遇到瓶颈了，是否需求帮助?也要留意时间曲线下降幅度过大的成员，他发现了什么好的办法，有没有低估需求?这样，项目经理会更面向结果，只要按计划保证质量完成任务就行，成员到底花了多少时间是个人的事。传统做法记录每个人每天的工作内容，第一是因繁琐而失真。其次，一旦上级发现某人工作时间不够(即便他完成了任务)，忍不住会派新任务，从而造成越干活越多，反过来打击程序员的积极性。
　　敏捷估算的关键之处，是把成员能力这个变量的估算，交给最合适的人去做，即程序员本人。然后通过比较历次迭代时的预估和实际时间，给出校正系数，以避免程序员过于保守或过于乐观。这肯定不是绝对准确的，但效果往往比项目经理自己拍脑袋估算，然后强行指定deadline 要好得多。
　　在敏捷开发中，做计划比计划本身更重要。项目经理需要时刻向前考虑，考虑各种动态因素，而不是死报着计划本身。在进度估算的时候，项目经理应该在不同阶段，根据实际情况，给出合乎情理的回答。

>>> 由论坛统一发布的广告：

楼主

wcabt

职务无
军衔主帅
来自天津市
发帖 1283篇
注册 2006/12/14
PM币 21982
经验 9785点

Re：敏捷开发中对进度的把握 [回复于 2014/2/11] [回复] [引用]
Project是工具，我觉得好的工具是能够帮助提高管理效率的。敏捷开发过程也许有管理工具。

1楼

eicol

职务无
军衔三等兵
来自北京市
发帖 2篇
注册 2014/2/11
PM币 24
经验 11点

Re：敏捷开发中对进度的把握 [回复于 2014/3/7] [回复] [引用]
感谢分享
-------------------------------------------------------------------------------------------------------- http://www.szxyyp.com http://www.szxyyp.net http://www.ygbyp.com http://www.sztlyp.com http://www.sz-xyyp.com

2楼

413467879

职务无
军衔三等兵
来自广西壮族自治区
发帖 26篇
注册 2012/3/12
PM币 26
经验 43点

共1页 97 [ 第1页 ] 8:

！您尚未登录，不能回复主题。现在登录注册

建设运营：共创时网络