[Salon Linux] – Atelier sur le développement collaboratif

Ce premier atelier sur le Salon Linux Open Source de 45 minutes sur l’industrialisation des développements, les premiers bilans et les bonnes pratiques a été présenté par Olivier LEAL, directeur de projet chez Bull.

Comme son nom l’indique, il avait surtout pour but d’introduire les avantages d’une forge logicielle complète en se basant sur le retour d’expérience du conférencier.

L’atelier s’est déroulé en trois grandes parties :

• pourquoi avoir mis en place la forge logicielle
• quels ont été les points sur lesquels l’attention s’est portée
• et le bilan de cette expérience

Objectif de la forge logicielle

Je ne m’attarderai pas trop à vous détailler ce point car l’intérêt d’une forge logicielle et de l’intégration continue est déjà largement couvert dans de nombreux articles sur la toile. Cependant, il est à retenir que le besoin est venu d’un constat simple qui était que le rapport délai/coût était trop élevé sur de nombreux projets et qu’il est apparu évident que l’utilisation d’outils permettrait d’anticiper la découverte de problèmes qui pouvaient se produire sur le projet (ndlr : le fameux effet tunnel…)

Points couverts par la forge logicielle

La forge logicielle a permis de couvrir les points suivants :

• la gestion du périmètre : importer les exigences au sein du référentiel de cette dernière, permettant ainsi leurs classifications mais également de lier le code aux exigences (sous forme de références à l’identifiant de l’exigence via l’utilisation de tags) qui a permis l’auto-documentation du code. Cela a permis d’effectuer un suivi des exigences tout au long du projet :
  • suivi fonctionnel en connaissant le nombre d’exigences par catégorie ayant été développé, l’impact que pouvait avoir une modification des exigences sur le code, mais également la couverture de tests par exigences,
  • suivi via le code (connaître ce que le bout de code donné couvrait comme exigence)
  • et suivi via les tests (connaître ce qu’un test donné couvrait comme exigence)
• la productivité : fournir une traçabilité du code en appliquant les bonnes pratiques via une génération du code en utilisant une approche MDA (Model Driven Architecture) permettant ainsi de :
  • générer le code
  • générer les fichiers de configurations
  • générer les schémas de la base de données

En outre, la forge, en offrant un forum, wiki et l’utilisation de Mantis, a permis de capitaliser les connaissances en évitant les échanges par mail et ne offrant un outils pour gérer le suivi des questions/réponses.

• les rapports de qualités : grâce à la mise en place d’une base de connaissance renseignée par les informations poussés par des outils type checkstyle, covertura, mantis et autres, il a été possible de :
  • générer des rapports quotidiens sur la couverture de tests mais aussi sur l’application de bonnes pratiques,
  • tracer via les rapports quotidiens, émis par mail, l’évolution des exigences
  • se tenir informé sur le suivi de l’activité des faits techniques (demande d’évolution ou corrections d’anomalies) aussi bien au niveau de leur cycle de vie que de leur importance
  • gérer les releases notes permettant la traçabilité des livrables.

Au niveau de la génération des rapports, un outils comme Birt a été utilisé pour extraire les informations et les consolidés à la demande offrant ainsi la possibilité de choisir les critères des données remontés.

• et la capitalisation : offrir des outils permettant la capitalisation de l’information entre différents projets et modules en offrant un repository unifié pour les composants communs. Cette capitalisation étant faite au niveau :
  • du code (scm)
  • des binaires (type remote proxy repository pour maven)
  • des normes de bonnes pratiques (template de code)
  • de la base de connaissances des faits techniques
  • de la résolution de problèmes communs via la mise en place de forums communs.

Bilan

Pour conclure, Olivier LEAL est revenu sur les points positifs et négatifs de cette mise en œuvre.

Les points positifs étant :

• une amélioration du coût/qualité/délai
• un accès à un catalogue de produits open source
• la diffusion d’une culture projet
• un travail en transparence permettant ainsi la mise en avant de la prise d’initiative et l’implication de chacun
• le travail collaboratif
• la personnalisation du reporting en fonction du projet
• la mise en place de méthodes indépendantes du langage.

Les points négatifs ou plutôt de vigilance étant :

• que l’utilisation de forums pour partager la connaissance n’a pas été un succès car pas dans les mœurs
• la difficulté de faire comprendre aux architectes techniques et fonctionnels de l’intérêt de partager les problèmes (ndlr : tous le monde le sait bien, son problème est unique 😉 )
• qu’il est nécessaire d’adapter la taille de l’usine logicielle à la taille du projet
• qu’il est souvent nécessaire d’avoir un leader techniques chargé, entre autre, de maintenir l’environnement mais aussi de prêcher la bonne parole…

Au final, une bonne conférence qui, bien que portant sur des sujets connus, a permis d’avoir le retour d’expérience sur la mise en place d’une telle méthodologie sur un projet d’envergure.