《人月神话 （32周年中文纪念版）》学习笔记

一直在制造错误解决方案，问题决定解决方案， solving the wrong problem

第一章：焦油坑 The Tar Pit

1、程序，编程系统（接口和系统集成），编程产品（通用化，测试文档，维护），编程系统产品

2、职业的快乐，和职业的苦恼（1，追求完美，学习编程最困难的部分是将做事的方式向追求完美的方向调整，2，来自由他人设置的目标，供给资源和提供信息，3，bug寻找是一件很苦恼的事，4 无奈，投入大量劳动，产品完成了，却已经陈旧过时）

我们最大的挑战和任务是在实际的进度和有效的资源范围内，寻找解决实际问题的切实可行方案。

第二章：人月神话 The Mythical Man-Month

3、（乐观主义）系统编程的进度安排背后的第一个错误的假设是：一切都将运作良好，每一项任务花费它所“应该“花费的时间

4、创造性的活动分为：构思，实现和交流

5、（人月）谬误的思考方式是在估计和进度安排中使用的工作量单位：人月，暗示人员的数量和时间是可以相互替换的。成本随着开发人员的人数和时间的不同，有这很大的不同，但是进度却不是。

人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流

当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助，在相同人月的前提下，采用增加人手来减少时间得到的最好情况，也比未调整前要差一些

沟通的负担：培训和相互的交流

6、（系统测试），1/3计划，1/6编码，1/4架构测试和早起系统侧实，1/4系统测试，所有的构件已完成，大多数项目的测试都花了进度中的一般时间，不为系统安排足够的时间，简直就是一场灾难，在早期进度策划时，允许充分的系统测试时间是重要的。

7、（空乏的估算）开发并推行生产率图标，缺陷率图表，估算规则等或者在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持他们的估计，确信自己的经验和直觉总比从期望生产的结果要强的多

8、（重复产生的进度灾害）简化的Brooks法则：向进度落后的项目中增加人手，只会使进度更加落后（Adding manpower to a late software project makes it later）

总之，在缺乏合理的进度安排是造成项目之后的最主要的原因，它比其它所有因素加起来的影响还要大

第三章：外科手术队伍 The Surgical Team

1、需要协作沟通的人员数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引发的不良结果（系统调试）

2、对于效率和概念的完整性来说，最好是由少数干练的人员来设计和开发，而对于大型系统，则需要大量的人手，以使产品能在时间上能满足要求。那么该如何调和两方面的矛盾?

传统的俩人队伍 和 外科医生-副手团队架构区别：1】传统一人负责一部分工作的设计和实现，后者，是主副了解所有的设计和全部代码，2】传统大家平等，如有问题需要妥协和让步，外科医生中，能达到可观的一致性，另外就是团队人员高度专业化，团队交流比较简单。

外科医生，副手，管理员，管理员文秘，编辑，编辑文秘，程序职员，工具维护人员，测试人员，语言专家

3、团队的扩建，当我们面对几百人的队伍的时候如何应用外科手术团队的概念？

协调外科医生的思路，前提是一个高效的系统架构师，从上至下的系统架构设计，必须清晰的划分体系的设计和实现的界限，上述的角色分工和技术是可行的。

更新中。。。。