今天阅读了构建之法第5章团队和流程，团队和非团队的的特点在于：团队有一致的目标，团队要一起来完成这个目标。一个团队的成员不一定要同时工作；团队成员有各自的分工，相互依赖合作，共同完成任务。好的软件团队会有好的业绩。现在我们的这种团队就像是一窝蜂的模式，编写哪个功能就一群人都围上去，这样的团队模式没有很好的机会去让人去很好的观察，这并不是一个很好的团队模式，同时我认为也失去了团队所带来的效率问题。当然随着时间的发展我们的团队也会发生变化，有的变成了主治医师模式：一个人发挥，其余人跟着打酱油，现在在我们这种小的团队中这种模式经常出现，这个同学学习好，大部分程序都会做，而我们这些都不会，大部分成员的想法都是：等他做完，我们跟着看看怎么写的；就这样就这一个学生来做程序，其余人都跟着打打下手，在这种模式下，不仅失去了团队的意义，而且个人也得不到发展.
学校里面的软件工程专业的学生可能是"写了再改模式"，因为作业是这么要求，但是这种开发方法的缺点特别大。软件行业一开始也会使用"瀑布模型"，即分析-设计-实现-销售-维护的模式，但是对于软件工程来说，需要做很多次的回溯。但是慢慢发现回溯很困难等等的其他问题，需要在生产出产品之后才能知道产品的实用性，这是很头疼的问题。后来根据"瀑布模型"提出了生鱼片模型，但是问题是：不知道上一个阶段什么时候结束。后来引入了子瀑布模型，但是难度相当大，用户只有到了最后才能看到结果，也不实用。
对于这一章我的阅读最深的感悟是，一个好的团队需要各个成员的共同努力，必须要有明确的分工；同时要遵循一定的开发流程，提高代码质量和软件的使用性能。