Récemment, je vois de nombreux exemples de la façon dont les chefs de projet techniques (alias CTO) suivent les canons du culte Cargo dans le développement et la gestion de projets, au lieu d'introduire des entités selon les besoins et de construire le processus en fonction des besoins actuels, des ressources et des compétences disponibles interprètes. Nous parlerons de la façon d'identifier un tel adepte du fret et des risques qu'il comporte pour le projet.
Discussions quotidiennes du matin (aka Daily Standup)
À ma question naturelle à l'un de ces CTO - à quel point cet avantage est tangible, CTO a honnêtement répondu - "Je ne sais pas non plus." Malgré certains avantages pour l'équipe, dont une partie fonctionnait à distance, les discussions se sont certainement résumées à «Hier, j'ai écrit du code, aujourd'hui j'écris du code et demain je prévois d'écrire du code aussi, mais bon, je corrige toujours tel ou tel bogue». En conséquence, nous avons moins une demi-heure de chaque membre de l'équipe. Un avantage supplémentaire pour les travailleurs à distance est la communication quotidienne avec l'équipe, pour certains, c'est important. À mon avis, l'utilité de ces discussions quotidiennes pour le développement est plutôt faible, car la tâche principale de ces rassemblements généraux est de fournir à tout le monde des informations sur l'état actuel du développement, les plans pour un avenir proche (d'une semaine à un mois), pour discuter de certaines questions qui intéressent tout. Très souvent, de telles discussions se glissent dans des discussions sur des questions de niche qui sont intéressantes pour quelques personnes, et les autres commencent à s'ennuyer et à s'attendre à ce que cela se termine. Cela devrait certainement être supprimé et discuté plus tard, dans un format plus étroit. L'état actuel de développement et les plans sont très importants, mais il suffit d'en discuter une fois par semaine voire moins, selon la vitesse à laquelle l'équipe travaille.
Déploiement cloud
Actuellement, de nombreux outils sont disponibles qui vous permettent de décrire l'infrastructure du projet (services, réseaux, dépendances) sous une forme pratique, par exemple Terraform. Cette chose est certainement utile, mais avec une certaine taille de projet, par exemple, quand cela devient assez compliqué. Pour la plupart des startups et des petits projets, il s'agit d'un outil redondant, car l'infrastructure change extrêmement rarement et la capacité de déployer rapidement une autre production est nécessaire, en gros, une fois par an, de nombreuses startups peuvent tout simplement ne pas survivre. Par conséquent, plus le projet est décrit simplement, mieux c'est pour beaucoup Docker Compose.
Couverture de code avec tests unitaires
Un enthousiasme excessif pour les tests conduit au fait que de précieuses ressources de développement y sont consacrées, augmente considérablement le coût de la refactorisation (après tout, tous les tests concernés doivent être réécrits) et crée souvent l'illusion d'un code fiable et de son bon fonctionnement. J'ai rencontré une startup où, après un an de développement, plus de 2000 tests ont été écrits pour le backend uniquement! Pour avancer efficacement dans le développement, les tests doivent couvrir uniquement les sections vraiment importantes du code où certains calculs sont effectués et le diagnostic manuel des erreurs est difficile. Souvent, pour les startups, la couverture des tests peut être retardée jusqu'à ce que la structure du code devienne stable et que la logique métier devienne claire et ne change probablement pas de manière significative. Pour les tests unitaires frontaux, ils sont souvent inefficaces, car il n'y a généralement pas assez de calculs et d'algorithmes complexes, et il est préférable de couvrir les fonctionnalités SPA de base telles que les pressions de boutons pendant la phase de test de BlackBox via Selenium ou similaire.
Gestion des processus de développement
Le CTO Cargo cultist utilise toujours ces outils et technologies qui ont déjà fonctionné pour lui auparavant, il a lu plus tôt des choses intéressantes ou on leur en a parlé. L'applicabilité de tout cela dans les conditions actuelles est difficile pour lui à évaluer, donc il suit clairement les canons du culte de la Cargaison - "après tout, un avion a volé avant, donc je le fais bien." Convaincre le CTO qu'il est préférable d'utiliser d'autres outils et technologies pour le projet actuel devient une tâche ardue et non triviale, car le CTO n'est pas habitué à analyser les conséquences.
Management d'équipe
Il y a une façon pour le pratiquant de Cargo, et il la suit. Le fait que la gestion de l'équipe doive être construite sur la base de l'état actuel du projet, de ses exigences, de ses qualifications et de ses limites de l'entrepreneur est nouveau pour lui et il n'y attache aucune importance, car il court un risque élevé de ne pas pouvoir y faire face. Il n'est pas facile pour lui d'admettre qu'il devrait y avoir une attitude différente envers les développeurs seniors et intermédiaires, qu'il existe des développeurs spécialisés dans les communications, l'approche commerciale et la responsabilité. Pour lui, toutes les pièces de l'échiquier sont à peu près les mêmes, il fait à peu près les mêmes mouvements. Il n'a probablement pas entendu parler du fait qu'il est nécessaire d'identifier et d'utiliser les points forts de chaque développeur. De ce fait, l'efficacité du travail de l'équipe est considérablement réduite, les développeurs le remarquent très bien et cela les rend moins satisfaits du travail, généralement caractérisé par un roulement décent. Souvent, ces CTO aiment dire qu'ils ont tous des développeurs Fullstack, même si personnellement j'ai rarement vu des frontaux et des backend aussi forts, trop de technologies doivent être connues à un bon niveau.
Comment ne pas devenir / ne pas être un adepte du fret
- Adoptez toujours une approche critique pour introduire de nouvelles entités (services, technologies). S'il y a des gens dans votre équipe qui connaissent bien MySQL mais qui n'ont pas travaillé avec Postgres, alors il est inutile de choisir Postgres si cela ne vous donne pas d'avantages significatifs.
- Le processus de développement doit être adapté à l'équipe et à l'entreprise. Si Vasya travaille sur Scrum et couvre tout avec des tests unitaires, cela ne signifie pas que cette approche fonctionnera également pour vous, vous devez toujours évaluer de manière critique et comparer avec d'autres options (cascade). En règle générale, ce qui fonctionne pour une petite équipe cesse de fonctionner pour une grande équipe et vice versa.
- Identifiez les points forts des membres de l'équipe et utilisez-les au maximum. Cela augmentera l'efficacité de toute l'équipe et les employés seront plus heureux, car ils apportent plus d'avantages pour moins d'efforts.