Open Agile

• Diviser votre organisation en petit équipe, avec des fonctions transverses et auto-organisé

• Diviser le travail en une liste de petits livrables concrets. Définir une liste qui sera triée par priorité et estimer l’effort relative pour chaque élément.

• Diviser le temps en petites itérations fixes (habituellement 1 à 4 semaines), avec un livrable qui puisse être potentiellement montré.

Optimiser le plan de release et mettre les priorités en collaboration avec le client, cette optimisation est fondée sur les connaissances acquises en analysant la release après chaque itération.

Optimiser les processus par une rétrospective après chaque itération.

Ainsi au lieu d’un grand groupe qui passe beaucoup de temps à construire un grand truc, nous avons une petite équipe qui passe un peu de temps à construire un petit truc, mais en réalisant des tests régulièrement pour voir le tout.

C’est fini !

Idée originale de Henrik Kniberg – http://blog.crisp.se/henrikkniberg

Lors de mon dernier billet sur le planning poker, je vous avez indiqué que je détaillerais la méthode (carte et attribution des points) pour bien mettre en œuvre cette technique. Me voila de nouveau pour clore ma présentation sur le planning poker.

Le Planning poker combine des opinions d’experts, des analogies et des échanges dans une ambiance agréable et ludique, qui permettent d’obtenir des estimations rapides avec des résultats fiables.

Les participants au planning poker inclus tous les développeurs de l’équipe. Rappelez-vous que le terme développeurs en méthode agile se réfère à tous les programmeurs, testeurs, ingénieur système, ingénieurs base de données, les architectes, concepteurs de l’interaction avec l’utilisateur, et ainsi de suite.

Sur un projet agile, qui ne dépasse pas généralement plus dix personnes. Si c’est le cas, il est généralement préférable de se séparer en deux équipes. Chaque équipe pourra alors faire une estimation de manière indépendante. Le directeur de produit participe à la planification, mais il ne fait d’estimation.

Au début de la planification, chaque participant reçoit un jeu de cartes. Chaque jeu de cartes distribué doit permettre de réaliser une estimation fiable. Chaque participant peut, par exemple, recevoir un jeu de cartes qui va de 0, 1, 2, 3, 5, 8, 13, 20, 40 à 100. Les cartes doivent être prêtes avant la réunion de planification et les nombres doivent être assez grands pour être vu de l’autre côté de la table.

Pour chaque cas d’utilisation ou fonction à estimer, un animateur lit le descriptif. Le modérateur est généralement le directeur de produit ou un architecte. Toutefois, le modérateur peut être n’importe qui, car il n’existe pas de privilège associé avec le rôle. Le directeur de produit répond à toutes les questions des participants. Néanmoins, tout le monde doit savoir qu’à un certain moment les discussions complémentaires ne conduisent pas à améliorer la précision. L’objectif avec le planning poker est de ne pas procéder à une estimation qui supportera toutes les futures fonctionnalités. Au contraire, l’objectif est de qualifier la première vue pour arriver sur la fin à une estimation fiable, d’où une première estimation peut être considérée à « bon marché ».

Après que toutes les questions ont trouvé des réponses (enfin, on essaye), chaque participant choisit une carte représentant son estimation. Les cartes sont montrées une fois que chaque participant a fait son choix. À ce moment-là, toutes les cartes sont retournées en même temps de manière à ce que tous les participants puissent voir chaque estimation individuelle.

Il est très probable à ce stade que les estimations diffèrent sensiblement. Il s’agit en fait d’une bonne nouvelle. Si les estimations diffèrent, les participants avec des valeurs hautes et des valeurs basses doivent expliquer la raison de leurs estimations. Il est important que cela ne fonctionne pas comme un reproche à l’intention des participants. Mais un échange sur des visions différentes.

A titre d’exemple, un participant avec une estimation haute peut dire: Eh bien, pour tester ce cas d’utilisation, nous devons créer une base de données avec des objets fictifs. Cela pourrait nous prendre un jour. Je pense aussi que l’algorithme de compression n’est pas bon, ce qui impliquerait d’en développer un nouveau plus efficace . Le participant qui a fait une faible estimation peut répondre : Je pensais que nous allions stocker les informations dans un fichier XML – ce qui serait plus facile qu’une base de données.

