Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Simple, compliqué, complexe ou chaotique

Publié par Louis-Philippe Carignan le mardi 26 février 2013 à 15:03

L’Agilité est de plus en plus présente en entreprise. Selon une étude de Forrester publiée en 2010, les méthodes Agile sont maintenant plus utilisées que l’approche traditionnelle en développement logiciel. D’ailleurs, le CHAOS Reort, publié en 2011, montre que plus de projets Agile sont réalisés avec succès que l’approche traditionnelle (42% pour l’approche Agile tandis que 14% pour l’approche traditionnelle).

Le sondage 2011 de VersionOne nommé « State of Agile Survey » confirme que la gestion de projets avec Scrum est l’approche la plus utilisée lors de projets Agile. Vous avez peut-être vous-même eu un certain succès avec Scrum dans un projet pilote ou bien vous êtes peut-être maintenant rendu au stade où vous utilisez toujours l’Agilité lors de la phase de réalisation de vos projets de développement. Fier de ce nouveau succès professionnel, je trouve que l’être humain a tendance à répéter ce qui a bien fonctionné sans prendre le temps de prendre connaissance de la nouvelle situation qui se présente devant lui. L’objectif de ce billet n’est pas d’énumérer les situations où Scrum s’applique. Plutôt, il veut rappeler au lecteur quel type de problème on peut résoudre avec cet outil.

La matrice de Stacey

Ralph Stacey de l’Université de Hertfordshire a mis au point une matrice qu’il nomme « The Stacey Matrix ». Cette matrice permet de prendre connaissance du degré de complexité d’une situation selon le niveau d’incertitude et le niveau d’accord face à la situation. 

La matrice de Stacey

L’axe des X montre le niveau d’incertitude où, à la gauche, il y a peu d’incertitude (close to certainty) tandis qu’il y aura de plus en plus d’incertitude lorsqu’on s’éloigne vers la droite. Sur l’axe des Y, on évaluera le niveau d’accord. Plus on se rapproche de l’origine, plus le niveau d’accord est fort tandis que plus on s’éloigne de l’origine, plus on devient en désaccord sur un sujet. On peut accoler plusieurs thèmes sur ces axes.

Par exemple, on peut se servir de cette matrice dans le choix des technologies à employer pour un projet. Les technologies viendront donc meubler l’axe des X où le degré d’incertitude permettra de nous situer au bon endroit. Quant à l’axe des Y, lors d’un projet, il pourra représenter les requis. Selon le niveau d’accord par le monde Affaires (i.e. votre clientèle à qui est destiné le produit final) face à leurs besoins, on peut alors se situer sur l’axe des Y.

Simple Stacey Chart

À une plus simple expression de la matrice de Stacey, on retrouve 4 états que l’on énumère de la façon suivante :

  • Connu (simple): Tout est connu
  • Compliqué (complicated): Il y a plus de connus que d'inconnus
  • Complexe (complex): Il y a plus d'inconnus que de connus
  • Chaotique (anarchy): Très peu d'éléments connus

Selon mon expérience, des besoins plus ou moins bien connus et une solution inconnue me situe dans la zone complexe de la matrice de Stacey. Selon moi, cela représente souvent l’état de plusieurs projets de développement logiciel en démarrage. Le client a une idée générale de son besoin mais ne sait pas encore à quoi va ressembler la solution finale.

Dans cette zone de complexité de la matrice, Scrum est un excellent outil pour gérer l’imprévisible. Par son approche empirique, Scrum permet de faire de petits pas en livrant des incréments de la solution finale pour permettre de gérer l’inconnu. Le style de management dans cette zone est aussi prescrit par Scrum. À l’aide d’un leadership au service de l’équipe, on fera émerger des idées tout en augementant le niveau de communication dans l’équipe.

Cependant, tous vos projets ne sont pas aussi complexes et ne requiert pas l’Agilité. Et c’est cette nuance que je vois largement ignorée. Par exemple, si vous êtes dans un projet d’entretien, demandez-vous si vous êtes encore dans la même zone de complexité. Si vos clientèles en maintenance ont des besoins très précis et indépendants l’un de l’autre, vous serez moins haut sur l’axe des Y puisque le niveau d’accord sera plus fort. L’impact de ces demandes sur le produit actuellement en production sera peut-être plus faible. En d’autres termes, le changement technologique demandé sera faible et bien compris, ce qui nous pousse vers la gauche sur l’axe des X.

Toutefois, il se peut que vous restiez dans une zone complexe si vos clients ne s’entendent pas sur leurs besoins mutuels. Il se peut aussi que le logiciel à entretenir soit mal conçu, provoquant ainsi de longues séries de tests avant une mise en production.

