[【转】人月神话读后感]
堵哥哥要我写人月神话的读后感，先找一篇膜拜一下~~~
————————————————————我是分割线————————————————————————
《人月神话》这本书风行已经很久了，写成于1975年，经历这么久的时间，在当前又重新流行，让我很惊讶,但是一直没有时间读，【转】人月神话读后感。今天突然想起自己的机器上有本拷贝别人的电子书，决定读读。
我今天只看了两章，即焦油坑和人月神话。人月神话看上去这么浪漫的名字，原来并不是真的说神话故事，作者阐述的主要观点是在软件开发项目上项目进度和增加人员这两个概念是不能互换。
虽然已经时隔20多年了，这本书依然给我震撼，一是让我惊讶的是，美国20年前软件项目所面临的问题，在我们现在依然如此，糟糕的情况没有改变，大家仍旧在焦油坑里挣扎，而且看上去没有解决办法。
二是作者对软件项目失败的总结，每一个问题我们依旧再犯，特别读到“是当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环，读后感《【转】人月神话读后感》。“，我对这句话简直是太有感触了，因为我身边这样的悲剧整天都在上演，公司对所有的项目搞得都是人海战术，进度没有提前，还整天加班，最后用户不满意，开发人员整天郁闷，结果是用户对公司失去了信任，成了一槌子买卖，开发人员就像割韭菜，旧人一一辞职，新人天天引进，公司何谈发展和积累，做了n年，涛声依旧，做法没有改变，情况没有改观，公司没有发展，好在中国人多地大，呼悠完一个行业，再呼悠另一个行业。
三是作者在那个时候，就根据自己的经验提出了对于软件任务的进度安排，以下是作者使用了很多年的经验法则：
1/3计划
1/6编码
1/4构件测试和早期系统测试
1/4系统测试，所有的构件已完成
我们公司是通过cmm3认证的，理论不用我说，大家好像都明白，实际情况呢，有谁真的拿出那么多时间作计划，又有谁拿出那么多时间作测试，不过令人欣慰的是，大家确实在向这方面改变，比如我们公司测试部现在就是一个很大很关键的部门，所有的程序发布都需要测试人员的签字。
当然，也许可以找点客观原因，比如现在国内多数客户不成熟，签单子靠关系，一旦签了又
恨不得明天就正式运行，但是本着“没有任何借口”的观点，我们该怎样改进呢，我决定读下去，看看能否找到作者所说的银弹呢。
[【转】人月神话读后感]
堵哥哥要我写人月神话的读后感，先找一篇膜拜一下~~~
————————————————————我是分割线————————————————————————
《人月神话》这本书风行已经很久了，写成于1975年，经历这么久的时间，在当前又重新流行，让我很惊讶,但是一直没有时间读，【转】人月神话读后感。今天突然想起自己的机器上有本拷贝别人的电子书，决定读读。
我今天只看了两章，即焦油坑和人月神话。人月神话看上去这么浪漫的名字，原来并不是真的说神话故事，作者阐述的主要观点是在软件开发项目上项目进度和增加人员这两个概念是不能互换。
虽然已经时隔20多年了，这本书依然给我震撼，一是让我惊讶的是，美国20年前软件项目所面临的问题，在我们现在依然如此，糟糕的情况没有改变，大家仍旧在焦油坑里挣扎，而且看上去没有解决办法。
二是作者对软件项目失败的总结，每一个问题我们依旧再犯，特别读到“是当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环，读后感《【转】人月神话读后感》。“，我对这句话简直是太有感触了，因为我身边这样的悲剧整天都在上演，公司对所有的项目搞得都是人海战术，进度没有提前，还整天加班，最后用户不满意，开发人员整天郁闷，结果是用户对公司失去了信任，成了一槌子买卖，开发人员就像割韭菜，旧人一一辞职，新人天天引进，公司何谈发展和积累，做了n年，涛声依旧，做法没有改变，情况没有改观，公司没有发展，好在中国人多地大，呼悠完一个行业，再呼悠另一个行业。
三是作者在那个时候，就根据自己的经验提出了对于软件任务的进度安排，以下是作者使用了很多年的经验法则：
1/3计划
1/6编码
1/4构件测试和早期系统测试
1/4系统测试，所有的构件已完成
我们公司是通过cmm3认证的，理论不用我说，大家好像都明白，实际情况呢，有谁真的拿出那么多时间作计划，又有谁拿出那么多时间作测试，不过令人欣慰的是，大家确实在向这方面改变，比如我们公司测试部现在就是一个很大很关键的部门，所有的程序发布都需要测试人员的签字。
当然，也许可以找点客观原因，比如现在国内多数客户不成熟，签单子靠关系，一旦签了又
恨不得明天就正式运行，但是本着“没有任何借口”的观点，我们该怎样改进呢，我决定读下去，看看能否找到作者所说的银弹呢。