- Agree on common patterns.
可以考虑计划、规约、代码、用户界面、文档、培训材料或任何其他工件的标准。但同时应当指出它们在什么情况下被应用，并且提供关于如何在必要时对它们进行裁剪的指导。
- Define consistent practices.
通常，人们对流程有意识，是因为流程让他们感觉到痛苦。例如，流程可能影响到协作、项目涉众的关系、或某种程度上不能满足团队的需要。也许有人会说“我从来没有碰到一个我喜欢的流程”，这个人很可能使用了很多很好的流程但他自己没有意识到。
如果不能恰如其分并且贯彻执行大家都认为是对的事情，那么好的流程的价值就丢失了
- Ensure that standards and processes are used.
如果发现一个被接受的标准、流程被忽略的时候，值得研究和跟进，因为可能有不同的原因导致这种情况发生，例如：
- 这个人只是忘记遵循流程和标准。提醒他
- 这个人不知道标准和流程，或者不知道如何使用它。改进你的交流和培训方法
- 标准或流程不适合手上的特定工作。重新评估裁剪的指导或替代办法
- 标准或流程对当前情况不够有效或过于累赘。简化它，让它在满足需求的同时，不会成为障碍
所有对标准或流程的违背都是一次很好的研究和改善它以便更好地满足团队需要的机会。
- Hold project retrospectives.
关键的问题是：哪些地方做的很好，将来我如何复制这些成功；哪些地方做错了，将来我如何避免它。
敏捷方法推荐在项目的过程中经常地做一些回顾，而不是在项目结束的时候简单地做一次回顾。这样做的好处是：
- 项目成员都能找到，因为他们都还在这个项目上
- 类似一个月左右一个阶段的研讨会较容易安排，因为只需要一两个小时，而不是一整天或更长时间
- 团队成员的经验在他们脑中仍然是“新鲜”的，所以讨论中更容易把所有的经验都包括进来
- 更重要的是，你可以在项目的余下的时间里把总结出的经验应用上去。
- Analyze and learn from defect data.
对于质量改进有用的缺陷数据包括：
- 什么地方出错了？这不是指症状，而是必须修复的问题所在。例如，“死循环”是一个症状，而“对循环指针步进”是问题所在。
- 问题是什么时候引入的？问题的根源在开发的具体哪一个阶段？是需求分析的问题么？系统设计阶段？编码？测试？（的确，我们在测试阶段修复缺陷的时候会引入其他的问题）
- 问题是什么时候被发现的？也许这个缺陷不会立即被修复，但是我们关心的是它在被发现之前存在多久了。
- 问题是如何被发现的？这个可以成为今后的一个指导性的实践。
- 这个缺陷的代价是多大？这个数字很可能被低估。确保你考虑到了所有必需的诊断和返工的工作量，包括重新设计、重新编码、重新编译、重新构建、重新测试、重新发布、打补丁、管理缺陷报告、更新状态等等（别忘了无形的代价比如市场上的阻碍）
- 这是什么类型的问题。
分析了缺陷数据之后，找出那些经常发生以及代价很大的缺陷，它们是你今后要避免（或至少要尽早发现）的，因为把握好了这些将对质量产生重大的提高和改进。
项目的初始阶段必须包括对之前项目的学习研究。看看过去学到的经验和以前的缺陷历史数据，想想这个项目如何做的和以前的不一样。如果要达到比以前更好的质量，需要做些什么？这必须是项目起始阶段一项明确的任务，否则很容易在开始新项目的匆忙中被忽视。
质量保证主要是一个学习的过程：学习哪些地方没有做好、如何改进；学习哪些流程工作的很好、它们适用的环境、让它们成为规程；学习对于你承担的每一个项目，如何做的更好。
任何一个有质量保证的组织都是一个学习型组织，第一步就是如何让质量保证成为工作的一个正常部分。
