Dans tout projet il est question de faire des choix et des arbitrages. Par rapport à cela, les projets agiles ont certaines spécificités.
Les variables QCD revisitées
Classiquement, les choix dans un projet sont perçus au bout du compte comme un arbitrage entre les trois composante du tryptique QCD :
- Qualité : La qualité ou le contenu du livrable (exemple nombre ou complexité des fonctions livrées).
- Cout : Qui revient souvent à la quantité de ressource qu’il va falloir mobiliser sur un projet (nombre de développeurs, moyens financiers …).
- Délais : Qui est la date de de livraison prévue.
Ainsi, améliorer la Qualité (Q) nécessite soit de mettre plus de ressource (donc un Cout supplémentaire) ou livrer plus tard (donc un Délais supplémentaire). Inversement, réduire le Cout (donc les ressources mobilisées) nécessiterait soit de réduire les fonctionnalités livrées (donc la Qualité) soit augmenter le Délais de livraison vu le manque de ressources. Ainsi de suite …
En projet classique toutes les variables sont considérées pour l’arbitrage, et souvent, on impactera d’abord le Délais, ensuite éventuellement le Cout et vraiment en dernier recours la qualité.
Les priorités QCD en projet Agile : la Qualité, variable de choix
En agile, les durées d’itérations sont fixées, la composante Délais n’est donc pas une variable d’ajustement sauf très rare exception. Cela a pour avantage de maintenir un synchronisme naturel à la fin de l’itération entre les équipes de développement et le reste de l’entreprise (équipes de test, déploiement, métier, communication …).
La composante Cout de son côté est souvent difficilement ajustable. En effet, en projet agile :
- La priorité est donnée au livrable par rapport à la documentation.
- L’interaction directe des membres prévaut par rapport aux processus et outils.
De fait la culture de l’équipe est relativement orale et met donc du temps à se transmettre aux nouveaux arrivants.
De plus, les équipes étant souvent auto-organisée, cela nécessite du temps pour se réorganiser en fonction des capacités de nouveaux arrivants.
La variable d’ajustement principale est donc souvent la Qualité autrement dit, la question revient souvent à une variante de : Que vas-t-on livrer ?
Les critères de décision en agile : la valeur et la capacité à livrer
Une fois la question posée, les réponses possibles sont analysées selon deux critères principaux :
- Quelle valeur ajoutée apporte tel ou tel choix à l’utilisateur (Valeur métier)
- A quel point les informations nécessaires pour livrer cette valeur sont disponibles.
Parmi les options suffisamment précise et réalisables on choisira donc celle qui apporte le plus de Valeur au métier.
Le droit à l’erreur
En projet agile, le changement est la règle et non pas une exception, de fait on se donne le droit de se tromper et de changer de cap, de fait la décision peut se prendre avec un certain niveau d’incertitude. Cependant, il convient dans ce cas là de se donner les moyens de détecter son erreur le plus tôt et la convertir en apprentissage dans le cadre de l’amélioration continue.
En conclusion
Les choix de projet agile reviennent souvent à redefinir le périmètre ou les détails du livrable (variable Qualité), ce choix doit se faire essentiellement en regardant la valeur métier et la capacité à réellement livrer cette valeur. Enfin, il n’est pas une exception de devoir éventuellement changer d’avis plus tard, l’important est de transformer les erreurs en apprentissage.
En fait ce triptyque, bien qu’utilisé ad nauseam, est incomplet. Plus précisément, il regroupe sous le terme “qualité” à la fois le périmètre fonctionnel couvert et les qualités non fonctionnelles (documentation, couverture de test …).
Dans les projets classiques on joue souvent sur la qualité, mais essentiellement sur le second volet. Pour finir dans les temps, on livre un système mal testé, avec une documentation incomplète … que l’on paie avec les intérêts lorsqu’il faut exploiter et maintenir le système.
Les méthodes agiles sont liées à l’eXtreme Programming, au Test Driven Development. La qualité au sens non fonctionnel n’est donc pas un choix mais une doctrine. Il en ressort effectivement que le périmètre fonctionnel est la seule variable d’ajustement.
Cette variabilité du périmètre effectivement implémenté n’est d’ailleurs pas un souci : la priorisation des user stories est là pour s’assurer que les plus intéressantes sont livrées en premier. On évite donc en pratique les soucis liés à des besoins mal définis ou juste fantasmés (fonctions développées mais jamais utilisées).