署名为 Brian 的网友在“Scrum 开发”邮件列表上提出了一个他遇到的质量问题：
在迭代结束的时候，我们的开发团队总是不能交付几乎没有缺陷的用户故事。一位管理人员建议我们，即使是修复缺陷，也创建一个故事——QA 点 (QA score)。
Jorge Rowies 提出了几个建立质量度量指标的方案：
测试人员和开发人员在同一个团队吗？如果不是，那么 QA 点将是一个很不错的减少缺陷的开端。每个用户故事都有验收测试吗？如果有，那些测试是谁写的呢？它们足够明确，并且能在一个迭代中完成吗？
Malcolm Anderson 认为暂停新的开发有助于完善当前的用户故事：
在开发人员开始做下一个用户故事之前，指派一个测试人员先审核做好的用户故事，这样是不是更好呢？这将把你的缺陷数降低至几近于零。
开发人员都倾向于做“新的东西”，那些完成速度很快、但质量很差的开发人员倾向去做那些最“新的东西”。我的这个方法可以预防开发人员高速低质的开发。
Jack Milunsky 提倡关注完成的定义：
你的团队需要对每个故事建立“完成”的标准。这包括验收测试和质量标准。如果在 sprint 结束的时候，一个用户故事还是存在缺陷，那么它就是未完成。你必须在同一个 sprint 里面完成一切开发、测试和缺陷修复。这会让你的产品拥有很不错的质量。
Peter Skeide 对于解决质量问题有一些很具体的建议：
- 改进回顾会议，这样团队可以有效地识别和解决这类质量问题。
- 如果不同的团队成员编写代码的质量不一样，那么让那些更强的开发人员识别出一些能帮助其他人提高代码质量的方法。
- 关注缺陷预防，而不仅仅是缺陷识别。一些有用的工具包括：
- 代码检查 (code inspections)
- 检查清单 (checklists)
- 通过结对编程来改进团队内部的知识共享。
- 开始定期使用一些静态或者动态代码分析工具。
评论