Salut Je m'appelle Oleg et je suis développeur front-end chez Alfa Bank. Je veux vous raconter une petite histoire philosophique - sur l'approche d'ingénierie du développement, sur mon premier travail et le rake que j'ai collecté là-bas, sur pourquoi les check-listers sont très importants (et sauvent des vies).
Et aussi sur la façon de continuer à travailler de manière productive et de ne pas creuser beaucoup de petites et peu de tâches.
Tout a commencé avec le chaos.
Lors de mon premier travail (pas Alpha, non) j'ai été en quelque sorte emmené et immédiatement jeté dans l'embrasure, ils ont dit, mec, maintenant tu fais du CRM, la maquette est là-bas. Que faire et comment faire - je ne comprenais pas du tout. Que font-ils habituellement dans une telle situation? C'est vrai - ils courent vers leurs collègues et commencent à vérifier avec eux comment livrer le code au serveur, comment sont les choses avec le git, quelles pratiques nous utilisons et lesquelles ne sont pas, etc. Cette approche m'a aidé et je conseille constamment aux autres de le faire. Posez, posez des questions, même si cela vous semble évident, précisez ce qui doit être clarifié. C'est normal. Ce n'est pas normal de ne pas demander.
Ma prochaine étape a été d'utiliser des livres. Parce que lorsque je renvoyais des questions et obtenais des réponses comme "Yuzay linter", je me suis surpris à penser que je sais comment faire tout cela, mais je ne comprends pas très bien pourquoi. J'étais sincèrement intéressé de savoir où poussent les jambes dans tous les processus, et j'ai décidé de chercher de l'aide dans les livres. "Code pur", "Code parfait" - en général, je suis allé à l'ensemble standard, où ils disent que la fonction ne devrait pas dépasser 30 lignes. Je dois dire tout de suite que cela n'a pas aidé à tout comprendre et à contrôler le chaos.
Oui, j'ai commencé à écrire nettement plus propre, mais le chaos sous la forme d'un tas de tâches, que je ne pouvais pas normalement résoudre, n'a pas disparu. Des collègues ont décidé d'aider avec des conseils judicieux comme "Mec, tu n'as juste pas assez de bord, lisons ici le bord et tout sera cool avec toi, si tu donnes aussi le Scrum-master."
Et bien oui. Agile seul est une bonne chose. Mais quand vous travaillez en équipe. Et l'Edge à une face est un peu étrange. J'ai commencé à creuser plus loin, j'ai trouvé des livres kaizen. Et puis j'ai rencontré la théorie de la restriction du système et le livre «But». Beaucoup le lisent probablement, donc je vais juste noter brièvement que l'un des principaux messages ici n'est pas d'améliorer tout partout à la fois, mais d'abord de trouver un problème et de le résoudre. Fixe - recherchez le suivant et corrigez-le. L'auteur y est parvenu grâce à des approches d'ingénierie, car les ingénieurs font quelque chose comme ça - ils recherchent un problème et le résolvent.
D'accord, ce sont les paroles, approchons-nous de la pratique.
Dans la vie
Supposons que vous ayez une sorte de processus sphérique dans le vide dans lequel il y a un concepteur, un frontal et un testeur. Le concepteur dessine des dispositions et des boutons en une journée, le front-end fonctionne en trois jours avec cela, et le testeur a besoin de deux jours. Cela semble être un schéma simple et il est immédiatement clair où améliorer le processus - sur le front-end, car son travail prend le plus de temps. Autrement dit, le point d'optimisation est de trouver l'étape la plus lente du processus.
Mais ceci est un exemple simple avec trois variables. Bien sûr, le travail est souvent différent. Et bien différent. Le processus se complique lorsque vous avez un backend, une documentation, un CI / CD et d'autres gadgets importants.
Et puis, il ne sera pas possible de saisir immédiatement et de dire quel processus est le plus lent et où commencer. Ici, le processus d'optimisation de l'étape la plus lente ressemblera à ceci:
- Il faut trouver la restriction, la plus lente.
- Décidez comment l'utiliser autant que possible.
- Subordonnez tout à la décision.
- Développer (étendre) la restriction.
- Revenez en arrière et répétez.
Cela peut sembler désordonné, je vais donc écrire plus en détail.
Que faire, avez-vous des tâches parallèles qui vous occupent?
Dans ce cas, vous chercherez l'itinéraire le plus long en jours au total. Dans l'image ci-dessus, il s'agit d'environ 6 jours. Commencez par cela, avec ce processus le plus long. Il s'avère que dans cet exemple, vous améliorerez le backend, car cela prend 4,5 jours. Ce n'est pas non plus si difficile, mais quand vous y arrivez et commencez à le faire, vous remarquez que la vie devient plus facile.
Je reviendrai sur des exemples de mon chaos de travail. J'ai eu un tas de tâches et je n'ai pas eu le temps. J'ai réalisé qu'il y a une limitation dans le frontend (c'est-à-dire en moi), que le problème n'est pas dans le testeur, car il trouve des bugs, notamment de mon côté. Pour y remédier, j'ai commencé à réfléchir à la manière d'utiliser cette restriction.
Et il a décidé que nous devons changer le processus afin qu'il n'y ait qu'un seul point d'entrée - une personne qui décide si nous ferons la tâche ou non. Parce qu'il y a eu des cas où une personne est venue et a dit, Oleg, nous devons déplacer le bouton ici un peu vers la droite. Et puis un autre. Et dans une demi-heure quelqu'un d'autre avec une tâche similaire. Et il semble que les petites choses et les ordures, mais à la fin j'ai cousu complètement, essayant de plaire à tout le monde.
Maintenant, j'essaie de ne pas faire plus de 2 tâches en parallèle (en parallèle et pas simultanément). Auparavant, je pouvais confier au testeur une tâche et aller faire ce qui suit, mais si le testeur détectait un bogue, je devais vérifier, me souvenir et basculer sur le code qui y était écrit, ce qui est plus difficile qu'il n'y paraît lorsque vous changez souvent. Et en général, la commutation coûte cher. Essayez de ne pas faire plus de 2 tâches en parallèle. 3 tâches sont déjà un moyen de coudre.
Voyons comment subordonner tout le reste à la décision. Il semble logique, oui, que s'il y a tant de tâches, alors vous n'avez pas besoin de lancer une diapositive? Par exemple, vous vous attendez à ce qu'une personne effectue trois tâches d'une complexité à peu près égale en trois jours. Si, en deux jours sur trois, il n'a effectué qu'une seule tâche, il est fort probable qu'il ne rentre pas dans le plan, alors lui lancer plus de tâches par le haut est un peu démotivant.
En savoir plus sur les restrictions
Bien sûr, les restrictions peuvent être étendues. Dans notre exemple, embauchez un autre front. C'est aussi logique, plus de fronts - ils auront le temps d'accomplir plus de tâches. Ensuite, la restriction sera transférée à un autre endroit.
Il existe également une approche dans laquelle ils élargissent non pas le nombre d'unités, mais leurs compétences. J'ai un exemple vivant - le testeur pourrait m'aider à l'avant si je connaissais l'avant. Chez mon collègue, le scrum-master a commencé à écrire le frontend par lui-même, parce qu'il était intéressé, il y a fait quelques fonctionnalités avec un clin d'œil, et il s'est amusé et l'équipe a aidé. Je n'encourage pas à le faire à la maison, car le résultat peut être très différent, mais à titre d'exemple, il existe une telle approche - oui, et cela fonctionne parfois.
Liste de contrôle
Les listes de contrôle aident vraiment à rendre la vie plus facile. Cette
liste de contrôle pour Alfa-Bank aide maintenant beaucoup dans mon travail
, où il y a pas mal d'étapes qui doivent être accomplies.
Cheklists sauvent même des vies, je vais donner un petit extrait du livre
«Comprendre les risques. Comment choisir le bon cours ":
À l'aube de l'aviation, les pilotes ont volé sur des avions qui n'étaient pas aussi équipés en équipements techniques qu'aujourd'hui. Les listes de contrôle ont commencé à être utilisées dans l'US Air Force seulement après qu'il est devenu clair que le bombardier B-17 était un avion trop gros et ne pouvait pas être contrôlé par une seule personne. En 2009, lorsque les deux moteurs ont décroché sur le vol 1549 d'US Airways immédiatement après le décollage de l'aéroport de La Guardia, les pilotes ont effectué toutes les actions de la liste de contrôle dans une telle situation d'urgence, y compris une tentative de redémarrage des moteurs. Les agents de bord, toujours conformément aux listes de contrôle, ont surveillé strictement la bonne préparation des passagers à un atterrissage d'urgence. Des listes de contrôle comme celles-ci sont un moyen simple et peu coûteux d'augmenter la sécurité.
En médecine, une image différente est observée. Chaque année, la mauvaise utilisation des cathéters veineux centraux provoque environ 80 000 cas d'infection sanguine et, par conséquent, environ 28 000 personnes meurent dans des unités de soins intensifs dans des hôpitaux américains. Et les patients qui parviennent à survivre passent en moyenne une semaine supplémentaire en soins intensifs. Le coût total du traitement de ces infections est estimé à 2,3 milliards de dollars par an. Qu'est-ce qui peut sauver ces gens? De meilleurs médicaments pour traiter les infections, de meilleures technologies? La réponse est: améliorer la culture des erreurs.
En 2001, Peter Pronovost de l'hôpital Johns Hopkins a rédigé une simple liste de contrôle pour les médecins des urgences afin de vérifier si ces mesures pouvaient réduire la propagation de l'infection. Voici cinq étapes successives conçues pour empêcher les bactéries dangereuses d'entrer dans le patient:
1) se laver les mains avec du savon;
2) traiter la peau du patient avec un antiseptique chlorhexidine;
3) couvrir le patient d'une feuille stérile;
4) porter un masque, un chapeau, un tablier et des gants stériles;
5) appliquer du matériel stérile sur le cathéter après l'insertion du cathéter dans la veine.
Dans cette liste, chacune des mesures de protection était bien connue, elle ne contenait rien de nouveau. Pronovost a demandé aux infirmières travaillant dans son unité de soins intensifs de voir si les médecins respectaient ces 5 règles. Les infirmières ont signalé que lors de l'installation d'un cathéter, plus d'un tiers de tous les patients n'avaient pas respecté une ou plusieurs de ces règles. Le taux d'infection de la circulation sanguine à l'hôpital à cette époque était de 11%.
Pronovost a convaincu l'administration hospitalière d'autoriser les infirmières à arrêter les médecins si elles manquaient l'une des cinq mesures prescrites. Cette innovation révolutionnaire a violé la structure hiérarchique dans laquelle le personnel paramédical (principalement des femmes) n'avait pas le droit de donner des instructions aux chirurgiens (principalement des hommes). Après un an, au cours duquel ces instructions ont été strictement suivies, le taux d'infection de la circulation sanguine chez les patients hospitalisés est passé de 11% à 0 (!). Et au cours des 15 mois suivants, seulement 2 cas d'une telle infection ont été notés. Rien que dans cet hôpital, la liste d'instructions a évité 43 infections, 8 décès et économisé 2 millions de dollars.
Pour montrer que l'effet de l'utilisation de la liste de contrôle ne se limitait pas à son hôpital, Pronovost a convaincu plus d'une centaine d'unités de soins intensifs du Michigan de participer à une étude conjointe à grande échelle. Il est important de noter que chacun d'eux a développé sa propre liste d'actions les plus pertinentes pour sa culture.
Les unités de soins intensifs participant à l'étude ont indiqué qu'auparavant, elles avaient enregistré un total de 695 cas d'infection de la circulation sanguine due à l'utilisation de cathéters. À peine 3 mois après le début de l’utilisation des listes de contrôle dans la plupart des services, le taux d’infection des patients est tombé à zéro. Les unités de soins intensifs restantes ont également réussi à réduire de manière significative cet indicateur pour l'année et demie au cours de laquelle l'étude a été menée. Ce programme à grande échelle pour sauver des vies a été mis en œuvre sans recourir à des technologies coûteuses et sans augmenter le nombre de personnel hospitalier.Autrement dit, chacun de ces points était connu, ce n'est pas une sorte de nouveauté ou autre chose. Peter l'a simplement conçu sous forme de liste de contrôle et l'a rendu obligatoire. C’est tout.
Nous essayons d'améliorer non seulement nos résultats, mais aussi les résultats des autres, nous mettons donc constamment à jour notre liste de contrôle de travail. Si j’ai soudain oublié quelque chose et que je n’ai rien fait dans le processus, je l’ai mis sur la liste de contrôle pour ne pas oublier la prochaine fois. Auparavant, les modèles étaient souvent retournés au concepteur pour être retravaillés, bien qu'il ait dit qu'il comprenait immédiatement tout et le ferait bien, et après qu'il nous a juste demandé une liste de contrôle, j'en ai jeté un morceau pour la conception, et c'est devenu plus facile.
J'ai trié ma liste de contrôle par action - 1 action = 1 élément de liste de contrôle. L'essentiel ici est également de ne pas se reposer très fortement et de ne pas entrer dans les listes de contrôle pour le plaisir des listes de contrôle. Page Make Up est un bon point. «Make up controls» - encore plus, vous aidera à ne pas oublier les contrôles et leurs nuances.
Une liste de contrôle peut être hiérarchique: mise en page -> mise en page -> mise en page.
Pourquoi le codage ne suffit pas
Des tests sont nécessaires. Mais ils ne sont pas toujours nécessaires. Par exemple, vous faites un atterrissage une fois, et vous ne prévoyez pas d'y revenir plus tard - alors il est inutile de le pousser très fort. Vous pouvez couvrir les sélecteurs avec des unités ou utiliser end2end, mais les tests unitaires pour le reste sont une perte de temps.
Mais c'est pourquoi le codage ne suffit pas. Encore une fois, un exemple du premier travail - j'ai dû changer quelque chose, je suis allé voir mes collègues et j'en ai parlé, ils ont répondu qu'ils étaient occupés. Et mon sprint brûle. Et il n'y a personne pour aider. En conséquence, il a commencé à se comprendre dans des compétences supplémentaires.
Supposons que vous ayez de bonnes compétences, par exemple, en travaillant avec CI / CD. Le concepteur vous a donné la mise en page et est parti en vacances, vous avez eu quelques modifications ou questions, mais jusqu'à ce qu'il revienne de vacances, c'est tout, le processus en vaut la peine. Développez vos compétences, car si le point faible du processus est du côté de la conception, eh bien, le concepteur est cousu pour un certain nombre de raisons, vous pouvez l'aider. Il s'agit d'un ensemble supplémentaire de connaissances, mais il peut être maîtrisé. Bien sûr, je ne parle pas de remplacer complètement et complètement un spécialiste, je parle de compétences de base.
Conclusions
Il est utile d'aborder la question en tant qu'ingénieur. Même si votre travail n'est pas de nature technique. Il vous permet de ne pas tout présenter sans réfléchir, mais de trouver un problème et de ne présenter que ce qui contribue à sa solution.
Besoin de communiquer et de discuter des solutions. La communication est en principe difficile à surestimer. Parfois, des problèmes surviennent à cause de la soi-disant initiative silencieuse. Nous avons eu un cas où on nous a donné un développeur .Net et une tâche simple pour lui d'écrire des tests. Il a rapidement tout écrit, des tests, des tests unitaires, des sélections, puis, pour une raison quelconque, a commencé à faire quelque chose au-delà de ce qui était dans la tâche. Apparemment, dans la conviction que cela nous sera utile. En conséquence, tout ce qu'il a fait nous a fait consacrer beaucoup de temps à une synchronisation supplémentaire, puis tout cela est allé à la poubelle essentiellement. Juste à cause de problèmes de communication de base. Ne fais pas ça.
Eh bien, une liste de livres utiles:
- Théorie de la restriction du système (E. Goldratt)
- Gestion de projet de chaîne critique (E. Goldratt)
- Gemba kaizen - un moyen de réduire les coûts et d'améliorer la qualité (M. Imai)
- Gestion agile: leadership et gestion d'équipe (A. Jürgen)
- Explication de la programmation extrême (K. Beck)
Une présentation détaillée peut être trouvée
ici .
Utilisez-vous des listes de contrôle, les jugez-vous nécessaires? Si vous avez une approche pour maintenir ou créer une liste de contrôle, veuillez partager dans les commentaires.