读完这本书的第一章就能感觉到这是一本好书，可惜我读了近一半才想起写读书笔记；
作者是在探讨一个软件工程如何才能更好的完成，需要哪些东西，至少是如何不让一个工程失败；
1·书的前六章读完之后才想起写笔记，但是因为时间拉得太长的，没能记住多少东西，只是记住了几个必须要做的事；
为了保证工程的完成，我们必须正视工程所需的一切，不仅仅是怎么做这个工程；
在讨论怎么做之前，必须明白自己要做什么，需求分析正是为这个目的而生的，在明确做什么之前，一切都是空谈；
之后还要明白自己有什么，不同的工作需要不同的资源，我们要有合理合适的队伍，时间，工具来完成工作，这也是必须的；也许一开始我们并不能满足着所有的条件，但是如果确定要做，就积极的去找，去收集；
还有，对于一个软件，也就是一个产品，为了保证它的概念完整性，它的设计工作必须由一个或者极少数人来完成，不是一个人负责一个模块的分配，项目就可以进行了；软件也好，网站也好，最终都是用户来使用的，他们所面对的不能是一个支离破碎的东西，而应该是一件完整的产品；要保证软件的概念完整性，它的设计工作就不能让大众做决定。
当然这里有个人问题，由极少数人完成了设计工作，那么具体到实现人员是否还有创造性可言，书上说是这不妨碍，而且对于实现人员的创造性还会有所增强，也许吧。但是我还是有疑惑。
2·
做一个工程之前，需要有的几样基本东西，
清晰的目标；
人力；
材料；
足够的时间；
足够的技术；
交流以及由此而产生的组织；
这里主要强调的就是交流，参与工程的人员需要足够的沟通来互相交流想法，包括非正式的沟通以及会议沟通，还有记录一些变更和修改的书册；
3·
第八章看的云里雾里的，有点不知道什么意思。
不过大致意思是在讲述关于工程的时间控制的问题，在做一个工程之前，我们都会对工程进行时间资源和人力资源的需求估计，但是即使是一个熟练而仔细的团队对时间的估计也是很难符合实际要求的。大部分时候，我们的估计相比较实际都会偏少，真正的工程耗时一般都是估算时间的1.5或者2倍。
4·
第九章讲解了关于工程的空间预算控制；
但是，事实是我也没看太懂，悲催；
但是，从中得到的两个信息是，一个仍然是要注重交流和沟通，缺乏交流和沟通会让开发人员各自为战，每个人会在自己所在的领域不断的优化，但是一个致命的缺点是缺少一个统筹的意识；每一个开发人员的作品最终都不是单独运作，所有人的作品都是整个工程的一部分，所以必须有所沟通，尤其是设计人员和实现人员之间那种和谐而且仔细的沟通交流，必须保证每一个参与人员明白自己的职责和自己的边界。
另外，这一章有一个重要的论述，数据的表现形式是编程的根本
技艺的改进结果往往是战略的突破，就像一个新的发明可能会带来新的生产力的革命，在it业，一个新的技艺的出现也能带来战略性的突破。要注重技术的改进和发展；
5·
到现在，我所了解到的一个文档所应该包含的内容，包括
目标：定义带满足的需求和目标，定义迫切需要的资源、约束和优先级；
技术说明：产品的手册和技术说明；
进度，也即是时间；
预算，也就是资金；
组织结构图，也就是人员；
工作空间的分配：
报价、预测和价格；
1792
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
