Une petite Game de poker ..! ça vous tente..!

Une petite Game de poker ..! ça vous tente..!

Je vous rassure tout de suite, je n’ai pas l’intention de suggérer de jouer au poker au travail et tous autres jeux de ce genre.

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 !

Agile et la modélisation, une première réflexion !

Traditionnellement dans les projets, construire ou non, l’architecture (donc la modélisation) ne se posait pas comme question. Dès que le projet était assez gros, on lui affectait un architecte (ou une équipe d’architecte et de modélisateur) pour construire l’architecture logicielle. Leur responsabilité était d’effectuer la modélisation du logiciel et de la base de données pour tout le système. (L’architecte, bien entendu je ne parle pas de la personne, mais du ou des rôles au sein du projet).

Durant cet exercice classique, l’architecte ou le modalisateur effectuait la conception du logiciel et de sa base de données. Un travail qui pouvait prendre beaucoup de temps. Un beau travail qui n’apporte rien au client, et ce, tant que le travail de programmation n’était pas commencé.

Mais en Agile, comme nous livrons des petits morceaux d’applications fonctionnelles par cycles. Il est difficile de penser qu’on peut faire toute la modélisation en début de projet. D’autant plus que de cycle en cycle, le besoin peut changer. Donc, ce qu’on aura modélisé au début (selon les approches classiques) risque de plus correspondent au besoin ou tout simplement être invalidé en cours de route.

Cette réflexion, pourrait faire conclure plusieurs personnes qu’il n’est pas nécessaire d’effectuer la modélisation ou de créer une architecture logicielle. Pourtant, même si nous sommes en Agile, elle demeure aussi importante.

Maintenant que nous sommes d’accord avec ce principe. Vous me direz comment, il faut le faire ? Je n’ai pas de techniques infaillibles. Mais, quelques principes que j’utilise selon le besoin.

Il y a plusieurs façons de faire cette modélisation, cette architecture logicielle. Mais, ce qui est généralement reconnu est de le faire selon le principe du juste à temps. C’est donc de faire ce qui est nécessaire pour le cycle.

Pour ma part, je conseille la règle du 110-120% nécessaire pour le cycle. L’excédentaire est une prévision pour le cycle suivant. 100% du besoin de ce que nous devons construire et 10-20% de mise en place des pièces qui seront nécessaires pour l’interconnexion des cycles suivants.

Par exemple, si nous travaillons sur la facette de la fiche Client. Il serait intéressant de prévoir les orientations des facettes commandes et facturations. Sans pour autant compléter le travail de ces dernières facettes.

Il arrive parfois pour le besoin du projet, nous avons besoin de mettre en place les bases ou les orientations d’architecture. Dans ce cas, n’ayez pas peur de faire un premier cycle consacré qui couvrira ces orientations. Mais, surtout faire une modélisation qui pourra évoluer selon les besoins durant le déroulement du projet. Il sera toujours le temps de le faire dans le cycle qui touchera la facette concernée.

Construiriez-vous une application, s’en savoir où en aller ? S’en avoir une vision de l’architecture sur quoi baser votre développement. Bien sûr que non. Donc, faire de la modélisation va de soit. Pour ce faire, voici quelques techniques qui peuvent vous aidez à faire cette modélisation. J’aime bien utiliser la modélisation par domaine pour la partie plus organique et les « User Story » pour la partie plus fonctionnelle.

Une bonne référence qui vous permettra de mieux faire la lumière sur le comment de la modélisation en contexte Agile, je vous suggère cette référence en Anglais : Agile Modeling. Elle couvre beaucoup de techniques relatifs à cette approche.

Mais, surtout voyez cette référence, commune une autre boite d’outils, et non le moyen comment faire la modélisation. Être Agile, faire un projet en Agile, ce n’est pas d’abandonner vos bonnes pratiques. C’est simplement, parfois, de les utiliser différemment !

En autres mots, il ne faut pas chercher à tout réinventer toute la modélisation. Il suffit de restreinte sa pensée au besoin du cycle. Rappeler-le souvent à vos architectes classiques.

Rappelez-vous la règle du rhinocéros. Il est difficile de le manger d’une seule bouchée, mais en toutes petites bouchées, c’est plus facile.

Agile, est-ce pour moi ?

Il y a toujours beaucoup de préjugés auprès des gens lorsqu'on veut leur parler de se lancer ou simplement adopter les méthodologies Agiles. Souvent leur premier réflexe est de répondre que les méthodologies Agiles ce n'est pas pour eux.