Pour conclure

L’objectif de ce billet est de rappeler au lecteur que l’Agilité ne s’applique pas à toutes les situations. Selon le niveau de complexité de votre projet, vous devez utiliser la bonne approche. La matrice de Stacey est un outil qui vous permet de vous positionner quant au niveau de complexité de votre projet. Une fois cela déterminée, il suffit de prendre l’approche pour gérer cette complexité.

Il existe plusieurs outils sur le marché pour vous aider à choisir entre l’Agilité et l’approche traditionnelle. Par exemple, Dean Leffingwell, auteur du Scaled Agile Framework, offre un questionnaire de 10 questions pour vous aider à déterminer quelle approche prendre. À mon avis, un retour à la base, c’est-à-dire bien comprendre l’envergure du projet ainsi que voir sa position dans la matrice de Stacey, vous permettra de voir clair quant à l’approche à prendre.

 

Références des graphiques:

http://www.gp-training.net/training/communication_skills/consultation/equipoise/complexity/stacey.htm

Dogme de l’agilité : Le triangle de projet agile

Publié par Philippe Tremblay le vendredi 12 octobre 2012 à 16:16

Cet article fait partie de la série sur Les dogmes de l'agilité

----

En gestion de projet traditionnel, les contraintes entourant un projet sont généralement celles-ci :

  • Portée (fonctionnalités)
  • Durée
  • Coûts

Ces contraintes se retrouvent illustrées sous la forme du « triangle de projet ».

Dans un modèle agile, le triangle traditionnel fait l’objet de distorsion puisque les contraintes sont observées sous un paradigme différent.

Triangle : traditionnel VS agile

En gestion traditionnelle, l’approche par phase d’un projet favorise grandement la cristallisation de la portée dès la mise en place du projet.  Et cette même approche, en repoussant au plus profond retranchement la notion de tests dans une « phase », tend à rendre la contrainte de qualité très malléable.

La vision agile du triangle de projet quant à elle favorise l’adaptation des fonctionnalités tout en intégrant un processus de qualité continu afin d’augmenter la prévisibilité d’un échéancier et budget fixe.

De plus, au cœur d’une approche agile se retrouve une nouvelle contrainte : la valeur.  Celle-ci est à la base de l’ensemble des décisions prises par l’organisation et ses équipes.

Agile _Triangle _Highsmith

Figure A – Contraintes de projets Agile

