Le matin, après une tasse de café, nous avons ce qu'on appelle une réunion quotidienne. Chacun d'entre nous raconte son histoire : "Hier, j'ai terminé cet outil, alors n'hésitez pas à l'utiliser", "J'ai apporté quelques modifications au pipeline de CI, il devrait fonctionner plus rapidement, mais si vous rencontrez des problèmes, contactez-moi", "J'ai eu une réunion avec un client, nous devons vraiment respecter le délai cette fois-ci, mais nous pouvons reporter la mise en œuvre de la fonctionnalité X à l'automne", "Je suis bloqué à cause de... Par conséquent, je fais Y au lieu de Z". Ainsi, chacun est responsable de faire connaître l'état de son travail à ses coéquipiers (et pas seulement à la direction). En fait, le stand-up quotidien n'est pas la seule façon de le faire, mais parfois cela fonctionne.
Mon coéquipier a terminé une tâche hier soir, et je suis invité à faire une revue pour la pull request. J'exécute le code et - oups - une NullReferenceException est levée. Il semble que le développeur n'ait pas testé le code en profondeur et qu'il ait manqué quelques cas limites. J'écris un commentaire avec mes conclusions pour que le développeur puisse corriger le bogue et ajouter les tests unitaires/intégration manquants. Faire des examens par les pairs, tester notre propre code et faire de notre mieux pour fabriquer un produit de bonne qualité fait également partie de nos responsabilités.
Puis il y a une longue réunion ennuyeuse de tout le monde avec beaucoup de chiffres. Les réunions sont nulles.
Après le all hands, il y a une belle occasion de travailler sur la conception d'une nouvelle fonctionnalité et enfin de faire du codage. En fait, c'est la partie préférée du travail.
Puis un ingénieur en automatisation des tests vient discuter des options possibles pour tester un nouvel ensemble de fonctionnalités. Nous travaillons ensemble sur le concept qui permet aux tests d'être moins fragiles et voyons comment les développeurs peuvent aider l'équipe d'automatisation des tests. L'interaction entre les différentes équipes fait également partie des responsabilités.
Puis nous devons discuter des nouvelles exigences avec un propriétaire de produit. Une nouvelle fonctionnalité sexy peut compromettre la sécurité du système, et probablement ce n'est pas ce dont les clients ont réellement besoin. Essayer de comprendre les exigences réelles fait partie de notre travail, et ce n'est pas le plus facile. Ensuite, nous avons un petit poker de planification pour estimer quelques tâches dans le backlog qui sont susceptibles d'être prises pour le prochain printemps. Seuls les développeurs peuvent estimer les efforts à fournir. (Honnêtement, les développeurs sont nuls en estimations, demandez à n'importe quel chef de projet)
La journée est presque terminée, j'ai un peu de temps pour apprendre la technologie que nous allons utiliser bientôt, et pour finaliser la tâche de codage d'aujourd'hui. Oh non, tous les pipelines de construction sont rouges. En parcourant les logs, je vois que les versions des artefacts sont totalement mélangées. Ce nouveau système de versionnement automatique maison que nous utilisons s'est avéré être une source éternelle de frustration. Nous devons réunir une nouvelle réunion pour discuter de ce que nous allons en faire (appliquer un nouveau correctif très probablement et attendre un mois jusqu'à ce que cela casse à nouveau nos pipelines).
Basiquement, c'est ce que nous faisons. Ok, ok, je'vais être honnête. C'est ce que notre chef de projet pense que nous faisons. Ce qui est dans la réalité peut être une autre histoire à raconter à une autre occasion.
C'est ce que nous faisons.