Post by "Shrek", 04-26-2009, 21:36
-----------------------------------------------------
通过这样的方法来估算，是一种办法，但“由项目经理或项目组长进行工作量的单位估算（以平均生产能力为单位）”这未必是常见的做法。项目经理会根据承担这个任务的人员的能力和任务的具体情况，来估计需要的工作量，而没有必要以平均生产能力为单位。
实际上平均生产能力，用来做项目概算还是合适的，但如果是用来安排具体的项目进度则用处不大。做项目概算时，项目人员不明确，故只能用平均生产力指标。但安排具体的进度计划时，谁来做这个任务，这个人的情况如何，任务的性质如何等全部都很清楚，根据这些信息完全可以做出准确的估计，这时如果还用什么平均生产力指标是没道理的，最多只能用来参考。
另参见：
项目估算可以分为两种应用场景：
1.用来招投标的时候用的。
2.用来指导具体项目工作用的。
对于第一种情况，项目通常需求不是很确定的，并且也不知道谁将会是项目组成员，这时有必要利用生产率数据进行估算，这个时候的估算一般只能算是概算。
对于第二种情况，需求应该比较明确，项目组成员也确定。这样，如果还是死抱着生产率来估算，是不太合适的。应该还是根据具体情况来估算，而生产率可以用来参考，而不是决定因素。
生产率实际上是一个统计值，并且只能反应历史情况的。用生产率来估算当前项目，只能大致反应项目的情况，实际上是不够精确的，但可以利用这个数字来校验你们的估算，重新思考你们的估算，但最终还是应该相信你们WBS的分解估算。
Reply by "Shrek", 04-26-2009, 21:37
-----------------------------------------------------
最近有这样的一个辩论，功能点VS代码行，辩论的焦点就是用哪一种来代表软件规模更好一点。项目规模的度量大有学问，如果您想去听听专业的软件功能点法课程，您可能要付上高昂的学费，并且有可能学了后还不知道如何用上这个办法。这里我不想谈论这两种办法，这些方法可能仅是理论上可行，目前我也没有见到过一个成功实践这类方法的案例。
软件规模就这么难度量吗？以前我的领导曾经问过主任评估师，我们把工作分解得足够细，直到我们可以估计工作量的程度，这不就把工作量估出来了？
没错，我想说的就是这种办法，而我们亲爱的微软，就是采用这样的方法来估算规模的。这样的办法虽然原始，但有效，并且容易掌握。虽然这种办法被扣上主观成分大、项目间难以横向对比的、难以积累历史数据等多种“罪状”，但不好意思，用功能点法或者代码行法就很准吗？我们亲爱的软件工程师们认可功能点法或者代码行法吗？搞功能点法代码行法等这些“虚”办法，还不如老老实实地WBS，直接估算每个工作的工作量。
中国的软件公司所做的大部分项目都会出现不同的新情况，功能点法和代码行法只适用项目类似的情况，或者是做外包时和对方讨价还价用的。下面介绍的软件规模度量办法，是所有公司都能马上采用的办法，而且将会让工程类人员乐于接受，我暂且把这个估算办法叫做“傻瓜估算法”。
第一步：把公司内部最有项目经验最有估算经验的工程们召集在一起，制订组织级别的估算表框架。
软件开发活动，可以分类以下几类：
l 直接生产软件的活动，如：需求开发、设计、编码、测试等工程类活动。
l 项目管理类活动，如：编写项目计划、计划跟踪、发布评审等活动。
l 项目支持类活动，如：配置管理、QA检查等。
l 维护类活动，项目验收后的数据整理、修改缺陷、系统维护等活动。
根据公司的实际情况，列出各类项目活动，可以根据不同的项目类别而列出不同的活动，尽量把这些活动种类细化，如考虑设计时，还需要考虑设计评审的时间，考虑编写计划时，需要考虑主计划、子计划的编写等等。
把这些框架定好，并设计出估算表模板，供项目组使用。
据我的经验，很多估算没有做好的缘故，常常是忘记或者是没有估算好估算管理类、支持类、维护类的活动。当一个公司的估算精英聚集在一起的时候，大家要列出公司估算中常常遇到的问题，全部考虑到估算表模板中，并写上足够清晰的指导。当项目组用这些模板的时候，相当于用了估算精英们的脑袋来思考本项目的估算了。
第二步：项目组选用合适的估算表模板，进行由底而上的估算。
项目组根据自己项目的特点，选用合适的估算表模板，然后项目组成员一起在这个模板的基础上，继续细化，进行详细的WBS，列出要完成这个项目所需要的全部工作，并且把这些工作落实到具体的项目组成员身上，由负责该任务的人来估算自己完成这个任务需要多少时间，而不是由项目经理分配一个完成时间。这就是由底而上的估算办法，这是微软MSF中的估算办法，这个办法有以下好处：
1. 最终该任务是由这个人来完成的，他估计多少时间才能做完，这个时间才是最接近实际的。
2. 负责该任务的人进行估算的时候，肯定需要认真思考这个任务的风险，需要做哪些具体的工作，这样更容易在未开始工作之前就发现更多的潜在问题。相反如果由项目经理来分配时间，这个人就可能不会去思考这个任务了。
3. 做这个任务的人会有被重视和尊重的感觉，他会很重视自己承诺的完成时间，并且想法设法按时间完成。这样会减少很多项目管理时间，因为每个任务负责人都会主动地跟踪好自己的工作。
第三步：持续完善模板，持续改进。
每个项目使用模板进行估算后，都可以对模板提出改进建议，把本项目的成功经验融入到模板中，让后面的项目收益。
“傻瓜估算法”非常直接有效，能很准确地估算出项目的工作量。学院派的人士会认为应该先估算出规模，然后再由规模估算出工作量，但我想说的是，估算规模的目的还不是为了估算工作量，如果有办法直接准确地估算工作量，干嘛还要去估算规模，干嘛还要去想功能点法好还是代码行法好？当时我们主任评估师也认可这样的做法，他也认为某些情况下工作量可以直接代表项目规模。CMMI也没有规定非要用什么功能点法代码行法来度量软件规模。
软件的工作量估算是很重要的一项工作，是整个项目成功的基础，用“土方法”也可以把工作量估好估准！
对于软件规模的度量，我们有两层的目的：
1. 能准确地估算出本项目的工作量，为整个项目控制打好基础。
2. 能在不同项目间进行横向比较，为度量组织的生产力打好基础。
如果目标一还没有实现的情况下，就不要直接去追求目标二了，要一步一步来。功能点法、代码行法无疑在理论上是可以同时满足两个目标的，但如果做不到就不要硬来，不要做“拔苗助长”的事情。先把目标一做好了，再考虑目标二。
那“傻瓜估算法”能不能满足目标二呢？
是可以的！做第二步进行WBS进行由底而上的估算时，这些WBS其实是可以分解成功能点或者是代码行的。当公司已经成功用“傻瓜估算法”满足目标一时，可以认真学习以下功能点法、代码行法的精髓，利用这些办法来提高估算的准确率。功能点法、代码行法这里就不详细论述。
Reply by "WantSong", 04-27-2009, 17:43
-----------------------------------------------------
不论是功能点、UC、还是生产率，首先都需要对范围进行界定。 而估算的难点在于范围的不确定性，范围越模糊，假设的成分也越多，估算的偏差也就越大。
不论是哪种估算方法，都将基于一个假设的模型（业务、工作）来考虑。如果模型一致，使用这些估算方法的结果应该殊途同归的。
可以做个试验，对已经开发了的系统，基于各种方法做一些估算，再与实际统计的成本进行比较。由于是已经开发了的，范围相当明确，也有最后的结果作为参照，这样可以调整估算方法中的参数。我曾经试过，很有意思，不过方法中的参数和计算公式是很难做到平衡的。如果需要更精确，就要交些高昂的学费了。
“把公司内部最有项目经验最有估算经验的工程们召集在一起，制订组织级别的估算表框架”，这部分工作能产出两部分内容，风险及风险储备，前提假设Checklist。对于估算所使用的参数，可能帮助不大。 |
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图