Le groupe peut discuter de nouveau sur le cas d’utilisation et de leurs estimations respectives quelques minutes de plus. Le modérateur peut prendre des notes qu’il pense utiles pour le développement et le test de ce cas d’utilisation. Après la discussion, chaque participant fait une nouvelle estimation en sélectionnant une carte. Les cartes sont une fois de plus gardées secrètes jusqu’à ce que tout le monde ait réalisé son estimation au cours de laquelle elles seront affichées en même temps.

Dans de nombreux cas, les estimations convergent déjà au second tour. Mais si cela n’est pas le cas, il faut continuer à répéter le processus. L’objectif pour les participants est de converger vers une seule estimation qui peut être utilisée pour le cas d’utilisation. Cela prend rarement plus de trois tours de scrutin, mais le processus doit continuer jusqu’à ce que les estimations convergent. Il n’est pas nécessaire que tout le monde dans la pièce retourne une carte avec exactement la même estimation. Si je suis un modérateur et sur le deuxième tour quatre participants proposent, 5, 5, 5 et 3, je vais demander au participant qui a fait la plus faible estimation, si il est OK si on décide d’une estimation à 5. Encore une fois, l’estimation ne nécessite pas une précision absolue, mais raisonnable.

Le droit à la discussion

Certaines discussions sur la conception préliminaire du cas d’utilisation sont nécessaires et appropriées, lors de l’estimation. Toutefois, dépenser trop de temps sur des discussions à propos de la conception est souvent un gaspillage d’efforts et de temps. Voici un moyen efficace d’encourager certains débats, mais assurez-vous qu’il ne va pas trop durer.

Acheter un sablier, et placez-le au milieu de la table de poker où la planification est en cours. Toute personne assistant à la réunion doit pouvoir voir le compte à rebours à tout moment. Lorsque le sablier est épuisé (environ deux minutes), la prochaine série de cartes est jouée. Si un accord n’est pas atteint, la discussion peut se poursuivre. Mais quelqu’un doit tourner immédiatement le sablier pour limiter la discussion à deux minutes. Le sablier n’a rarement besoin d’être utilisé plus de deux fois. Avec cette méthode, les équipes apprennent à estimer plus rapidement.

Les petites sessions

Il est possible de jouer au poker avec un sous-ensemble de l’équipe, plutôt que de tout le monde. Ce n’est pas idéal, mais cela est parfois une option raisonnable, surtout si l’équipe est nombreuse, s’il y a beaucoup de cas à estimer, comme cela peut se produire au début d’un nouveau projet.

La meilleure façon d’y parvenir est de scinder la plus grande équipe en deux ou trois petites équipes, dont chacun doit disposer d’au moins trois participants. Il est important que chacune des équipes de participant estime successivement.

Pour ce faire, commencer avec toutes les équipes ensemble dans une session de planification conjointe d’une durée d’une heure environ. Demandez-leur une estimation pour 10 à 20 cas d’utilisation. Ensuite, assurez-vous que chaque équipe a une copie des cas d’utilisation et leurs estimations et qu’ils les utilisent comme base pour estimer les cas d’utilisations qu’ils leur sont donnés à estimer.

Quand jouer au planning poker

Les équipes devront jouer au planning poker à deux moments différents. Tout d’abord, il sera généralement nécessaire de faire des estimations sur un grand nombre de cas d’utilisation avant que le projet ne commence officiellement ou au cours de sa première itération. Estimer une première série de cas d’utilisation avec l’équipe sous la forme de deux ou trois réunions allant d’une à trois heures chacune. Naturellement, cela dépendra du nombre de cas d’utilisation à estimer et de la taille de l’équipe, et si le directeur de produit a les capacités de préciser les exigences de manière succincte.

Deuxièmement, les équipes devront faire de nouveaux efforts à chaque nouvelle estimation de cas d’utilisation qui sont identifiés au cours d’une itération. Une façon d’y parvenir est de planifier une estimation sous la forme de réunion très courte vers la fin de chaque itération. Normalement, cela est tout à fait suffisant pour estimer les travaux qui sont à réaliser au cours de l’itération, et permet d’obtenir les priorités à appliquer à l’itération en cours.