Combien de fois, un programmeur ou un analyste, m'a faites cette affirmation! Je ne le compte plus.

Donc, essayons de réfléchir à qui s'adresse ces approches Agiles.

Est-ce qu'ils ont raison ? Dans les faits, leur analyse n'est pas tout à fait fausse. Car, leur affirmation est souvent relatif à la dérivation SCRUM des approches Agiles.

Donc, affirmer que SCRUM n'est pas pour soi. Cette affirmation n'est pas fausse. Il existe plusieurs méthodes qui dérivent des principes du manifeste Agile. Chacune d'entre elles adresse à une série de problèmes. Certaine sont plus adapté à la gestion projet (la gestion des livraisons), ex : SCRUM. Mais, il en existe plusieurs autres.

Il faut choisir selon le contexte de notre environnement ou tout simplement de son travail à effectuer ! Par exemple, si nous sommes une ou deux personnes, sur un projet. Il n'est pas nécessaire d'utiliser Scrum (Scrum demande une équipe de 5 à 9 personnes) . Cette équipe n'a pas besoin d'une gestion complète de projet. L'utilisation d'une approche qui lui permettrait de produire une meilleure qualité du code et qui automatiserait certaines tâches routinières. Je crois, serait plus approprié. Il pourrait utiliser des approches comme Test Driven Developpement (TDD) et BDD (Behavior Driven Developpement) pour définir les différents besoins qu'ils doivent couvrir dans l'application développement.

Prenons, un autre exemple. Une petite équipe (5 à 9 personnes) de développement qui cherche à construire une application commerciale (Software in boxe). Cette fois-ci, le besoin est différent. La simple utilisation des 2 méthodes précédemment citées (TDD et BDD), ne suffit pas. L'ajout d'une méthode de gestion de projets ou des livraisons comme SCRUM ou SCRUMBAN pourrait intéressant.

L'utilisation des méthodologies Agiles, dans ses projets, est accessible à tout le monde. Que nous soyons chargés de projet, Analystes ou même programmeurs. Il suffit de prendre la méthode qui correspond à notre besoin.

Donc, lorsqu'on m'affirme que les méthodologies Agiles ne sont pas pour eux. Ils ne peuvent pas utiliser ou appliquer, les méthodologies Agiles. Il faut (et au besoin se faire aider) prendre le temps de trouver la méthode qui nous convient. Et si on ne trouve pas, dans une seule méthode, ce qui nous convient. Il ne faut jamais hésiter d'en prendre une comme base, ex scrum (si nous sommes une équipe) et la complémenter avec une autre selon le besoin qu'on veut couvrir.

Donc, affirmées que les méthodologies Agiles ne sont pas pour nous, signifie seulement que la connaissance ou l'analyse des approches Agiles qu'on a faites sont insuffisantes. Comme dans toutes choses, il faut prendre le temps d'analyser, de se documenter.

Aujourd'hui, demain et dans l'avenir, les méthodologies Agiles sont là pour rester. Donc, nous devons s'y préparer ! Chacune sa méthodologie et les projets agiles iront encore mieux !

Mes petites résolutions Agiles pour l’an 2010.

Quelle belle tradition que sont les résolutions du Nouvel An. J’ai eu donc l’idée de vous partager aujourd’hui quelque une de mes résolutions pour ce Nouvel An. Mais, surtout un pour une année que j’espère où les méthodologies agiles prendront encore plus la place qui lui revient.

La première, nous (Moi, mon organisation, vous, tout le monde) à parler avec le plus de justesse possible des méthodologies Agiles. Quand nous voulons être une référence, il faut toujours vérifier ses affirmations et les baser sur la vérité, une vérité vérifiable.

La deuxième, dépassé plus que la simple formation. Travailler avec les gens pour les accompagner à s’accaparer les méthodologies. Je crois que pour les méthodologies Agiles, prend la place qu’elles méritent. Les gens doivent s’accaparer un peu comme leur langue maternelle.

La troisième, accompagner les gens ainsi que leur organisation, dans leurs choix et leurs transitions vers les méthodologies Agiles. Si vous le ne savez pas encore, choisir d’effectuer ce virage n’est pas une chose facile. Donc, les gens ont besoin de notre aide, mais surtout de notre accompagnement.

