敏捷开发中对进度的把握.doc

敏捷开发中对进度的把握 项目经理被问到最多的问题就是，“这个项目什么时候才能完成 ?” 被问的时候，可能项目才定下来，仅仅知道大概的功能模块，非功能性需求还模糊不清，甚至团队成员都没到位。但是上级、销售、客户急切地要知道，这个项目什么时候才能完成 ? 被问的时候，也可能项目已临近结束，或者说临近当初计划的交付日期。然而待完成的功能还有一堆，测试出来的 bug 有一大堆，客户又提出了新的需求，团队正有人要离职 …。但是上级、销售、客户非常急切地要知道，这个项目到底什么时候才能完成 ? 这还不算糟糕。更头疼的问题是：“再有三周，项目应该完成了吧 ?” 因为后者根本不是问题，而是命令。项目经理必须要能够合理解释为什么三周不能够完成项目 ;或者说明在三周内，能够完成什么。 我们都用过 MS Project， 但是那上面的漂亮表格对这样的困境毫无帮助。相反，正是 Project 中的甘特图和日程表，埋下了陷阱。因为，在 Project 中无法预估需要多少工作日才能完成模糊不清的需求，也无法体现实际情况发生变化后对进度的影响。 当我们讨论进度的时候，其实包含了两个未知的变量。第一是完成需求所 要的工作量，包括需求定义、开发内容边界 ;第二是团队的工作能力，包括成员的行业知识专业技能，成员之间、成员和外部的沟通能力，等等。 关键就在于，这两项都是变量。如果任务是搬一千块砖头，每分钟每人能搬10 块，那么结果是显而易见的。 在敏捷开发中，采用相对估算和迭代求精的方法来处理项目进度的问题。 首先是工作量。用估算代码行数或者界面元素的方式，就像论斤卖书一样，只适用于粗制滥造的软件生产过程。用户需要的并不是代码或者按钮，而是可靠易用的功能。 在敏捷开发方式中，先由用户和设计人员粗略估计各个功能 模块的相对规模和难度，给出一定的分值。分值不代表具体人月，起相对比较的作用。例如有查询、显示、修改三个模块，如果实现显示模块的工作量是 10 分，那么查询模块可能是 15 分，而修改为 20 分。 下一步，选择一个工作量估分最低的模块，例如这里是显示模块，然后进一步考量其工作量。例如要准备数据库、设计界面、执行查询，显示内容等等。假设这轮估算得出此模块需要 10 人天，从而得出单位分值对应的人天为 1;那么，整个项目就需要 45 人天。 这个估算建立在对项目的初步了解上，主要依赖项目经理的经验。有