8 signes que votre agile n’est pas agile

En 2001, année de la rédaction du manifeste Agile, des années d’essais et d’erreurs avaient conduit les ingénieurs à se rendre compte que les pratiques traditionnelles d’ingénierie ne pouvaient pas être utilisées pour construire des logiciels efficacement.

Avec leur nouvelle méthode, ces ingénieurs ont construit des équipes performantes transformant un secteur entier. Tout le monde a alors essayé de reproduire ces methodes avec des résultats variables.

Aujourd’hui, tout développeur est “Agile” et le mot “Agile” est utilisé pour tout et n’importe quoi.

Bien que l’ensemble du secteur estime qu’ils exécutent un travail de développement Agile, vous trouverez ci-dessous une liste de signes indiquant qu’une équipe a perdu l’essence de ce qui rend Agile beau et efficace à la base:

1. L’équipe “AQ”

Si vous avez une équipe “AQ” distincte (assurance qualité), c’est l’un des indicateurs les plus clairs pour lesquels vous ne travaillez pas avec Agile. Ce sont les développeurs qui ont conçu le logiciel qui doivent le tester à mesure de leur progression. Ils devraient écrire des tests automatisés pour gagner du temps. La qualité du travail ne doit pas être vérifiée à la fin de la chaîne de montage; il devrait être vérifié à chaque étape du processus.

2. Mauvaise communication

Cela peut sembler évident, mais créer un logiciel avec des méthodologies Agiles implique une communication rapide, claire et directe entre toutes les parties impliquees l’entreprise.

3. Un emploi du temps imposé

Sous la pression du travail, les responsables essaient d’imposer des délais aux tâches avec peu ou pas de compréhension du temps nécessaire pour atteindre le jalon requis. Ils ont promis le résultat à un client d’obtenir un contrat ou à un investisseur pour obtenir du financement. La direction ne peut à la fois prétendre utiliser Agile et imposer des délais. La direction n’atteindra jamais l’efficacité obtenue par les parents d’Agile tant qu’ils ne comprendront pas que faire pression sur une équipe ne peut que conduire à des ralentissements.

4. Une mauvaise atmosphère de travail

Agile a été créé pour les ingénieurs en logiciel et est conçu pour leur fournir un environnement idéal. S’il n’y a pas d’étincelle dans les yeux de vos développeurs, il y a peut-être un problème avec la façon dont votre entreprise applique la méthode Agile.

5. Un renouvellement continu des ingénieurs

Un autre signe clair de dysfonctionnement est lorsque l’équipe de développeurs perd et gagne fréquemment ses membres. Les développeurs qui partent ne vous diront peut-être pas pourquoi ils sont partis - ils peuvent dire qu’ils ont trouvé une grande opportunité ailleurs - et ils l’ont peut-être déjà fait. On peut se demander pourquoi ils cherchaient du travail ailleurs. Les meilleures équipes n’ont presque pas de renouvellement d’ingénieurs.

6. Les ingénieurs les plus expérimentés codent au lieu d’enseigner

L’ingénieur senior le plus efficace ne devrait presque pas coder. Les ingénieurs expérimentés savent qu’ils sont plus rapides que leurs collègues plus jeunes. Ils voudraient le faire eux-mêmes parce que, à court terme, cela leur permettrait peut-être de respecter le délai imposé (voir le point 3). Cependant, la vérité mathématique est qu’un ingénieur principal codant très vite ne vaut rien comparé à toute une équipe codant assez rapidement. Les meilleurs ingénieurs devraient être [Programmation en binôme] (https://en.wikipedia.org/wiki/Pair_programming) avec leurs homologues plus jeunes au moins 50% du temps. De cette façon, toute l’équipe gagne en vitesse. - et l’équipe gagne de plus en plus d’autonomie de votre ingénieur principal -

7. Manque de partage de connaissance

Certaines équipes ont chaque personne responsable d’un seul aspect de la base de code. Les managers, qui n’ont pas ete forme de la bonne manière, peuvent penser qu’une telle spécialisation crée de l’efficacité, mais l’inconvénient est que, si quelqu’un manque à l’appel, rien ne sera fait. Dans les logiciels, l’efficacité est un facteur de qualité du code. Si tout le monde travaille ensemble, alors chacun est constamment confronté à de nouveaux lecteurs de son code. L’équipe codera alors toujours plus clairement. Le code lisible en clair est beaucoup plus facile et efficace à modifier.

8. Des limites rigides des rôles

Agile repose sur la notion selon laquelle les développeurs de logiciels doivent être complets. Les équipes agiles ont tendance à éviter les rôles d’ingénieur trop spécialisés. Cela nous permet de déplacer les efforts d’ingénierie là où l’entreprise a besoin de nous. Au besoin, nous pouvons passer du front-end au back-end en passant par dev-ops. Les rôles flexibles nous aident également à partager les connaissances afin de prévenir ou de résoudre rapidement toute défaillance ou bug dans nos systèmes.