De nombreux projets de développement conservent une approche traditionnelle (cycle en V ou waterfall) sur bien des aspects. Même si beaucoup d'entre nous admettent les travers d'une telle approche : pression forte, gestion des changements douloureuse, délais et budget souvent dépassés, relation client parfois difficile, journées de travail longues...

J'appelle « approche traditionnelle », une approche essentiellement basée sur le prédictif souvent illustrée par une phase de conception énergivore et coûteuse censée accoucher de spécifications fonctionnelles détaillées millimétrées. Ces spécifications deviennent ensuite le nerf de la guerre entre le commanditaire et le réalisateur lors de l'apparition des premiers changements (inévitables évidemment). Le tout dans le cadre d'un forfait classique.

Dans cet article, je propose de donner un peu plus de souplesse à cette approche sans basculer complètement dans l'agilité qui fait peur à beaucoup de monde (par ignorance, la plupart du temps). 

Méthodologie

Les principes de méthodologie que je propose, interviennent principalement sur les 4 axes suivants :

• Expression et priorisation du besoin
• Visibilité du commanditaire et des utilisateurs finaux
• Gestion des changements
• Suivi de l'avancement
  

Expression et priorisation du besoin

 Dans les travaux préparatoires d'un projet de développement, il est primordial de bâtir la « Baseline » du projet. Cette dernière est indispensable à la gestion des changements futurs et au suivi de l'avancement du projet. Elle consiste principalement en un découpage fin du besoin en exigences.

La première version de cette liste d'exigences peut être déduite d'un éventuel cahier des charges ou spécifications générales préexistants. Elle peut également être rédigée par le commanditaire. Au cours des travaux préparatoires du projet, le réalisateur :

• Complète la liste d'exigences (avec des exigences non fonctionnelles par exemple)
• Découpe des exigences trop difficiles à estimer en l'état
• Estime chacune d'entre elle avec une unité de charge arbitraire (des points par exemple) en précisant ses hypothèses de calcul

La MOA et la MOE s'associent ensuite pour prioriser les exigences obtenues en fonctions des critères suivants :

• Importance métier du point de vue du commanditaire
• Contraintes techniques du point de vue du réalisateur
• Clarté du besoin
• Estimation de charge

Visibilité du commanditaire et des utilisateurs finaux

Lors de la phase de réalisation du projet, il est important de s'assurer que le produit réalisé est bien en phase avec le besoin initial. Pour cela, il faut régulièrement donner de la visibilité au commanditaire et aux utilisateurs finaux sur le produit en cours de réalisation.

Cette visibilité s'obtient grâce aux deux principes suivants :

