L’atelier de ‘Story Mapping’

Jean-Sébastien et moi avons invité le groupe à un atelier de ‘Story Mapping’. En plus de faire découvrir l’outil au groupe, cela m’a donné l’occasion de partager avec eux :

• comment il est possible de conjuguer à la fois l’analyse du processus d’affaires avec l’établissement de la valeur d’affaires;
• la production d’un produit minimal très tôt dans le projet ouvre des options intéressantes. Livrer une version minimale d’un produit n’est pas naturel parce que nous avons l’habitude de penser que le résultat ne représente pas une véritable valeur d’affaires. Cependant, cela permet de réduire le risque d’avoir un système non fonctionnel à la fin du projet et cela donne la possibilité de capitaliser sur une version réduite du produit.

Les curieux peuvent voir les photos de la soirée et aussi consulter le matériel de présentation.

Photos

Matériel de la présentation

Le BABOK et l’Agilité

Pendant la soirée, j’ai pu constater combien le matériel du BABOK est compatible avec celui de l’Agilité. Comme pour l’Agilité, le BABOK n’associe pas les activités d’analyse à des moments particuliers du cycle de vie du projet. Tous les types d’analyses peuvent être requis à tout moment dans le projet, même si la proportion des efforts peut être différente tout au long du projet. Par exemple, il est correct de penser que l’analyse d’entreprise se fera en plus grande partie en début de projet et que l’analyse des spécifications et la validation des exigences (requirements) seront réparties sur toute la durée du projet.

Aussi, j’ai hâte de voir le contenu de la version 3 du BABOK. De ce que j’ai pu comprendre, les notions de l’itératif et de l’incrémental y seront traités. C’est à surveiller.

Il y a deux choses intéressantes que j’aimerais vous partager :

1. Lors du premier cours, nous avons demandé aux étudiants de partager leur expérience en Agilité. Plusieurs ont parlé de Pyxis et ils ont nommé quelques Pyxissiens. Bravo! Nous avons encore une grande visibilité, même chez les débutants.

2. Je trouve que Pyxis est un incubateur d’opportunités et je suis reconnaissant d’en profiter.

• À mon retour de la France, je me suis impliqué dans l’organisation d’Agile Montréal sur invitation de François.
• Lorsque la communauté Agile de Montréal a quitté les locaux du CRIM, nous avons rencontré Claude Besner, professeur à l’UQAM. Il contribue énormément aux activités d’Agile Montréal et d’Agile Tour Montréal.
• Devenir Coach à Pyxis m’a permis d’élargir mes connaissances sur l’Agilité et de donner des cours de formation.
• Répondre à l’invitation d’Éric Laramée d’écrire un livre, jumelé à la rencontre de Sylvie en mandat avec moi à la SIQ, a permis l’écriture d’un ouvrage couvrant de manière large les méthodes Agiles.
• Claude m’a mis en relation avec Shayne, qui a fait une thèse portant sur l’Agilité, pour que nous préparions ensemble un cours sur les méthodes Agiles.

Pour ma part, j’en conclus que Pyxis et la communauté Agile sont une source de potentiel insoupçonné. Même si on a l’impression que certaines de nos actions ne paient pas à court terme, on peut être surpris en chemin. Dans le doute, ne lâchez pas!

Qu’est-ce qui manque?

Notre nouveau collègue Martin Dupont a demandé au groupe Agile Québec : Comment définir si un projet est un succès? Philippe Tremblay lui a répondu quelque chose d’intéressant : « Un des facteurs clairement négligés est la mesure des impacts de ce projet sur notre clientèle. Peu importe le respect du budget, de la qualité et de l’échéancier, si les clients n’utilisent pas ce qui a été réalisé ou s’ils l’utilisent seulement en partie, quelle valeur avons-nous produit? »

Les approches Agiles offrent des points d’inspection fréquents. À chaque itération, il est possible de vérifier la qualité du bien livrable, le budget consommé et le temps disponible pour compléter le projet. De mon expérience, ses indicateurs sont mesurés pour la majorité des projets. Cependant, ces indicateurs sont insuffisants pour mesurer le VÉRITABLE succès du projet.

J’ai en tête un projet visant la réécriture d’un logiciel servant à calculer le taux de facturation des clients de la Société immobilière du Québec. Le système actuel n’est pas efficace, car :

• il requiert la consolidation des données de plusieurs sources différentes;

• il nécessite d’assurer l’intégrité des données avant de calculer quoi que ce soit;

• il ne permet pas d’expliquer une hausse de la tarification autrement que par une analyse manuelle des calculs.

