本资料由我们的合作伙伴Equio准备 。
购买IT产品以解决各种公司问题时，业务客户通常会考虑其成本，功能，便利性，集成能力等。 这些不是很明显的问题，例如技术支持的质量和水平，他们已经在第二位考虑了。
但是最终产品的质量在很大程度上取决于开发人员如何组织测试，识别和修复错误的过程，在被称为“错误”的开发人员中（英文错误-错误，任何昆虫，病毒，语通常表示错误）在程序中）。 很少有个别商业客户问这个问题。
我们想告诉您开发人员如何识别和修复错误，使其适合进行测试。 一种方法是基于零错误政策。
剧透！ 我们将告诉您开发人员实际花费的时间，以及为什么不能解决所有错误。 
七个保姆
有一个著名的笑话专门用于宣布新版本“优化的应用程序性能，错误修复，添加了新功能”。 实际上，修复错误并添加新错误是一个永恒的过程，旧错误已得到修复，但新错误的出现不少。
当大量开发人员甚至几个项目团队在单一代码库上开发软件产品时，这一点尤其明显。 同步他们的工作并获得完全无错误的输出代码非常困难。 例如，一个团队将更改保存在master分支中，即，在存储库（存储库）中的代码的主版本中。 反过来，另一个团队则面临着大量冲突，并正在努力解决这些冲突。 结果，所有这些东西都发布了，也就是产品的最终版本，适合普通用户使用，并且这里出现了大量令人难以置信的错误。 这充满了金钱，客户的损失，最重要的是，对开发商声誉的威胁。
那么在这种情况下该怎么办？ 您可以将所有精力和资源投入到纠正错误中，但是又如何进行产品开发，改进现有产品并添加新功能呢？
看不见，积压
一家大型IT公司也遇到了类似的问题。 由于在公司工作的一位专家的推荐，因此决定采用“
零错误政策”方法。 不幸的是，关于他的报道还很少。
其实质如下。 当测试人员或用户发现产品中的任何错误并通知开发人员时，开发人员会决定是要修复该错误还是不影响产品的性能，因此可能会延迟或完全排除其纠正措施从积压（任务列表）。 该错误被指定为“不会修复”状态，此错误将永远从开发人员的视野中消失。 在某些情况下，具有此状态的错误会放置在待办事项的结尾。 这意味着开发人员只有在解决所有其他任务时才会“动手”修复它们。
但是回到已经提到的IT公司。 它的员工分析了检测到的错误的整个列表，并对发现的问题进行了排序。 几乎一半的错误被确定为在不久的将来被修复，并且超过一半的错误被指定为“不会修复”状态。 所有这些工作花费了大约两个月的时间，之后公司决定持续采用
零缺陷政策 。 迄今为止，该公司的积压任务中未完成的任务不超过10个。 这使您可以专注于新功能的实现。
错误专家
错误如何分类？ 谁决定一个错误很关键并且需要纠正，而另一方面，您可以继续安居乐业，或者将其纠正推迟到以后？
我们将告诉您如何使用灵活的项目管理（敏捷）概念来组织此过程。 众所周知，敏捷包括几种技术。 我们将以其中之一为例，即SCRUM，因为它在软件开发领域中最常用。
产品所有者或Scrum产品所有者是项目团队的关键成员之一。 正是他代表了最终用户的利益，并竭尽全力使产品价值最大化。 从头到尾，他还负责产品积压工作。 整个开发团队都参与了bug的分类工作，但硬道理始终是产品负责人。 它确定将修复的错误以及标记为“不会修复”的错误。
实际上，一切都是金钱。 例如，如果修复一个错误不会给公司带来任何财务收益，但同时要花费大量的时间和资源，则最好将此类错误分配给``不会修复''状态，然后将其推迟到更好的时间进行。 实际上，“产品所有者”负责确定错误的优先级和状态。
换句话说，每个人都有“壁橱里的骨架”。 但是，如果它们对产品的性能没有任何影响，不妨碍用户的行动或不影响集成过程，则可以完全忽略它们。
选择标准
任何开发人员的产品中都存在此类“次要”错误。
例如，在内容管理系统的管理界面中，不可能为部分，文章等输入过长的标题。 开发人员决定不修复此错误。 毕竟，更正需要时间，资源，并且您只需将名称改成一定数量的字符即可。 仅仅警告用户不支持超过30个字符的名称就足够了。
该按钮的颜色略有错误，界面元素位于所需元素的左侧两个像素处，所有这些都是错误，不会影响应用程序的可用性或性能。 因此，它们可能被归因于“无法修复”。
关键错误主要是由许多导致或可能导致客户端由于程序员缺陷而蒙受损失的客户处理的错误。 所有这些都定义了产品负责人，他必须像手背一样了解产品，不仅要了解其功能，还必须了解商业客户如何使用它，以及特定公司中存在哪些应用场景。
集体意识
零错误政策通常与服务水平协议（SLA）相关联。 通常，开发人员会获得几条技术支持。
第一个接收到来自用户的错误消息，并收集所有必需的数据以进行复制和分析，然后将所有这些信息传输到第二行。 第二行的专家在与用户安装了相同版本产品的工作站或服务器上重现此错误。 如果按照用户的要求重现了错误，则有关该错误的信息将落入活动的sprint中，即，针对开发人员的任务列表。
第一和第二技术支持热线以及开发人员都有SLA。 错误越严重，修复它的SLA标准就越严格。 还有一个用于故障排除的通用SLA：从客户联系到在生产中获取正确的代码。 技术支持的第二行决定是否将错误状态分配给“不会修复”。 但是，她的判决不是最终裁决。 首先，其员工遵循当前冲刺的原则和规则。 此外，开发人员，客户，业务开发部门都有一些期望。
如果在考虑所有这些因素后出现有争议的情况，那么最后一句话将恰好位于第二条支持线后面，当然也包括产品所有者。
满意意味着生产
开发公司为什么需要所有这些？ 原因之一是开发人员的动机增强。 修复错误是一项例行且不愉快的工作，并非所有人都喜欢这样做。 实施新功能比解决同事的错误要有趣得多。 这提高了生产率和生产率。 最后，通过这种方式，可以在不牺牲质量的前提下，节省大量的测试人员维护费用，而只剩下一到两个专家而不是整个部门。
为什么用户和商业客户需要此？ 随着业务的发展，IT不断面临需要借助IT产品解决的新挑战。 如果开发人员将大部分时间用于消除不重要的错误，而不是改善其创作的功能，那么他们就有可能远远落后于竞争对手。 企业将选择那些正在前进的人员，同时将质量标准保持在较高水平。
仅此而已。 有关
“ Equio”公司的更多信息，请访问其官方网站。
在
Otus网站上，您可以熟悉我们的课程，并参加您感兴趣的
免费网络研讨会 。