©Cette image est une propriété de M. Jim Highsmith (http://jimhighsmith.com/2010/11/14/beyond-scope-schedule-and-cost-the-agile-triangle/)

Triangle agile sans être flexible, possible?

Qu’arrive-t-il si une organisation désirant être agile ne peut adapter la portée, les fonctionnalités d’un projet?  Par exemple lorsqu’une loi ou un contrat fixe cette portée?

Peut-elle espérer l’agilité sans adhérer aux principes des contraintes de projet agile?

Certainement!  Ce n’est probablement pas la situation optimale.  Mais c’est la situation actuelle de l’organisation.  Et cette contrainte, qu’elle soit temporaire ou permanente, n’empêche pas l’atteinte d’une variété considérable des bénéfices des approches agile et lean.

La visibilité et la communication ouverte pourraient être des atouts appréciables pour l’organisation faisant face à de telles contraintes.  Car peu importe le projet, agile ou non, il y aura toujours des choix à faire : un peu plus de finition visuelle, un peu moins de performance, plus de robustesse, etc.

Moins flexible, mais tout aussi transparent

Lorsqu’une organisation fait face à une certaine rigidité de par ses conditions ou la nature de son existence, il devient impératif de communiquer cette situation clairement à l’ensemble de ses employées.

La transparence est une valeur essentielle d’une approche agile et un atout incomparable dans l’alignement des objectifs d’entreprise.  L’organisation devrait donc s’assurer d’exposer ces contraintes afin que chaque personne impliquée dans le projet puisse prendre des décisions éclairées en tenant compte aussi bien des conditions de succès que des contraintes du projet.

Le concept de « Project success sliders » pourrait être un outil efficace pour diffuser les impératifs du projet en terme de succès.

Software in 30 days

Publié par Louis-Philippe Carignan le dimanche 1 juillet 2012 à 00:00

Le dernier livre des créateurs de Scrum, Software in 30 days est écrit pour les gestionnaires occupés qui cherchent les grandes lignes de Scrum sans aller dans les détails. La police est nettement supérieur aux livres Agile de référence. Les chapitres sont meublés de diagramme pour simplifier la compréhension. Écrit en 120 pages, ce livre est parfait pour ceux et celles qui désirent convaincre leurs gestionnaires des avantages que l'Agilité peut apporter à leur organisation.

Software in 30 days

Comment bâtir une équipe exceptionnelle

Publié par David Beaumier le mardi 14 février 2012 à 07:17

Dans cette entrevue, Robert C. Martin présente son approche sur les bonnes façon de composer une équipe exceptionnelle de développement logiciel. Il propose plusieurs pistes intéressantes et offre même quelques références pour approfondir le sujet

Est-ce que vous avez déjà utilisé l'approche du "chef programmeur" tel que mentionné par uncle Bob et popularisé par Fred Brooks dans son ouvrage The Mythical Man-Month?

Établir sa vélocité initiale

Publié par Louis-Philippe Carignan le samedi 11 février 2012 à 21:05

Suite à une discussion où mon collègue Mathieu Boisvert chez notre client m'a fait réfléchir, j’ai voulu écrire un billet sur la façon de dresser la vélocité initiale d'une équipe pour ainsi prédire le plan de livraison de cette dernière.

Mise en situation

Imaginons une équipe qui a évalué qu’elle devra livrer un projet de 200 points répartis de la façon suivante :

  • Obligatoire: 100 points
  • Important: 60 points
  • Facultatif: 40 points

Nous avons 43 itérations d’une semaine pour livrer ces points, donc environ 1 an pour livrer ce projet si on enlève les vacances de l'équipe. Le SunSet graph suivant nous permet d'illustrer ces points sur une ligne du temps.

Sun Set De Depart

La prochaine étape consiste donc à établir la vitesse à laquelle seront livrés les points du projet. J'avais surtout l'approche client mais en parlant avec Mathieu, il m'a fait comprendre que l'approche de l'équipe était très important, surtout parce qu'elle m'expose un risque dès le départ.

Comparons donc les deux approches pour voir ce qu'elle nous apporte comme information

L'approche client

Si on se place dans les souliers du client, il veut son projet complété dans 1 an. Si on enlève les vacances de son équipe, on peut dire qu'il faut 43 itérations pour livrer. S’il a 200 points à livrer, il peut se donner trois scénarios possibles :

  • Meilleur scénario : 200 points / 36 itérations = 5,55 points par itération
  • Scénario normal : 200 points / 43 itérations = 4,65 points par itération
  • Pire scénario : 200 points / 50 itérations = 4 points par itération

Cependant, cette approche a un problème. Le client dresse ses attentes dès le départ. Si on présente ces chiffres à l’équipe, elle aura naturellement tendance (à mon avis) à atteindre ces chiffres, même si elle se met à couper dans la qualité des fonctionnalités.

Voyons voir si l'approche de l'équipe peut nous apporter une perspective différente.

L'approche équipe

Si on se place dans les souliers de l’équipe, on constate qu’il faut 200 points à livrer dans 43 itérations. Cependant, on ne leur demandera pas de dresser les trois scénarios comme avec le client.

Lors de la planification de l’itération initiale, on demande à l’équipe de découper les stories retenues pour l'itération en tâches. Selon le nombre d’heures qu’elle peut donner, on voit le nombre de points qu’ils peuvent faire en une itération dès la fin de la planification de l'itération. On va donc chercher la vélocité initiale que l’équipe peut donner dès le départ du projet.

À ce moment, on peut tout de suite constater si l’équipe pense être en mesure d’atteindre les 200 points pour la fin de l’année. Si l’équipe ne peut prendre que 2 points pour la première itération, on voit donc déjà un risque apparaître. Si l’équipe se rend compte qu’elle peut faire 15 points dès la première itération suite au découpage, peut-être que la durée du projet sera plus courte.

Conclusion

Si on utilise l'approche du client, il faut attendre la fin de la première itération pour faire le constat si l’équipe peut (ou non) livrer les points dans l’année. Cependant, avec l'approche de l'équipe, on peut faire ce constat dès le départ, avant même l’itération 1, qu’il y a un risque que l’équipe n’atteigne pas ses 200 points à la fin de l’année du projet.

Ma conclusion est qu’il faut faire les deux approches. Je ferais l'approche client avec le client, seul, pour qu’il constate ce qu’il attend de son équipe dans la prochaine année. Par la suite, à la fin de la planification de l’itération 1, je ferais l'approche de l'équipe. Une fois les deux approches élaborées, je les comparerais et les mettrais en évidence au client pour qu’il puisse comparer de par lui-même que ce qu’il espère (l'approche client) puisse ou non se réaliser par l’équipe.

Archive