Le client nous demande donc de lui produire un nouveau système pour l’aider à calculer rapidement la nouvelle tarification. Très vite, on peut imaginer un système répondant aux besoins suivants :

• un processus automatisé pour consolider les sources multiples;

• un processus automatisé pour contrôler l’intégrité des données;

• une fonctionnalité pour générer à la demande le détail de la tarification des clients.

Avec cette solution, il est déjà possible de construire un carnet de produit aligné sur les objectifs d’amélioration. Toutefois, à mon avis, ce n’est pas suffisant pour mesurer si le projet est un VÉRITABLE succès. Il manque un moyen pour mesurer l’atteinte des objectifs à chaque itération. Je crois que des objectifs mesurables seraient encore plus utiles. Par exemple :

• calculer une tarification triennale en moins d’un mois;

• importer les données des 10 sources en un seul clic;

• répondre sur demande aux détails de la tarification par client.

Pourquoi des objectifs mesurables sont-ils utiles?

Des objectifs mesurables permettent d’attribuer une valeur d’affaires aux items du carnet de produit. Dans le cas du programme de tarification, ils permettent de choisir les solutions économisant le maximum de temps de traitement, soit celles consolidant les données en une seule opération et celles qui recensent au quotidien les données nécessaires pour produire le détail de facturation de manière rapide et ad hoc.

Avec une valeur d’affaires chiffrée attribuée à chaque item du carnet de produit, il est possible de comparer les gains par rapport au coût, et donc de calculer le rendement de l’investissement et la valeur acquise. Dans un monde idéal, la somme de la valeur des items livrés devrait être égale à la somme des gains attendus à la livraison du produit.

Si en plus une approche Agile est utilisée, il est possible de mesurer à chaque fin d’itération que le dernier incrément de logiciel atteint les objectifs visés par le projet.

De plus, comme chaque incrément est un bien livrable, il est possible de vérifier cette mesure avec les utilisateurs réels du système.

Comment s’améliorer?

Voici ce que je propose pour assurer un meilleur contrôle et garantir le succès d’un projet Agile :

• prendre conscience que l’estimation du carnet de produit ne suffit pas pour mesurer le succès. Les estimations (comme les story points) sont des indicateurs de coût, pas de la valeur d’affaires;

• fixer des objectifs mesurables en début de projet;

• mesurer l’atteinte des objectifs à chaque itération. Une bonne façon serait de les inclure dans la définition de ‘terminé’ ou dans les tests d’acceptation;

• avec un bien livrable fonctionnel en main, mesurer l’atteinte des objectifs dans un contexte le plus proche de celui de la production, et ce, avec les utilisateurs réels du système.

La prise de décision au dernier moment responsable est un concept fort des méthodes Agiles, en particulier de l’approche Lean. La lecture du document Agile Extension to the BABOK Guide m’a fait redécouvrir l’analyse par les options réelles (en anglais : ROA–Real Options Analysis), qui est une application du concept du dernier moment responsable.

L’analyse par les options réelles est une pratique de prise de décision visant à déterminer le meilleur moment pour acheter ou vendre des produits financiers (par exemple des actions). L’intention est de garder les options ouvertes le plus longtemps possible de manière à réduire le risque par manque d’information ou de découvrir de nouvelles possibilités. En d’autres termes, ne pas se peinturer dans le coin par une décision hâtive!

Ne pas se peinturer dans le coin par une décision hâtive! (tiré des albums de Gaston Lagaffe de Franquin)

L’analyse par les options réelles est un modèle de prise décision qui préconise la définition des options qui s’appuie sur le « quand » plutôt que sur le « comment ». Concrètement, la pratique s’appuie sur trois règles simples :

• une option a une valeur;
• une option a une échéance; et
• il ne faut jamais choisir une option sans savoir pourquoi.

Ces règles permettent à la fois de garder les options ouvertes le plus longtemps possible tout en restant conscient qu’une option a une date limite à laquelle il faut prendre position si on veut en profiter.

Et comment cela s’applique concrètement?

Louis-Philippe Carignan, coach en mandat avec moi à la SIQ, me racontait qu’au départ, le modèle Prius de Toyota n’était pas conçu comme une voiture hybride. Les concepteurs avaient plutôt le choix entre plusieurs moteurs (26 je crois) et un objectif de créer une voiture à faible consommation. C’est en gardant les options ouvertes le plus longtemps possible et en éliminant graduellement les modèles ne convenant pas que le choix d’un moteur hybride s’est fait.

