👨🏾‍💻 🧑🏽‍🤝‍🧑🏼 👨🏼‍🔧 Sur les épines et les étoiles sur la voie de l'optimisation des processus de développement 📛 🧑🏿‍🤝‍🧑🏾 🍛

Rêves, rêves

Les froides soirées d'automne, nous et les développeurs d'applications de visualisation 3D nous sommes réunis dans la cuisine ... avons bu du café ... et y avons pensé ... à l'organisation de référence du développement.

- Mes amis sur le travail agile pour moi: sprints, points d'histoire, toutes choses ...
- Oui, nous reviendrions au moins ...

Le fait est qu'à cette époque, ce n'était pas très fluide avec nous. Par exemple, le stockage de projets dans git était très inhabituel:

il y avait plusieurs référentiels, et chaque partie contenait une partie du projet;
certains référentiels étaient communs, certains ne concernaient que certains projets, d'autres un seul;
pour obtenir une copie de travail, vous avez dû télécharger le contenu de tous les référentiels et les placer dans des dossiers spécifiques.

Puisque nous travaillons avec des graphismes 3D et que nous avons ensuite utilisé le concept de «contrôles + modèles (l'emplacement des éléments à l'écran, la logique des transitions)», pour être plus précis, les choses étaient comme ceci:

lorsque vous travaillez sur des contrôles, les validations sont allées au référentiel avec des contrôles de base et, éventuellement, au référentiel avec des ressources (si les modèles tridimensionnels déjà utilisés devaient être utilisés ailleurs);
lorsque vous travaillez avec des contrôles et des modèles (par exemple, s'il était nécessaire de remplacer l'arrière-plan dans l'application sous le panneau d'aide), les images devaient être téléchargées dans le référentiel avec des ressources et la mise en page modifiée dans le référentiel avec des modèles. Si l'arrière-plan a été créé avec un habillage (style unique), alors 3 référentiels pourraient être impliqués.

Avec cette approche, les revues de code étaient un luxe pour le coût:

le développement a été réalisé dans une seule branche;
les changements sur une tâche ont affecté plusieurs référentiels et le suivi des validations liées à quelle tâche était très problématique.

En conséquence, en raison du manque de capacité à «apprendre des erreurs», à échanger des expériences, à analyser le code de l'autre au cours de l'examen, les développeurs n'ont pas pu améliorer leurs compétences assez rapidement. Et pour développer des applications "plus rapidement" - c'était nécessaire. Et afin de maintenir la vitesse de développement à un niveau acceptable, sur chaque nouveau projet, les gens étaient engagés dans des tâches similaires à celles des projets précédents. C'est-à-dire si quelqu'un travaillait auparavant avec une carte 3D, il obtenait encore et encore des tâches liées aux cartes, ou si quelqu'un développait une fois le composant «graphique», il était condamné aux graphiques. Et cela a sa propre logique, car plus vite, la tâche est réalisée par celui qui l'a rencontré similaire ou identique. En conséquence, il s'est avéré que les développeurs se spécialisent dans des choses spécifiques et ne sont pas interchangeables.

Quant aux méthodologies de développement et à un flux de travail clair, elles n'ont pas non plus été appliquées pour un certain nombre de raisons. Partant du fait que pour cela, il a fallu consacrer un temps considérable à la réflexion sur tous les concepts et processus de développement, pour finir par le fait qu'il n'y avait tout simplement personne pour l'apporter. Ni moi, en tant que dernier employé arrivé, ni les gars n'avaient le pouvoir de réorganiser. Et il ne restait plus qu'à râler et rêver.

«Là où il y a un rêve, il y a toujours une chance»

Bien sûr, pour moi, en tant que personne qui n'est pas indifférente à son travail, le but était de changer la situation. Sinon, quel est l'intérêt de mon activité, si je ne peux pas influencer positivement les processus existants et fournir de telles conditions de travail aux personnes dans lesquelles ils peuvent révéler leurs capacités et s'améliorer? Le développement de ceux qui créent l'application, qui incarnent l'idée projetée sur papier, dans la vie est le développement des projets et de l'entreprise dans son ensemble.

Une bonne chance pour la réalisation de l'objectif était d'approuver le développement d'un nouveau module de visualisation de notre plateforme. Ce projet n'était pas comme les autres, car Ce n'était pas le développement d'une application sur la plateforme, mais l'implémentation d'une partie de la plateforme elle-même. Par conséquent, ici, nous n'étions pas attachés à cet étrange concept de stockage et de travail avec des projets dans de nombreux référentiels git, qui me semblait une excellente occasion d'introduire des revues de code.

