Le terme "kaizen" a été introduit par Toyota, et beaucoup a été écrit à ce sujet dans des livres épais de la série Toyota Tao.
Kaizen est également appelé le «processus d'amélioration continue». Habituellement, il est associé à la production industrielle de voitures et de convoyeurs, ou du moins au contrôle de processus. Ils parlent peu de développement, mais kaizen est très bien adapté au développement de logiciels.
De plus, vous découvrirez plusieurs cas qui ont progressivement amené l'auteur à comprendre le kaizen en développement.
Une série de problèmes
Le premier cas s'est produit juste le jour de l'an, à 20h00. Le disque dur s'est écrasé sur le serveur et à cause de cela, il a fallu rompre avec la préparation des salades et se rendre de toute urgence à Moscou au site d'échange de trafic pour changer l'appareil cassé.
Après le disque dur, la carte mère a grillé. Ils ont tout changé, mais ont ensuite décidé de comprendre pourquoi cela se produisait.
Les administrateurs familiers ont clairement indiqué que vous devez faire très attention au matériel du serveur, ne pas acheter n'importe où et réserver tout et à tous les niveaux.
Il a été décidé de changer de serveur et de faire très attention au choix d'un fournisseur. Nous avons examiné le matériel du serveur, demandé des recommandations et choisi un serveur qui a ensuite fonctionné sans s'arrêter et sans interruption pendant 7 ans. Il continue de travailler maintenant, bien que 5 ans se soient écoulés depuis que l'auteur a quitté ce travail.
Un peu plus de temps s'est écoulé et un incendie s'est déclaré sur le site. Le serveur a miraculeusement survécu. Ensuite, tout le monde a bien tremblé, car il y avait un risque de destruction totale de l'entreprise.
Après cela, un miroir du site et de la base de données a été réalisé sur un site séparé et complètement indépendant à l'autre bout de la ville. Et une fois, elle a même été utilisée.
Il y a également eu un cas où le trafic a commencé sur le site qui vient d'être lancé, et soudain, il s'est complètement arrêté, ne pouvait tout simplement pas supporter la charge.
Après l'étude, il est devenu clair que la société d'externalisation qui a créé le site a fait en sorte qu'il ne détienne pas plus de 200 personnes par jour. Drôle et triste.
Après cela, il a été décidé d'abandonner l'externalisation et de former votre propre équipe de développement.
Après avoir créé l'équipe, nous avons eu un autre problème - la correction de toute erreur a provoqué une avalanche de nouvelles erreurs. Tout changement a presque submergé l'ensemble du site.
Chaque correctif entraînait de très, très nombreux problèmes. Lorsque nous avons analysé la situation, nous avons réalisé que nous devons fondamentalement tout changer en général - tous les intérieurs. Et puis tout le site a été complètement refactorisé, toute son architecture a été bouleversée. Et ce n'est qu'après que la situation a radicalement changé et que les problèmes ont complètement disparu.
Éliminer la cause profonde
Toutes ces solutions étaient unies par une seule chose - toutes visaient à garantir que le problème fondamental qui les sous-tend ne se posait plus, de sorte qu'il était complètement éliminé. Du mot du tout. Et pour que le même problème ne se reproduise plus.
Tu comprends?
Élémentaire: l'ordinateur s'est écrasé - nous avons réalisé que nous devons choisir le bon matériel, qui ne tombera jamais en panne.
Le site a pris feu - ils ont fait une copie pour exclure la survenue d'une situation similaire à l'avenir.
Ensuite, les mots ne savaient pas une telle chose - kaizen.
5 pourquoi
La cause profonde du problème n'est pas toujours à la surface, il faut parfois creuser.
Un bon exemple a été donné dans l'un des livres Tao de Toyota. À l'usine, on a découvert que l'une des machines était inactive pendant une grande partie de la journée.
Pourquoi a-t-il des pauses dans son travail? Il s'est avéré que la machine s'arrête pour le nettoyage.
Autour de la machine se trouvent des copeaux et de la saleté. Naturellement, s'il y a des copeaux autour, alors il doit être retiré, sinon il est impossible de travailler. Ça va?
Mais Kaizen dit: vous devez creuser à la racine.
Pourquoi la puce tombe-t-elle? La réponse vient tout de suite: les puces sont empilées car elles ne vont nulle part - la machine ne possède pas de dispositif permettant de la retirer et de la récupérer. S'il existait un tel appareil, il n'était pas nécessaire d'arrêter la machine.
Eh bien, trouvons une solution qui permettrait de retirer cette puce de la machine et de la faire en sorte qu'elle ne s'arrête pas du tout pour le nettoyage. Cette solution est déjà purement technique et assez simple.
Il existe une technique très simple pour déterminer la cause première: la méthode bien connue du «5 pourquoi».
Kaizen recommande de l'utiliser pour aller au fond des causes profondes.
Considérez constamment les causes du problème, l'une après l'autre:
- Pourquoi la machine s'arrête-t-elle? Parce que le nettoyage est fait.
- Pourquoi le nettoyage est-il effectué? Parce que les copeaux et la saleté volent de la machine.
- Pourquoi les copeaux et la saleté volent-ils? Parce qu'ils ne s'éloignent pas de la machine.
Avec l'aide de «5 pourquoi», nous trouvons la cause première, trouvons une solution pour l'éliminer, affectons une personne responsable et des délais, et vérifions chaque semaine l'atteinte du résultat.
Gardez à l'esprit que tout problème peut être résolu à la fois cher et bon marché.
Kaizen dit: choisissez d'abord le moyen le moins cher. C'est généralement le plus simple et le meilleur.
Kaizen dans le développement de logiciels
Et maintenant quelques exemples récents de la vie d'une équipe de développement logiciel.
Emplois Feil
L'équipe déploie ses meilleures pratiques dans Prod en lançant Jenkins. En fait, Jenkins est un sheduler comme crontab qui peut exécuter des tâches planifiées. Et l'équipe avait un tel travail.
Une fois qu'il a été découvert que Prod-Jobs est tombé 5 fois de suite avec le statut d'échec. Et personne n'y a prêté attention, même si, en fait, chaque fichier sur le Prod devrait être une alarme universelle.
Puis ils ont commencé à découvrir la raison en utilisant la méthode du «5 pourquoi»:
- Pourquoi les jobies se sont retournés 5 fois et personne n'y a prêté attention? Parce que tout le monde reçoit constamment des notifications de feil jobs, il y en a beaucoup et ils se familiarisent
- Pourquoi deviennent-ils familiers? Parce que presque tous les jours, nous recevons une sorte de notifications, échouons et échouons. Nous ne voyons pas la différence. Ils ne leur faisaient tout simplement pas attention.
- Pourquoi les notifications viennent-elles tous les jours? Parce que l'un des développeurs teste un nouveau travail qui tombe, et les notifications à ce sujet vont à tout le monde. Le travail n'est pas important pour le moment, donc tout le monde a cessé de prêter attention aux notifications d'elle et, en même temps, de tous les autres emplois.
La décision était transparente: pour les travaux de test, les notifications sur les fichiers ne seront envoyées à personne sauf au propriétaire du travail, et même s'il en a besoin.
De plus, il a été officiellement enregistré que toute notification du travail est une urgence exceptionnelle, à laquelle tout le monde devrait répondre.
Script déchu
Le deuxième exemple est un problème avec l'application QlikView.
Une fois que l'équipe a été informée que leurs rapports QlikView étaient en quelque sorte différents. Tout semble fonctionner, mais les données ne sont pas les mêmes. Ils ont commencé à comprendre le problème.
Il s'est avéré que le script de téléchargement n'a pas fonctionné jusqu'à la fin. Pourquoi n’a-t-il pas fonctionné jusqu’à la fin? Parce qu'il y avait beaucoup de code dans le script et quelque part au milieu se trouvait l'opérateur de débogage Exit Script - ils ont simplement oublié de le supprimer, ne l'ont pas remarqué. La situation s'est avérée lorsque le script de téléchargement est tombé et que les données ont été utilisées anciennes.
Pourquoi tu ne l'as pas remarqué? Parce que les tests ne l'ont pas montré à cause de l'architecture. L'application était divisée en deux parties indépendantes (back / download script et front), et ainsi de suite. il y avait beaucoup de données, ils ont essayé de ne pas les redémarrer à nouveau, afin de ne pas perdre beaucoup de temps à ce sujet.
Il a été spécialement conçu pour que l'avant ne soit pas connecté au script de chargement. Il a juste pris un certain fichier de données et l'a montré. Il n'était pas clair que ce fichier de données soit ancien, c'est-à-dire qu'il était impossible de déterminer la présence d'une erreur.
Qu'est-ce qui a été inventé pour éviter une situation similaire à l'avenir?
L'équipe s'est posée la question: comment s'assurer de constater une telle situation à l'avenir? Comment faire comprendre que le script de téléchargement n'a pas fonctionné jusqu'à la fin?
Il a été décidé d'enregistrer le label au début du script et de le supprimer à la fin. C'est-à-dire si l'étiquette n'est pas supprimée, cela signifie que le script n'a pas terminé le téléchargement à la fin. Le front a vérifié que, s'il y avait une balise, elle afficherait une bannière rouge sur le sol de la page avec une notification du problème.
Ainsi, bien que la possibilité d'apparition de tels problèmes n'ait pas été complètement exclue, au moins elle a été immédiatement connue à leur sujet. Solution simple et économique.
Perte de données lors des redémarrages
Le service de surveillance Web a reçu des données de stands industriels. Périodiquement, il devait être finalisé et corrigé, et chaque correction nécessitait un redémarrage. Bien que le redémarrage ait duré quelques secondes, à ce moment-là, les données industrielles et l'abîme pouvaient être garantis. Il était impossible de les perdre, alors l'équipe a décidé d'analyser le problème plus en profondeur.
Les questions «5 pourquoi» ont clairement indiqué que la cause première du problème est l'architecture - c'est elle qui n'a pas permis de faire autrement. Peu importe comment le service a été resserré, peu importe ce qu'ils en ont fait, tout se résumait à un redémarrage.
La nouvelle architecture a résolu le problème une fois pour toutes - le service était divisé en deux parties indépendantes, la réception et le traitement des données. Ces parties étaient physiquement séparées, c'est-à-dire vous pouvez désactiver le gestionnaire en toute sécurité et, tout en recevant des données, vous avez continué à travailler et à enregistrer tout ce qui y était associé. Et surtout, le récepteur de données a été conçu de manière à ne jamais nécessiter de redémarrage. Les gestionnaires peuvent être désactivés, modifiés et surchargés en toute sécurité sans se soucier du risque de perte de données.
DevOps semble être là, mais il ne semble pas
DevOps est une chose magique. Il semble être là, mais en même temps il arrive aussi qu'il n'existe pas.
L'un des développeurs a publié ses meilleures pratiques sur le banc de test. Malgré le fait qu'il ait utilisé DevOps, il s'est avéré «soudainement» que le banc d'essai était connecté à la base de données de combat. Une partie des données a été irrémédiablement perdue.
Nous avons commencé à le découvrir. Il s'est avéré que le développeur n'a pas remarqué qu'il utilisait la chaîne de bataille de connexion.
La raison principale était que le développeur devait modifier manuellement la chaîne de connexion pour différents supports et serveurs.
Que dit Kaizen? Ok! Nous devons trouver une telle solution pour éliminer complètement le problème, c'est-à-dire supprimer la nécessité de modifier manuellement la ligne.
Et la solution a été mise en œuvre - la chaîne de connexion a commencé à être automatiquement sélectionnée en fonction du serveur sur lequel elle s'exécutait. Le problème a été résolu une fois pour toutes.
Je pense que vous-même avez déjà compris à partir des exemples ci-dessus que l'essence de l'amélioration continue peut être exprimée en une phrase simple - pour éliminer complètement la réapparition du problème.
Résultats clés - une partie intégrante de Kaizen
Le résultat du kaizen est la réalisation, pas une idée.
Trouver une solution n'est pas si difficile, il est beaucoup plus difficile de la mettre en œuvre.
Pour chaque décision prise, il est important de produire des résultats clés, c'est-à-dire de comprendre qui doit faire quoi et à quelle date.
Comment comprenez-vous que vous avez obtenu un résultat positif?
Prenons un exemple avec une chaîne de connexion. Quel résultat
matériel sera considéré comme un succès ici? Le succès sera atteint lorsque:
- une bibliothèque sera créée pour sélectionner automatiquement la chaîne de connexion,
- le développeur construira une bibliothèque pour lui-même et lancera avec succès son logiciel avec.
Les deux mesures doivent être prises à une certaine date par certaines personnes. Ce n'est qu'avec les deux étapes que nous pouvons supposer que le succès a été atteint.
Les résultats clés sont des critères de réussite; kaizen ne fonctionne pas sans eux. Le succès est la mise en œuvre.
Seule une solution implémentée vous permettra d'éliminer le problème à l'avenir, donc quand vous parlez de kaizen signifie toujours que vous devez implémenter tout ce qui est inventé.
Où cela peut-il être appliqué
Comme vous l'avez probablement vu dans les exemples, le kaizen peut et doit être utilisé dans l'analyse des incidents. En fait, il a été créé pour cela.
Les incidents dans les groupes de support technique, l'infrastructure et le développement de produits sont parfaits.
En ce qui concerne le codage, vous pouvez analyser ici votre code et voir comment il peut être modifié afin de supprimer définitivement les problèmes trouvés.
Oui, et le très célèbre rétro Agile est également kaizen, car lors de ces réunions, les problèmes sont analysés pour le sprint, des questions sont posées «5 pourquoi» et des mesures sont prises pour éviter les problèmes. Le kaizen le plus naturel!
La technique kaizen elle-même fonctionne très bien dans le développement de logiciels, elle est très facile à utiliser et bien adaptée à une utilisation personnelle.
Le secret du succès est simple: éliminez les problèmes un par un et ils ne resteront pas du tout. Il s'agit d'une amélioration continue.
Toyota lui-même utilise le kaizen en production avec un succès retentissant. Ses résultats parlent d'eux-mêmes: les défauts de production ne sont que de 3 défauts pour 1 000 000 de pièces.
Pourquoi ne pas l'appliquer pour vous?
Maintenant, vous êtes officiellement pompé. Si vous entendez un tel terme, vous saurez ce que c'est.
Et du succès dans votre travail.