带透明材质的描绘过程

这次，我想看看软件开发过程中如何支持质量。 我们将分析此类过程的某些阶段，并检查各个步骤的明确存在如何支持团队和组织的质量维护。

以下是我多年的观察中的问题，在寻找有关质量控制的答案时值得提出

• 在软件开发过程的每个阶段都明确定义了质量概念吗？
• 阶段在什么基础上可以正确完成？
• 是对“质量”一词进行了讨论，同意，记录和宣布，还是仅仅是员工对“质量”的“期望”？
• 是否很容易在给定步骤中绕过质量控制，例如由于紧急情况？

最简单的板

在多家公司工作了近20年，并担任培训师，我拜访了许多办事处，并与许多团队进行了交谈。 在这些办公室中，我看到了许多板，这些板上都可以看到给定团队的软件开发过程，例如看板或Scrum。

这是最简单的木板的一个例子

以上过程如何保证质量？ 在哪里检查代码或添加缺少的测试用例？ 当代码在进行更改后不再被他人阅读时，重构的地方在哪里，这将阻碍代码的开发？

我必须承认，我多年以前工作的团队也使用过类似的董事会。 很多时候，最常见的问题是该功能是否已经实现。 这个问题通常是由充当“测试员”的人回答的

质量不是捉迷藏的游戏

根据我在上述情况下的经验，诸如添加缺失的测试，具有自动化的代码质量报告，重构，根据新要求调整项目体系结构之类的事情–如果发生，它们将以隐藏的方式执行……您不会谈论他们正式，只有程序员将扩展编程或测试阶段，以将它们塞在某个地方..

可以轻松地跳过不是该过程正式部分的步骤。 另外，它们可以在过程外完成，但这总是会使程序员感到不适。

最坏的情况是基于不正确（不完整）过程的微观管理。 当程序员受到每小时一次的工作控制并且对质量的关注不是过程的正式组成部分时，它肯定不会进入团队。 如果程序员意识到技术债务的后果，也许会发生这种情况，但仍然会以隐藏的形式延长计划的实施时间。

我遇到的最极端的情况涉及奖励经理以产品交付的速度，而开发人员/测试人员则是接下来几个月客户报告的缺陷数量的唯一“负责人”。 …

引入透明度

这个过程中是否有检查点

• 代码是否经过审查？
• 更改后代码仍然可读吗？
• 组件和/或集成测试是否覆盖了代码？

惯例是，如果我们没有对工作中的事情进行正式评估，那么我们可能不会担心。 可能同时发生的是，团队成员只为交付速度付费，而从未根据客户报告的缺陷数量来判断。 在这种情况下，谁获得薪水？ 这种方法可能在以较高速度工作的程序员与更加在意代码质量的程序员之间造成不健康的气氛。

让我们继续分析下一个白板

这里对质量的照顾看起来更好吗？ 在这种情况下可以跳过代码搜索过程吗？ 此外，此过程强调，在代码审查完成之前，没有人可以在集成环境中测试解决方案。

尽管此配置在质量控制方面听起来更可靠，但我仍根据不同的工作组织规则看到了不同的结果。 这是两个真实的例子

1. 至少2位程序员应检查代码更改。 但是在这种情况下，谁应该对此做出全面负责？ 可能会发生两个不同的程序员同时执行粗略检查的情况，以加快等待“可用”质量工程师进行测试的任务。 而且，这两个程序员中的每一个都可以假设另一个会更彻底地复习……
2. 只有一个人可以同时审阅代码，并对可读性，测试用例的覆盖范围以及批准变更所做的扩展可能性负全部责任。 如果这样的人对质量有任何疑问，他们有权将其评论提交给作者或下一位审阅者进行确认。

第二种方法似乎更能抵抗“泄漏缺陷”。

引入更大的透明度

让我们在董事会上再增加一列。

在上述情况下，很明显质量工程师执行的测试仅在集成环境中进行。 您还可以清楚地看到任务何时已被检查并且正在等待在集成环境中实施。

技术修复的透明度

代码审查的结果可能是您需要进行更正。 这样的更正可能是紧急的重构，增加了缺少的集成测试。 它也可以设置约会会话以重新讨论体系结构，因为必须在整个团队的层次上讨论该问题。

一些团队可能认为这没关系，只需将任务的最高优先级放回“要做”一栏中。 但这是否有可能将具有新功能的任务与“补丁”任务区分开来？ 这是否意味着转换任务将与“待办事项”列中有关新功能的新任务竞争？ 因此，另一种选择是显式添加一列，其中任务将通过其他“修复程序”进行处理。

当然，如果代码复审顺利，则可以省略“返工/修复”列，但是它的存在强调了对代码质量进行更正（例如，由于缺乏可读性或缺乏测试范围），即使代码按预期工作。

任何其他透明度

要敏捷。 回顾期间定期讨论所有质量控制问题。 在过程中放置​​有关质量控制的最重要阶段。 使他们“合法”和正式。 对质量负责。

同样，另一个示例：部署到生产环境中–让每个任务的实际情况可见。 您可以自己讨论这种专栏的好处。

摘要–确保质量控制可见性

如果要保证质量，则必须创建流程和程序来鼓励人们提高质量，并阻止人们跳过质量。 在这样的环境中，人们可以体验因缺乏质量而做出决策的后果，而且有权对这些原则进行自我完善。

密切注意过程的形状。 使他的步骤非常清晰，并在质量控制方面进行明确定义。 该过程应突出显示与需求有关的所有内容，例如质量，代码可读性，测试范围，重构选项，甚至交换技术和业务知识。

请记住，程序和流程可确保工作中的心理安全。 它们构成了我们履行职责和评估工作的准则。 如果未明确定义“预期”结果，则其发生的可能性将很小。

翻译自: https://www.javacodegeeks.com/2019/08/transparent-quality-process.html

带透明材质的描绘过程