Ici, au fait, ce que nous avons fait

Et un beau matin d'hiver, j'ai attaqué l'architecte du projet avec une proposition pour introduire Gitflow. Au début, il a pris mon idée en contradiction, mais il y avait des raisons à cela: certains modèles standard ne conviennent pas toujours. Cependant, dans le processus de communication, l'option la plus appropriée a été développée pour ce projet, que nous utilisons maintenant avec succès.

Notre Gitflow modifié est le suivant:

il y a une branche principale (nous l'avons appelée master, mais vous pouvez donner n'importe quel nom pour ne pas être confondu);
il y a un sprint à Jira, formé de tâches de backlog qui sont unies par une micro-cible;
le développeur prend la tâche de la liste des tâches ouvertes dans le sprint en cours et crée une branche de fonctionnalité à partir du maître, indiquant le code de tâche au nom de sa branche de fonctionnalité (par exemple, PLAYER-55);
dès que le travail sur la tâche est terminé, le développeur soumet son travail pour révision: via Gitlab crée une demande de fusion à maîtriser et transfère la tâche à Jira sur révision avec un lien vers la demande de fusion dans le commentaire;
si la révision est terminée et toutes les discussions sont fermées, la tâche dans Jira se ferme, la branche de fonctionnalité est fusionnée dans master et supprimée;
s'il y a des commentaires après la révision - dans Jira, la tâche est redécouverte depuis Review et l'algorithme s'exécute depuis le début, sauf que la branche de fonctionnalité a déjà été créée.

Lorsque toutes les tâches sont fermées, nous entrons dans la phase de publication:

la branche de publication est appelée loin de master, qui est appelée deux chiffres, par exemple, release-3.0, où 3 est le numéro de version du projet et 0 est le numéro de la branche de release (respectivement, la prochaine branche de release sera appelée release-3.1, etc. );
D'autres tests de la version candidate sont effectués (généralement le développement de petites démos);
si aucun défaut n'a été trouvé pendant les tests, la version candidate est prête pour la production: le dernier commit dans la branche release est marqué avec une balise de production composée de 3 chiffres (par exemple, prod-3.0.0, où 3 est le numéro de version du projet, 0 - numéro de branche de publication, 0 - numéro de version de production), puis la branche de version est bloquée dans le maître et n'est pas supprimée, contrairement au Gitflow classique;
si des défauts sont toujours trouvés, ils sont enregistrés dans Jira en tant que bogue, puis le processus de correction de bogues est similaire à l'utilisation d'une tâche dans la branche des fonctionnalités (il n'est vérifié qu'à partir de la version, pas du maître) et lorsque tous les bogues sont fermés, nous posons la balise de production, la version est sortie vers le prod et la branche release est fusionnée en master, sans être supprimée.

Dans le cas où des bugs sont détectés en production, il existe également un accord:

le travail sur ces bogues est également effectué dans la branche de publication de cette version de la vente, si les modifications sont urgentes, elles sont marquées comme correctif et sont effectuées directement dans la branche de publication avec des chefs d'équipe;
sinon, le travail sur ces bogues est similaire au travail sur les bogues trouvés dans la version candidate.

Alors pourquoi exactement Gitflow et juste ça?

