Bien souvent je travaille avec des équipes, agiles ou non, dont l’attention se porte naturellement sur la fourniture de nouvelles fonctionnalités. Or, dans cette course à la production de valeur pour rester compétitif face à la concurrence, les équipes doivent faire un choix. Elles se retrouvent régulièrement dans cette situation compliquée où il faut faire un compromis entre développer une nouvelle fonctionnalité ou corriger des anomalies.
Sous la pression du marché, le choix se porte un peu trop souvent sur la livraison de la nouvelle fonctionnalité. La dette technique s’accumule et imperceptiblement le nombre d’anomalies augmente. Et par conséquent les délais de résolution, avec les conséquences qui en résultent sur la satisfaction des clients et du métier, ainsi que sur le moral des équipes. Ceci est contraire à l’esprit DevOps qui préconise de travailler sur 4 indicateurs clef dont l’un est le « Mean Time To Repair » (MTTR – cf Wikipedia), le temps moyen de réparation.
Je vais vous expliquer comment je traite ce problème dans une équipe produit avec certaines pratiques de DevOps s’appuyant sur le management lean dans l’IT.
Lire la suite « DevOps en pratique : comment réduire le Mean Time To Repair »
Une méthode d’assessment (évaluation) du niveau DevOps des entreprises : benchmark, prioritisation des axes d’amélioration, préconisations. Cette offre est payante et Operae est le seul partenaire de DORA en France capable de le réaliser (à lire 