Sinon, Kent Beck propose une enveloppe accrochée sur le mur avec tous les nouveaux cas d’utilisation positionnés dans l’enveloppe. L’équipe va récupérer un ou deux cas d’utilisation dans l’enveloppe et les estimer. Les équipes doivent établir une règle pour eux-mêmes, généralement que tous les cas d’utilisation doivent être estimés d’ici la fin de la journée ou à la fin de l’itération. J’aime bien l’idée d’accrocher une enveloppe sur le mur qui contient les cas d’utilisation non estimés. Toutefois, je préfère lorsque quelqu’un qui a un peu de temps consacre quelques minutes à faire une estimation, il trouve au moins une autre personne et ils font une estimation conjointe.

Pourquoi le planning poker fonctionne

Maintenant que je viens de décrire la mise en oeuvre du planning poker, je vous propose de passer un petit moment sur les raisons pour lesquelles il fonctionne si bien.

Tout d’abord, le planning poker rassemble de multiples expertises pour réaliser les estimations. Parce que ces experts forment une équipe pluridisciplinaire sur un projet de développement applicatif, ils sont le plus à même pour estimer une tâche que d’autres personnes. Après avoir réalisé un examen approfondi de la littérature sur les estimations des charges en développement, Jørgensen (2004) a conclu que les personnes les plus compétentes pour résoudre la tâche doivent l’évaluer .

Deuxièmement, un dialogue animé s’ensuit au cours de la planification, et les planificateurs sont appelés par leurs pairs pour justifier leurs estimations. Cela a été proposé pour améliorer la précision de l’estimation, en particulier sur les cas d’utilisation avec de grandes quantités d’incertitude (Hagafors et Brehmer 1983). Être invité à justifier les estimations a démontré que cela se traduit par une meilleure estimation pour compenser les informations manquantes (Brenner et coll. 1996). C’est d’autant plus important sur un projet agile parce que les cas d’utilisations sont souvent intentionnellement vagues.

Troisièmement, des études ont montré que la moyenne des estimations individuelles conduit à de meilleurs résultats (HOEST et Wohlin 1998) de même que des discussions de groupe de planificateurs (Jørgensen et Moløkken 2002). Le groupe de discussion est la base du planning de poker, et ces discussions aboutissent à une sorte de moyenne des estimations individuelles.

Finalement, le planning poker fonctionne parce que c’est amusant !

La définition des plannings est des charges associées à un projet sont un mélange d’expérience, d’échange et un peu de hasard. Je vous propose dans ce billet une méthode ludique et en équipe pour définir les charges d’activités sur les projets. Cette méthode découle des méthodes de gestion de projet Agile.

Le Planning Poker est l’un des outils de la méthode Scrum. Il permet à une équipe lors d’une réunion de planification de donner des cotations pour le développement d’une fonctionnalité. Lors de la réunion, le product owner (directeur de produit) représente le client, le commanditaire. Il donne l’ordre dans lequel doit s’effectuer les développements des nouvelles fonctionnalités. L’équipe a pour responsabilité de donner des quantifications au directeur de produit afin que celui-ci sache aussi que telle fonctionnalité coûte 10 unités et qu’une autre fonctionnalité ne coutera que 2 unités. A noter que je ne parle pas de jour/homme pour l’instant. Et c’est là qu’intervient le Planning Poker.

Mettons-nous en situation. Vous réunissez votre équipe de 5 personnes dans une salle. Vous demandez à tout le monde “combien de temps pour développer l’ajout de la fonction X sur mon logiciel ?” .

Mr A pense qu’il sait exactement ce qu’il faut faire, donc il pense 5 jours. Mr B et Mr C sont plus prudents. Mr D et E ne participent pas activement à la conversation et n’écoutent pas. Bref, c’est Mr A qui prend la parole et qui vous répond, “Je pense 5 jours“.

L’équipe est influencée par la première personne qui s’exprime. C’est un risque important, car en fait on voit que B et C pensaient que cette fonction demande plus de temps à développer. Nous risquons de perdre de l’information ici et leurs doutes doivent être exprimés.

