从题目便可以感觉到这本书的与众不同，软件工程是一门理论与实践相结合的课程，而理论往往是严密且严肃的，它的这种独特的“传道授业解惑”的方式，也是大大吸引我们这些刚接触软件工程的学生或可称作菜鸟的人的注意力。之前的我也一直和书中的果冻类似，一直被绕口的官方解释所费解着，这样往往不能获得有价值或者易于理解的信息，这本书里白话甚至叙事式的讲解还真叫人收获颇丰。
开发经验不足的我在这本书里认识到了，敏捷开发，这在平时作业中也是小有体会的，虽然不会像书中或者一个大的项目中那样的系统且有条不紊。大工程分解为小的成果，在每个小的单元实现并测试之后合并对最终的效果影响很大，从设计到实现，设计与分配显得分量极重。
本书构建了一个虚拟的项目，并且围绕着一个完整的项目“导演”了一出实战的大戏，我们可以清晰地看到每一个工程角色在这个戏目中的表演，心态，甚至神情，这应该是对这本书的某几章的一个形象的概括了。
1.有哪些典型的错误的开发方式，刚刚接触软件工程的我们，在经验不足的情况下即使接受了敏捷开发以及一些高效的开发方式，在具体实施过程中不免走老路。
2.开发团队如何划分任务，怎么去评判团队中开发人员的能力并分配给相应的任务呢？也许团队中队员的能力差别较大，被误以为“抱大腿”的情况很多，作为菜鸟，或者作为大神，又要怎样去处理和队友的关系？
个人认为i，在团队中，我们要互相信任，信任他人可以暗示保质完成任务，同时也要为他人的信任负责，自己要尽自己的努力去保质保量完成任务。MSF也给了我们一个必须交流的项目合作模式，即在对任务的处理中，通过预设置的状态变更条件来完成简单的交流。
3.团队的合作中少不了代码的阅读，而大家的码代码习惯又有所不同，怎样使自己的代码可读性强？
若使自己的代码可读性强，规范的注释是必须的，正如上学期的面向对象课程中的注释的写法。其次，我认为代码实现过程中的设计是最为重要的，一个简介清晰的代码一定要比一个总是有多重嵌套的代码的可读性要高。
4.在这本书中，我读到了PM的重要地位，PM在项目的开展，实施过程发挥着举足轻重的作用，那PM又是怎样培养出来的，PM是否需要写代码，PM的优秀与否是以怎样的评判标准？
5.在我们写的代码中，经常在最后出现很多bug，更糟糕的是，bug总是越改越多，怎样的一个流程能够使得有效地减少bug,提高程序性能？
在修改代码时，不断保存之前的代码也许能够避免程序越改越糟，当进行不下去时可以恢复之前的代码。但是一个有效的修改策略才能真正提高效率。