“ kaizen”一词是由丰田公司引入的，并且在《丰田陶》系列的厚书中对此有很多记载。
改善也被称为“持续改进的过程”。 通常，它通常与汽车和输送机的工业生产有关，或者至少与过程控制有关。 他们很少谈论开发，但是kaizen非常适合软件开发。
此外，您将了解一些逐渐导致作者理解开发中的改善的案例。
一系列的麻烦
第一个案件发生在新年20:00。 硬盘驱动器在服务器上崩溃，因此有必要中断准备沙拉的工作，并紧急前往莫斯科前往交通交换站点以更换损坏的设备。
硬盘驱动器后，主板烧坏了。 他们改变了一切，但随后决定弄清楚为什么会发生这种情况。
熟悉的管理员清楚地表明，您需要非常注意服务器硬件，而不是在任何地方购买和保留所有物品。
决定更改服务器，并在选择提供程序时要非常小心。 我们查看了服务器硬件，提出了建议，并选择了一个服务器，该服务器后来连续工作了7年，没有停止并且没有中断。 他现在继续工作，尽管从作者离开该工作已经过去了5年。
再过一段时间，现场发生了火灾。 服务器奇迹般地幸存了下来。 然后所有人都摇了摇，因为 存在完全破坏业务的风险。
之后，该站点和数据库的镜像是在城市另一端的另一个完全独立的站点上创建的。 一旦她被使用过。
还有一种情况是，在刚启动的站点上开始出现流量，突然流量完全停止了，无法承受负载。
研究结束后，很明显，创建该站点的外包公司做到了这一点，以使其每天的容纳人数不超过200人。 有趣和悲伤。
此后，决定放弃外包并组成您自己的开发团队。
创建团队后，我们又遇到了一个问题-更正任何错误都会导致大量新错误。 任何更改都几乎淹没了整个站点。
每个修复程序都会带来很多问题。 当我们分析情况时，我们意识到我们需要从根本上改变总体上的一切-内部。 然后整个站点被完全重构，其整个体系结构被颠倒了。 直到那以后，情况发生了根本变化，问题才完全消失。
消除根本原因
所有这些解决方案都是一件事结合在一起的-所有这些解决方案的目的都是确保解决这些问题的根本问题不再出现，从而将其彻底消除。 从所有的词。 这样，相同的问题就不会再重复了。
你懂吗
初级：计算机崩溃了-我们意识到我们必须选择正确的硬件，而这绝不会失败。
该网站着火了-他们制作了副本以排除将来发生类似情况。
然后，这些词都不知道这样-改善。
5个为什么
问题的根本原因并不总是在表面上，有时您必须进行深入研究。
丰田的一本道教书中给出了一个很好的例子。 在工厂，发现其中一台机器白天闲置了大量时间。
他为什么要休息一下？ 原来，机器停止清洁了。
机器周围有切屑和灰尘。 自然，如果周围有刨花，则必须将其清除，否则无法工作。 可以吗
但是kaizen说：您必须挖掘根本原因。
为什么芯片掉下来？ 答案马上就来了：芯片堆积了，因为它们无法运到任何地方-机器没有可将其取出和收集的设备。 如果有这样的设备，则不必停止机器。
那么，让我们提出一个解决方案，该解决方案允许将该芯片从机器中取出并制造出来，从而使其完全停止清洗。 该解决方案已经纯粹是技术性的并且非常简单。
确定根本原因的方法非常简单：众所周知的“ 5个为什么”方法。
Kaizen建议使用它来查清根本原因。
始终如一地考虑问题的原因：
- 机器为什么停止？ 因为清洁完成了。
- 为什么要清洁？ 因为碎屑和污垢从机器飞走。
- 为什么碎屑和尘土飞扬？ 因为它们不会远离机器。
在“ 5个为什么”的帮助下，我们找到了根本原因，提出了解决方案，消除了根本原因，指定了负责人和期限，并每周检查结果的实现情况。
请记住，任何问题都可以通过昂贵和廉价的方式解决。
Kaizen说：首先选择最便宜的方式。 它通常是最简单和最好的。
改善软件开发
现在有一些来自软件开发团队的近期案例。
乔布斯
该团队通过推出Jenkins在Prod中部署其最佳实践。 实际上，詹金斯（Jenkins）是像crontab这样的人，可以运行预定的作业。 团队有这样的工作。
一旦发现Prod-Jobs连续5次跌落为“失败”状态。 尽管事实上，产品上的每个文件都应该是一个通用警报，但没有人关注它们。
然后他们开始使用“ 5为什么”方法找出原因：
- 为什么工作人员翻转了5次却没有人注意？ 因为每个人都不断收到虚假工作的通知，所以他们很多，他们变得熟悉
- 他们为什么变得熟悉？ 因为几乎每天我们都会收到某种通知，所以失败并不会失败。 我们看不到区别。 他们只是不注意他们。
- 为什么每天都会收到通知？ 因为其中一名开发人员正在测试一项即将下降的新工作，并且有关该工作的通知会发送给所有人。 职位目前不重要，因此每个人都停止关注她的通知，同时也停止关注所有其他职位的通知。
决定是透明的：对于测试作业，关于文件的通知将不会发送给除作业所有者（即使他需要）以外的任何人。
另外，据正式记录，这份工作发出的任何通知都是特殊的紧急情况，每个人都应对此做出回应。
掉下来的脚本
第二个示例是QlikView应用程序出现问题。
一旦团队被告知他们的QlikView报告有所不同。 一切似乎正常，但数据并不相同。 他们开始了解问题。
事实证明，下载脚本无法运行到最后。 为什么到最后都没用？ 因为脚本中有很多代码，并且在中间某处是调试运算符Exit Script-他们只是忘记删除它，而没有注意到它。 事实证明，下载脚本丢失时，数据已过时。
你为什么没注意到呢？ 因为架构，测试没有显示出这一点。 该应用程序分为两个独立的部分（后退/下载脚本和前端），依此类推。 有很多数据，他们试图不再重新启动它们，以免浪费大量时间。
它是特制的，因此前端未与加载脚本连接。 他只是拿了一个特定的数据文件并显示了出来。 尚不清楚此数据文件是否旧，即无法确定其中是否存在错误。
为避免将来发生类似情况而发明了什么？
团队向自己提出了一个问题：如何确保将来能注意到这种情况？ 如何明确表明下载脚本无法正常运行？
决定在脚本的开头注册标签，并在最后删除标签。 即 如果未删除标签，则表示脚本尚未完成下载。 前端检查是否有标签，它将在页面底部显示一个红色横幅，并带有有关该问题的通知。
因此，尽管没有完全排除出现此类问题的可能性，但至少立即知道了这些问题。 便宜的简单解决方案。
重新启动时数据丢失
Web监视服务从工业站点接收数据。 必须定期完成并更正它，并且每次更正都需要重新启动。 尽管重新启动持续了几秒钟，但那时可以保证工业数据和深渊。 丢失它们是不可能的，因此团队决定更深入地分析问题。
问题“ 5为什么”清楚地表明了问题的根本原因是架构-正是它不允许这样做。 无论如何加强服务，无论他们做了什么，都归结为重新启动。
新的架构一劳永逸地解决了这个问题-服务被分为两个独立的部分，即数据接收和处理。 这些部分在物理上是分开的，即 您可以安全地关闭处理程序，并且在接收数据的同时继续工作并保存其中的所有内容。 最重要的是，数据接收器的制造使其不再需要重启。 处理程序可以安全地关闭，修改和重载，而不必担心数据可能丢失的事实。
DevOps似乎在那里，但似乎并不存在
DevOps是一件神奇的事情。 它似乎在那里，但同时也发生了它不存在的情况。
一位开发人员在测试台上发布了他的最佳实践。 尽管他使用了DevOps，但“突然”事实证明测试台已连接到战斗数据库。 部分数据无法挽回地丢失了。
我们开始寻找。 原来，开发人员没有注意到他正在使用连接争用字符串。
根本原因是开发人员必须手动更改不同机架和服务器的连接字符串。
Kaizen说什么？ 对！ 我们必须提出这样的解决方案以完全消除问题，即 无需手动更改该行。
解决方案得以实现-根据运行连接的服务器，开始自动选择连接字符串。 这个问题一劳永逸。
我认为您自己已经从上述示例中了解到，可以用一个简单的短语来表达持续改进的本质-完全消除问题的再次发生。
主要成果-改善的一个组成部分
改善的结果是实现，而不是想法。
提出一个解决方案并不是那么困难，要实施它就困难得多。
对于每个做出的决定，重要的是要提供关键的结果，也就是说，了解谁需要做什么以及在什么日期之前做。
您如何理解自己已经取得了成功的结果？
让我们以连接字符串为例。 哪些
实质性结果将被视为成功？ 在以下情况下将取得成功：
- 将创建一个库来自动选择连接字符串，
- 开发人员将为自己建立一个库并成功启动其软件。
某些人必须在特定日期之前采取这两个步骤。 只有通过这两个步骤，我们才能假定成功。
关键的结果是成功的标准；没有它们，改善将无法进行。 成功就是执行。
只有已实施的解决方案才能使您在将来消除此问题，因此，在谈到kaizen时，始终意味着您必须实施已发明的一切。
还有什么可以应用的
从示例中您可能会看到，kaizen可以并且应该用于事件分析中。 实际上，他是为此而创建的。
技术支持小组，基础架构和产品开发方面的事件非常完美。
至于编码，您可以在此处分析您的代码，并查看如何对其进行更改以永久消除发现的问题。
是的，非常臭名昭著的“敏捷复古”活动也得到了改善，因为在这些会议上针对冲刺分析了问题，并询问了问题“ 5个为什么”，并采取了措施来预防问题。 最自然的改善！
改善技术本身在软件开发中效果很好，非常易于使用，非常适合用于个人事务。
成功的秘诀很简单：一劳永逸地解决问题，然后根本不会解决。 这是持续的改进。
丰田本身在生产中使用了改善，取得了巨大的成功。 其结果说明一切：每1,000,000个零件中，生产缺陷仅为3个缺陷。
为什么不为自己应用它呢？
现在您已正式上任。 如果您听到这样一个词，您将知道它是什么。
在您的工作中取得成功。