Reprenons la même scène avec le planning poker. Le principe est de donner à chacun de vos équipiers un jeu de carte spécial, le fameux Planning Poker dont voici une photo :

Vous distribuez un jeu complet à chacun de vos équipiers.

Comme vous pouvez le constater, les cartes ne se suivent pas. Elles sont basées en partie sur la suite de Fibonacci afin de forcer les personnes à trancher. L’unité n’est pas le nombre de jours/homme, mais une unité arbitraire. Il est important de donner un jeu à chaque personne de l´équipe.

Ensuite voici comment se déroule la séance : refaisons l’évaluation. Le product owner (directeur de produit) dit :

L’équipe lui pose des questions afin d’affiner la demande pendant environ 5 mn. Ensuite commence la phase du vote. Chacun prend une des cartes et la pose devant lui face cachée. Cette fois-ci chacun pense librement et activement. Mr D et Mr E sont obligés aussi de participer. Une fois que tout le monde a sélectionné une de ses cartes, on retourne celle-ci en même temps et le résultat du premier vote est discuté par l´équipe.

Cette fois-ci nous voyons bien qu’entre Mr A et Mr C, une discussion s’impose à propos de l’histoire. Après quelques discussions, Mr A réalise qu’il a oublié une partie du développement et qu’il faut l’inclure. Mr C réalise qu’avec la proposition de Mr A en effet il est possible de réaliser plus rapidement la fonction et que donc son estimation est un peu trop pessimiste. Après 5 mn, toute l’équipe refait une estimation en reprenant les cartes, et en sélectionnant une nouvelle carte, ou la même s’ils n’ont pas changé d’avis.

Voilà maintenant une cotation réaliste et réalisable de la demande initiale. Les développeurs se sont parlé activement afin de présenter une vision sur la solution envisagée. Et tout le monde y a participé. Ce qui est aussi efficace en terme d’échanges et de communications.

Il existe quelques cartes spéciales:

• la carte 0 représente une fonction qui est déjà implémentée
• la carte ? représente le fait que vous n’avez vraiment aucune idée sur la question
• la carte “tasse de café” c’est le joker pour signaler que vous voulez faire un break

Ressources complémentaires:

Vous pouvez fabriquer un jeu de cartes avec quelques fiches cartonnées ou en acheter un à cette adresse CRISP

Vous retrouverez aussi la version en anglais (CRISP) de cet article que j’ai librement traduit à cette adresse et donc le crédit de cet article va en premier à Crisp SE. Merci à eux.

Je vous prépare pur la prochaine un billet qui décrit la valeur des cartes et l’attribution des unités.

Les projets à base de développement Agile sont livrés en plusieurs petits morceaux, des petites livraisons, des livraisons incrémentales et itératives.

Dans les projets de développement traditionnel, le cycle de vie (simplifié) se compose de l’analyse, le développement et les tests – tout d’abord, toutes les exigences sont recueillies pour l’ensemble du produit, ensuite les éléments du logiciel sont développés, une fois terminé, le produit est entièrement évalué et tester avant sa livraison.

Méthode en cascade

En développement Agile, le cycle de vie et d’analyser, développer, tester, analyser, développer, tester, et ainsi de suite. Réaliser chaque étape pour chaque fonction, une fonction à la fois.

Méthode itérative

Les avantages de cette approche itérative du développement sont :

• Réduction des risques: Permet d’avoir une visibilité de ce qui est achevé à un moment précis du projet.
• Augmentation de la valeur : livrer rapidement à des avantages, être en mesure de livrer le produit quand il est considéré comme assez bon, plutôt que de devoir attendre tous les éléments destinés à être livrés,
• Plus de souplesse / agilité: on peut choisir de changer de direction ou d’adapter les prochaines itérations sur la base ce qui a été développé et sur l’utilisation du logiciel.
• Une meilleure gestion des coûts: si, comme tous les trop nombreux projets de développement de logiciels, vous courez après le budget, une certaine économie peut-être apportée par la méthode Agile.

Pour cette approche et pour être pratique, chaque fonction/caractéristique doit être pleinement développé, dans la mesure où elle est doit être livré, avant de passer à la suite.

