当流程改进没有意义时

发布于:2021-01-26 13:41:28

0

222

0

流程 改进

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

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

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

当流程改进不起作用时

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

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

我说的是:

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

  • FxCop必须没有新的警告。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我还在思考这个问题 。

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

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

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