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

Question

在另一次压力释放之后,软件工程师会遇到什么？好吧,我们在小组中遇到的第一件事是我们在公开场合发布的错误.我们作为软件工程师在压力释放后遇到的最大问题是意大利面条代码,也称为泥球.

追求完美的时间和金钱很少可用,也不应该.为了生存,我们必须尽一切努力让我们的软件按时运转.事实上,如果一个团队有时​​间完成一个项目,今天的管理人员很可能会将其作为一个标志,以便在下一次提供更少的时间和金钱或更少的人.

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

成本:架构是一项长期投资.支付账单的人很容易解雇,除非有一些切实的直接利益,如税务注销,或者除非有多余的资金和时间可用.这种情况很少发生.更常见的是,客户需要明天工作的东西.通常,控制和管理开发过程的人根本不认为架构是一个紧迫的问题.如果程序员知道工艺是看不见的,而管理者无论如何也不想为此付出代价,那么就会产生恶性循环.

但如果真的如此,那么每个长期的软件项目最终都会导致一团糟.

我们知道并非总是会发生.怎么会？因为管理者不把架构视为紧迫问题的说法是错误的.至少现在.IT领域的管理人员非常清楚可维护性是业务的关键.

业务依赖于驱动它的数据.企业已经变得严重依赖于他们的软件和计算基础设施.有许多关键任务系统必须每周二十四小时/每周七天播出.如果这些系统出现故障,则无法检查库存,无法支付员工费用,无法路由飞机等.[..]

因此,寻求方法使系统远离泥泞的大球是业务的核心.该系统仍然可维护.系统实际上是有效的,而且你作为程序员可以证明它确实如此.你的经理是否问你今天是否完成了编码,她是否会问你是否可以在今天完成修复A,B和C的版本,或者她是否询问将要发布的软件是否真的有效？你证明它有效吗？什么？

现在我的问题:

我们有什么方法可以向我们的经理和/或利益相关者证明我们的软件有效？我们软件单元测试的那些绿灯是否足够好？如果是的话,那不仅仅证明我们的泥球仍在按照我们的预期行事吗？该软件是否可维护？你怎么能证明你的设计是对的？

[后来添加]

Chris Pebble他的回答是让我的团队走上正轨.质量保证绝对是我们正在寻找的东西.谢谢克里斯.与利益相关方达成一致的QA政策不是我的团队所寻求的合乎逻辑的结果.

后续问题是质量保证政策应该是什么？

• 使该构建服务器对我的利益相关者可见
• 使构建服务器不仅"只是构建",而且添加作为QA策略一部分的测试
• 我的利益相关方就我们的开发流程达成协议(开发人员审核彼此的代码是其中的一部分)
• 更多..

更多信息:我领导的团队正在构建其他软件团队所使用的Web服务.这就是为什么破坏网络服务立即花钱的原因.当演示层团队的开发人员或实际的测试人员无法前进时,我们立即面临压力并且必须尽快修复错误,这反过来会导致快速破解.

[稍后补充]

感谢所有的答案.这确实是关于'信任'.如果利益相关者不信任该软件,我们就无法发布,他们正在使用使用我们的网络服务的网站自行测试我们的软件.出现问题时,我们测试人员的第一个问题是:它是服务层问题还是表示层问题？这导致我有一个质量保证政策,确保我们的软件可以用于他们正在进行的测试.

因此,我能够(现在)设想与测试人员建立信任的唯一方法是: - 与当前的测试团队交谈,检查他们能够手动执行的测试(来自他们的测试脚本和场景)并确保我们的团队将这些测试作为单元测试已经检查过我们的Web服务.在我们发布presentationlayerteam必须集成的版本之前,这将是一个"签字"的良好起点.需要花费一些精力来澄清为所有这些场景创建自动测试需要一些时间.但它肯定会有用,以确保我们构建的实际工作.

Answer 1

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

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

那么解决方案是什么:

• 首先,将管理层与程序员分开,并建立一个友好的团队领导.
• 第二,获得一个合格的QA团队.在最初的几个星期里,错误发生在100秒.
• 第三,把2-3个开发人员作为支持团队,有责任不做任何新任务,只需修复bug,直接与QA一起工作.
• 第四,激励这些家伙,有时候不是关于金钱或额外的假期,有时候一个好词会很完美.小例子,在连续工作3天,每天工作近15个小时后,团队负责人向经理发了一张纸条.两天后,我收到了首席执行官的一封信,感谢我的努力,给了我两个假期.

我们很快将提供系统的第4个模块,作为支持团队之一,我可以说它至少95%没有bug.这是我们的第一个模块的巨大跳跃.

今天,我们拥有一支强大的开发团队,合格的QA和专家漏洞修复工具.

很抱歉,但这就是我们的团队(在4个月内)向经理和客户证明我们是可靠的,并且只需要合适的环境.

Answer 2

你无法在测试范围之外证明它，除非有一个防弹规范（从来没有），否则测试永远不会证明任何超出显而易见的事情。

作为一个团队，你可以做的就是以负责任的方式进行软件设计，不要屈服于编写糟糕代码来取悦经理的诱惑，要求必要的资源和时间限制，并将整个过程视为一门手艺。一份工作。最优秀的文艺复兴时期雕塑家知道没有人会看到背部雕像被放置在大教堂的角落里，但仍然努力确保他们不会低估自己。

作为一个团队，证明你的软件可靠的唯一方法是建立跟踪记录：从一开始就正确做事，在实现新功能之前修复错误，永远不要屈服于快速修复，并确保每个人都共享相同的内容对代码的热情和尊重。