二.第五章“团队和流程”第二节“软件团队的模式”中为我们介绍了十种模式，我看过之后也有了一定的了解并选择出了适合自己团队的团队模式，关于开发模式不    是特别了解，书中第102页的课后题中也提到了，团队模式和团队的开发模式有什么关系？所以在这里想请教一下老师，团队的开发模式与团队模式有何关        系？

答：软件团队的模式包括以下几种：

（1）主治医师模式：一人为主，其他人为此人服务。

（2）明星模式：主治医师模式到达极致，一人的光芒掩盖所有人。

（3）社区模式：每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬。

（4）业余剧团模式：在不同项目中每个人扮演着不同的角色，可能随着项目的改变，自己的角色也会发生变化。

（5）秘密团队模式：一些软件项目在秘密状态下进行，别人不知道他们具体在做什么。

（6）特工团队模式：有一些有特殊技能的专业人士组成的团队。

（7）交响乐团模式：人员工具齐全，准备充足的团队。

（8）爵士乐模式：相对自由，有风险，人少且不靠谱。

（9）功能团队模式：具备不同能力的同事们平等协作，共同完成一个功能。

（10）官僚模式：层层领导的团队模式。

团队的开发模式包括以下几种：

（1）写了再改模式：和一窝蜂团队模式比较像。

（2）瀑布模型及其各种变形。

（3）RUP统一流程。

（4）老板驱动的流程。

（5）渐进交付的流程。

（6）TSP的原则。

至于团队模式和团队的开发模式的关系，我的理解是一群人在一起做软件开发，总是要一些方式方法。而这里团队模式就是这一群人的定性，团队的开发模式则是这群人使用的方法的定性。

三.第六章“敏捷流程”第五节“敏捷的问答”（书116页）中提到敏捷的方法论有三种，分别是FDD-Feature Driven Design,SCRUM以及XP，那么这三种方法论具       体是怎样的呢?我们是否可以把他们放到实践中呢？它们是否是最佳的实践方法呢？它们是分别适用于怎样的情况呢？

答：FDD是一个模型驱动( model-driven)、短期遍历(short-iteration)的过程. 注意，FDD是一个开发过程，过程总是有起点和终点，FDD的起点是起源于创建一个全局的模型轮廓（不要求很精确，大概模样就可以），然后大概是两周的一系列的"design by feature, build by feature"的迭代，逐渐丰富模型功能内容，features是指小的、以软件用户的视角看是有用的特征功能。

四.还是想问一下老师关于第六节练习与讨论中提出的第一个问题“什么时候适合选择敏捷？”我在书中看到，他说敏捷对团队的要求很简单，但是团队项目各式各     样，就算团队为了要变成敏捷流程，做出了敏捷对团队的要求，但是敏捷也不是万能的，它还是有它最适用的范围，那么这个范围是那些？我们什么时候选择     敏捷呢？

答：敏捷过程的适用范围 软件需求经常变化或者需求变化比较大； 项目团队与用户之间进行沟通比较容易； 项目的开发风险比较高；            规模比较小，一般项目组        成员在50 人之内； 项目团队的成员能力比较强，而且具有责任感； 项目的可测试性比较好。

五.我看了第13章“软件测试”，这一章中列举了许多种不同种类的测试方法。看过课本之后，我们知道，在软件测试阶段，可能遇到的问题可能比开发过程中遇到     的问题还要多，在这么多的测试方法中，我们应该如何选择最合适的测试方法，为了确保产品质量，我们是否应该选择尽可能多的测试方法进行测试？怎么处    理好在测试阶段中的问题，怎么运用不同的测试方法进行测试，需要老师为我们指导和讲解。

答：在测试项目之初就要制定相应的测试计划。接下来是如何编写测试计划问题。首先了解以下几个问题：

1． 为什么要编写测试计划？
      1）领导能够根据测试计划做宏观调控，进行相应资源配置等；
      2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等；
      3）便于其他人员了解测试人员的工作内容，进行有关配合工作

2． 什么时间开始编写测试计划？
    （测试需求分析前总体测试计划书/测试需求分析后详细测试计划书）

3． 由谁来编写测试计划？
      具有丰富经验的项目测试负责人

4． 测试计划编写6要素？（5W1H）
     1）why——为什么要进行这些测试；
     2) what—测试哪些方面，不同阶段的工作内容；
     3) when—测试不同阶段的起止时间；
    4) where—相应文档，缺陷的存放位置，测试环境等；
    5) who—项目有关人员组成，安排哪些测试人员进行测试
    6) how—如何去做，使用哪些测试工具以及测试方法进行测试。

由此，关于测试的问题都可迎刃而解了。

六.我看了第四章“两人合作”的第四节“代码复审”，关于代码应该如何进行复审这一问题，我还是不太懂。复审过程中牵涉的人员众多，理解度不一等等各类问         题，我们应该怎样做才能更有效的进行复审呢？

答：在复审前 ：

1. 代码必须成功地编译，在所有要求的平台上，同时要编译 Debug | Retail 版本。编译要用团队规定的最严格的编译警告等级。

2. 程序员必须测试过代码。什么叫测试过？最好的方法是在调试器中单步执行。

3. 程序员必须提供新的代码，以及文件差异分析工具。

4. 复审者可以选择面对面的复审、独立复审或其他方式。

5. 在面对面的复审中，一般是开发者控制流程，讲述修改的前因后果。但是复审者有权在任何时候打断叙述，提出自己的意见。

6. 复审者必须逐一提供反馈意见。注意，复审者有权提出很多看似吹毛求疵的问 题，复审者不必每一件事都要亲自调查，开发者有义务给出详尽的回答。

7. 开发者必须负责让所有的问题都得到满意的解释或解答，或者在 TFS 中创建新的工作项以确保这些问题会得到处理。

8. 对于复审的结果，双方必须达成一致的意见。

1） 打回去 — 复审发现致命问题，这些问题在解决之前不能签入代码；

2） 有条件地同意 — 发现了一些小问题，在这些问题得到解决或记录之后，代码可以签入，不需要再次复审；

3） 放行 — 代码可以不加新的改动，签入源码控制服务器。要注意避免不必要的繁文缛节，我们做代码复审的目的是为了减少错误的发生，而不是找一个人来对着你的代码点头。一些简单的修改不是非得要一个复审者来走一遍形式。在项目开发的早期斤斤计较于一些细枝末节（例如：帮助文件里的拼写错误，数据文件格式不够最优化等）也是于大局无补的，但是，这些问题并不是不用处理了，我们可以建立一些优先级较低的工作项来跟踪处理。