人月神话阅读笔记02
在写这篇博客之前，结合这章的内容，我回顾了一下我的第一个团队项目：网页版二手网站“转赚”，现在还在构建的过程中，这是第一次团队的项目，老师让我们像一个真正企业中的做项目一样，也会制作任务板、进行站立会议。
“团队”这个名词听起来就会觉得很有正能量，但是真正做到一个项目团队该有的样子又是怎样的不易，说实话我们项目团队的凝聚力确实不够，不仅团队其他人的问题，连我自己就有问题，交流沟通了解都是需要时间的，在这短短的两周，对我来说有点难。刚开始我们开始大胆的想象，构思了好多功能，但是到最后去实现的时候，就遇到了很大的问题，对自己的技术要求过高，所以每当编着编着就要百度查一下，不仅浪费了太多的时间，而且完成的东西还是有缺陷，也盲目乐观了。
在书上讲到了关于这方面的知识：
1.
在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。导致灾难的原因是：
首先，我们对估算技术缺乏有效的研究。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相混淆
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这工作。
第四，对进度缺少跟踪和监督。
第五，当意识到进度的偏移时，下意识（以及传统的反应是增加人力）。
- 系统开发过程中，乐观主义并不应该是理所应当的。
在单个任务中，“一切都将运转正常”的假设在时间进度上具有可实现性。因为所遇的延迟是一个概率分布曲线，“不会延迟”仅具有有限的概率，所以现实情况可能会像计划安排的那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。
3.
成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数
量和时间是可以相互替换的。因为软件开发本质上是一项系统的工作错综复杂关系下的一种实践沟通交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。
从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
4.
在时间进度中，顺序限制所造成的影响，没有哪个部分比单元测试和系统测试所受
到的牵涉更彻底。对于任务的进度安排，以下是作者使用了很多年的经验法则：1/3
计划 ，1/6编码 ，1/4构件测试和早期系统测试（单元测试），1/4系统测试
5.
如果发现项目的实际进度滞后于预计的进度，项目经理最好的办法是重新安排进度，而不是增加项目人手。
6.
项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度表。总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还要大。
从这些内容中我明白了：
团队之前要多沟通交流，而且要互相换一下彼此的角色，而且要对自己的能力有一定的准确估算，作为一个项目经理，一个项目的灵魂人物，项目经理要随时调整进度，就比如我们组长李同学，他虽然不善沟通，但是对于这一点他做的就非常好，时刻根据项目的进度调整进度的安排，这一点不得不赞扬，但是沟通交流的问题也需要重视，只有加强沟通交流，才能使学术交流的最大化。
