对理想团队的设想：书中介绍了很多很有趣的，我从未了解过的（而且讲的十分通俗易懂）团队合作模式，并不是像现在自己在学校里的那种乱哄哄（窝蜂模式）或者 大多自己一个人挑大梁的（和主治医师模式、明星模式很像）：社区模式、业余剧团模式、秘密模式、特工模式、交响乐团模式、爵士乐模式、功能团队模式、官僚模式。（说实话，看见这些名字自己就已经很感兴趣了。）而对于自己理想团队的设想，我是这样想的：一个好的团队，大部分都需要是“猪”，一小部分的“鸡”，以及个别“鹦鹉”。（人都是活在现实中，和自己不一样的人、相似的人都对塑造一个越来越好的自己起一定的作用，像运送沙丁鱼的故事）模式有点像功能团队+官僚模式，每个人都有自己特别的能力，负责一定的部分，同时每个人都以一种“大老板”的视角去对待自己的项目，而且，每个人都是这个项目上都是平等的，意思是，每个人的想法都应该得到尊重，大家不会因为身份而忽视掉对方，而是把对方同样视为自己的“小老板”或者“大老板”，但同样也可以提出自己的看法，再由大家一起定夺。，虽然这样看上去可能浪费掉更多时间和精力，但这种模式可能为后期减少不必要的花费，以及提高大家的参与度，不在只是将自己视为“打工仔”。
软件流程的理解 ：软件流程有：写了再改模式（在学校里大多都是这种吧）、瀑布模型以及它的各种变形、Rational Unified Process 统一流程RUP、老板驱动、渐进交付等等。我觉得，符合TPS（Team Software Process）原则的，都算是好的优秀的模式，流程。（其中有一些方法比如迭代开发，MVP、MVP 都让我眼前一亮，大开眼界，有点期待还未看得敏捷流程，MSF。也理解为什么很多人几天时间就把它看完了）我比较喜欢RUP统一流程和渐进交付这两种方法，现实中需要我们不断重复之前的步骤，而不是完成其中某一部分之后就不再出现的，并不是。就像测试，很多人觉得测试就只是在最后完成软件后测试下能不能实现预期的功能，满足了用户需求就好了（以前我也真是这样觉得），但事实上，在了解需求的时候就可以进行相应的一些测试，这些测试并不是我们了解的意义上很狭隘的测试，而是测试用户的需求等等。所以在迭代开发的那张表中，我觉得比较合理的是无论是哪个阶段，无论是哪个部分，都应该出现一个小驼峰，整个表呈现出多个驼峰。同时，里程碑只能说60%那部分已经完成，剩下的40%应该穿插在其他的阶段。
个人的一些问题：
1，在第17章里，P369，萝卜与白菜的故事中，可以以萝卜+白菜以Team的形式（萝卜以开发为主，白菜以修补为主，程序员+检测员）进行开发吗？
2，在第5章的团队和流程里，我看到的大多是团队之间的合作去完成项目，而很少说到个人在团队里的作用，个人在团队里的角色，仅仅是以“猪”“鸡”“鹦鹉”来区别就够了吗？有时候我觉得可以在团队里加一个观察者的角色，来观察队员，为他们的表现评分，评定他们的绩效，以及判断他们更适合什么工作，起人尽其用的作用