Agile, intégration et … Rock’n'roll ?

Je suis actuellement en mission dans une équipe d’intégration pour la refonte d’un SI vers des applications Java/J2EE (principalement). Le périmètre d’intervention de mon équipe se situe à la fois au niveau du développement, de la qualification et de la recette client. Nous sommes donc décrit comme une équipe transverse.

Notre quotidien :

• Livrer aux équipes de qualification puis au client, les releases de nos équipes de développement,
• Maintenir les différents environnements de qualification et de développements opérationnels

Mais aussi :

• Etre un garant de la cohérence des environnements applicatifs pour les différents acteurs du projet
• Assister dans la mise en oeuvre des différents éléments de l’architecture globale du SI (je pense notamment aux éléments de sécurité)

Et enfin :

• Toujours améliorer nos processus pour fournir à nos “clients” un service efficace, réactif mais aussi constant.

L’organisation globale du projet possède des caractéristiques des méthodes agiles. Je pense aux releases fréquents des équipes de dévelopement (1 fois par semaine en moyenne pour chaque application du SI) et à l’implication du client dans la recette de chaque version qui lui ait livré (1 fois toutes les 2 semaines en moyenne). En revanche le périmètre des fonctionnalités est definit au démarage du projet sous forme de contrat : c’est un projet au forfait. Notre équipe d’intégration maintient en quelque sorte l’infrastructure d’une usine de développement applicatif.

J’ai pu lire sur différents blogs que des méthodes agiles tel que SRUM ne sont pas adaptés aux projets de type TMA (dont le mode de travail est très proche de celui de l’intégration). Or les valeurs supportés par agile, sont des valeurs qui pourrait s’intégrer parfaitement à notre mode et améliorer énormément nos processus :

(de wikipédia)

• L’équipe (« Personnes et interaction plutôt que processus et outils ») : Pour assurer une qualité de service constante il faut que chaque membre de l’équipe entretienne un niveau de compétence uniforme. La communication est primordiale (ce n’est pas nouveau en même temps).
• L’application (« Logiciel fonctionnel plutôt que documentation complète ») : Ça je vais avoir du mal à l’expliquer à mes chefs de projet ! Le problème de la documentation c’est qu’elle devient néfaste si elle n’est pas à jour. Combien de temps perdons-nous à corriger les problèmes survenus lors de l’application d’une documentation obsolète ? S’il faut vérifier la pertinence de la documentation crée par ses collègues, où est l’intérêt de la documentation ?
• La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») : Dans notre cas ce n’est pas LE client mais LES clients : le client du projet, les équipes de développement et de qualification. “Le client doit collaborer avec l’équipe et fournir un feed-back continu sur l’adaptation du logiciel à ses attentes”. Pour nous il faut que chaque acteur se contente de la valeur qu’il percoie dans le service que nous offrons : en gros il faut que tout le monde soit content. Ainsi il est necessaire d’adapter constamment nos services aux besoins de nos clients. Voici un billet sur le concept de la valeur.
• L’acceptation du changement (« Réagir au changement plutôt que suivre un plan ») : Il n’est pas facile de faire accepter les changements aux autres, alors pourquoi ne pas tout mettre en œuvre pour que le changement soit aisé chez nous, et qu’il devienne moteur d’innovation et de satisfaction pour nous et nos clients.

Qu’est ce qui pose problème à l’application de SCRUM dans notre contexte ?

Mots-clefs : agile, Intégration, Integration continue, J2EE, Java, méthodes agiles, scrum, SI