本文目录一览

1，人月是什么时候

指的是一个时间段的工作量（一个月的工作量），不是一个时刻。通常在表达工期的时候用的词语。类似的还有人日，指的就是一个工作日的工作量，此外还有人时，指的是一个小时的工作量。

人月是什么时候

2，1000多人月 什么意思啊 哪位大侠知道啊

人月是指单位，就是说 人数*月 ，比如说，1000人月，是1000个人做了一个月，或者20个人做了50个月
HOHOO.那哪是自习啊.我就乖乖的呆着六楼.

1000多人月 什么意思啊 哪位大侠知道啊

3，人月怎么理解

人月是工作量的计量单位。1人月就是一个人一个月的工作量。人月的其他写法也包括 人×月 或者 人·月。
听说过人月两圆 两完还是头一次听说 人月两完，是不是情走到了尽头？一切已经结束。

人月怎么理解

4，软件开发项目大小单位人月日语怎么说

人月 にんげつ ningetsu
人月(にんげつ)例:3人月 三人月(さんにんげつ)
你好！人月(にんつき）一般是指人工（计算成本）。特别是开发，设计等业务。参考一天的人工是：人日（にんにち）打字不易，采纳哦！

5，什么是人月

软件工程里面的一个概念，人月，一个软件开发的工作量单位。但是想请教大家一下，我既然知道了这个项目需要那么多人月，如200人月，10个人开发，那算来就是花20个月就可完工，但是为何还要已经有了具体的人月还进行如putnum方法的具体开发时间的估算呢。
难道说200人月用10人20个月可以完工，用200个人的话就1个月可以完工了？ 所以要估算。

6，人月神话中的人月是什么意思

说到这里, 要说一下人月神话. 我们所有的进度都是以 人月 代码产量来衡量的. 而增加"人"并不能缩短"月"的量. 一个目标产品本身能有多大的代码量大致不会和预算的相差很多. 这时我的经验, 当然也有一些连代码量也估算不准的LEADER. 我们通常会最终会将代码量分解到每个模块, 并且根据程序员的工作能力来分配进度要求. 在很多情况下, 遇到进度失衡的时候, 第一反应是增加人手. 但是事实上增加人手的项目不到10%能准时解决. 很多情况下, 增加进去的人手并不能真正进入工作, 因为模块已经无法细分一小块出来给新加入的人手. 又或者新加入人手熟悉现有代码结构的时候已经到达项目终止时间. 而人月代码产量本身就不是一个固定的值. 我的最高写作时刻可以达到1600行/天. 真的就是32000行/月了么? 不! 更多时刻的代码产量在200-300行/天. 也有很多一个算法就花费1天. 变得只有100行/天的情况. 真正比较客观的状况, 根据最近3年的状况, 5000行/3月是比较客观的量. 这是C/C++的速度. 是我的速度, 其他程序员有这样的效率么? 真正能超过的并不多见. 即使是这样的代码效率, 也并不适合将计算进入商业产品的进度考虑.(个人完美产品和商业完美产品将在以后有写作欲的时候写) 因为很多难点并不是因为降低人月代码产量就能够攻克的. 我本人目前比较倾向的时间分配,也是比较真实的时间分配, 没有难点的时间分配 20% 代码编辑 30% DEBUG 30% 文档 20% 保留时间. 这就说明即使在没有已知难点的状况下. 有20%的保留时间仍然有必要. 因为很有可能1个小小的数学逻辑就能让你忙上半天一天. 这并不是不专心, 而是疏忽导致的. 而且从来就没有人能避免疏忽. 而30%文档时间有时并不能完成很漂亮的文档. 了解了这个神话, 我们就可以采取主动行动. 1.首先, 不要低估任何一个产品的难度, 难度估计得高点总是没有错的.(我曾经犯过多次这样的错误) 这样, 在确定任务进度前争取更多的时间. 2.很显然, 既然有可能在任意时刻发生问题, 为什么不提前多干点呢? 很少有人愿意这样. 但是我的经验是一定要提前多干. 在最近的2个项目中, 都是提前很多时候完成了大部分的工作. 90%的东西完成了, 而产品交付时间则剩下1个月. 眼看可以轻松了, 却仍然忙着攻克最后的难点, 到了最后一天才真正完成任务. 险得很. 按照时刻表完成进度的程序员都一定会翻船. 不信! 哼, 随便找一个去看看. 我很自信这点的判断. <>有着好的程序员可能效率比糟糕程序员高10倍的可能性.在我的人月神话中确实有着好的程序员比糟糕的程序员速度快上10倍的例证. 当时团队中一天无法完成一个极度简单功能的PROGRAMMER.(不知到此人现在怎么样) 但是在人月理论中, 这样的人也照样要占着进度表的一条... 参考资料：http://www.boraid.com/darticle3/list.asp?id=12900
shi bu a
人年就是一个人一年的工作量

文章TAG：人月  是什么  什么  什么时候  人月  
下一篇