今天看了这本书的一部分，作者以“人月”为单位，刻画了开发过程，印象深刻的是作者在结构师的角度进行关于项目进度的刻画，突出了按时完成任务的重要性，否则只能一步慢步步慢，如果为了项目的如期交付，可能需要更多的人参与进来，这是建立在浪费一部分时间上的，由此得出了“向进度落后的项目中增加人手，只会使进度更加落后”。
在我们平时的作业中，经常会因为某些能力不足导致一些问题无法解决而使其停滞不前，落后一步就要步步落后，真的是很苦恼。
有这方面的困扰的人可以借鉴作者对于进度安排的经验：1/3计划，1/6编码，1/4构件测试以及1/4系统测试。
还有笔者发现效率高，能力强的工作者对开发成本的控制使非常有利的，所以实力才是硬道理。
产品设计人员
在团队中进行开发时，尽早的交流和持续沟通能使结构师有较好的意识成本，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。交流是对他人思想的理解，寻求开发中的疑云的有效途径，可以使项目开发的模块，细节等得到很好的落实，使开发的结构变得更为理想。如果缺乏交流，仅仅是自成一隅，很可能由于其他人的各种假设，团队成员之间的理解出现偏差，结果可想而知。
出于精确性的考虑，我们需要形式化定义和记叙性定义中的一种作为标准，另一种作为辅助措施。
软件开发人员必须设立规模目标，控制规模。如果规模不受控制，运行时间大大增加，占据的内存也不小，这样的软件应该没有人会喜欢用吧。规模本身不是坏事，但不必要的规模使不可取的。我们要从系统整体出发，持有面向用户编程的态度。
尽量少，得到概念的完整性，
文档在开发中的重要性不言而喻，对于软件项目，要求是：目标、用户手册、内部文档、进度、预算、组织结构图和工作空间分配，有了规范的文档，才能进行有序的开发。
对于大多数项目，第一个开发的系统肯并不合用，可以丢弃系统和重新设计，这个是必须完成的步骤。在学习过程之中，通常都是一个项目完成后就丢下了，甚至有些模块的功能无法实现而放弃，可以在在一段时间内回过头去看看自己写过的项目，是否可以进行改进。
软件工程的一些特殊问题值得我们思考：
1.如何把一系列程序设计构建成系统。
2.如何把程序或者系统设计成健壮的、经过测试的、文档化的、可支持的产品。
3.如何维持对大量的复杂性的控制。
谈到这些，脑海中立马浮现出了一系列字眼：分而治之，愚公移山等，其他有效的方法还需要在开发过程中慢慢体会，慢慢总结。
整个系统将会开发的更快，易用性实际上需要设计的一致性和概念上的完整性。做一个项目之前，首先要有完整的架构，这样是比较合理的，如果只是一味注重编程，有时候会发现成果与期望大相径庭