Une autre pratique consiste à faire en sorte que chaque fonction/caractéristique soit développée par ordre de priorité, pas nécessairement dans un ordre logique par rapport au logiciel. Plutôt selon des critères de priorités client et de fonctions de haut niveau indispensable au logiciel. Dans le cas contraire, vous pourriez manquer de temp, pour avoir passé du temps sur des fonctions de moindres importances.

Construire les fonctionnalités du logiciel « importante, mais peu technique » est également souhaitable pour la même raison.

Ce n’est que lorsque vous avez terminé tout ce que vous devait avoir comme fonctions, que vous pouvez passer à ce que vous devriez avoir comme fonctions, et ensuite passer à ce que vous pourriez avoir comme fonctions. Sinon, vous pourriez obtenir une situation où vos premières caractéristiques sont fonctionnellement très riches, alors que du côté logiciel les caractéristiques sont de moins en moins sophistiquées avec le temps qui passe.

Essayez de garder votre produit backlog (terme lié à la méthode Scrum) ou votre liste de fonctionnalités pour qu’elle s’exprime en termes de cas d’utilisation, de scénarios utilisateur, ou caractéristiques – pas en tâches techniques.

Idéalement, chaque point de la liste doit toujours être quelque chose qui a une valeur pour l’utilisateur, et toujours vue comme un livrable plutôt qu’une activité pour pouvoir « taper dans les pneus » et de juger de la complétude, la qualité et prêt à livré.

Ce sont les caractéristiques importantes du développement itératif. Ils sont essentiels si vous prévoyez de délivrer dans les délais fixés – un des 10 principes clés du développement Agile.

La synthèse de cet article : Une équipe de développement identifie les exigences à un niveau élevé et au coup par coup, juste à temps pour chaque élément à développer. Avec une vision globale de l’objectif du projet.

Le développement Agile est idéalement visuel et doit être à la limite de l’acceptable, c’est-à-dire le strict minimum nécessaire pour permettre le développement et l’expérimentation pour procéder avec une efficacité raisonnable. La raison d’être est de minimiser le temps consacré à tout ce qui ne fait pas partie du produit final.

Le développement Agile peut-être confondu à tort par certains comme dépouillé de processus ou de règles. En d’autres termes que l’on réalise les choses au fur et à mesure . Cette approche n’est pas réellement Agile mais plutôt fragile !

Bien que le développement Agile est beaucoup plus souple que les méthodes de développement traditionnelles, le développement Agile n’est pas néanmoins exempt de rigueur et il est basé sur l’approche structurée (Lean Manufacturing) initiée par le groupe Toyota (leader de la productivité) – Remarque: Le travail de Toyota à été permis de créer la méthode « Lean Software Development » qui complète les méthodes Agile pour apporter la qualité tout au long du cycle de vie du projet. Je vous présenterais bientôt un billet sur cette méthode.

Je crois personnellement que les équipes de développement Agile peuvent créer de meilleurs produits s’ils ont une idée assez claire de l’ensemble des besoins avant de partir sur le développement, afin que les décisions de conception qui peuvent s’avérer erronées ne conduisent pas à l’équipe dans des impasses. Elle permet en complément des investissements plus raisonnables pour financer les projets.

Cependant, toutes les exigences identifiées au début doivent être vues à un niveau élevé et dans un format visuel, par exemple, comme un story-board de l’interface utilisateur. À ce stade, les exigences doivent être assez bien comprises pour déterminer les grandes lignes du produit et produire une première prévision du budget et rien de plus.

Idéalement, les équipes de développement Agile identifient les exigences à haut niveau dans des ateliers. Ils travaillent ensemble dans une grande collaboration de manière que tous les membres de l’équipe puissent comprendre les exigences. Il n’est pas nécessairement d’avoir des personnes avec des compétences particulières, comme un architecte comme dans des projets plus traditionnels, afin de recueillir les exigences indépendamment les unes des autres et de les formaliser par écrit. C’est une activité conjointe de l’équipe qui permet à chacun de contribuer et de comprendre ce qui est nécessaire.