Tous les responsables de produit avec qui je travaille utilisent également ce mode de décision. À l’aide du carnet de produit et en gérant les spécifications par ordre de priorité, il n’est pas rare qu’ils évitent le développement d’une fonctionnalité qui s’avère en cours de réalisation inutile ou mal adaptée. Par contre, je crois que les responsables de produit gèrent souvent l’échéance des options intuitivement. Il y aurait sûrement de la valeur à tenir compte de la date d’échéance des items du carnet comme élément de réflexion sur les priorités du produit.

Voici ce que la liste indique :

• Pour certains projets, il est possible qu’un analyste ne soit pas requis. Cela est possible dans le contexte où les développeurs ont une capacité d’analyse suffisante ou lorsque le responsable de produit est en mesure de rédiger par lui-même le carnet de produit.
• Dans les projets plus complexes, l’analyste peut être un facilitateur capable d’élaborer une vision unique. Cela peut s’avérer nécessaire lorsque plusieurs parties prenantes au projet expriment des perspectives et des besoins contradictoires.
• L’analyste peut tenir le rôle de responsable de produit. C’est possible s’il connaît suffisamment le domaine d’affaires et si on lui reconnaît les droits de définir et d’ordonner le carnet de produit.
• Pendant une absence du responsable de produit, l’analyste peut tenir le rôle de suppléant. C’est également une option lorsque le responsable de produit ne se trouve pas sur le même site physique que l’équipe de développement.
• L’analyste peut augmenter la disponibilité et l’efficacité du responsable de produit en devenant son bras droit. Cela permet au responsable de produit de dégager du temps, n’étant plus seul pour entretenir le carnet de produit, de répondre aux questions des développeurs et d’évaluer les résultats des itérations.
• L’analyste peut être le coach d’une équipe. Cela est utile lorsque le responsable de produit maîtrise le domaine d’affaires, mais qu’il a une expérience limitée en réalisation de projets de TI, ou lorsque l’équipe de projet ne connaît pas le domaine d’affaires.

Personnellement, j’ai pu observer chacune de ces propositions dans le cadre de mes mandats d’accompagnement. Ce qui manque à mon avis pour compléter la réflexion de l’adaptation du rôle, c’est la détermination des autres disciplines de développement qui sont à la fois utiles à l’équipe et habituellement une source d’intérêts pour les analystes.

L’article explique notamment que: – Scrum est dirigé par l’engagement et les boîtes de temps alors que le Kanban est dirigé par un flux tendu et le périmètre. – Kanban permet la ré-introduction de spécialités impossibles à diffuser au sein d’une équipe pluri-disciplinaire – Kanban permet au PO de planifier les items à développer à l’unité alors que Scrum permet la planification d’items en lot

Attention! Kanban est moins restrictif que le Scrum. Il faut prendre garde de respecter l’esprit Agile.

Avez-vous des mises en garde ou des opinions à propos de Kanban?

1. : Connaître un langage majeur (ex: .NET, Java, PHP)
2. : Connaître une technologie de client riche (RIAs)
3. : Connaître le développement web
4. : Connaître les services web
5. : Avoir des compétences humaines (Soft skills)
6. : Connaître les langages dynamiques
7. : Connaître les méthodes Agile
8. : Avoir de l’intérêt pour les domaines d’affaire
9. : Avoir une bonne hygiène de développement
10. : Connaître le développement embarqué (Mobile)

Les temps changent; il me semble qu’à mes débuts, la liste aurait aussi inclus des connaissances du SQL avec un SGBD, et au moins un langage script (utile entre autres pour faire des scripts de build et des batchs).

Dans tout les cas, je vois d’un bon œil d’avoir une liste d’axes de compétences avec laquelle je peux me mesurer dans mon processus d’amélioration continue.

- Hier j’ai travaillé sur l’import/export et je vais continuer aujourd’hui. Je n’ai pas de difficultés…”

Entendez-vous les violons stridents qui annoncent un meurtre? Ils annoncent la mort de la mêlée quotidienne. Même si on a déjà posté sur ce sujet sur le blog de Pyxis, j’en rajoute une couche.

Le problème avec l’intervention citée plus haut, c’est qu’elle n’a aucune valeur ajoutée; j’aurais pu obtenir la même information en regardant le tableau des tâches. Si vous tenez votre mêlée en face de votre tableau des tâches et de votre graphique d’avancement, et que les participants continuent de tenir de mêlées aussi insipides, vous gaspillez tous les jours 15 minutes de temps de travail. Au moins, vous aurez réduit à 15 minutes le massacre quotidien.