La quatrième, continué, continué à expliquer, mais surtout à ÉCOUTER les gens qui s’intéresse aux méthodologies agiles. Comme dit le bon vieux proverbe, on a deux (2) oreilles et une bouche. Donc, on doit écouter deux (2) fois plus !

Et une petite dernière, essayez juste un instant de penser différemment, de pensée Agile.

En terminant, permettez-moi de nous souhaiter à tous une bonne et heureuse année, mais surtout très Agile.

Un voeu pour la période des Fêtes

La période des réjouissances de Noël et du Nouvel An arrive à grands pas. Ce matin même l’hiver nous le rappelle avec un -20C qu’on bel et bien dans cette période-là pour rester.

Moi, Bruno Larouche, l’homme derrière Génération Agile et bien sur ce blogue, veut prendre quelque minute de votre temps pour vous souhaiter la plus joyeuse période de Noël et une année 2010 remplie de beaux projets Agile.

Espérons tous ensemble que cette nouvelle arrive à grand soit une année où les différentes approches Agiles auront encore une plus grande progression. Mais, aussi acquerra une maturité tant dans les pratiques que pour les gens qui les utilisent.

Je quitte aujourd'hui, pour une période de vacance qui je crois bien mérité. Je serais de retour le 4 janvier 2010 pour vous accompagner dans tous vos projets.

Je nous souhaite tous une Belle Année AGILE.

Comment choisir son Coach Agile ?

Je sais avec titre comme celui-là, beaucoup d’entre vous, vous attendez que je vais vous fournir une recette de cuisine ou encore une fiche à remplir pour aider à bien choisir votre Coach Agile. C’est bien mal me connaître. Je ne crois tout simplement pas aux procédures définies. Encore plus dans les différents processus de sélections des ressources humaines.

Je vais plutôt vous aider à apporter une réflexion sur besoin spécifique d’un Coach Agile.

À la base, les coachs agiles proviennent de différents profils. Souvent, ils proviennent de 2 grands profilés. La gestion de projets bien, mais aussi des architectes intégrateurs.

Il faut prendre le temps d’évaluer vos besoins. Par exemple, si vous avez un problème de gestion de projets. Cherchez-en un, qui a été chargé de projet.

Il faut aussi qu’il ait joué les différents rôles dans une équipe Agile. Il doit comprendre ce que chacun des rôles on fait. S’il n’a jamais été programmeur, comment, il pourra expliquer au programmeur l’impacte sur leur travail.

Tout comme un chargé de projets devra avoir géré des projets dans un contexte agile ainsi hors des méthodologies agiles. Comme dit si bien, l’expression anglaise « a Jack work trail ». Plus, il aura occupé différents postes aux files de sa carrière, plus il sera en mesure d’expliquer les impacts dans le passage aux méthodologies agiles.

La formation apporte beaucoup, mais elle ne remplacera jamais, l’expérience terrain. Tout comme, une certification Scrum Master ou autre certification du genre, à laquelle ne s’ajoute aucune expérience pratique, ne sont pas plus performant que si vous commander un livre chez Amazone.

Un vieux proverbe disait : « Il y a des choses qui s’apprennent. Mais, qui ne se montre pas ! » C’est le cas, du coaching agile. Les meilleures formations, certifications, ne remplaceront jamais l’expérience.

N’oubliez pas, que les méthodologies agiles, sont basées des approches de gestions et de bonnes pratiques. Donc, pas de règles rigides qu’on applique sans réfléchir. Par exemple, le Guide vert, donnent beaucoup d’exemples comment faire les choses, on peut s’y référer pour résoudre nos problèmes. Cette approche n’est pas prônée en Agile.

Il est vrai aussi de dire que les méthodologies agiles possèdent beaucoup de documentations (livres, site web, blogue (comme le mien)). Mais, le rôle principal du Coach Agile, n’est pas d’appliquer les règles écrites. C’est d’apporter la lumière des interlignes, des problèmes que vous vivrez durant le projet.

Je ne crois pas non plus au « GOUROU AGILE » qui arrive avec livre de recettes agiles. Comment on peut appliquer une recette magique, avec une équipe, une organisation, une technologie, etc. Applique une recette comme celles-là, va en l’en compte même des principes d’agiles. Chaque individus, organisation, projets sont différents les uns des autres. Donc, comment pourraient ton avoir un tel livre de recettes.