• Découpage de la phase de réalisation en itérations courtes (1 à 4 semaines en moyenne)
• Chaque itération se conclut par une démonstration du produit par le réalisateur à destination du commanditaire et des utilisateurs finaux (les premières démonstrations sont souvent assez pauvres : prototype, maquettes d'écran,...)

Gestion des changements

Au cours de la phase de réalisation, le besoin peut changer, il est important de pouvoir s'adapter au changement tout en respectant les délais et le budget du projet.

Cette adaptation au changement est possible selon les deux principes suivants :

• Lorsque le commanditaire émet une demande de changement, le réalisateur fournit une estimation de la charge associée. En fonction de cette estimation, le commanditaire peut lui-même retirer de la liste une exigence qui n'a pas encore été réalisée dont l'estimation est équivalente (exigence de type « Nice to have » par exemple). On peut appeler ça du troc.
• Par ailleurs le découpage de la réalisation en itérations permet au commanditaire de détailler plus tard son besoin sur les exigences de priorité faible destinées aux itérations futures (exemple : détail des IHM).

Suivi de l'avancement

 Comme nous l'avons vu précédemment, la liste des exigences est pondérée par une estimation de charge du réalisateur. Nous pouvons ainsi établir le montant total de la charge de travail de réalisation. Nous avons tout ce qu'il faut pour tracer et d'interpréter le graphique d'avancement ci dessous. 

 

Par ailleurs le découpage en amont du projet en exigences permet de suivre plus finement le cycle de vie d'une exigence de l'expression du besoin aux corrections d'anomalie.  

Outillage

L'outillage de la gestion de projet est aujourd'hui incontournable. Et je ne parle pas d'Excel et MSProject. Un des outillages les plus intéressants (rapport qualité/prix) et les plus répandus provient de l'éditeur « Atlassian ». Il est intéressant principalement pour les raisons suivantes :

• Produits de bonne facture, d'une grande flexibilité et simples d'utilisation
• Forte capacité d'intégration avec des outils tiers (ex : Mercury, gestionnaires de version,...)
• Large choix de briques d'outil
• Système de licence souple
• Solution reconnue, répandue et récompensée
• Support de qualité

Il existe un autre outil plus pointu très intéressant appelé Polarion (véritable outil de gestion du cycle de vie d'un projet de développement). Je ne l'aborde pas dans cet article, car je l'estime plus compliqué à prendre en main par des personnes peu familières avec ce type d'outillage (autre qu'Excel et MSProject). Il mérite toutefois le détour dans certain cas.

Contenu de la solution

 La solution que je préconise rassemble les outils Atlassian suivants

• JIRA : Gestionnaire de demandes (exigences, tâches, anomalies,...) permettant principalement de planifier et suivre les différentes tâches du projet (conception, développement, corrections,...). Il permet également de faire du reporting graphique.
• Confluence : Wiki permettant de créer des espaces projet. Exemple : espace projet « commanditaire » contenant les informations principales du projet (annuaire, graphique d'avancement, camembert de répartition des anomalies par criticité, releases notes,...).
• Outils de développement contribuant à la qualité selon les besoins du projet :
  • Bamboo : outil d'intégration continue
  • Crucible/FishEye : outil de revue de code inter développeurs
  • Clover : outil de surveillance de la couverture des tests
    

Aux produits Alassian peuvent s'ajouter les plugins suivants issus d'autres éditeurs :

• GreenHopper : Outil avancé de planification/suivi des tâches par itération
• Go2Group JaM pour intégrer dans JIRA les plans de test de Quality Center (très répandu) 

Quelques captures d'écrans

 Je trouve que les captures d'écrans commentées suivantes valent bien mieux qu'un long discours.

Exemple de tableau de bord (personnalisable)

Planification des itérations ou phases 

Suivi simple d'une itération

Suivi d'activité 

Suivi des demandes 

Revue de code 

Cuisine interne

 Pour les plus ouverts, le pousserai vers un ensemble de principes et pratiques qui ont fait leur preuves telles que : 

Rédaction des spécifications fonctionnelles détaillées au fil de l'eau : tout spécifier dans le détail avant même d'avoir commencé la phase de réalisation est souvent inutile voir impossible. En particulier le détail des IHM. Parfois même nous reproduisons le schéma de l'élève face à une dissertation qui préfère noircir plus de pages que de raison. Dans nos projets, le besoin évolue, c'est une évidence, alors pourquoi ne pas lisser la rédaction des SFD au fur et à mesure de l'avancement des itérations. La phase de conception s'en trouverait ainsi réduite et plus ciblée sur les travaux de conception technique (Architecture et Spécification Techniques Détaillées principalement). 

Le tableau des tâches affiché sur un mur qui permet de savoir qui fait quoi et où en est le projet. Ajouté à cela, le graphique d'avancement et le challenge de l'équipe est fixé. Nous aimons tous les challenges. 

La réunion quotidienne de moins de 15 minutes debout un café à la main. Oui je sais vous n'y croyez pas, mais laissez moi vous expliquer. Les règles sont fixées dès le début : chacun ne répond qu'à trois questions simples et les problèmes sont soulevés mais traités en off. Les questions sont : qu'as-tu fait hier ? Que fais tu aujourd'hui ? Quels obstacles ou ralentissement as-tu rencontré ? Cette pratique est bourrée de bénéfices insoupçonnés, les plus évidents sont : création d'un esprit d'équipe fort, on traite les problèmes sur le champ, on s'entraide au besoin, on tire parti d'un développement déjà fait par un autre,... 

La réunion de rétrospective d'une itération de 2 heures : on réunit l'ensemble de l'équipe MOE et rempli 2 colonnes sur un paper-board : « points positifs » / « points négatifs ». Lors de cette réunion on met sur la table les mauvaises expériences vécues et les idées de chacun dans le but d'améliorer la productivité sur l'itération suivante (principe CMMI niveau 5 au passage). On détermine ensemble un plan d'action d'amélioration pour les itérations futures. Le point de vue et les idées de tout le monde sont étudiées en séance.

Plus de liberté aux développeurs : souvent les personnes les mieux placées pour orchestrer dans le détail les tâches techniques sont les développeurs eux même. Selon le degré de maturité, il peut être profitable de les laisser s'attribuer les tâches d'une itération et déterminer l'ordre dans lequel elles doivent s'accomplir. En tant que chef de projet, il faut lâcher un minimum le contrôle et faire confiance. Une bonne équipe Scrum est une équipe auto-organisée (avec un ScrumMaster bien entendu).

Le planning poker est une pratique à retenir pour le chiffrage d'un projet, des évolutions,... 

La revue de code par paire (ne serait ce qu'un quart d'heure par jour avec un bon outil comme crucible) permet de prévenir les bugs, de garantir l'uniformité ainsi que la maintenabilité du code, le respect des bonnes pratiques... 

L'intégration continue

Une grande taille d'écran qui permet d'avoir une visibilité étendue du code. Voir de visualiser simultanément le rendu sur le navigateur. Le PC portable pour développer est une véritable torture selon moi. Nous ne développons pas du Cobol ou je ne sais quel langage séquentiel simple.