« Less - Intégration continue » : différence entre les versions
De Wiki Agile
| Ligne 291 : | Ligne 291 : | ||
'''Mettre en place un système d'intégration continue''' - La plupart des produits sur lesquels nous avons travaillé ont lancé un projet dédié pour mettre en place un système d’intégration continue. Cela fonctionne, même si une meilleure alternative consisterait à l’ajouter au Backlog Produit et à laisser une équipe feature travailler dessus. Cela permet d’obtenir davantage de visibilité ainsi qu’un sentiment d’appropriation - les développeurs sont aussi des utilisateurs. | '''Mettre en place un système d'intégration continue''' - La plupart des produits sur lesquels nous avons travaillé ont lancé un projet dédié pour mettre en place un système d’intégration continue. Cela fonctionne, même si une meilleure alternative consisterait à l’ajouter au Backlog Produit et à laisser une équipe feature travailler dessus. Cela permet d’obtenir davantage de visibilité ainsi qu’un sentiment d’appropriation - les développeurs sont aussi des utilisateurs. | ||
La plupart des problèmes d’implémentation de l’intégration continue sont d’ordre organisationnels et non techniques. Sur un certain nombre de produits sur lesquels nous avons pu travailler, nous avons vu l’intégration continue devenir un véritable désordre organisationnel. On y retrouve tout un ensemble de fonctions traditionnelles mélangées avec de nouveaux rôles : des développeurs, des responsables, des testeurs, des ingénieurs en automatisation de tests, des Scrum Masters, des coachs agiles, des administrateurs de GCL et le département des technologies de l’information. Et qu’est-ce que cela donne ? Des responsabilités floues, des personnes s’accusant les unes les autres et des comités (également connue sous le nom de “groupes de pilotage”) discutant sans fin en l’absence des personnes qui font vraiment le boulot. Et le résultat alors ? Ça n’avance pas. Si cela vous arrive, n’essayez pas de cacher les problèmes organisationnels avec des solutions techniques et n’abandonnez pas sous le motif | La plupart des problèmes d’implémentation de l’intégration continue sont d’ordre organisationnels et non techniques. Sur un certain nombre de produits sur lesquels nous avons pu travailler, nous avons vu l’intégration continue devenir un véritable désordre organisationnel. On y retrouve tout un ensemble de fonctions traditionnelles mélangées avec de nouveaux rôles : des développeurs, des responsables, des testeurs, des ingénieurs en automatisation de tests, des Scrum Masters, des coachs agiles, des administrateurs de GCL et le département des technologies de l’information. Et qu’est-ce que cela donne ? Des responsabilités floues, des personnes s’accusant les unes les autres et des comités (également connue sous le nom de “groupes de pilotage”) discutant sans fin en l’absence des personnes qui font vraiment le boulot. Et le résultat alors ? Ça n’avance pas. Si cela vous arrive, n’essayez pas de cacher les problèmes organisationnels avec des solutions techniques et n’abandonnez pas sous le motif que “''notre produit est trop complexe pour faire de l’intégration continue''”. | ||
Pourquoi ne pas avoir abandonné alors ? Parce que chaque groupe produit avec lequel nous avons travaillé est passé par là, par ce processus “d’enlever ce gros caillou de la chaussure” pour réussir à faire de l’intégration continue et tout le monde a en fin de compte trouvé cela ''infinimment utile''. | Pourquoi ne pas avoir abandonné alors ? Parce que chaque groupe produit avec lequel nous avons travaillé est passé par là, par ce processus “d’enlever ce gros caillou de la chaussure” pour réussir à faire de l’intégration continue et tout le monde a en fin de compte trouvé cela ''infinimment utile''. | ||