L'entrée dans les branches de fonctionnalités est un moyen d'introduire une revue, qui vous permet de partager votre expérience, d'augmenter le niveau global de qualification de l'équipe et, surtout, d'éviter de faire entrer du code de mauvaise qualité dans le produit fini qui n'a pas de style commun, est difficile à comprendre et plein de bugs.
Je pense que beaucoup de gens connaissent la situation lorsque le projet est évalué selon les termes de référence et les spécifications, un budget est alloué pour cela, vous implémentez la fonctionnalité selon les exigences de la documentation, mais ici, de nulle part, quelqu'un des patrons apparaîtra et vous entendrez: «Oh, mais ajoutons ici quelques licornes, le client va l'aimer »,« Et pouvez-vous avoir la possibilité d'appeler un ami dans cette région en cliquant sur une région sur la carte? Ce sera une bombe, continuez "," Nous devons ajouter une légende "," Maintenant, la légende doit être supprimée, et les signatures aussi "," La suppression des signatures était superflue, retournez-la. " Et tout cela est "gratuit sans inscription ni SMS". Et puis, lors du calcul des coûts réels, il s'avère qu'il a fallu trop de temps pour développer avec un si petit nombre de tâches (après tout, les «demandes» à Jira ne sont généralement pas enregistrées, car tous les développeurs ne peuvent pas refuser le patron ou l'envoyer pour enregistrer sa «demande»). ", Et cela peut être compris). L'introduction de la règle de nommage des branches individuelles avec le code Jira et l'impossibilité de fusionner les branches en maître sans lier à Jira élimine la présence de travaux non enregistrés et les conflits qui peuvent survenir si le développeur "commence à télécharger les droits", vous obligeant à remplir la "demande" en tant que tâche dans Jira, et vous permet également d'avoir une idée claire de la quantité de travail réellement effectuée (les tâches dans Jira sont confirmées par le code qui leur est associé, code écrit par communication avec la tâche enregistrée).
La connexion de Gitflow avec Jira en termes de mise à jour des statuts de tâche permet d'éviter une situation où plusieurs personnes effectuent la même tâche. Dans le cas de la mise à jour des statuts en fonction de leur étape Gitflow, tout le monde verra que telle ou telle tâche est déjà en cours ou en révision, respectivement, pour eux il y a déjà des branches de fonctionnalités dans lesquelles le code est écrit, et vous n'avez pas besoin de les prendre. Il est également clairement visible qui fait quoi et ce qui fonctionne peut s’affecter mutuellement, lequel des gars doit contacter et convenir plus souvent d’une implémentation particulière, de sorte que lorsque la fusion n’a pas à résoudre les conflits de code pendant une période longue et douloureuse.
Étant donné que nous développons une plate-forme pour créer des applications, il convient de considérer que les produits finis de quelqu'un dépendront de notre politique de prise en charge des anciennes versions de la plate-forme et d'introduction de nouvelles. Il est possible que certains utilisateurs de la plate-forme utilisent la dernière version de la plate-forme et trouvent un bogue lié à la plate-forme. Si nous supprimons des branches de publication, nous ne pourrons pas aider nos utilisateurs dans une telle situation, surtout si les fonctions qu'ils utilisent dans leur version sont supprimées ou modifiées dans la nouvelle implémentation de la plateforme. En conséquence, l'enregistrement des branches de version vous permet de fournir une assistance aux utilisateurs qui ne travaillent pas avec la dernière version de la plate-forme.

Et Agile?

Comme vous l'avez probablement déjà remarqué, nous avons commencé à aborder lentement les principes de développement de mêlée agile, en commençant par diviser les tâches en sprints pour les micro-cibles.

Ensuite, ont été présentés Planning Poker, Story Points, analyse de la vitesse de l'équipe, rétrospective.
La participation à Planning Poker et l'attribution de Story Points à des tâches permettent à l'équipe d'avoir une vision plus globale du projet, de la structure de son architecture, de ce que nous recherchons généralement et de ce qui devrait être le résultat. Les gens ont la possibilité de penser de manière systémique, et pas seulement dans le cadre de leurs tâches. Cela affecte favorablement à la fois leur développement professionnel et le projet lui-même:

de nouvelles fonctionnalités utiles sont offertes, car il devient plus clair pour les développeurs ce qui et où peut être amélioré en général;
le plus souvent, des erreurs et des défauts sont constatés qui ne pourraient devenir clairement visibles qu'au moment du fonctionnement de la plate-forme.

En raison de la disponibilité des données sur le nombre de tâches accomplies dans le sprint et les Story Points correspondants, il devient possible d'analyser la vitesse de l'équipe de développement afin de réaliser à l'avenir des estimations de planification et de calendrier plus compétentes.

Certes, il y a un peu de chagrin dans le cadre de notre projet à cet égard: la composition de l'équipe change très souvent, car certains développeurs sont périodiquement emmenés pour des projets urgents, les remplaçant par des libres de tâches. Pour cette raison, l'estimation de la vitesse est réinitialisée à chaque fois. Il est presque impossible de compter dans de telles conditions. Le seul moyen qu'ils ont trouvé est de collecter des données sur chaque composition pour 3-4 sprints, puis d'essayer d'identifier la valeur moyenne.

"Et allons vite" ou 3 applications de démonstration à part entière pendant un mois

