Der Begriff "Kaizen" wurde von Toyota eingeführt und viel wurde darüber in dicken Büchern aus der Toyota Tao-Serie geschrieben.
Kaizen wird auch als "kontinuierlicher Verbesserungsprozess" bezeichnet. Normalerweise ist es mit der industriellen Produktion von Autos und Förderbändern verbunden, oder zumindest mit der Prozesskontrolle. Sie sagen wenig über Entwicklung aus, aber Kaizen eignet sich sehr gut für die Softwareentwicklung.
Außerdem erfahren Sie mehr über verschiedene Fälle, die den Autor dazu gebracht haben, Kaizen in der Entwicklung zu verstehen.
Eine Reihe von Problemen
Der erste Fall ereignete sich genau am Neujahrstag um 20:00 Uhr. Die Festplatte stürzte auf dem Server ab und deswegen musste die Zubereitung von Salaten abgebrochen und dringend nach Moskau zur Verkehrsbörse gefahren werden, um das defekte Gerät auszutauschen.
Nach der Festplatte ist das Motherboard durchgebrannt. Sie änderten alles, beschlossen dann aber herauszufinden, warum dies passiert.
Bekannte Administratoren machten deutlich, dass Sie sehr vorsichtig mit der Serverhardware umgehen müssen, um nirgendwo etwas zu kaufen und alles und auf jeder Ebene zu reservieren.
Es wurde beschlossen, den Server zu wechseln und bei der Auswahl eines Anbieters sehr vorsichtig zu sein. Wir haben uns die Serverhardware angeschaut, nach Empfehlungen gefragt und einen Server ausgewählt, der später 7 Jahre lang ohne Unterbrechung und ohne Unterbrechung funktioniert. Er arbeitet jetzt weiter, obwohl 5 Jahre vergangen sind, seit der Autor das Werk verlassen hat.
Nach einiger Zeit kam es zu einem Brand auf der Baustelle. Der Server überlebte auf wundersame Weise. Dann haben alle gut geschüttelt, weil Es bestand die Gefahr einer vollständigen Zerstörung des Geschäfts.
Danach wurde ein Spiegel der Site und der Datenbank auf einer separaten, vollständig unabhängigen Site am anderen Ende der Stadt erstellt. Und einmal wurde sie sogar benutzt.
Es gab auch einen Fall, in dem der Verkehr auf der gerade gestarteten Website begann und plötzlich ganz zum Erliegen kam und der Last einfach nicht standhielt.
Nach der Studie wurde klar, dass das Outsourcing-Unternehmen, das die Website erstellt hat, nicht mehr als 200 Personen pro Tag beschäftigte. Lustig und traurig.
Danach wurde beschlossen, das Outsourcing aufzugeben und ein eigenes Entwicklungsteam zu gründen.
Nachdem wir das Team zusammengestellt haben, haben wir ein weiteres Problem: Die Korrektur eines Fehlers hat eine Lawine neuer Fehler ausgelöst. Jegliche Änderungen überwältigten fast die gesamte Site.
Jedes Update brachte sehr, sehr viele Probleme mit sich. Als wir die Situation analysierten, stellten wir fest, dass wir alles im Allgemeinen grundlegend ändern müssen - all die Innereien. Und dann wurde das gesamte Gelände komplett umgestaltet, die gesamte Architektur auf den Kopf gestellt. Und erst danach änderte sich die Situation radikal und die Probleme verschwanden vollständig.
Beseitigen Sie die Grundursache
Alle diese Lösungen waren in einem Punkt vereint - sie alle sollten sicherstellen, dass das ihnen zugrunde liegende Grundproblem nie wieder auftrat, sodass es vollständig beseitigt wurde. Aus dem Wort überhaupt. Und damit sich das gleiche Problem nie wieder wiederholt.
Verstehst du
Grundlegend: Der Computer ist abgestürzt - wir haben festgestellt, dass wir die richtige Hardware auswählen müssen, die niemals ausfällt.
Die Website geriet in Brand - sie erstellten eine Kopie, um das Auftreten einer ähnlichen Situation in der Zukunft auszuschließen.
Dann wussten die Worte so etwas nicht - Kaizen.
5 warum
Nicht immer liegt die Ursache des Problems an der Oberfläche, manchmal muss man sich damit befassen.
Ein gutes Beispiel wurde in einem von Toyotas Tao-Büchern gegeben. In der Fabrik wurde festgestellt, dass eine der Maschinen tagsüber über einen großen Zeitraum im Leerlauf war.
Warum hat er Arbeitspausen? Es stellte sich heraus, dass die Maschine zur Reinigung stehen bleibt.
Um die Maschine herum befinden sich Späne und Schmutz. Wenn Späne in der Nähe sind, müssen diese natürlich entfernt werden, andernfalls kann nicht gearbeitet werden. Alles ist richtig?
Aber Kaizen sagt: Man muss nach der Ursache suchen.
Warum fällt der Chip? Die Antwort kommt sofort: Die Chips stapeln sich, weil sie nirgendwo hingehen - die Maschine hat kein Gerät, mit dem sie entnommen und eingesammelt werden könnte. Wenn es ein solches Gerät gab, musste die Maschine nicht gestoppt werden.
Nun, lassen Sie uns eine Lösung finden, mit der dieser Chip aus der Maschine entfernt werden kann, damit er nicht zum Reinigen angehalten wird. Diese Lösung ist schon rein technisch und recht einfach.
Es gibt eine sehr einfache Methode zur Ermittlung der Grundursache: die bekannte „5-warum“ -Methode.
Kaizen empfiehlt, es zu verwenden, um den Ursachen auf den Grund zu gehen.
Bedenken Sie konsequent nacheinander die Ursachen des Problems:
- Warum stoppt die Maschine? Weil geputzt wird.
- Warum wird geputzt? Weil Späne und Schmutz von der Maschine fliegen.
- Warum fliegen Späne und Schmutz? Weil sie sich nicht von der Maschine entfernen.
Mit Hilfe von „5 warum“ finden wir die Ursache, finden eine Lösung, um sie zu beseitigen, weisen eine verantwortliche Person und Termine zu und überprüfen wöchentlich die Erreichung des Ergebnisses.
Denken Sie daran, dass jedes Problem sowohl auf teure als auch auf kostengünstige Weise gelöst werden kann.
Kaizen sagt: Wähle zuerst den billigsten Weg. Es ist normalerweise das einfachste und das beste.
Kaizen in der Softwareentwicklung
Und nun einige aktuelle Beispiele aus dem Leben eines Softwareentwicklungsteams.
Feil Jobs
Das Team setzt seine Best Practices in Prod ein, indem es Jenkins auf den Markt bringt. Tatsächlich ist Jenkins ein Sheduler wie Crontab, der geplante Jobs ausführen kann. Und das Team hatte einen solchen Job.
Es wurde festgestellt, dass Prod-Jobs fünfmal hintereinander mit dem Status "Fehler" gefallen ist. Und niemand achtete auf sie, obwohl tatsächlich jede Akte auf dem Prod ein universeller Alarm sein sollte.
Dann begannen sie, den Grund mit der 5-warum-Methode herauszufinden:
- Warum haben die Jobies 5 Mal gewechselt und niemand hat darauf geachtet? Da jeder ständig über Jobs informiert wird, gibt es viele von ihnen, und sie werden vertraut
- Warum werden sie vertraut? Weil wir fast jeden Tag eine Art von Benachrichtigungen erhalten, die immer wieder scheitern. Wir sehen den Unterschied nicht. Sie haben einfach nicht auf sie geachtet
- Warum werden Sie täglich benachrichtigt? Denn einer der Entwickler testet einen neuen Job, der gerade ausfällt, und Benachrichtigungen darüber gehen an alle. Job ist im Moment nicht wichtig, daher hörten alle auf, auf Benachrichtigungen von ihr und gleichzeitig von allen anderen Jobs zu achten.
Die Entscheidung war transparent: Bei Testaufträgen werden Benachrichtigungen zu den Dateien nur an den Eigentümer des Auftrags gesendet, und selbst dann, wenn er sie benötigt.
Außerdem wurde offiziell vermerkt, dass jede Benachrichtigung vom Job ein außergewöhnlicher Notfall ist, auf den jeder reagieren sollte.
Abgefallenes Skript
Das zweite Beispiel ist ein Problem mit der QlikView-Anwendung.
Einmal wurde dem Team mitgeteilt, dass ihre QlikView-Berichte irgendwie anders waren. Alles scheint zu funktionieren, aber die Daten sind nicht die gleichen. Sie begannen das Problem zu verstehen.
Es stellte sich heraus, dass das Download-Skript nicht bis zum Ende funktionierte. Warum hat es nicht bis zum Ende funktioniert? Weil das Skript eine Menge Code enthielt und sich irgendwo in der Mitte der Debug-Operator Exit Script befand - sie vergaßen einfach, ihn zu entfernen und bemerkten ihn nicht. Die Situation stellte sich heraus, als das Download-Skript herunterfiel und die Daten veraltet waren.
Warum hast du das nicht bemerkt? Weil das Testen dies aufgrund der Architektur nicht gezeigt hat. Die Anwendung wurde in zwei unabhängige Teile unterteilt (Rückseite / Download-Skript und Vorderseite) und so weiter. Es gab viele Daten, sie versuchten, sie nicht erneut zu starten, um nicht viel Zeit zu verlieren.
Es wurde speziell so gemacht, dass die Front nicht mit dem Ladeskript verbunden war. Er nahm nur eine bestimmte Datei und zeigte es. Es war nicht klar, dass diese Datendatei alt ist, das heißt, es war unmöglich, das Vorhandensein eines Fehlers darin festzustellen.
Was wurde erfunden, um eine ähnliche Situation in Zukunft zu vermeiden?
Das Team stellte sich die Frage: Wie kann man sicherstellen, dass eine solche Situation in Zukunft bemerkt wird? Wie kann man klarstellen, dass das Download-Skript bis zum Ende nicht funktioniert hat?
Es wurde beschlossen, das Etikett am Anfang des Skripts zu registrieren und ganz am Ende zu löschen. Das heißt Wenn das Etikett nicht gelöscht wird, bedeutet dies, dass das Skript den Download nicht bis zum Ende abgeschlossen hat. Die Vorderseite überprüfte, ob ein Tag auf dem Boden der Seite ein rotes Banner mit einer Benachrichtigung über das Problem anzeigt.
Somit wurde, obwohl die Möglichkeit des Auftretens solcher Probleme nicht vollständig ausgeschlossen war, zumindest sofort bekannt, dass sie auftraten. Günstige einfache Lösung.
Datenverlust beim Neustart
Der Web-Überwachungsdienst erhielt Daten von Industrieständen. In regelmäßigen Abständen musste es finalisiert und korrigiert werden, und jede Korrektur erforderte einen Neustart. Obwohl der Neustart einige Sekunden dauerte, konnten zu diesem Zeitpunkt industrielle Daten und der Abgrund garantiert werden. Da es unmöglich war, sie zu verlieren, entschied sich das Team, das Problem eingehender zu analysieren.
Fragen "5 warum" machten klar, dass die Hauptursache des Problems die Architektur ist - es war es, was es nicht zuließ, etwas anderes zu tun. Egal wie sehr der Service verschärft wurde, egal was sie damit gemacht haben, es kam alles auf einen Neustart an.
Die neue Architektur hat das Problem ein für alle Mal gelöst - der Service wurde in zwei unabhängige Teile aufgeteilt, Datenempfang und -verarbeitung. Diese Teile wurden physikalisch getrennt, d.h. Sie könnten den Handler sicher ausschalten und während des Datenempfangs weiterarbeiten und alles speichern, was dazu kam. Und am wichtigsten ist, dass der Datenempfänger so konstruiert wurde, dass kein Neustart erforderlich ist. Handler können sicher ausgeschaltet, geändert und überlastet werden, ohne dass Daten verloren gehen könnten.
DevOps scheint da zu sein, aber es scheint nicht so zu sein
DevOps ist eine magische Sache. Es scheint da zu sein, aber gleichzeitig kommt es auch vor, dass es nicht existiert.
Einer der Entwickler hat seine Best Practices auf dem Prüfstand veröffentlicht. Trotz der Tatsache, dass er DevOps verwendete, stellte sich "plötzlich" heraus, dass der Prüfstand mit der Kampfdatenbank verbunden war. Ein Teil der Daten ging unwiederbringlich verloren.
Wir fingen an es herauszufinden. Es stellte sich heraus, dass der Entwickler nicht bemerkte, dass er die Verbindungskampfzeichenfolge verwendete.
Der Grund dafür war, dass der Entwickler die Verbindungszeichenfolge für verschiedene Stände und Server manuell ändern musste.
Was sagt Kaizen? Richtig! Wir müssen eine solche Lösung finden, um das Problem vollständig zu beseitigen, d.h. Entfernen Sie die Notwendigkeit, die Zeile manuell zu ändern.
Und die Lösung wurde implementiert - die Verbindungszeichenfolge wurde abhängig vom Server, auf dem sie ausgeführt wurde, automatisch ausgewählt. Das Problem wurde ein für allemal gelöst.
Ich denke, dass Sie selbst anhand der obigen Beispiele bereits verstanden haben, dass die Essenz der kontinuierlichen Verbesserung in einem einfachen Satz ausgedrückt werden kann - um das Wiederauftreten des Problems vollständig zu beseitigen.
Schlüsselergebnisse - ein wesentlicher Bestandteil von Kaizen
Das Ergebnis von Kaizen ist die Verwirklichung, keine Idee.
Eine Lösung zu finden ist nicht so schwierig, es ist viel schwieriger, sie umzusetzen.
Für jede getroffene Entscheidung ist es wichtig, wichtige Ergebnisse zu liefern, dh zu verstehen, wer was zu welchem Zeitpunkt tun muss.
Wie verstehen Sie, dass Sie ein erfolgreiches Ergebnis erzielt haben?
Nehmen wir ein Beispiel mit einer Verbindungszeichenfolge. Welches
materielle Ergebnis wird hier als Erfolg gewertet? Erfolg wird erreicht, wenn:
- Es wird eine Bibliothek erstellt, in der die Verbindungszeichenfolge automatisch ausgewählt wird.
- Der Entwickler wird eine Bibliothek für sich selbst erstellen und seine Software damit erfolgreich starten.
Beide Schritte müssen von bestimmten Personen zu einem bestimmten Zeitpunkt unternommen werden. Nur mit beiden Schritten können wir davon ausgehen, dass Erfolge erzielt wurden.
Wichtigste Ergebnisse sind Erfolgskriterien, ohne die kaizen nicht auskommt. Erfolg ist Umsetzung.
Nur mit einer implementierten Lösung können Sie das Problem in Zukunft beheben. Wenn Sie also von Kaizen sprechen, müssen Sie immer alles implementieren, was erfunden wurde.
Wo sonst kann dies angewendet werden
Wie Sie wahrscheinlich anhand der Beispiele gesehen haben, kann und sollte Kaizen in der Ereignisanalyse verwendet werden. Eigentlich wurde er dafür geschaffen.
Vorfälle in technischen Support-Gruppen, in der Infrastruktur und in der Produktentwicklung sind perfekt.
In Bezug auf die Codierung können Sie hier Ihren Code analysieren und sehen, wie er geändert werden kann, um die gefundenen Probleme dauerhaft zu beseitigen.
Ja, und der sehr berüchtigte Agile Retro ist auch kaizen, denn bei diesen Meetings werden Probleme für den Sprint analysiert, Fragen zum „Warum“ gestellt und Schritte unternommen, um Problemen vorzubeugen. Das natürlichste Kaizen!
Die Kaizen-Technik selbst funktioniert gut in der Softwareentwicklung, ist sehr einfach zu bedienen und für den persönlichen Gebrauch gut geeignet.
Das Erfolgsgeheimnis ist einfach: Beseitigen Sie die Probleme nacheinander und sie bleiben dann gar nicht mehr bestehen. Dies ist eine kontinuierliche Verbesserung.
Toyota selbst setzt Kaizen mit überwältigendem Erfolg in der Produktion ein. Die Ergebnisse sprechen für sich: Produktionsfehler sind nur 3 Fehler pro 1.000.000 Teile.
Warum bewerben Sie sich nicht?
Jetzt bist du offiziell gepumpt. Wenn Sie einen solchen Begriff hören, wissen Sie, was es ist.
Und Erfolg bei Ihrer Arbeit.