代码之家 › 专栏 › 技术社区 › Mo.

如何证明我的利益相关者和经理我的软件有效[关闭]

maintainability release unit-testing

5

Mo. · 技术社区 · 6 年前

在另一个完整版本发布后,软件工程师会遇到什么?嗯,我们小组中遇到的第一件事就是我们公开发布的bug。作为软件工程师,我们在完全发布后遇到的最大问题是意大利面代码,也称为 big ball of mud .

追求完美的时间和金钱很少,也不应该如此。为了生存,我们必须尽一切努力让我们的软件正常工作并按时出门。事实上,如果一个团队在有空闲时间的情况下完成了一个项目,那么今天的管理者很可能会将此视为下一次提供更少时间和金钱或更少人员的标志。

您需要在预算内按时交付高质量的软件

成本:架构是一项长期投资。支付账单的人很容易放弃它,除非有一些有形的即时利益,比如税收减免,或者除非有多余的钱和时间。这种情况很少发生。更多情况下,客户需要在明天之前完成一些工作。通常,控制和管理开发过程的人并不认为架构是一个紧迫的问题。 如果程序员知道做工是看不见的,而管理者无论如何也不想为此买单,那么恶性循环就产生了。

我们知道,这种情况并不总是发生。怎么会?因为管理者不认为架构是一个紧迫问题的说法是错误的。至少现在是这样。IT领域的管理者非常清楚,可维护性是业务的关键。

因此,寻求使系统远离大泥球的方法是业务的核心。系统仍然可以维护。这个系统确实可以工作,而你,作为程序员,可以证明它可以工作。您的经理是否会问您是否已经完成了今天的编码,她是否会问您是否可以在今天完成已修复A、B和C的发布,或者她是否会问将发布的软件是否实际工作?你证明它有效了吗?用什么?

现在回答我的问题:

我们有什么方法来证明我们的管理者和/或利益相关者我们的软件工作正常?我们的软件单元测试的绿灯是否足够好?如果是的话,这难道不能证明我们的大泥球还在做我们期望它做的事情吗?软件是可维护的吗?你如何证明你的设计是正确的?

[稍后补充]

Chris Pebble他下面的答案是让我的团队走上正确的轨道。质量保证绝对是我们追求的目标。谢谢你,克里斯。与利益相关者达成一致的QA政策是我的团队所寻求的逻辑结果。

接下来的问题是,QA政策中应该包含哪些内容?

让构建服务器对我的涉众可见
让buildserver不仅“只是构建”,而且添加作为QA策略一部分的测试
与我的利益相关者就我们的开发过程达成一致(开发人员相互审查代码是其中的一部分)
更多

更多信息:我领导的团队正在构建其他软件团队使用的Web服务。这就是为什么一个坏掉的Web服务马上就要花钱了。当presentationlayer团队的开发人员或实际的测试人员无法前进时,我们会立即面临压力,必须尽快修复bug,这反过来会导致快速的黑客攻击。。

[稍后补充]

谢谢你的回答。这确实是关于“信任”。如果软件不受利益相关者的信任,我们就不能发布,利益相关者正在使用使用我们的Web服务的网站主动测试我们的软件。当问题出现时,测试人员的第一个问题是:这是服务层问题还是presentationlayer问题?这就要求我制定一个质量保证政策,确保我们的软件可以进行测试。

因此,我(现在)能设想的与测试人员建立信任的唯一方法是:

5 回复 | 直到 8 年前

1

4

Guy 15 年前

你不能证明它超出了测试的范围,除非有一个防弹规范(从来没有),那么测试永远不会证明任何明显的以外的东西。

作为一个团队,证明您的软件可靠的唯一方法是建立一个跟踪记录:从一开始就正确地做事情,在实现新功能之前修复bug,绝不向快速修复妥协,并确保每个人都对代码抱有同样的热情和尊重。

2

5

medopal 15 年前

我是一个团队的成员,为一个政府客户做一个大项目。第一阶段的第一个模块是一场巨大的灾难,团队没有得到管理,没有QA团队,开发人员没有动力更好地工作。相反,经理不停地叫喊,并为那些没有加班的人扣工资!!

客户,嗯,别问这个,他们真的很生气,但是他们留在了我们公司,因为他们知道没有人像我们一样了解业务。

首先,将管理层和程序员分开,并安排一位友好的团队领导。
第二,找一个合格的QA团队。在最初的几周里,臭虫的数量达到了100只。
第四,激励员工,有时不是为了钱或额外的假期,有时一句好话会很完美。举个小例子,在连续工作3天几乎每天15个小时后,团队负责人给经理写了一张便条。两天后,我收到了首席执行官的一封信,感谢我的努力,并给了我两天假期。

我们将很快交付系统的第四个模块,作为支持团队的一员,我可以说它至少95%没有bug。这与我们的第一个模块相比是一个巨大的飞跃。

今天,我们有一个强大的开发团队,合格的QA和专家错误修复。

抱歉,说来话长,但我们的团队(在4个月内)就是这样向经理和客户证明我们是可靠的,只需要合适的环境。

3

Konklone 15 年前

在除琐碎的情况外的所有情况下,您都无法“证明”您的软件是正确的。

这就是我们的角色 ser 接受

4

1

Chris Van Opstal 15 年前

我认为这是本末倒置。这无异于一个步兵试图向将军解释什么是作战演习,以及为什么保护你的侧翼很重要。如果管理层不能分辨出质量代码和一个大泥球之间的区别,那么你最终总会得到一个大泥球。

不幸的是,完全不可能“证明”你的软件没有bug(windows xp的商业广告总是让我恼火,因为它宣布了“有史以来最安全的windows版本”,这在发布时是不可能证明的)。由管理层来设置和实施QA流程,并确定可交付产品的实际外观以及最终版本中可接受的bug或意外行为的级别。

5

1

Daniel Paull 15 年前

正如比利·乔尔(Billy Joel)曾经说过的,“这一直是信任的问题。”

关键是在开发和业务的其他部分之间建立信任、尊重的关系。你如何建立这种信任?这是一个敏感的人的问题。。。你需要做一点实验。我经常使用以下工具:

过程可见性 -确保每个人都知道你在做什么,事情进展如何。另外,确保每个人都能看到开发过程中发生的影响和变化。
-为了建立信任,指出事情何时完全按照你的计划进行。试着找出你必须做出判断的情况,并在管理层中使用“减轻风险”一词。
不要说,“我告诉过你的。” -假设你告诉管理层你需要2个月来完成一些任务,他们说,“你只有3周时间。”结果不太可能是好的(假设你的估计是准确的)。让管理层意识到这个问题,并记录下你为达到最后期限所必须做的所有事情。当质量不佳时,你可以以专业的方式解决你所面临(和记录)的问题,而不是指手画脚地说:“我早就告诉过你了。”

如果您与您的经理关系良好,您可以建议他们阅读一些特定于软件开发的书籍,以便了解行业最佳实践。

另外,我要向你的老板指出,不允许你作为一名专业的软件开发人员正在损害你的职业生涯。你真的想在一个能让你专业成长的地方工作,而不是在一个能让你变成黑客的地方工作。