第一章的问题：随着软件工具的开发我认为能减轻这些难点，而且不会不利于一个团队密切的严密性？
第二章：在经过百度我理解到了单元测试与回归测试的算法在此就不一一回答，还有一个temp的分工应该根据每个人的优点和处事能力分工的。
第三章：证件和能力有时候是相互互补的，因为你能考到什么位置的证件就具备着什么样的能力。
第四章：在2人合作中，调试工作应该由操作者来处理，能力高者辅助配合。
第5章:在团队中，模式是切换使用，因为计划永远赶不上变化，选择最合适团队的模式就好。
5.3老板的能力以及决定的因素，可以影响一个团队，但是不一定能改变一个团队,员工在一个团队也是占有一定分量的！
6.3敏捷流程是以人为核心的迭代循环渐进的开发！
7.3MSF主要包括三个模型：1、 规划，企业的总体结构规划的过程提供和揭示了商业运行的标准和所受的局限，使商业运作过程更易管理，费用低。它以一种“边规划，边设计”为基础， 就意味着在企业的总体结构规划中可以一直的伴随商业需求变化和技术发展的连续过程。它受企业模型所控制，且可以直接影响企业总体结构发展的影响。 2. 构建，构建包含了定义方案开发准则，组件方案设计和可用设计。它可以克服自上而下的方法会抑制创造力，有效的交流和真正的方案开发，且可以更好的 满足商业需求和功能设计，强调用户界面和操作衔接等原型技术。3、 维护，强调一致的规划和管理给系统带来了好处和费用的降低。瀑布模型： 依照固定的顺序连接的若干阶段工作，规定了自上而下的相互衔接的固定顺序，但并非完全是自上而下的线性因式，由上一阶段向下一阶段开始进行开发，严格地控制了软 件开发项目的进度，最终能按时的交付产品及保证软件的质量创造了有利的条件，但是其缺乏灵活性，无法通过开发活动澄清原本就不够确切的软件需求，使开发出来的软 件与用户期望的相差很多，最终返工，不得不在维护中纠正偏差，使费用最终很高，造成很多的损失。
第8章：我们可以以实际的预测产品演示给顾客看，或者简单化的介绍给顾客，以相互理解为主！
第9章：1. 号召力 2. 交流能力 3. 应变能力 4. 对政策高度敏感 5.管理技能。
第10章：定义典型用户对我们的影响取决于主要取决于需求!
10：功能驱动这方面多多去了解，多去百度搜索一下了解下。
11：怪一个团队，一个团队的分工虽然由master决定，但是赶不上也可能是个人的因素，所以2者之间都有不可避免的责任，所以还是多多的考虑下自己有没有不足的地方可以反思下尽可能做的最好。
12：用户的调查是最主要的一步，因为用户的调查可以看出你这个产品的利用价值，还有你的产品的使用率，也就是决定了你这个产品有无利用价值的调查。
13.在写代码过程后，运用各种测试来检测自己代码是否错误时，主要根据每个人的习惯来采取不同的测试方法，这样主要还能达到效率的最大化，还可以避免一些技术上的误导，导致越做越乱之类的烦恼。
14.软件的质量主要是根据软件的不一定使用度来决定，或许你的软件还有价值但是没人发掘到，不过多数软件做出来都是为了能够被人使用才被制作的，所以一个没有多少用的软件质量还是无法保障的。还有质量的保障中我们应该偶尔翻新软件，如果有价值的软件，我们可以不断的继续翻新，但是对于一个不太有用翻新了也无用处的软件可以不必翻新。
15.会诊小组我个人认为应该由一些细心有能力的人来充当，然后由程序的创作者来辅助，这样才能达到效率的最大化，
16.一个软件的创新过程中，如果发现一个创新的软件没多大用途是否要中途放弃？这个问题我觉得看个人，如果你觉得做下去有意义，那就继续做下去，如果想放弃就放弃，总之看个人。
17.没有什么问题。。