当流程改进没有意义时

自从我加入TrackAbout的团队以来，我一直在重新思考我对流程改进的一些想法。

我一直大力提倡测试驱动开发、静态代码分析和软件开发中的其他最佳实践。

在以前的工作中，我有很大一部分时间是在明确或隐含地改进发展过程中度过的。这不是一个真正有趣的地方，但我一直感到有一种强烈的道德信念，那就是接受这份工作，把事情做好。

当流程改进不起作用时

我在TrackAbout工作的团队中有很多开发人员，他们确实是我共事过的最聪明的人之一，他们不仅有丰富的经验，而且知识渊博，尤其是在最佳实践方面。

在这里应用相同的开发过程改进步骤似乎没有意义。

我说的是：

• 代码在单元测试中必须有90%的代码覆盖率。

• FxCop必须没有新的警告。

• 不能同时处理两个积压的代码。

• 积压的代码必须分解为不超过x小时的任务。

在我工作过的大多数团队中，这些类型的“规则”确实有助于提高团队生成的代码质量。

这是我第一次觉得在开发团队中引入“规则”实际上会损害代码的生产率和质量。

非常优秀的开发人员似乎有判断力，能够做出正确的决定，即他们需要多少代码覆盖率，以及哪种静态分析规则是重要的。

似乎没有一套开发过程规则能够捕捉到这种判断的价值。

我觉得在我工作的地方，每个人都对自己写的每一行代码都有自我意识，他们不必被告知对此有自我意识，这真的是我在其他地方从未经历过的事情。

我在那里工作过的大多数地方，可能都有一两个与我志趣相投的人，他们是公司里所有的开发人员中的一员，但老实说，在TrackAbout，每个开发人员都有同样的热情。

所以我是说开发过程是不必要的吗？

一定要说“不！“但我要说的是，有时他们的僵化程度是不需要的。

当我在过去负责建立开发过程时，经常有人问我“为什么单元测试90%的代码覆盖率？”这一问题。

在单元测试中拥有90%的代码覆盖率并不是什么神奇的事情。它不会突然让你的代码变得很好，但它通常可以确保以下几点：

• 您有一种可测量的、可执行的方法来确保单元测试是真正编写的。

• 如果开发人员正在经历困难以获得90%的代码覆盖率，那么他们更有可能编写好的单元测试来实实在在地执行代码。（不总是这样，但肯定更有可能。）

• 它防止了那些不应该做出判断的人需要做出判断。你不能相信每个开发人员都能做出正确的判断，所以通过强加一个任意的规则，你可以在沙子上划出一条线，而这条线大部分是正确的地方。

强加开发过程规则还有其他好处和原因，老实说，对于大多数团队，我强烈推荐它们。

我在这篇文章中所做的是质疑我自己的想法，即如何将它们应用到一个成就卓越的团队中。

如果没有一套严格的规则，那么如何改进流程？

这是我现在正在努力解决的问题。老实说，我还没有一个很好的答案。

即使在这种情况下，看起来我的看板和指南中的原则仍然适用。 

我还在思考这个问题 。

我觉得总是需要一些过程改进，持续改进是非常重要的，没有一个团队可以从过程改进中获益。

关于高绩效团队的改进过程的另一个问题是，没有人坐在那里谈论改进过程。相反，每个人都在完成事情。通常情况下，过程改进讨论是出于必要性，或者因为显然存在需要改进的问题。

我相信，当我自己找到这些问题的答案时，我会在这个话题上写得更多。