使用Joel Test来衡量开发团队的过程

Joel Test是一组非常简单的问题列表，可以非常快捷的来评审软件团队的开发过程。最早是由Joel Spolsky发布在其网站Joel on Software上面，尽管Joel宣称它是“一个不太靠谱的、粗糙的来评定团队的测试”，但是它被软件管理者、面试主考官还有软件投资者广泛使用。

下面是问题列表:

1. 是否启用版本控制？

2. 是否可以一步构建?

3. 是否进行每日构建？

4. 是否有bug跟踪列表？

5. 是否在修改bug后，才开始写新代码？

6. 是否及时更新工作计划？

7. 是否在开发前编写了大家一致认可的功能文档？

8. 是否给予团队安静的工作环境？

9. 是否在使用最好的软件开发工具？

10. 是否有专职测试人员？

11. 是否在面试时以实际编写代码来检查求职者？

12. 是否利用陌生人进行可用性测试？

这里重点关注几条：

5. 是否在修改bug后，才开始写新代码？

微软制定了“零缺陷策略”。其真正含义是：在任何时候，都要把解决现有程序里的问题作为首要问题来抓，然后再去写新程序。
为什么要这样做呢？
第一条：越早解决问题，越容易解决。
第二条：刚写的程序里发现问题，你能够比较容易地估算解决它的时间。如果你的开发过程中有许多虫没有及时解决，那你的开发计划肯定不可靠。反过来，如果你们已经把已知的虫全部解决了，要做的事只是写新的程序，那你的开发计划就会比较准确。
第三条：把已知的虫全部解决，这样做还有一个好处：保持“让开发中的产品随时处在可以交给用户的状态。如果你的 竞争对手推出一个新的功能想把你的客户抢走，你可以马上在你的产品里加上这个功能，立刻将新产品交付用户，因为你没有一大堆积累下来的问题要解决。

12. 是否利用陌生人进行可用性测试？

这句话的意思是，让你从走廊里随便抓几个人来试用你的软件。如果你抓五个人来用你的软件，那就有可能发现95%的可用性问题。

得分：

对于每一个问题如果回答“Yes”，可以得一分。12分是优秀的团队，11分可以看成刚刚及格，这些都是最基本的问题，缺一不可。尽管一些大的团队例如微软可以得12分，但是许多团队只能得2到3分。

这个问题列表是Joel在2000年做的，十年过去了，Joel Test Update for 2010 诞生了。

下面是新的列表：

1. 是否采用了配置管理系统？

需要定义一个配置管理系统，除了对源代码进行版本管理外，还应该包括建立代码分支、定义分支合并策略，版本稳定策略，产品部署计划，系统角色和权限定义，还有每个阶段的质量检验关方法（quality gates）。

2. 是否每个人都可以一步构建？

3. 是否每日构建中添加了自动测试？

4. 是否将Bug数据库与源代码管理集成？

一个Bug的修复对应着那些代码的改变？每一次代码的改变是否关联着一个Bug或者开发任务？一次代码分支的合并关联着那些Bug？ 每一次代码的提交应该修复某个Bug或者完成某个开发任务，我们可以通过Bug报告来查询代码中的改变。换句话说，源代码管理应该与Bug追踪、项目任务追踪集成。

5. Do you fix bugs and write new code?

通过建立代码分支、以及分支合并等等手段开发团队可以将同时进行上一次发布的Bug修复和下一次发布的代码编写。质量保证团队必须要确保在上一次的发布版本中Bug能够被修复，而且要能够将修正代码同步到当前的发布版本。

6. 是否能够追踪任务并且管理变化？

7. 是否拥有一个需求管理系统？

需要支持需求功能文档的变更管理。我看到很多的开发团队有着很好的文档编写开发流程，但是文档的变更管理流程却很糟糕。

8. 是否给予团队一个安静的工作环境以及一些作战室？

9. 是否在使用最好的软件开发工具？

10. 测试人员是否参与到需求管理中？

11. 是否在面试时让求职者评审实际代码？

12. 是否利用陌生人进行可用性测试？

怎么样看看你所在的团队情况如何？