敏捷开发中对进度的把握

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

 

来源:软件开发网

火爆 售票中
Scrum.Org 主办
搜索
近期公开班
scrum alliance csm认证徽章
12月14-15日 (周六、周日)
Scrum Master (CSM) 中文认证课
远程
Lance Zhang 张宁宁 授课
专业Scrum Master (PSM I) 认证徽章
12月19-20日(周四、周五)
专业Scrum Master (PSM I) 认证公开课
远程
Derek Ding 丁志润 授课
Scrum.org专业Scrum产品负责人(PSPO)认证徽章
1月4-5日 (周六、周日)
专业Scrum产品负责人(PSPO)中文认证公开课
远程
Derek Ding 丁志润 授课
领导大规模敏捷Leading SAFe认证徽章
1月11-12日(周六、周日)
Leading SAFe领导大规模敏捷认证课
远程
Scott Wang 王庆付 授课
safe scrum master ssm
2月22-23日(周六、周日)
SAFe ScrumMaster 官方认证公开班
远程
Eric Liao 廖靖斌 授课
大规模敏捷顾问SAFe SPC认证课徽章
2月27-3月2日(周四-周日)
SAFe认证-SPC SAFe认证培训师导师班
上海
Eric Liao & Marsha Xue授课
safe scrum master ssm
8月10-11日
SAFe ScrumMaster 官方认证公开班
Eric Liao 廖靖斌 授课
scrum alliance csm认证徽章
11月09-10日
Scrum Master (CSM) 中文认证课
Lance Zhang 授课
scrum alliance csm认证徽章
10月26-27日
Scrum Master (CSM) 中文认证课
中文远程
Scott Dunn & Eric Liao 授课
领导大规模敏捷Leading SAFe认证徽章
10月19-20日
Leading SAFe领导大规模敏捷认证课
Eric Liao 廖靖斌 授课
Scrum联盟acsm认证徽章
10月19-20日
高级Scrum Master(A-CSM)认证公开课
Jim Wang 王军 授课
0
0
小时
0
分钟
0
由Scrum.org主办的 2024中国Scrum大会 8月17日将在上海开幕
0
0
小时
0
分钟
0
预约回电
留下您的手机号,我们会在第一时间联系您。
热线电话:400-696-6280
预约回电
预约成功,我们会尽快联系您。