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