XP (eXtreme Programming) applique des « pauses » aux exigences sous la forme de petites parties appelées « User stories ». Ils sont fondamentalement similaires au cas d’utilisation (Use Case), mais sont plus légers et plus simples par leur nature.

Une équipe de développement Agile visualise les exigences sur un tableau blanc et crée des sessions de story-board (séquences de captures d’écran, des visuels, des croquis, des wireframes ou des diagrammes de séquence) pour montrer à peu près à quoi ressembleront la solution et l’interaction de l’utilisateur dans la cinématique de la solution. Il n’existe pas de long cahier d’exigence ou des spécifications à moins qu’il y ait des zones de complexité qui le justifient réellement. Sinon, les story-boards sont tout annotés et seulement lorsque cela est nécessaire.

Une approche commune entre les équipes de développement Agile est de représenter chacune des exigences, cas d’utilisation ou de story board sur une carte et utiliser une T-card (une représentation visuelle très efficace de plusieurs story board) pour permettre aux scénarios d’être facilement déplacés pour permettre d’ajuster les priorités. Exemple de T-card :

T-card

Les exigences sont ventilées en très petits morceaux afin de parvenir à ce résultat; en fait, c’est la force des cartes de pouvoir réaliser cette ventilation en très petits morceaux. L’avantage par rapport à une documentation classique, c’est que cette approche est extrêmement visuelle et tactile, vous pouvez être debout autour du système de T-card et le tableau blanc pour discuter de l’avancé, des priorités et des questions.

La technique de la carte et du T-card est très utile quand le contexte métier ou la technologie n’est pas totalement maitrisée par l’équipe projet. Toutefois, quand l’équipe de développement à une expérience importante du métier et peut rapidement identifier le périmètre et les cas d’utilisation, il est préférable d’utiliser un tableau blanc et un appareil photo pour capturer les cas d’utilisation et les diagrammes de séquence. Les cartes restent néanmoins utiles pour se rappeler des différentes exigences nécessaires du projet et pour l’évaluation de la charge.

Les besoins évoluent, mais les délais sont fixes. Au cas où il serait nécessaire de changer les priorités ou d’ajouter de nouvelles exigences dans le projet, le responsable du projet doit retirer une charge comparable au montant de la nouvelle exigence avant de pouvoir placer la nouvelle carte dans le projet.

Les équipes traditionnelles de projet qui ne contrôlent pas le changement peuvent terminer le projet hors du champ initial avec le redoutable glissement de planning, une des raisons les plus communes pour quoi les projets de développement échouent.

Les équipes Agile, en revanche, acceptent le changement, en fait, ils s’attendent. Mais elles gèrent le changement en fixant les délais et la négociation.

Les cartes peuvent bien sûr être complémentées par une documentation appropriée (souvent nécessaire pour le client), mais toujours dans un principe de développement agile, il faut toujours documenter le strict minimum d’informations qui permettra à une fonction d’être développées et toujours ventilées en très petites unités.

Pour exemple, pour mes projets nous faisons avec l’équipe de développement des cas d’utilisation (CU), des diagrammes de séquence (DS), les visuels (UHM) un par un sur un tableau blanc, nous terminons une série en prenant des photos du tableau. Ensuite on transfère au client un par un les CU, DS et interface IHM. Une fois stabilisé, nous pouvons écrire le document (par exemple une spécification fonctionnelle), mais jamais avant que le développement du CU ne soit réalisé.

Utiliser Scrum est une bonne pratique pour la gestion des projets, les exigences (ou les fonctionnalités ou les cas d’utilisation, quelle que soit le mot que vous préférez utiliser) sont ventilées en tâches qui ne dépassent jamais plus de 16 heures (c’est-à-dire 2 jours de travail) et de préférence pas plus de 8 heures, de sorte que les progrès peuvent être mesurés objectivement sur une base quotidienne.

Une dernière chose et qui je pense devrait être certainement adopté de PRINCE2 (la méthodologie de gestion de projet pas agile du tout !), est l’idée de s’assurer que tous les besoins sont des éléments à fournir plutôt que des activités ou des tâches. Vous pouvez voir un produit et donner un « coup de pied dans les pneus », afin de juger de sa qualité et de son exhaustivité. Avec une tâche vous ne pouvez pas le faire.