Bien sûr, personne n'a annulé le développement d'applications. Surtout si elles sont nécessaires pour atteindre les objectifs globaux de l'entreprise. Surtout si c'est très urgent. Et récemment, la nécessité d'une mise en œuvre rapide des applications de démonstration pour les spectacles a considérablement augmenté.

Bien sûr, ayant travaillé dans un nouveau paradigme, je ne voulais pas du tout revenir aux anciennes conversations. Ensuite, nous avons décidé d'utiliser des parties du nouveau module de visualisation (en tant que système intégré, il n'était pas encore complètement préparé pour ces tâches), en prenant comme guide les principes de son développement.
Étant donné que tous les développeurs n'étaient pas encore dans le sujet du flux de travail, et que l'adaptation des gars au nouveau dispositif de développement était un gros risque en termes de termes de nos démos «brûlantes», nous avons essayé de trouver un certain «compromis» entre le passé et, espérons-le, l'avenir. En conséquence, voici ce qui s'est passé avec l'utilisation partielle des principes du nouveau module de visualisation sur les démos:

Petites équipes. 2-3 développeurs, concepteur, testeur et gestionnaire.
Développement parallèle (auparavant les contrôles étaient d'abord créés, puis les modèles avec l'apparence et la logique de l'application).
Utiliser des tâches comme Story dans Jira. Il n'y avait pas de spécifications claires et de savoirs traditionnels, j'ai donc collecté toutes les informations disponibles sur le comportement et l'apparence attendus de l'application et j'ai tout mis dans Story. Ensuite, ils ont été testés sur eux, ce qui a provoqué une réaction positive parmi les testeurs, car toutes les informations ont été collectées en un seul endroit, mais en même temps elles ont été divisées en parties fonctionnelles, ce qui a facilité la vérification. Et l'équipe dans son ensemble n'a pas eu à lire un tas de textes officiels pour bien comprendre et terminer la tâche. De plus, contrairement aux documents Word avec des spécifications, Story mis à jour plus rapidement, les gens ont rapidement reçu des descriptions avec de nouvelles améliorations et, en conséquence, ont commencé à les mettre en œuvre plus rapidement.
Gitflow avec branches develop et master, mais sans fonctionnalité:

tout développement a été effectué dans la branche develop, mais pour exclure la présence de tâches non enregistrées, chaque commit doit avoir été marqué avec le code de tâche de Jira, dans le cadre duquel il a été réalisé;
lorsque toutes les tâches prévues pour la version ont été résolues, une nouvelle build était en cours d'assemblage: un chef d'équipe a effectué un examen de la branche de développement et, si tout allait bien, les modifications ont été fusionnées en master avec l'attribution d'une balise avec le numéro de build. Si des erreurs et irrégularités grossières ont été révélées lors de l'examen, le code a été envoyé pour révision et ce n'est qu'après avoir été entré et revérifié qu'il est entré dans le masque.
les builds étaient numérotées avec deux chiffres, par exemple 0,1 - c'est toujours le numéro de la première build de test, où 0 - signifie appartenir à la version de production, 1 - numéro de build. Et donc, dans le nombre de chaque génération de test suivante, le dernier chiffre a augmenté, jusqu'à ce que le testeur et le gestionnaire concluent que la génération est prête pour la sortie en production. Par conséquent, s'il s'agissait de la quatrième version de test (0.4), il s'agissait de la première version de production (1.0) et la balise correspondante était placée dans la branche principale. Si des défauts sont détectés dans la production et que la version de production a été envoyée pour modification, le deuxième chiffre augmente également lors de la numérotation de toutes les versions suivantes (1.1, 1.2, etc.).

Ainsi, au cours d'un mois, nous avons implémenté 3 applications de démonstration à part entière, dont nous avons reçu des critiques positives et qui continuent d'être utiles. Auparavant, nous ne pouvions pas implémenter une telle fonctionnalité si rapidement et avec autant de personnes dans l'équipe.

À mon humble avis

Qu'est-ce que j'en pense personnellement?

Que l'organisation des processus affecte vraiment le résultat et que l'écoute des pratiques de développement du monde inventées par les développeurs eux-mêmes et orientées vers eux n'est pas seulement «élégante, à la mode, jeune», mais nécessaire (après les démos, pour la première fois depuis plusieurs années de pratique, nous avons continué à faire le reste projets, et ne s'est pas assis jusqu'à la nuit 2 semaines après la livraison, transpirant le visage du tas découvert par le client honteux défauts).
Le niveau de chaos, de malentendu et de stress sur les projets avec un flux de travail clair est plus faible (les gens sont mieux équipés en informations pertinentes, ils savent où les obtenir si nécessaire).
La bonne utilisation des outils de gestion de projet affecte le développement des projets eux-mêmes et leurs participants (en raison de l'optimisation du développement dans Gitlab, Jira, l'introduction des principes de la mêlée agile, il est devenu possible d'échanger des expériences dans une équipe, des compétences de pompage dans une équipe, plus souvent les connaissances et l'expérience des chefs d'équipe juniors ont commencé à être transférées et développeurs intermédiaires).

Voici le secret

Malgré les conclusions ci-dessus, et quelque chose d'autre est devenu évident pour moi:

- Tout le monde n'est pas prêt pour ce dont il rêve.

Parfois, lorsque nous observons quelque chose de côté, il nous semble que c'est quelque chose de bon, d'utile, nécessaire pour réussir, corriger et référencer. Mais le rêve vaut la peine de devenir une réalité, comme nous le comprenons: "Ce n'est pas ce que j'imaginais." Donc, au travail: il semble que maintenant vous donner de telles conditions dans lesquelles les "entreprises normales" travaillent, et vous vous épanouirez. Mais hélas. Et il arrive que vous, sans ménager votre énergie, essayiez de donner aux gens quelque chose dont ils rêvaient comme une garantie de succès, mais un miracle ne se produit pas: le travail n'est toujours pas fait en haute qualité, et vous comprenez que vous avez peut-être accepté le comportement typique de quelqu'un mots de soutien pour une conversation en cuisine pour de vraies aspirations et rêves.

Ainsi, dans le processus d'introduction de nouvelles règles et principes, nous avons été confrontés non seulement à des retours et des résultats positifs, mais aussi à une perception négative de ce qui se passait. Pour certains, travailler avec Jira et Gitlab semblait être très compliqué, et changer cette perception était extrêmement difficile jusqu'à ce que les gens rencontrent une situation problématique qui se produisait en ignorant le flux de travail généralement accepté. Certaines tâches ont toujours été effectuées avec négligence, les descriptions dans Story et les énoncés de problèmes n'ont pas été pris en compte ou perçus comme des «demandes personnelles» et n'ont pas été effectuées, malgré l'enregistrement auprès de Jira avec une déclaration claire.En général, les versions avec une implémentation de paramètres de mauvaise qualité ou inappropriée sont toujours apparues et certains bogues ont été rouverts de génération en génération. Bien que le résultat final ait été positif dans toutes les démos, j'ai quand même pensé au fait qu'avec les gars responsables du travail, soucieux de donner le meilleur résultat possible, nous avons réussi non seulement à implémenter les fonctionnalités nécessaires, mais aussi à introduire de nouvelles fonctionnalités, à optimiser l'application et à "Ajoutez Ryushechek." Et avec des équipes où quelqu'un pouvait se permettre d'être trop paresseux ou était moins intéressé à obtenir le résultat de la plus haute qualité, nous avons mis en œuvre uniquement les fonctionnalités de base et quelques petites fonctionnalités à la demande supplémentaire du client après la livraison.

Et puis, peut-être, ma conclusion la plus importante m'est venue:

- Pas un processus, pas la technologie - les vraies clés du succès, mais ceux qui créent, créent, incarnent l'idée dans la réalité - les gens et leur attitude envers leur travail. Un musicien qui met son âme dans son travail affectera le public, jouant même l'instrument le moins cher et le plus inconfortable. Et donnez-lui Stradivari - il rendra le public fou. Et il y a ceux à qui même Stradivarius, au moins fournit le dernier développement des principaux fabricants d'outils - tout semblera sans importance.

Vous pouvez offrir aux gens des conditions confortables et des technologies de pointe, mais en fin de compte, vous obtenez un résultat insatisfaisant de leurs activités, car «et ainsi de suite». Et vous pouvez obtenir un résultat décent si vous n'avez pas le plus de succès, et parfois même entraver la mise en œuvre compétente des technologies, car ceux qui l'ont atteint ne peuvent pas se permettre de remettre un travail inachevé ou mal fait. Et il est très important de discerner, de soutenir ces membres de l'équipe, de pouvoir les écouter et de créer des conditions favorables à leurs activités.

La technologie et l'organisation des processus ont vraiment un impact sur le résultat et sont très importantes, mais la clé du succès réside dans des personnes talentueuses, responsables et axées sur le développement.