Quel est le contexte d’une mêlée? Ça ressemble un peu à un article de journal; je veux savoir ce qui a progressé depuis hier à propos des élections américaines. Si rien n’a changé, je ne tiens pas à le savoir. Dans le cadre d’une itération, en tant que membre impliqué, je veux savoir où nous en sommes et je veux partager avec mes coéquipiers mes contributions, mes observations et les risques que j’ai identifiés. Ce n’est pas moi le sujet de cette rencontre, mais notre engagement. En quoi ma journée a contribué au projet? En quoi j’ai affecté NOTRE itération? En quoi j’ai amélioré la qualité de NOTRE produit? Qu’est-ce qu’ON peut faire pour adresser un obstacle?

- Mais Mathieu, je n’ai rien fais sinon de modifier les scripts d’import pour tenir en compte les accents qui n’étaient pas supportés. C’est un travail qui n’était pas prévu et a été vite réglé. Maintenant je dois finir l’import.

Voilà!

Si vous avez de la difficulté à secouer vos troupes, changez la formulation de vos questions ou jetez-les par la fenêtre! Préférez une question qui s’adresse à tous le groupe sur la progression de votre itération. ]]> http://pyxis-tech.com/blog/2009/03/20/quand-la-melee-quotidienne-sonne-faux/feed/ 0 http://pyxis-tech.com/blog/2009/03/10/les-dojos-de-developpement-coding-dojo/?utm_source=rss&utm_medium=rss&utm_campaign=les-dojos-de-developpement-coding-dojo http://pyxis-tech.com/blog/2009/03/10/les-dojos-de-developpement-coding-dojo/#comments Tue, 10 Mar 2009 19:04:24 +0000 mathieu boisvert http://36.41 L’amélioration continue est un concept clé des pratiques agiles. Les livres, les blogues et les formations sont de bonnes façons de se perfectionner. La tenue de dojos est une autre façon ludique et motivante de partager et se perfectionner sur le développement logiciel.

Les Dojos

Si je veux apprendre le Judo, je vais m’inscrire au dojo du coin et y passer une heure par semaine pendant deux ans, au bout de quoi j’aurai peut-être envie de pratiquer plus assidûment.

Si je veux apprendre la programmation objet, mon employeur va me trouver une formation de trois jours à Java dans le catalogue 2004.

Cherchez l’erreur.

Laurent Bossavit

Se donner des périodes pour pratiquer la programmation nous éveille à de nouvelles techniques et nous fait découvrir de nouveaux langages sans amputer sur nos mandats professionnelles. De le faire en groupe nous encourage et nous aide à nous défaire de nos pratiques routinières.

Références

• http://codekata.pragprog.com/codekata/
• http://codingdojo.org/
• http://butunclebob.com/ArticleS.UncleBob.TheProgrammingDojo 
• http://www.pyxis-tech.com/fr/dojo/

Statégies

• Recommencer à zéro: on ne cherche pas vraiment à résoudre un problème, mais plutôt à pratiquer. Les problèmes rencontrés dans un cas simple réalisable en une heure seront similaires à ceux que l’on rencontre dans la réalisation de plus gros projets.
• Prévoir une courte pause au milieu de l’atelier pour inspecter et ajuster l’exercice en cas de besoin. On pourra y définir de nouvelles règles ou s’entendre sur la ligne directrice de conception.

Foire aux questions

• Où peut-on trouver des exemples de défis?

Un défi populaire dans la communauté, c’est le fameux pointage du jeu de quilles . Le catalogue du site Coding Dojo  est une bonne source d’inspiration. Pragmatic Dave propose également d’autres katas .

Le défi se doit de rester simple et réalisable dans un court laps de temps. Écrire un convertisseur de chiffres romains est un bon exemple de défi raisonnable.

• Quel est le but du dojo si ce n’est pas la résolution du défi?

Le but est de se perfectionner dans une discipline du développement logiciel. On peut perfectionner une pratique comme le TDD ou l’orienté-objet, un langage comme Ruby, ou encore l’utilisation d’un framework comme Rails.

• A quel moment on doit changer le binôme au commandes d’un randori?

Une boîte de temps est sûrement la technique la plus simple (ex. entre 5 et 7 minutes). On aussi peut utiliser le cycle normal du TDD; chaque binôme est responsable de faire passer un nouveau test.

Le Coding Dojo de Pittsburg a une autre approche; tous les participants binôment simultanément sur le défi et l’atelier se termine par une rétrospective de groupe.

Je la retranscris pour votre bon plaisir!