S.V.P., n’applique une fiche des sélections pour recruter votre Coach Agile. C’est un non-sens à mes yeux. Rappelez-vous du principe numéro 1 du manifeste Agile : « L’interaction avec les personnes que les processus et les outils ».

Rencontrez les ressources, discutées avec eux de leur vision et de leur philosophie. N’oubliez pas, cette personne aura un impact important dans votre organisation. Laisseriez-vous, votre concierge prendre la direction de votre compagnie sans vérifier ces compétences ? Le meilleur sera toujours celui avec qui vous pourrez vous assoir pour discuter du ou des problèmes. L'humain a la place #1 en agile. Donc, il faut que la communication passe entre vous et votre Coach Agile.

En terminant, trouver un Coach Agile qui vous conviendra, ce n’est pas un processus facile. Il n’y pas de mauvais Coach Agile. Il y a un qui vous convient mieux que d’autres. Aussi, pourquoi pas, au lieu d’une seule personne, de faire intervenir une équipe avec diversifié et spécialité pour vous accompagner dans ce virage important pour votre organisation. Chacun des membres de cette équipe pourrait vous apporter une lumière sur différents axes.

Comme toujours, soyez Agile dans votre réflexion et votre démarche.

Agile, de Haut jusqu’en bas, et Droite à Gauche.

Beaucoup d’organisation qui se lance dans les méthodologies Agiles, oublie un facteur important dans leur adaptation de ces nouvelles approches.

Beaucoup d’organisations qui démarrent un petit projet pilotent en Agile dans une équipe de développement. Oublie souvent, trop souvent, l’impact que cela peut avoir sur leur organisation.

Tout passage Agile, même au sein d’une petite équipe de développement aura un impact sur l’organisation tout entier.

Traditionnellement, les équipes de développement étaient dynamiques. C'est-à-dire qu’à tout moment, et souvent selon besoin momentané de l’organisation, être totalement réorganisés ou restructurés. Aux files du besoin ou des changements de l’organisation, les membres de l’équipe peuvent changer ou être remplacés durant la vie du projet. Mais, l’une des règles importantes en Agile, c’est justement l’intégrité de l’équipe. Normalement, il est très souhaitable que l’équipe reste intègre du début jusqu’à la du projet.

Donc, cela a un impacte direct sur la gestion des ressources disponibles. Chaque membre s’engage en tant qu’individu et aussi à titre de membres de l’équipe à livrer une série de composantes. Donc, s’il manque une ou plusieurs personnes dans l'équipe, l’engagement ne peut plus tenir !

Le second impact, est la disponibilité de la personne qui joue le rôle de product owner (méthodologie Scrum). Cette personne est aussi importante que tous autres membres de l’équipe. Il n’est jamais facile de libérer cette personne à cause de son expertise et sa connaissance du domaine d’affaires de l’entreprise.

Mais pour acquérir cette expertise, ça veut dire aussi qu’il occupe une place importante au sein de l’organisation. Donc, il occupe une fonction qui peut-être difficile à redistribuer ou à replacer.

Le dernier problème qu’il est difficile de réaliser avant sa mise en place. C’est la livraison fréquence et surtout beaucoup plus rapide de morceaux d’applications fonctionnelles. C’est bien beau sur le papier, mais en pratique, il apprendre à le gérer ces livraisons fréquentes. Avoir une application à tester tous les 6 à 12 mois, les organisations sont habituées. Mais, en avoir a testé, tous les 2, 4 ou 6 semaines, ce n’est pas la même chose.

Comme vous le voyez, se lancer dans un processus de mise en place des méthodes Agiles, impacte bien de haut et bas, et de droite à gauche l’organisation.

Bien entendu, l’impact pourra varier d’une organisation à une autre, mais l’expérience m’a démontré qu’elle dépassera l’équipe qui l’implémentera dans son projet de développement. Mais, une chose est sûre, il y aura un impact plus grand que seulement que dans l’équipe de développement.

Je sais vous aller dire que je prêche pour ma paroisse. Mais, je vous recommande de vous joindre une personne d’expériences, une personne qui a tant de l’expertise technique en méthodologie Agile. Mais, qui a aussi de l’expérience en contexte organisationnel. Autrement dit-on bon mélange entre l’expertise organisationnelle (monde des affaires) et l’expertise en implémentation des approches Agiles.

En terminant, rappelez-vous que vous faisiez des affaires avant l’implémentation des méthodologies Agiles et que vous devriez en faire encore après !