Quel est le bon outil de gestion de projets informatiques ?

Quel est le meilleur outil pour gèrer les projets de développement informatique? Faut-il fédérer l ‘équipe autour de diagramme de Gantt? Ou est-ce mieux d ‘utiliser un plan d ‘action excel? Ou peut être un tracker?

Je me suis entretenu à ce sujet avec plusieurs developpeurs, chefs de projet et architectes de divers horizons et la question semble loin d ‘avoir une réponse évidente unanimement accptée.

Plusieurs types d ‘outils

Pour être très synthetique, j ‘ai retrouvé essentiellement 3 types d ‘outils :

  • les listes de taches que ce soit une simple feuille excel ou un outils plus avancé de type tracker (redmine…)
  • les gantt de type msproject gantt project ou libreproj.
  • les tableaux de sticker (post it board) il s ‘agit de tableaux blancs ou tableaux de paperboard découpés en sections sur lesquels des post-its représentant les taches sont collés et déplacés.

Plusieurs facteurs de réussite

Lors des différents échangés les outils peuvent être appréciés ou rejetés pour des raisons que je synthétise par :

  • L ‘adoption : les développeurs et les chefs de projet vont-ils réellement savoir utiliser l ‘outil?
  • L ‘utilité : l ‘outil vas-t-il réellement rendre service à son utilisateur ou est-ce un fardeau à porter par obligation?
  • La souplesse : l ‘outil vas-il s ‘adapter au fonctionnement de l ‘équipe ou vas-t-il introduire des contraintes a ce fonctionnement?

Au delà de l ‘outil, les revues régulières, l ‘écoute et la pédagogie du team leader sont un must pour favoriser la bonne utilisation des outils et le bon déroulement du projet.

Symptôme du mauvais outil : le multi-suivi

Quand l ‘outil adopté par le projet ne satisfait pas l ‘équipe, un phénomène se produit quasi systématiquement : Le développement de suivis parallèles à l ‘outil principal : des plans d ‘action sur Excel, des échanges de mail, des pages Wiki des Trackers … Reprennent et s’ajoutent aux taches principales du projet.

Cela vas sans dire : Cela est très nuisible à la synergie de l’équipe et à l’efficacité de la collaboration.

INVEST – Les 6 piliers d’une bonne User Story scrum

La façon dont les besoins du Metier sont exprimés en terme de story agile est déterminante pour maximiser le gain d’efficacité promise par les projets agiles.

Qu’est ce qu ‘une story

C ‘est une paragraphe court qui decrit sommairement une fonction du produit et sa valeur métier, par exemple :

En tant que client je peut chercher les produits de la e-boutiques en tapant des mots clés cela me permet de trouver rapidement l'ensemble des produits qui repondent à mes besoins.

Une user story est censée être un sujet de discussions et non pas une description détaillée d’une fonction. Il n ‘y a pas de mal à ce que une story soit au départ trops générique voir mal cernée par le product owner lui même tant qu ‘elle reste dans le backlog. Cependant, elle ne peut être admise dans une itération que quand le product owner a la maturité nécessaire pour pouvoir donner des informations detaillées : sur la fonction principale, les chemins alternatifs, les cas d ‘erreur… (Voir cet article sur les critères de réalisation d’une story)

Les 6 critères de qualité INVEST

Afin de s ‘assurer qu ‘une user story a les qualités nécessaires pour être effectivement incluse dans une itération, 6 critères ont été definis sous l’acronyme INVEST.

  • Independant : chaque story doit constituer un avantage métier par elle même : On ne peux pas avoir deux story qui dépendent l ‘une de l ‘autre pour produire de la valeurs. Exemple:

    Story 1: en tant que client mes transactions doivent être stockée en base lors d 'un achat. 
    Story 2: en tant que client je doit recevoir une fois par mois une liste détaillée de transactions pour pouvoir mettre à jour ma comptabilité.
    

    La story 1 ne produit pas de valeur en soit, imaginons qu ‘elle soit réalisée lors d ‘une iteration, il n’y aura de vrai ROI (retour sur investissement) qu’appartir du moment ou la Story 2 est mise en place. Entre temps, du temps de développement a été investi sans réelle rentabilité. Par ailleurs, dans un environnement changeant, la story 2 pourra devenir à un certain moment inutile ou pas prioritaire, on aura alors investit du temps inutilement.

  • Negociable : Toute story peut être remise en question, discutée négociée à tout moment. Par ailleurs, elle doit être exprimée dans un language compris à la fois par l’équipe de développement et le métier pour permettre une réelle négociation et connaissance des enjeux partagée.

  • Valuable : Chaque story doit apporter de la valeur, c’est la base du bon sens. Si on est incapable de décrire le bénéfice utilisateur d’une story, c’est qu’elle est probablement supérflue ou plus proche d’une tache technique que d’une story. Les besoins non fonctionnels sont des fois assez astucieux à exprimer en terme de valeur métier. Ainsi, mettre en place des logs techniques peut s’expriemer :

    En tant qu'opérateur de maintenance je doit avoir accès à des traces d'erreur afin de rapidement résoudre les incidents qui bloquent les utilisateurs.
    
  • Estimable : Litérallement, cela veut dire que l’équipe de développement peut donner une estimation de l’effort pour réaliser la story. Plus concrètement, il s’agit de s’assurer que l’équipe a une discussion autour de la story et voit globalement la solution technique pour la réaliser.

  • Sized appropriately : Doit avoir une taille la plus petite possible. Afin de réduire la taille d’une story une des techniques est de découper en variante ainsi :

    En tant qu'utilisateur, je peux payer mes achats en ligne afin de recevoir ma commande plus rapidement.
    

    On pourrait découper cette story en 3 :

    En tant qu'utilisateur, je peux payer mes achats en ligne par carte banquaire afin de recevoir ma commande plus rapidement.
    En tant qu'utilisateur, je peux payer mes achats en ligne avec mon compte paypal afin de recevoir ma commande plus rapidement.
    En tant qu'utilisateur, je peux payer mes achats en ligne avec mon compte mobile afin de recevoir ma commande plus rapidement.
    
  • Testable : Chaque story développée doit pouvoir être validée par le métier en effectuant des tests. Il faut donc qu’elle soit définie de façon concrète avec des critères d’acceptation précis.

En conclusion

Le découpage en story n’est pas juste une façon différente de produire un cahier des charges mais a un impact réel sur la conception du produit lui même et le déroulé du projet. C’est ce bon découpage qui donne tout son intérêt à un projet agile:
– La motivation des équipe augmente en voyant l’aboutissement concret de ce qu’elles réalisent sans être bloquées par le métier.
– La satisfaction des managers augmente en voyant à chaque itération des fonctions utiles livrées et améliorées et donc un ROI progressif.

Et enfin, le métier garde la marge de manoeure pour ajuster ou re-prioriser les fonctions du produit et gérer les risques et incertitudes de l’évolution du contexte.