4. 要求提交代码前做Code Review，而开发人员不做，或敷衍了事，怎么办？

如果每个开发人员都是积极主动的，Code Review的作用能落到实处。但如果不是呢？团队管理者需要一些手段促使其有效地进行Code Review。首先，我们采用的Code Review有2种形式，一是Over-the-shoulder，也是2个人座在一起，一个人讲，另一个人审查。二是用工具Code Collaborator来进行。无论哪种形式，在提交代码时，必须注明关于审查的信息，比如：审查者（Reviewer）的名字或审查号（Review ID，Code Collaborator自动生成），每天由一名专职人员来检查Checklist中的每一条，看是否有人漏写这些信息，如果发现会提醒提交的人补上。另外，某段提交的代码出问题，提交者和审查者都要一起来解决出现的问题，以大限度避免审查过程敷衍了事。

博主Inovy在某个评论说的很形象：“木（没）有赏罚的制度，是带到厕所的报纸，看完可以用来擦屁股了。”没有奖惩制度作保证，当然上面的要求没有什么效力。所以，当有人经常不审查提交，或审查时不负责任，它的绩效评定会因此低一点，而绩效的评分是跟每年工资涨落挂钩的。说白了，可能某个人会因为多次被查出没有做Code Review提交代码，而到年底加薪时比别人少涨500块钱。

5. 软件研发到底需不需要文档？

软件研发需要文档的起原可能有2种，一是比较原始的，需要文档是为了当开发人员离职后，企业需要接手的人能根据文档了解他所接手的代码或模块的设计。二是较高层次的，企业遵从ISO9001质量管理体系或CMMI。

对于第一种，根源可能来自于两个方面：

- 原开发人员设计编码水平不高，其代码可读性较差。

- 设计思想和代码只有一个人了解，此人一旦离职，无人知道其细节。

在编码前写一些简单的设计文档，有助于理清思路，尤其是辅以一些UML图，在交流时也是有好处的。但同时，我们也应该提高开发人员的编码水平增加其代码的可读性，比如增强其变量命名的可读性、用一些被大家所了解的设计模式来替代按自己某些独特思路编写的代码、增加和改进注释等等，以减少不必要的文档。另外推行代码的集体所有权（Collective Ownership），避免某些代码只被一个人了解，这样可以减少以此为目的而编写的文档。

对于第二种，情况有些复杂。接触过敏捷开发的人都知道《敏捷宣言》中的“可以工作的软件胜于面面俱到的文档”。接触过CMMI开发或者ISO9001质量管理体系的人知道它们对文档的要求是多么的高。它们看起来水火不相容。但是，它们的宗旨是一致的，即：构建高质量的产品。

对于敏捷，使用手写用户故事来记录需求和优先级的方法，以及在白板上写画的非正式设计，是不能通过ISO9001的审核的，但当把它们复印、拍照、增加序号、保存后，可以通过审核。每次都是成功的Daily Build和Auto Test报告无法证明它们是否真正被执行并真正成功，所以不能通过ISO9001的审核。但添加一个断言失败（类似assert(false)的断言）的测试后，则可以通过审核。

CMMI与敏捷也是互补的，前者告诉组织在总体条款上做什么，但是没有说如何去做，后者是一套佳实践。SCRUM之类的敏捷方法也被引入过那些已通过CMMI5级评估的组织。很多企业忘记了终目标是改进他们构建软件及递交产品的方式，相反，它们关注于填写按照CMMI文档描述的假想的缺陷，却不关心这些变化是否能改进过程或产品。

所以敏捷开发在过程中只编写够用的文档，和以“信息的沟通、符合性的证据以及知识共享”作为主要目标的质量体系文档要求并不矛盾。在实践中，我们可以按以下方法做，在实现SCRUM的同时，符合审核和评估的要求：

- 制作格式良好的、被细化的、被保存的和能跟踪的Backlog。复印和照片同样有效。

- 将监管需要的文档工作也放入Backlog。除了可以确保它们不被忘记，还能使监管要求的成本是可见的。

- 使用检查列表，以向审核员或评估员证明活动已执行。团队对“完成”的定义(Definition of “Done”)可以很容易转变为一份检查列表。

- 使用敏捷项目管理工具。它其实是开发程序和记录的电子呈现方式。

总而言之，软件研发需要文档（但文档的形式可以是多种多样的，用Word写的文字式的文件是文档，用Visio画的UML图也是文档，保存在Quality Center中的测试用例也是文档），同时我们只需写够用的文档。

6. 当有开发人员在开发过程中遇到难题，工作无法继续，因而拖延进度，怎么解决？