Archive
Chacun sa méthode, chacun son problème !
Souvent lorsque les gens me parlent des méthodologies Agiles, ils font rapidement référence à SCRUM ou Extrem Programming (XP). Mais, il en existe beaucoup plus que cela.
Chacune des méthodes adressent une problématique, chacun son problème. Par exemple, SCRUM adresse la capacité de la livraison d’un logiciel en développement. Je sais, je résume de manière très simpliste. Mais, mon propos n’est pas de parler de SCRUM en particulier.
Mais, il existe plusieurs tâches ou problèmes qu’on peut adresser avec les méthodologies Agiles. À la base des méthodologies Agiles, c’est le Manifeste Agile et aussi de bonnes pratiques de développement logiciels.
Il ne faut jamais chercher à prendre une implémentation des principes du Manifeste Agile comme un couteau suisse, mais comme une lame ou un outil de celui-ci. Si vous prenez soin de bien identifier le problème que vous voulez résoudre.
Mais trop souvent, les gens cherchent une méthode qui va solutionné leur problème, sans vraiment le connaître. Lorsque mon auto a problème, je demande à mon mécanicien de faire un diagnostique, pas juste changé la batterie ou l’huile de la voiture.
Si vous ne savez pas exactement ce qu’est votre problème, faites comme avec votre voiture, demandé l’aide d’un ou de plusieurs spécialistes qui vous aidera à choisir la bonne méthode.
Il me serait facile de vous faire une liste de problèmes typiques avec leur solution, leur méthode qui pourrait le résoudre. Mais, ça irait à ‘inverse de ma philosophie et à l’opposer des principes des méthodologies Agiles. À besoin, fait comme je le recommande dans cet article « Un chef et son buffet de services, un buffet de services agiles» inventer la vôtre !
Ma revue de l’année Agile 2010.
En cette période de fin d’année, il est temps de revoir ce qui a bien été. Comme vous le savez, je travaille à promouvoir les méthodologies par Vents et marées. Donc, j’ai choisi de faire ma revue en traitant de cette méthodologie.
En janvier dernier, lors de mes veux pour le nouvel an, j’avais émis le souhait suivant : "Mes petites résolutions Agiles pour l’an 2010". Je souhaitais que les méthodologies Agiles prennent un virage important. Que l’année 2010 soit une année phare pour les méthodologies agiles.
Je croyais et crois toujours que l’année 2010 a été une année importante pour les méthodologies Agiles. L’année tire à sa fin, et mon souhait est presque réalisé. Voici quelques éléments marquants de cette année :
1. La communauté Agile
En début d’année, on sentait un vent de changement à un tel point que le Groupe CGI de Québec a décidé de constituer un OSBL avec La Communauté Agile de Québec. D’ailleurs, afin de combler les postes au conseil d’administration, il y a dû avoir une élection parce qu’il y avait plus de candidatures que de postes à combler, signe que la communauté est en santé.
De la vingtaine dont la majorité des « GEEK » qui était membre de la communauté au tournant de 2001.. Elle n’a cessé d’évoluer, de croitre aux files des années. Aujourd’hui, ce n’est pas rare d’atteinte le 40, voir 50 et + lors des activités mensuelles.
2. Le jugement qui ouvre la porte à l’open source
Un fait marquant est arrivé est début de printemps. Le jugement de Savoir-Faire Linux contre la Régie des rentes qui ouvrait la porte à l’open source. On peut voir le Jugement de Savoir-Faire Linux contre RRQ
Vous demanderez sans doute, c’est quoi le rapport entre ce jugement et les méthodologies Agiles. Pourtant, il est signe de changement de vision et d’approche dans la manière de faire l’informatique au gouvernement.
C’est en plein qu’apportent les approches Agiles. Cette ouverture aux changements permettre surement d’ouvrir aussi la porte aux méthodologies Agiles.
Les meilleurs outils pour mener à bien un projet Agiles proviennent du monde de l’open source. Donc, ouvrir l’apport à l’open source, c’est donc aussi un peu ouvrir la porte aux méthodes Agiles.
C’est un signe que les changements ne sont peut-être pas pour demain ! Parfois la justice faite mieux que bien des représentations.
3. Le X et P d’agiles et l’eXtrem Programming
La communauté Agile recevait deux des cosignataires du manifeste l’Extrem Programming, MM. Ron Jeffries et Chet Hendrickson. Une conférence qui ne fallait pas manquer. Leurs longues feuilles de route en Agilité qui persiste depuis 1996 a fait que leur conférence a été plus qu’intéressante.
Voir les explications dans un livre c’est une chose, mais entendre les explications de la bouche même des auteurs cela fait toute la différence. Ils l’ont validée depuis longtemps et à plusieurs reprises les informations partout dans le monde ! Ils connaissent aussi ce qu’il y avait dans l’entre-ligne.
4. L’appel de conférenciers pour l’Agile Tour de Québec.
Si vous vous demandiez, si l’intérêt pour les méthodologies Agiles, était en perte de vitesse, détrompez-vous . Une vingtaine de sujets ont été présentés pour la conférence bien que seulement 12 places étaient disponibles. Un processus de votation a donc déterminé les sujets qui seraient présentés
Des quelques Gourous que nous étions aux débuts, le cercle s’est agrandi pour accueillir des gens de toute l’industrie. En plus, il en avait pour tous les goûts. De l’introduction aux méthodologies Agiles, des conférences pour sur toutes les bonnes pratiques et sur les différents rôles en projets agiles jusqu’au retour d’expériences sur de longs projets. On serait pensé dans la cave à vin (Agile) des meilleurs restaurants du monde.
La grande qualité des sujets et ainsi que des présentateurs lors de la conférence, rendait les choix difficiles. Nous devions faire le choix de 4 parmi les 12 proposé.
Quant aux taux de participation, ils ont battu des records d’assistance. Je me suis laissé dire que Québec a été la plus grosse assistance au monde pour cette année.
En résumé, on peur dire que la conférence d’Agile Tour fût un véritable succès.
5. L’Agile de Montréal n’était pas non plus en reste.
La conférence d’Agile Tour à Montréal n’était pas en reste. Là aussi, le nombre de conférences et bien sûr l’assistance ont battu des records.
Tout comme pour Québec, il fut aussi très difficile de faire une sélection de conférences à cette journée. Nous étions dans les mêmes dilemmes, 4 choix parmi 12. Une chance que les fous comme moi, qui on assisté d’abord Montréal puis à Québec. Et qu’il y avait une certaine redondance entre les 2 villes. Si on avait raté une à Montréal, si elle se donnait à Québec. On pouvait se reprendre.
Après, mais 2 jours de conférence (Montréal puis Québec), j’avais juste hâte à l’an prochain pour recommencer.
6. Le père de SCRUM revisitait le concept de « Done »
L’une des conférences phares des deux journées d’Agile Tour de Montréal et de Québec était celle donnée par M. (pour ne pas dire Maitre) Ken Schwaber. Lors de son Key Note, il nous a fait une revue des principaux concepts des Scrum. Mais, à mes yeux, un des éléments qui ressort de cette exposée. C’est sa vision, sa compréhension du fameux « Done ».
Pour de nombreuses équipes et praticiens Agiles, dont moi le premier, « Done » signifiait que j’avais terminé mon travail sur l’unité courante. Mais, selon les sages explications du maitre. Lorsqu’on affirme qu’une unité à atteint ce statut, elle devrait être prête pour aller en production.
Du « done » que je pensais lorsque j’avais fini ma programmation. Mais de là, à la rendre apte en production, il y avait une marge. Mais, pourtant il avait raison. Lorsqu’on dit que notre travail est terminé, surtout en mode Scrum. Nous devrions l’affirmer seulement lorsqu’il est prêt à être déployé en production. C’était vraiment une belle réflexion. Mais, je vais devoir terminer celle-ci dans un billet en 2011. Ces quelques lignes sont vraiment trop courtes pour l’expliquer en profondeur.
7. Et si le gouvernement s’ouvrait à l’Agilité.
C’est pourtant ce que je me suis laissé dire par un ami. L’idée venait d’un discours du sous-ministre à la Journée informatique du Québec en réponse à l’échec des grands projets. Les méthodologies Agiles ne sont peut-être pas la seule solution aux problèmes d’échecs des grands projets, mais surement une voie de solution à explorer. Dieu, que j’aurais aimé être là pour entendre ce discours de mes propres oreilles.
Prononcer le mot « Agiles » dans un ministère était tabou, et osez penser qu’on pouvait utiliser cette méthodologie, là je pense que c’était un beau rêve. Ça prenait juste un fou comme moi qui pouvait y penser et y travailler. Ne vous en faites pas, je n’ai pas encore jeté mes notes sur Macroscope ou Mérise.
8. Conclusion
En résumé, l’année 2010 a été une grande année pour les méthodologies Agiles. Il nous reste plus qu’à continuer sur cette belle lancée. La prochaine fois que vous voudrez faire un projet, prenez donc le temps de voir s’il ne pourrait pas se faire avec la Méthode Agile.
Espérons, qu’à la même période l’an prochain, nous pourrons en dire autant si non plus sur les méthodes Agiles. Continuons tous notre travail ! Continuons tous à réfléchir différemment les problématiques. Et qui nous trouverons peut-être des solutions à des problèmes qui n’en ont pas aujourd’hui.
Être architecte ou concepteur en contexte Agile, est-ce possible ?
Le constat
Avec l’arrivée en grand pas et d’un pas sur des méthodologies Agiles change du travail de bien des intervenants. L’un de ces rôles qui subissent un changement, une évolution de sa pratique. C’est bien celui de l’architecte et concepteur.
Dans une approche plus traditionnelle, l’architecte, son exercice consistait à mettre en place des structures qui seraient à exploiter plus tard. Mais, trop souvent malheureusement, après leur passage au sein du projet. L’architecte devait apporter les grandes visions de l’architecture. Cependant, elles étaient souvent immuables et difficiles à faire évoluer rapidement.
L’architecture qu’on dépose doit couvrir tout le besoin du projet, tenté de prévoir tout, voir même l’impossible, ce qui serait nécessaire à mettre en œuvre durant la vie de projet. Autrement dit, de réponse aux grandes questions et données les pistes de réponses aux détails qui seront éclaircies par la suite.
La transition vers l’agilité
Dans un monde idéal Agile ou lorsqu’on découpe le projet en petite phase, il est plus difficile de prévoir tout ce qui peut arriver en début de projet. Encore plus, lorsqu’on adresse le changement dès qu’il arrive. Si vous, ne l’avez pas compris, le rôle de concepteur tel que nous l’avons connu, en Agile. Ça n’existe plus !
Mais, le besoin de mettre en place une architecture existe toujours. Certains vous diront qu’on ne peut pas faire dans l’architecture en mode Agile. Et que conséquemment, l’architecture du projet doit être projet qui ne sera pas incluant dans la gestion Agile du projet.
L’évolution du rôle d’architectes
Pour ma part, je ne partage pas ce point de vue. D’ailleurs, j’ai mis la base de réflexion dans ce billet titré : Agile et la modélisation, une première réflexion !
Le rôle de l’architecte tant par son expertise que par l’apport qu’il peut apporter au projet est important. Mais, avant de bien jouer son rôle, il devra apprendre à penser différemment. Trop souvent dans les approches traditionnelles, ils avaient une sorte de statut de Dieu. Je ne veux pas faire ici le procès d’aucuns. Je ferais le mien aussi ! Le temps et parfois, la multiplicité des projets nous imposent d’avoir cette mauvaise attitude.
Il m’est arrive aussi, de déposer en une heure, le travail de plusieurs jours à une équipe. J’avoue, dans ce contexte, je ne suis pas très collaboratif envers l’équipe de programmeurs. Encore plus, si cette intervention se fait en coup de vent, sans une vraie implication dans l’équipe de développement.
Mais, en contexte agile, la collaboration à toute son importance. Encore plus pour ce qui est de la mise en place de l’architecture. Afin de respecter et de pousser au maximum cette collaboration. Beaucoup d’équipes, choisir de former les fameux comités d’architectures.
La non plus, je ne pense pas que c’est une bonne stratégie. Je crois qu’il faut repenser le modèle d’interversion de l’architecte tant dans l’attitude que dans l’acte lui-même.
Il ne faut plus être des gurus qui apportent un savoir que nous sommes seules à détenir. Que seulement nous avons la solution aux problèmes. Je crois que nous devons oui apporter une connaissance, notre connaissance et notre expérience aux services de l’équipe de développement et bien sur celui du client.
Une stratégie s’impose.
La stratégie que je recommande toujours, ce n’est pas de faire l’architecture itérative. Mais, une architecture qui est évolutive. Il ne faut chercher à répondre à toutes les questions, c’est impossible. C’est certain le besoin va changer en cours de route du projet.
Il faut aussi répondre à des grandes questions avant de lancer le projet, quoi soit en Agile ou autrement, les bonnes pratiques en architecture. Qu’on parle d’analyse préliminaire, de cycles zéro, nous devons définir ces orientations.
À la différence près que ces orientations ne doivent pas être coulées dans le béton. Même chose pour la présentation, je choisis toujours de le faire avec ouverture. Je trouve aussi intéressant d’avoir l’opinion de l’équipe. J’ai eu parfois de belles surprises. On besoin de leurs expériences, car, c’est eux qui vont la mettre œuvre.
L’évolution de l’architecture au fil du temps
Notre architecte sera amené à évoluer aux fils du temps, aux files des besoins. Il faut aussi gérer cette évolution. Il faut être juste réactif. Ce n’est pas le temps que nous arrivons à implémenter un besoin qu’il faille faire pour l’architecture. Encore moins, lorsque le programmeur est prêt à la mise en œuvre.
Il faut essayer de prévoir, un ou plusieurs cycles à l’avance. Un architecte n’est pas un pompier qui éteint les feux lorsqu’ils se présentent. Mais, une personne qui cherche à les éviter autant que possible.
Donc, je suggère souvent d’utiliser la règle du cycle -1. On essaie de mettre en œuvre l’architecture ou la modélisation qui sera nécessaire un cycle à l’avance. Exemple, en exécutant le cycle 2, si nous savons que nous devrons normale répondre à un problème donné dans le cycle 3. Il est temps de mettre en place maintenant. Il pourra arriver que nos décisions du cycle 2 changent ou évoluent lors de l’exécution du cycle 3. C’est normal, il faut travailler en conséquence et en conscience de ce phénomène.
Fausses idées
Beaucoup de fausses idées persistent sur l’impossibilité de cette transformation tant du rôle d’architecte que de l’architecture elle-même en contexte Agile. J’espère, suite à cette réflexion, que vous n’hésiterez plus à faire parvenir au sein de vaux équipes Agiles.
Les méthodologies Agiles, ce ne sont pas juste un monde pour les programmeurs, mais pour tous les intervenants d’un projet informatique.
Quelques références sur l’architecture logiciel Agile (ou en anglais : « Agile Modelling »)
- D’abord la section de mon blogue qui traite d’Architectures logicielles
- La référence en Agile Modelling. Mais, ce n’est pas pour les débutants : http://www.agilemodeling.com/
- Une définition en anglais de l’agile modelling :http://en.wikipedia.org/wiki/Agile_Modeling. Elle est courte. Mais, une série de bonnes références en fin de texte.
- La dernière, moi Bruno Larouche, je suis un architecte de solution et j’exerce en contexte agile . Je peux « Coacher » vos équipes, dont vos équipes d’architectures.
En conclusion
Donc, la réponse à la question : « Être architecte ou concepteur en contexte Agile, est-ce possible ? », à mon un humble avis, c’est oui ! N’hésitez pas à laisser un commentaire pour compléter ou pour vous opposer à cette réflexion
La PME et Agile, est-ce possible ?
Pour beaucoup de petites organisations en développement logicielles pensent que les méthodologies Agiles, ce n’est pas pour elles. Mais pourtant, beaucoup de ces petites organisations par leur manière de travailler sont très proches des la philosophie et des approches Agiles.
Car, pour être « Agile », ce n’est pas juste en implémentation une des nombreuses dérivations comme SCRUM ou Kanban. Mais c’est d’abord avoir une ouverture à la communication et la collaboration, ce qui est généralement par nature dans les petites organisations.
Car sans la communication et la collaboration, tant des membres d’une équipe de développement que la direction de l’entreprise sont les assises de la mise en place d’une ou plusieurs approches agiles dans une organisation.
Bien sûr, une petite organisation n’a pas toujours les moyens pour mettre en place les méthodologies Agiles dans son organisation. Il faut donc y aller progressivement. Il faut intervenir d’abord où il y a des problèmes. Là où ça fait mal comme on dit.
Par exemple, si vous avez un problème de qualité ou de solidité du code produit. Optez d’abord vers une approche qui vous permettra, comme Test Driven Developpement, d’adresser le problème.
Même chose pour la gestion du développement vous pourriez utilise une approche comme Scrum ou Kanban. Utilisez une approche chirurgicale au début pour corriger les problèmes petits à petits. Il n’est pas conseillé (je ne recommande pas) de faire de grand virage tout d’un coup. Vous n’oubliez pas, vous avez l’agilité d’une petite structure. Mais, une capacité moindre en cas de crash. La grosse structure bouge difficilement. Mais, elle a les budgets et les ressources pour se remettre sur pieds rapidement.
N’ayez pas peur de revenir en arrière pour mieux avancer. Les méthodologies Agiles, c’est bien ce n’est pas pour toutes les organisations. Même, les petites toutes comme les grandes sont incapable d’effectuer ce virage. Comme disait mon grand père, on est toujours plus intelligent après qu’avant. Il faut apprendre de ces erreurs et bien sûr, tenter de les corriger dans la nouvelle version.
Même si vous avez la capacité de faire les changements rapidement. Ne partez pas à la course les faire. Implémenter Agile, même dans une petite organisation. Il va avoir plusieurs impacts. Prenez le temps de les absorber.
¸Surtout, « être agile » ce n’est pas d’implémenter toutes les méthodes agiles. Mais, d’avoir des processus qui permettent de produire un logiciel efficacement, tant budgétairement et techniquement. Que toutes vos ressources sont utilisées à leurs pleines puissances.
Mais, surtout que les différents processus que vous implémentez au sens de votre organisation devront pour optimiser votre production des logiciels, mais aussi à chacun des membres de votre organisation
De cette manière, nous pourrons affirmer que les méthodologies Agiles, c’est aussi fait pour les PME tout comme pour les grandes. Ou encore, à la fin de cette réflexion, vous répondrez peut-être, que vous déjà Agile.
Vous avez peur de ne pas réussir, appelez-nous, on pourra vous accompagner pour effectuer cette continuité vers l’agilité.
L’automne arrive à grands pas !
L’autonome arrive à grands pas.. Bien sûr pas les journées froides et pluvieuses. Mais, le démarrage de vos nouveaux projets que vous voulez lancer cet automne.
Pourquoi pas les planifier en utilisant les méthodologies Agiles. C’est donc le temps de mettre en place les structures et les outils qui vous permettront de mener à bien votre projet en utilisant aux mieux tant vos ressources humaines que celle budgétaire.
Ce ne sera pas quand le projet partira qu’il faudra choisir et mettre en place une ou plusieurs méthodologies Agiles. Prenez ce temps, plus ralenti pour vos équipes pour tout mettre en place.
Nos équipes sont prêtes pour vous accompagner, vous orienter vers les meilleurs choix de mise en place d’un buffet de services agiles au sein de votre organisation. Nous prendrons le temps de vous écouter afin de trouver avec vous les meilleures solutions.
Vous ne croyez pas que cela peut faire la différence dans votre organisation, laissez nous passer quelques heures au sein de vos équipes. Quelques heures qui nous permettront de jeter un regard extérieur, mais un regard d’expert !
Nous croyons que nous pouvons faire une différence dans vos projets, vous accompagnez dans votre quête de la meilleure solution, mais surtout aux meilleurs coûts.
On commence quand, vous voulez manger quoi ? Notre chef a déjà ses ustensiles et les livres de recettes en main !
Un chef et son buffet de services, un buffet de services Agile
Un chef et son buffet de services, un buffet de services Agile
Ce petit concept pour parler d’Agile, commence à faire du bruit sans que vous sachiez qui en est l’auteur!
Donc, comme je suis à l’origine de cette analogie, j’ai le devoir de vous expliquer ce qu’elle soutient.
Qui d’entre vous est déjà allé au restaurant ! Et une fois arrivé dans ce restaurant, vous vous trouvez devant 2 problématiques. Soit vous vous retrouvez dans un restaurant qui ne sert pas ce que vous pensiez y manger ou ne savez pas quoi manger. Mais encore, le serveur ne vous apporte pas le plat commandé!
Trop souvent en informatique et malheureusement en méthodologie Agile, vous vivez (vous les clients) ce genre de situations désagréables. Vous voulez vous lancer en dans cette aventure. Mais, vous ne savez pas comment et encore moins quelles implémentations prendre.
Donc, c’est pour cela que j’ai réfléchie à comment apporter une solution à ce problème et bien entendu , d’une manière Agile.
Premier constat, nous ne pouvons pas savoir ce dont vous avez besoin sans que nous vous l’ayons demandé. Mais, il ne suffit pas de demander, il faut aussi beaucoup écouter.
Deuxième constat, votre besoin peut et va changer ! Donc, pour être en concordance avec le principe de la réactivité aux changes (en référence au Manifeste Agile) que je dois donc vous offrir une solution qui suivra cette évolution.
En reprenant l’exemple du restaurant, je peux préparer un excellent menu, d’excellent mets. Mais, lorsqu’arrive le temps de choisir , il peut arriver que ce que j’ai préparé ne vous convienne pas exactement. Là sera mon vrai rôle de conseiller, de chef Agile en vous orientant vers de combinaisons qui pourraient répondre à votre besoin. Et si nécessaire; après tout, j’ai de très bons fournisseurs de produits alimentaires; je pourrai vous concocter une recette bien à vous. Une combinaison de méthodologies agiles (ou juste une seule) qui permettra d’adresse votre problème.
En Agile, il existe plusieurs méthodologies (Scrum, Lean, Kanban, XP, etc.) qui répondent chacune à différents besoins. Peut-être, l’une d’entre elle correspondra à votre besoin à certains moments. Et plus tard, dans le projet, se sera le tour d’une autre.
Mais choisir la bonne méthodologie Agile, c’est comme arrivé devant un buffet lorsqu’on est affamé ! On veut tout avoir, tout gouter, de l’entrée au dessert, en passant la petite soupe là-bas !
Si nous mangeons, nous goutons à toutes les choses comme des enfants, nous allons nous rendre malades. Et le problème (notre faim) que nous voulions résoudre pourrait être la cause de beaucoup d’autres. Dans ce cas-ci, potentiellement des maux de ventre pour avoir trop mangé.
Vouloir essayer toutes les méthodes, de demander à Pierre, Jean, Jacques n’est pas la solution. Mais, si vous arrivez aux buffets et que vous demandez, conseille à un chef d’expériences. Il vous fera surement découvrir des nouvelles choses, des nouvelles combinaisons que vous n’auriez jamais pensé d’essayer.
Si vous avez encore faim après la première, la deuxième assiette, vous pourrez en reprendre ou changer selon votre goût. Même chose, pour les méthodologies Agiles.
Imaginer, 10, 100 personnes qui arrive au buffet, croirez-vous sincèrement quelle prendront exactement la même chose devant l’éventail choix qui sont mis à leur disposition. Chacun de vos projets est unique. Donc, il faut appliquer de manière unique les méthodologies Agiles.
Donc, Agile et ses implémentations méthodologiques (SCRUM, XP, LEAN,Kanban, Crystal Clear et autres) doivent s’adapter à votre besoin au moment de votre commande. Au besoin, on pourra changer de chef, changer d’ingrédients, inventer, mixer avec l’aide d’experts pour trouver la recette! La recette qui vous permettra d’atteindre l’objectif de créer un logiciel qui correspond à vos besoins.
Je m’engage à vous concocter la recette dont vous aurez besoin au moment.
Aujourd’hui, vous avez le goût de manger quoi, vous avez besoin de combler quelle problématique ?
Une petite Game de poker ..! ça vous tente..!
Je parle plus tôt d’une technique d’évaluation de la complexité d’un projet appelée « Planning Poker ». C’est un exercice est basé sur une série de cartes, généralement base de 0, ½ , 1, 2,3,4,5,8,13,20, 40, ? (point d’interrogation) , Infini, pause café (carte joker). Certains jeux de cartes peuvent avoir une variance, mais l’idée reste la même.
Les cartes permets aux différents membres de l’équipe d’évaluer l’ampleur ou la complexité d’une tâche donnée qui devrait normale être exécuté dans le sprint. Le but de cette activée n’est pas de faire planifier le projet et son ordonnancement par l’équipe de développement.
Comme on dit, plus il y a de têtes, plus on a de chance d’identifier les problèmes qui pourraient survenir, conséquemment les adresser rapidement. En utilisant une carte, pour émettre son évaluation, le membre de l’équipe ne subira pas l’influence des autres. Comme tout le monde retourne en même temps, ça carte, personne ne peut influencer l’autre.
Normalement, tous les membres de l’équipe de développement, le client (Product Owner), le chargé de projet et toutes personnes qui pourraient apporter un éclairage sur la problématique, qu’on doit résoudre, peuvent participer à cette séance. Mais, généralement on se limite à l’équipe élargie (Développement, plus product owner).
Le déroulement de cet exercice est simple. Bien sûr, tous les participants doivent avoir son jeu de cartes. Le responsable du projet (ou le product owner) doit expliquer la tâche (histoire ou story) qu’on doit évaluer. Chacun, choisit une carte, qu’il garde cachée jusqu’au moment du dévoilement. Le choix doit corresponde tant à leur évaluation individuelle. Je dis souvent : « Comment, tu penses que c’est long à faire ? » Ce n’est pas juste une question de temps ! Mais, d’effort à consacrer pour le faire.
N’oubliez pas, que parfois, même si une tâche prend, exemple 6h. Il arrive parfois qu’elle demande un temps de préparation avant son accomplissement. Et aussi, un temps de déploiement pour l’équipe de tests. Il faut aussi prévoir ces tâches, soit en l’incluant dans l’évaluation de son parent ou encore en définissant une ou des tâches spécifiques.
Tout à l’heure, je vous ai énuméré la série. Mais, il y a quelque carte qui demande une certaine explication. Chacune des cartes représente une valeur en heures ou en unités, de zéro jusqu’à 40, parfois 100 sur certain jeux, avec des cartes spéciales, la carte infinie ou illimitée, la carte pause café, point d’interrogation. La notion d’unités est importante, tant pour des fins de planifications, que pour des comparaisons entrent les différents morceaux.
Les valeurs ½, 1, 2, 3, 5, 8, 13, 20, 40 ne demandent pas d’explications supplémentaires. Elle représente l’effort dans l’unité définie par l’équipe.
La carte zéro possède quant à elle, une double signification ou peut-être plus selon les contextes. Elle peut signifier que je l’ai déjà fait, que j’ai déjà une librairie ou module dont on pourrait se servir, et surtout le temps d’intégration du projet est très court. La deuxième signification, c’est que la tâche en question est tellement simple qu’il n’est pas nécessaire de la planifier.
Mais, par expérience, je ne recommande jamais son utilisation. Car, je ne connais très peux de tâches qui ont un temps d’intégration de zéro. Il m’arrive parfois de supprimer cette carte des jeux. Lorsque, j’organise une séance de « Planning Poker », je préviens tous les participants du coté légèrement pervers de la carte Zéro. Elle peut nous apporte une sur évaluation de nos compétences et de nos capacités. Je leurs suggère gentiment. Qu’il serait peut-être préférable lorsqu’il pense que la tâche est trop simple, de plus tôt utilisé la carte de ½ aux fins de sécurités.
De l’autre côté, un peu par opposition, il existe la carte de l’infini. Généralement, selon l’expérience vécue, les gens l’utilisent quant ils n’ont qu’une vague idée ou qu’ils sont incapable d’estime la complexité.
Si lors du dévoilement, il y a plusieurs cartes infinies, cela indique généralement deux grands problèmes, la « story » est très mal compris par l’équipe, elle doit être précisée davantage. De plus, il semble que la complexité de tâche demande un raffinement, un découpage plus précis. Cette tâche est en problème, il serait conseillé de la reporter à cycle subséquent. Tout report d’une tâche doit accepter par le Product owner, et justifier en conséquence.
Ce jeu aide aussi à identifier les incompréhensions, tant des membres de l’équipe que des fonctionnalités intrinsèques et extrinsèques. Malgré, qu’il est recommandé de faire la séance sous un mode détendu. Le responsable du jeu doit avoir l’oeil ouvert pour détecter tous problèmes éventuels.
Une autre source d’indicateur de problème, est la carte point d’interrogation, signifie bien sûr que la personne n’a aucune idée de la complexité de la tâche ou encore quelque refuse de se commettre sur une évaluation. Lorsque qu’une ressource utilise cette carte, je la voix comme une lumière rouge, une alerte.
J’interviens rapidement, pour identifier la nature de l’incompréhension. Car, s’il y a une personne qui choisit cette carte. A mes yeux, il ne doit pas être la seule personne qui n’a pas compris. Il faut immédiatement éclaircir la situation en interrogeant la personne.
Ce semblant de jeux aide souvent à voir la compréhension du projet que l’équipe possède. Il faut donc le faire, avec beaucoup de soin.
La dernière et non la moindre, cette de la pause café.. ! La carte Joker par excellent ! L’évaluation de la complexité est une tâche complexe pour n’importe qui ! Encore plus, pour des programmeurs et analystes qui n’ont jamais eu à évaluer leurs travaux.
Donc, c’est important de permettre à tous les membres de l’équipe d’avoir, la possibilité de prendre une pause. L’esprit clair, il est plus facile d’avoir bon jugement. Il ne faut pas oublier que le travail d’équipe est important. Et les pauses aussi le sont autant.
La définition de la valeur en heure ou en unité, à mon avis ce la n’a pas grande importance. Tant que vous convenez ensemble ce que veux dire tous ces cartes. Les deux choix, à mes yeux s’équivalant. Le plus important, s’est d’avoir une base de comparaison, un étalon.
Il faut établir une base de référence, trouver ensemble les bases que l’équipe pourra utiliser, pour comparer et mieux évaluer. Il est très recommandé qu’une fois établie cette référence, elle ne doit plus changer en cours de projets. Cette phrase n’est pas une loi, mais une forte recommandation. Cette charte de référence doit être comprise de tous et surtout être disponible à tous pour consultation. L’expérience des cycles aidera à mieux comprendre, tant la technique que sont application.
Mais, si après quelque cycle, ça ne fonctionne pas ! N’ayez pas peur d’arrêter ou de redonner les explications. Il faut que chacun comprenne que malgré les apparences, ce n’est pas jeux. C’est un exercice très important. Il existe d’autres méthodes pour l’évaluation de l’effort et de la compréhension de l’équipe. Bien utiliser, elle vous permettra tant l’appropriation de l’équipe des tâches à accomplir. Mais, aussi détecter des problèmes plus rapidement.
Souvenez-vous que les méthodologies Agiles proposent plusieurs outils, il suffit de trouver le bon. Le Poker Planning est une bonne technique, mais elle ne convient pas à toutes les équipes et tous les projets. Trouvez-la bonne pour vous !
Génération Agile
