对一个项目的评估，往往被要求在项目需求还不明确的时候开始。不知道你是否有这样的体会，客户给你简单介绍了一点需求，或者发给你一份写的很粗略的文档，就要求你给个价格看这东西大概是要花多少钱多少时间才能建成。以前我做网站的时候，遇到过好多好多的这类问题。
对一个项目的评估，往往被要求在项目需求还不明确的时候开始。不知道你是否有这样的体会，客户给你简单介绍了一点需求，或者发给你一份写的很粗略的文档，就要求你给个价格看这东西大概是要花多少钱多少时间才能建成。以前我做网站的时候，遇到过好多好多的这类问题。
在 软件 开发过程中，总要面临一个"估算(Estimation)"的问题。这个项目需要多长时间?这个模块你大概多久完成?一共要花多少钱才能搞出来? 软件 开发的 成本 主常常用人月来计算，当然，也有人/小时，人/天。从数学上说，计算一个时间的先决条件，是必须要知道速率和距离。那 软件 开发度速率是多少?开发要走完的距离又怎么估计?
假定"人天"可以作为我们需要找到的速率(Velocity)的单位，就是某个人每天8小时能干的活的工作量，或说他的开发能力。对于一大堆待要开发的需求，它的总工作量和整个 团队 的单位开发能力的计算需要考虑更多的因素。
先来考虑需求的总量。我们来看这一个例子，列举你认识的满足下面条件的人：人，男人，20岁的男人，20岁的 头发有些染黄的男人，20岁的头发有些染黄抽烟的男人。从这一组词中，我们可以看到，从左到右描述的越来越具体，你能列举出的也越来越少。而反过来顺序，词的外延更大，你的能想到的却越来越多的。
同样的，对于需求的描述，如果描述的越细致，你就越能够准确的估算它的工作量。 登录系统，这样的需求很难说要多久。而一个使用用户名密码登录，支持找回密码功能的登录系统就稍微好一些。如果能够画出界面原型图那就更加清晰了。对于这样的需求，我们可以用"理想的人天"来评估。我们说某一个需求的 成本 ，是2 Ideal Days。 就是一个人在理想的2天内能够完成这个工作。
说到开发人员的"理想的人天"，就不能离开 团队 孤立的看。一个 团队 包括 项目经理 和需求分析师、测试员等角色。他们的工作不直接反应到代码量的多少。如果只考虑一个项目开发人员的代码开发量 成本 ，毫无疑问要亏损的。另外， 团队 成员水准参差不齐，不同的任务不同程序员来完成所花费的时间也不同。因此，单独相加每个成员的"人天"毫无意义。必须要整体考虑一个 团队 的总"人天"。
那么如何衡量一个 团队 的总"人天"?如果一个 团队 已经经过长期的磨合，那么可以从以往的数据来获得他们的开发量。 如果是新建立的 团队 ，没有经过磨合，那就需要开始实际进行一段时间的开发，在开发后3-4个星期再回头来计算这几个星期的 团队 速率。一般的，一个 团队 经过一段时间的磨合，在开发速率上会有缓慢的提升。例如一个需求的估算是5理想人天，而 团队 实际开发了10天。那么 团队 的速率就是5理想人天， 团队 的负载系数，即正常被其他事情干扰而降低的比率是2。
有了这个 团队 的速率， 项目经理 就可以放心大胆的说，我们 团队 有10人，开发能力是"n理想人天每周"，负载系数是2，由于有20n的需求总量，我们大概在40周左右完成。因此，我们的报价是xx,xxx,xxx元。
如果你有幸长期跟踪过一个 团队 的开发速率，就会发现很多有趣的现象。一开始， 团队 速率很低，但慢慢的成长。到达一定时期后，就会稳定在一个固定值附近。有时候有新的成员加入进 团队 ， 团队 的开发速率会出人意外的降低一段时间再慢慢回增。
成本 、时间、范围、质量，这是 项目管理 常见的四要素，四者很难同时满足。如果关心时间，又不想出钱，还要完成那么多功能，那牺牲的就真正是质量了。常说的一分钱一份货，在 软件 开发中反映的淋漓尽致。所以，为了能够保证按时按质完成任务，一个合理的开发价格是合格的 项目经理 必须能够估算出来的。而这需要长期经验和实践的积累，急不来的。
但有些时候，也有些不好处理的问题。有人问：我是老板，如果我的开发 团队 合起伙来编造一个估算，把我的需求估算的很多，而把他们的速率估算的很低，工起来工作量不饱和，老消极怠工怎么办?呃。我只能说，这只好借助于开发方法以外的事情了，例如奖金激励、绩效考核、引入外部咨询 团队 (例如ThoughtWorks)等等，人的问题不是能够简单靠过程就解决了的，如果道歉有用的话，要警察干嘛? 转
<script type="text/javascript"> function ImgZoom(Id)//重新设置图片大小 防止撑破表格 { var w = $(Id).width; var m = 550; if(w < m) { return; } else { var h = $(Id).height; $(Id).height = parseInt(h*m/w); $(Id).width = m; } } window.onload = function() { var Imgs = $("content").getElementsByTagName("img"); var i=0; for(;i
对一个项目的评估，往往被要求在项目需求还不明确的时候开始。不知道你是否有这样的体会，客户给你简单介绍了一点需求，或者发给你一份写的很粗略的文档，就要求你给个价格看这东西大概是要花多少钱多少时间才能建成。以前我做网站的时候，遇到过好多好多的这类问题。
在 软件 开发过程中，总要面临一个"估算(Estimation)"的问题。这个项目需要多长时间?这个模块你大概多久完成?一共要花多少钱才能搞出来? 软件 开发的 成本 主常常用人月来计算，当然，也有人/小时，人/天。从数学上说，计算一个时间的先决条件，是必须要知道速率和距离。那 软件 开发度速率是多少?开发要走完的距离又怎么估计?
假定"人天"可以作为我们需要找到的速率(Velocity)的单位，就是某个人每天8小时能干的活的工作量，或说他的开发能力。对于一大堆待要开发的需求，它的总工作量和整个 团队 的单位开发能力的计算需要考虑更多的因素。
先来考虑需求的总量。我们来看这一个例子，列举你认识的满足下面条件的人：人，男人，20岁的男人，20岁的 头发有些染黄的男人，20岁的头发有些染黄抽烟的男人。从这一组词中，我们可以看到，从左到右描述的越来越具体，你能列举出的也越来越少。而反过来顺序，词的外延更大，你的能想到的却越来越多的。
同样的，对于需求的描述，如果描述的越细致，你就越能够准确的估算它的工作量。 登录系统，这样的需求很难说要多久。而一个使用用户名密码登录，支持找回密码功能的登录系统就稍微好一些。如果能够画出界面原型图那就更加清晰了。对于这样的需求，我们可以用"理想的人天"来评估。我们说某一个需求的 成本 ，是2 Ideal Days。 就是一个人在理想的2天内能够完成这个工作。
说到开发人员的"理想的人天"，就不能离开 团队 孤立的看。一个 团队 包括 项目经理 和需求分析师、测试员等角色。他们的工作不直接反应到代码量的多少。如果只考虑一个项目开发人员的代码开发量 成本 ，毫无疑问要亏损的。另外， 团队 成员水准参差不齐，不同的任务不同程序员来完成所花费的时间也不同。因此，单独相加每个成员的"人天"毫无意义。必须要整体考虑一个 团队 的总"人天"。
那么如何衡量一个 团队 的总"人天"?如果一个 团队 已经经过长期的磨合，那么可以从以往的数据来获得他们的开发量。 如果是新建立的 团队 ，没有经过磨合，那就需要开始实际进行一段时间的开发，在开发后3-4个星期再回头来计算这几个星期的 团队 速率。一般的，一个 团队 经过一段时间的磨合，在开发速率上会有缓慢的提升。例如一个需求的估算是5理想人天，而 团队 实际开发了10天。那么 团队 的速率就是5理想人天， 团队 的负载系数，即正常被其他事情干扰而降低的比率是2。
有了这个 团队 的速率， 项目经理 就可以放心大胆的说，我们 团队 有10人，开发能力是"n理想人天每周"，负载系数是2，由于有20n的需求总量，我们大概在40周左右完成。因此，我们的报价是xx,xxx,xxx元。
如果你有幸长期跟踪过一个 团队 的开发速率，就会发现很多有趣的现象。一开始， 团队 速率很低，但慢慢的成长。到达一定时期后，就会稳定在一个固定值附近。有时候有新的成员加入进 团队 ， 团队 的开发速率会出人意外的降低一段时间再慢慢回增。
成本 、时间、范围、质量，这是 项目管理 常见的四要素，四者很难同时满足。如果关心时间，又不想出钱，还要完成那么多功能，那牺牲的就真正是质量了。常说的一分钱一份货，在 软件 开发中反映的淋漓尽致。所以，为了能够保证按时按质完成任务，一个合理的开发价格是合格的 项目经理 必须能够估算出来的。而这需要长期经验和实践的积累，急不来的。
但有些时候，也有些不好处理的问题。有人问：我是老板，如果我的开发 团队 合起伙来编造一个估算，把我的需求估算的很多，而把他们的速率估算的很低，工起来工作量不饱和，老消极怠工怎么办?呃。我只能说，这只好借助于开发方法以外的事情了，例如奖金激励、绩效考核、引入外部咨询 团队 (例如ThoughtWorks)等等，人的问题不是能够简单靠过程就解决了的，如果道歉有用的话，要警察干嘛? 转
3075
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
