5

我在一家程序员不到 10 人的小型软件公司工作。我们的软件安装在全球数十个地方。我们的代码库非常庞大,主要是由于糟糕的设计和大量的代码重复 (IMO)。我们有大约 30 个不同的项目,每个项目总共有大约 600 KLOC,其中大约 200 KLOC 是我们自己开发的代码。当我在 2006 年到达那里时,这段代码甚至还没有受到修订控制。我已经设法说服权力,它很重要,我们现在使用代码控制系统(cs-rcs,不是我的选择,但总比没有好)和错误跟踪系统。最大的缺失是整个过程中完全缺乏质量保证。我们的发布过程在纸面上是不存在的,实际上它包括“按 ctrl-F9,将二进制文件复制到客户端,声明问题已修复”。

谁能指点我一些官方文件或PHB语言文件或文章来解释这个过程中的公然疯狂?我相信老板可以聘请一些顾问告诉他这件事,然后他可能会相信。但我只是一个拥有软件工程学士学位的低级维护人员。而且我的种族对我也没有帮助。在这种情况下使用什么弹药最好?

4

9 回答 9

4

在这种情况下,你最好的弹药就是等待不可避免的灾难。一旦它发生,让你所有的鸭子排成一排,制定一个让这场灾难不再发生的计划,一个强调实施成本远低于灾难本身成本的计划。

如果他们一开始就不想要“它”,那么再多的谈话也不会让 PHBs “明白”。最终只有那个严厉的主人给他们一个大耳光——现实——才能说服他们。

哦,当你在做的时候,更新你的简历并开始寻找。倾向于说服人们他们需要 QA 的灾难与杀死公司的灾难非常相似。

于 2009-01-11T07:43:02.930 回答
3

金钱是你最好的选择——在支付方面,它最痛苦。
我认为下面的图片说明了一切:( 图片来自www.developertesting.com错误成本

于 2009-01-11T08:53:08.200 回答
3

同义反复,说服他们的唯一方法是将他们放在令人信服的东西面前。那件事可以从一个列表中得出,例如:

  • 预示着代价高昂的灾难促使人们采用先前提出的解决方案
  • 用现成的永不重演的解决方案解决无法预料的灾难
  • 对灾难的精彩、有说服力的预言
  • 对贪婪的极有说服力的呼吁(节省预言灾难的机会成本)

或者是其他东西。在所有这些情况下,有人将不得不在某个时候为您提出的 QA 解决方案提出理由,并且从外观上看,必须是您。所以我开始学习说服力。

如何赢得朋友和影响人们最多应该花你几美元。 Getting To Yes也很便宜。

您是如何同意源代码控制的?你能继续削减,一次一小步地改进流程吗?

尝试谷歌搜索“改变你的组织”,看起来有一些有希望的链接。

最后,请记住(正如一位智者曾经说过的),如果你不能改变你的组织,那么你应该改变你的组织。真的总是有另一种选择。

于 2009-01-11T10:45:14.760 回答
1

管理层只会理解两件事:(1)成本效益和(2)客户满意度。第二个很难量化,但第一个很容易。你可以花 40,000 到 60,000 美元聘请一位体面的 QA 工程师,他可以进来并开始理解混乱并开始围绕它制定计划。成本效益来自确保更高技能的工程师不必花费 2 个月的时间来追踪隐藏在 10 万行代码中的错误。

还有另一种方法可以解决这个问题...您可以在我工作的地方做我们正在做的事情。从一开始就开始为代码编写测试,然后当你完成代码时,如果测试通过了,那么你就是黄金。测试通过后,您就可以进行测试,以确保您一旦破坏该代码,您将几乎立即知道它。如果你让你的程序员同事参与进来,那么至少所有新代码都将在测试框架下开发。测试驱动开发不仅使过程更快(在开始编码之前您已经知道想要的结果是什么),而且还有助于快速完善您的需求。最重要的是,通过一点社会工程(与您的同行合作),您可以一点一点地改变开发文化,直到该过程完成。

于 2009-01-11T09:43:56.150 回答
1

我可以推荐丰田方式。短版通常可以从丰田网站免费订购。管理层应该已经阅读了它,但显然他们还没有。阅读它,消化它,让管理层阅读它。为了获得灵感,我真的可以推荐阅读Toyota 的 Long Drive 的教训(获得 PDF 的几块钱是非常值得的)。

于 2009-01-11T11:51:54.563 回答
0

也许如果你让一些程序员同事支持你,管理层会更愿意倾听。您无需成为天才即可意识到庞大而笨拙的代码库表明有很大的改进空间。

于 2009-01-11T07:41:54.477 回答
0

参考乔尔的

于 2009-01-11T07:53:13.173 回答
0

如果您的管理层认为 QA 不重要,那么明显和“常识”到任何外行都会同意的程度,那么我不认为将一堆学术论文或其他任何东西放在他们会有所作为。

您唯一的希望可能是尝试整理一份可以显示成本节省的文件,但我怀疑这在这种情况下会有所帮助。

于 2009-01-11T07:54:44.573 回答
0

我在一个部门工作,那里有一个公共池在开发任务和测试之间轮换。这完成了两件事:

  • 高技能、高效率的测试人员,他们最多知道代码要做什么,以及如何
  • 知道轮到他们进行测试的开发人员,或者刚刚从测试中返回的开发人员。所以测试坏代码的痛苦是众所周知的,测试好代码的乐趣也是如此。

整个团队中最受尊敬的家伙是一个无情的测试人员,在开发时会生产出零缺陷的软件。

于 2011-01-07T16:18:20.900 回答