MSF九大原则：
1. 推动信息共享与沟通:“谐”，Alert
2. 为共同的远景而工作:目标明确—用户/老板
3. 充分授权和信任:
4. 各司其职，对项目共同负责:
5. 交付增量的价值:
6. 保持敏捷，预期和适应变化:
7. 投资质量:
8. 学习所有的经验:
9. 与顾客合作:
MSF团队模型定义了小组同级成员的角色和职责：用户体验、产品管理、项目管理、开发、发布管理、测试。我惊讶地发现，在分配职责时“用户体验”显然不是一项团队的开发活动，MSF使用了“结果”（Outcome）来进行定义，而不是Action.
而过程模型——螺旋模型，除了干活之外，十分注重规划优势、交流与增量式开发，这与之前提到的敏捷原理不谋而合。
软件需求方面，体察用户需求上，调研“可用性”成为一个非常容易忽略的因素，为了避免“用户在各种菜单中幽幽暗暗反反复复地寻找某个功能，我们在单向玻璃后面替他着急……我们的界面里’平平淡淡从从容容才是真‘差太远了”，我认为：开发人员应该成为用户的一部分。正如我们的项目源于自己的需求而非纯功利性的获益，本身就身为用户的我们就能更好的体察到用户的感受。
而另一个让人深思的问题则是人类学调查，面对着海量用户，或许我们真的不需要非常geeky的手段与狂拽酷炫的界面，简单实用才能适用于大多数的人，太高端的功能反而得不到普通人的青睐。
Estimate估计是指计划时间、以当前了解的情况和掌握的资源，要花费多少人力物力时间才能实现某事。有了对开发时间的估计，我们才能明确目标和并且及时在岔路口觉醒。书中举了许多例子中国陆地边界长度、非洲人口密度、长江年流量、2013年亚洲货币流通总量、一生说过多少句话等等，这些数据很难一眼就估计出数量级，并且大多数时候人们总是有一种对自己有利的倾向。
在估计之后，我们还要找到估计后面基于的假设，推动数值收敛，使上下界不断接近。通常的公式是：实际时间花费Y=X+-X/N，X为估计时间，N为类似开发工作的次数
最后书中介绍了WPS分割树，要点从结果出发构建而不是从团队的活动出发，叶子节点足够小，子节点不相互覆盖，所有子节点覆盖全部父节点内容。从结果出发构建正好与之前MSF团队模型不谋而合。