从写上一次阅读笔记到现在，我读完了4-10章，下面做个总结。
这些章节主讲的都是软件工程团队方面的知识。在做项目开发上，肯定是离不开团队的，团队协作在这里就显得尤为重要。目前我在大学里学习还是单人编程，自己设计自己的作品，但按照主任的教学计划走，下学期我们也将成立各自的小组，算是初探“开发团队”模式。对于团队协作我是十分赞同的，我并不是那种特立独行的性格。如果有人能搭把手自然是最好的，但在团队也要注意不要给别人添麻烦——这就是我的想法。按照书中介绍的团队模式来讲，再结合老师平时说的一些团队协作方面的东西，用最简单的话说就是各自负责各自的模块，最后拼接到一起。虽然我还没有接触团队工作模式，但显然“拼接”是易错点。这个时候就要注意沟通问题了，沟通一向是团队工作中解决问题的最佳手段。
之前也说过“需求分析”的问题，但在读书过程中我发现了一个问题，假如用户方出现了需求更改，或者在原有的基础上添加了一个棘手的需求，导致工作变更怎么办？回答还是协商。坦白说看到现在我能用两个词概况软件工程要干的事情：开发与沟通。但要是跟用户协商沟通，虽然能达到一个妥协的局面，但难免会给用户留下一个不是很好的印象，毕竟用户看到的是最终结果，他不会管过程是否艰辛。我们作为开发人员也不可能直接跟用户说：“我们就按照你这个需求来了，不要再有变动了。”我们只能去预期变化，如果将变化的可能性考虑在内，做出应对会简单很多。
对团队模式的讨论，书中给了几种团队模式，如果从我个人的性格考虑，我更喜欢当个副手，我在主攻的时候并不是十分自信，因为技术不过硬。一个团队的开发流程显然遵循瀑布模型，至少在我看来这个模型很合理。让我在意的是怎样才能成为一个“敏捷团队”，如果我站在用户的角度，我指定的开发团队如果很“敏捷”，那我会非常开心。敏捷团队要求三点：自主管理，自我组织，多功能型。且不说后两个，第一点就能砍下去大部分人，人总是爱摸鱼的。此外，团队也是会出现变化的，比如人员变更什么的，这也是团队工作中要注意的一点，作为一个新成员要尽快融入进去；作为一个老成员要带新人，帮助他尽快融入氛围。这并不是领导者的义务，而是团队成员的义务。
第七章的MSF，之所以要单独拿出来说，是因为这一章，作为学生我看到的是高质量团队的高效率工作，他们能做出严密的测试工作，是实打实的敏捷团队。如果我以后步入工作，再回过头来看这一章，说不定能有新的收获。
软件工程团队已经做出了大量的介绍，接下来就是对用户的分析了。用户需求分析妥当，我们才能有目的的开发，才能拿到钱。那么我们在开发自己产品的时候，就要面向市场需求，首先就是定义自己这款软件，面向什么用户。面向学生，那就做的酷炫一点；面向大众，那就简约一点。而且每个用户期盼的功能还不一样，这也是一个考虑的点，为此要做出大量的市场调查。第十章的典型用户分析讲解的十分详细，包括规格说明书的写法，在这一章里我看到了很多干货。这是一个详尽的开发思路，而不是三分钟热度的“我要做这个”，“开始行动吧”，这种笼统的概括。