Christmas Backlog

((/dotclear/public/christmas-backlog.gif|Christmas Backlog|L|Christmas Backlog))Ce matin, j’ai gardé ma fille malade à la maison. Elle a 6 ans, et ça a été une occasion parfaite pour mettre en pratique le billet de Jean Claude Grosjean : ++[« Un Backlog priorisé pour le Père Noël »|http://www.qualitystreet.fr/2009/11/13/un-backlog-priorise-pour-le-pere-noel-acte-2/|fr]++.%%% %%% __Étape 1__ : lecture de 4 catalogues de jouets et découpage ; 1h30mn environ; 70 user stories (jouets) dans l’état « en vrac » dans le product backlog initialisé%%% %%% __Étape 2__ : parcours des user stories pour écarter les découpages sans référence, sans prix, des jouets pour les moins de 4 ans ou les plus de 6 ans, des jouets dépendants d’autres jouets non sélectionnés comme des jeux vidéos sans la console qui va avec, des user stories en double (ou presque) ; 15 mn ; reste 50 user stories dans l’état « prêt » dans le product backlog%%% %%% __Étape 3__ : priorisation des user stories et, le Père Noël n’ayant qu’une nuit pour faire ses livraisons dans le monde entier, j’ai proposé de nous concentrer sur 20% du haut du backlog ; 30 mn (quand même, on a dû relire certaines user stories, il y eu des sacrifices) ; reste 10 user stories dans l’état « priorisé’ en entrée du sprint backlog, c’est-à-dire une enveloppe adressée au Pôle Nord ;-)%%% %%% __Étape 4__ : estimation et planification du sprint backlog avec la maman ; on va devoir croiser les priorités et les prix…%%%

Utiliser les développements incrémental et itératif ensemble

[((/dotclear/public/photos/.Alistair_Cockburn_t.jpg|Alistair Cockburn|L|Alistair Cockburn))|/dotclear/public/photos/Alistair_Cockburn.jpg]Je suis tombé sur un article extrêmement intéressant de Alistair Cockburn : ++[« Using Both Incremental and Iterative Development »|http://www.stsc.hill.af.mil/crosstalk/2008/05/0805Cockburn.html|en]++ datant de Mai 2008. J’ai décidé de le traduire.%%% %%%  »Le développement incrémental est nettement différent du développement itératif dans ses objectifs ainsi que dans ses implications dans la gestion de projet. Les équipes rencontrent des problèmes en faisant l’un et pas l’autre, ou en essayant de les gérer de la même manière. Cet article explique leurs différences et comment les utiliser ensemble. »%%% > Les développements incrémental et itératif sont antérieurs au mouvement Agile. Je les ai d’abord étudié lors de mes recherches pour le groupe IBM Consulting en 1991. A cette époque, j’ai appris comment ils différaient en termes d’objectif et de nature, et, finalement, comment il fallait les utiliser.%%% > %%% > Ces différences semblent avoir été oubliées depuis. Je vois maintenant des équipes qui souhaiteraient faire de l’Agile et qui souffrent de ne faire que du développement incrémental, là où j’avais l’habitude de voir des projets, basés sur le modèle en cascade, souffrant de ne faire aucun des deux ou seulement du développement itératif.%%% > %%% > Les deux sont nécessaires. Les gens ont besoin d’apprendre à les utiliser séparément et ensemble.%%% >%%% > __Définitions, s’il vous plaît !__%%% > %%% > Brièvement :%%% > %%% > – Le développement __incrémental__ est une stratégie par étape et planifiée dans lequel différentes parties du système sont élaborées à différents moments ou degrés et intégrées dès qu’elles sont terminées.%%% > %%% > La stratégie alternative au développement incrémental est de développer l’ensemble du système avec une intégration  »big-bang » à la fin.%%% > %%% > – Le développement __itératif__ est une stratégie de remaniement (~rework) planifié dans lequel du temps est réservé pour réviser et améliorer certains aspects du système.%%% > %%% > La stratégie alternative au développement itératif est de prévoir d’avoir tout bon du premier coup.%%% > %%% > Il est important de remarquer qu’aucune stratégie ne suppose, requiert, ou implique l’existence de l’autre. Il est possible de n’en utiliser qu’une seule, les deux, ou aucune.%%% > %%% > Dans la pratique, il est conseillé d’utiliser les deux à doses raisonnables. Si vous faites seulement de l’incrémental, il pourra y avoir une surprise désagréable à la fin quand la qualité ne sera pas au rendez-vous. Si vous faites de l’itératif sur l’ensemble du système, les effets dominos dus aux nombreux changements pourront facilement vous faire perdre le contrôle du projet.%%% > %%% > __Ce n’est pas le modèle en cascade__%%% > %%% > Tout d’abord, nous avons besoin d’éviter de tomber dans le piège du « ça ressemble au modèle en cascade ».%%% > %%% > Dans tout développement, qu’il s’agisse de prototypage, Agile, en spiral, ou en cascade, nous décidons d’abord de ce qu’il faut construire; nous concevons et programmons ensuite quelque chose. Seulement, après avoir fait un peu de programmation (généralement plus que ce que nous avions décidé initialement), nous nous préparons à déboguer le système. C’est seulement une fois que le système fonctionne que l’on peut valider le fait que ce que nous avons construit est la bonne chose et que c’est correctement construit. Ce cycle est illustré à la figure 1.%%% > %%% > ((/dotclear/public/traductions/Cockburn_Fig1.jpg|Fig1-cycle||Fig1-cycle))%%% > Figure 1: Le mode de validation en V est un acte normal de la vie%%% > %%% > La figure 1 devrait vraiment être lue à l’envers, comme un diagramme de dépendance : nous ne pouvons pas livrer tant que nous n’avons pas débogué et validé; nous ne pouvons pas déboguer tant que nous n’avons pas codé; nous ne pouvons pas coder tant que nous n’avons pas conçu; nous ne pouvons pas concevoir tant que nous n’avons pas décidé quoi concevoir.%%% > %%% > En d’autres termes, la validation en V est un acte normal de la vie, et nous aurons à le traiter aussi bien dans le développement incrémental que itératif.%%% > %%% > __Développement incrémental__%%% > %%% > Dans le développement incrémental, nous découpons les tâches en petits morceaux et les planifions pour être développées au fil du temps et intégrées dès qu’elles sont terminées. Les figures 2 à 4 illustrent ce cycle.%%% > %%% > Imaginez que les premiers blocs du dessus représentent divers composants de l’interface utilisateur, les blocs du milieu représentent le middleware, et les blocs du bas représentent les composants du back-end ou de la base de données.%%% > %%% > La figure 2 montre que, lors du premier incrément, un ensemble complet de fonctionnalités est construit de l’interface utilisateur (IHM) jusqu’au back-end (et dans ce cas, des morceaux supplémentaires de l’interface utilisateur sont également construits). Dans le second incrément (figure 3), nous voyons que la fonctionnalité supplémentaire qui est ajoutée concerne toutes les couches du système. Cela peut constituer un stade d’avancement suffisant pour déployer le système tel qu’il est pour les utilisateurs finaux et commencer à en faire bénéficier le métier. Dans le troisième incrément (figure 4), le reste du système est complété.%%% > %%% > ((/dotclear/public/traductions/Fig2-inc-stage1.jpg|Incrémental – étape 1||Incrémental – étape 1))%%% > Figure 2 : Développement incrémental – Niveau 1%%% > %%% > ((/dotclear/public/traductions/Fig3-inc-stage2.jpg|Incrémental – étape 2||Incrémental – étape 2))%%% > Figure 3 : Développement incrémental – Niveau 2%%% > %%% > ((/dotclear/public/traductions/Fig4-inc-stage3.jpg|Incrémental – étape 3||Incrémental – étape 3))%%% > Figure 4 : Développement incrémental – Niveau 3%%% > %%% > Le modèle qui vient d’être décrit est celui utilisé par la plupart des projets actuels, Agile ou non. C’est une stratégie par étape qui a connu beaucoup de succès.%%% > %%% > L’erreur que font aujourd’hui les gens c’est d’oublier d’itérer. Ils ne prennent pas le temps d’apprendre à partir de ce qu’ils ont mal compris quand ils ont décidé de ce qu’il fallait construire au tout début et de réfléchir à ce qui devait être amélioré dans la phase de conception.%%% > %%% > Cette erreur aboutit au classique échec de livrer des choses que les gens ne veulent pas. Je tiens à souligner que, même de nombreuses équipes de projet Agile commettent cette erreur.%%% > %%% > La stratégie corrective est le développement itératif.%%% > %%% > __Développement itératif__%%% > %%% > Avec le développement itératif, nous réservons du temps pour améliorer ce que nous avons.%%% > %%% > Les spécifications et les interfaces utilisateurs sont historiquement connues pour être génératrices de tâches d’adaptation, mais ce ne sont pas les seules. La technologie, l’architecture et les algorithmes sont également susceptibles d’avoir besoin d’inspection et d’adaptation. La sous-performance est souvent mal anticipée dans les premières phases de conception, et nécessite une grosse adaptation de l’architecture.%%% > %%% > Si l’on regarde le modèle de validation en V, la différence est qu’au lieu d’intégrer et peut-être même de livrer le logiciel à la fin du cycle, on l »’examine » sous divers angles : était-ce la bonne chose à développer ? les utilisateurs apprécient-ils la façon dont cela fonctionne ? est-ce-que cela fonctionne assez rapidement ?%%% > %%% > La figure 5 montre le modèle de validation en V pour un cycle de développement itératif.%%% > %%% > ((/dotclear/public/traductions/Fig5-cycleV-iteratif.jpg|Itératif – modèle de validation||Itératif – modèle de validation))%%% > Figure 5: Modèle de validation en V pour un cycle itératif%%% > %%% > Il y a deux stratégies de remaniement spécialisées et particulières :%%% > %%% > – Développez le système aussi bien que possible en ayant à l’esprit que, si c’est suffisamment bien fait, les modifications seront minimes et pourront être rapidement intégrées.%%% > – Développez le moins possible avant que cela sois soumis à évaluation, en ayant à l’esprit que vous aurez limité le gaspillage lorsque vous aurez la bonne information.%%% > %%% > Il y a des aficionados des deux approches. En effet, les deux fonctionnent bien dans certaines circonstances. Un chef de projet doit apprendre à utiliser les deux.%%% > %%% > Ce qui suit est une utilisation efficace de la première stratégie : un musicien et un photographe ont réalisé un DVD ensemble. Le musicien a fait un enregistrement de quatre minutes. Le photographe a remarqué qu’un petit ensemble de transitions entre les diapositives ne correspondait pas à la musique. Le musicien a uniquement ré-enregistré ces parties et les a insérées dans l’enregistrement.%%% > %%% > Pour démontrer une utilisation efficace de la deuxième stratégie, j’adapte l’exemple de Jeff Patton concernant la peinture de la Joconde et en imaginant un débat entre Léonard de Vinci et son client (figures 6 à 8).%%% > %%% > Léonard dessine une esquisse de ce qu’il compte faire (figure 6) et se dirige vers son client en demandant : « Est-ce que ça va vous aller ? »%%% > %%% > ((/dotclear/public/traductions/Fig6-joconde-1.jpg|Figure 6 – Joconde 1||Figure 6 – Joconde 1))%%% > Figure 6 : Développement itératif de la Joconde, étape 1%%% > %%% > Le client répond : « Non, non, non. Elle ne peut pas regarder à droite, elle doit regarder vers la gauche ! ». Heureusement, Léonard n’a pas trop travaillé pour le moment, donc c’est facile à changer.%%% > %%% > Léonard s’en va, renverse l’image, rajoute un peu de couleur et des détails (figure 7). Il revient voir le client : « J’en ai à peu près réalisé le tiers. Qu’en pensez-vous maintenant ? »%%% > %%% > ((/dotclear/public/traductions/Fig7-joconde-2.jpg|Figure 7 – Joconde 2||Figure 7 – Joconde 2))%%% > Figure 7 : Développement itératif de la Joconde, étape 2%%% > %%% > Le client répond : « Non, vous ne pouvez pas lui faire une tête de cette taille ! Proportionnez sa tête avec le reste de son corps. » (Oui, ils avaient l’équivalent de Photoshop et des options de retouche d’image à l’époque – cela s’appelait  »Léonard »).%%% > %%% > Léonard s’en va, termine le tableau (Figure 8) et envoie sa facture au client.%%% > %%% > ((/dotclear/public/traductions/Fig8-joconde-3.jpg|Figure 8 – Joconde 3||Figure 8 – Joconde 3))%%% > Figure 8 : Développement itératif de la Joconde, étape 3%%% > %%% > Le client dit : « Vraiment, j’aurai préféré qu’elle ait les yeux plus gros, mais d’accord, je vous paye, disons-que c’est terminé. »%%% > %%% > Ce que je voudrais souligner c’est que les deux stratégies sont valides et les deux portent l’étiquette  »itératif ». Dans les deux cas, des remaniements ont été effectués sur une partie existante du système.%%% > %%% > __Fusionnez les deux__%%% > %%% > Les développements incrémental et itératif s’associent bien ensemble. En se basant sur le modèle de validation en V, nous pouvons le réorganiser en alternant des Vs « incrémental » avec des Vs « itératif » de diverses manières pour obtenir un nombre varié de stratégies mixant de l’itératif et de l’incrémental comme l’illustre la figure 9.%%% > %%% > ((/dotclear/public/traductions/Fig9-mixte.jpg|Figure 9 – mixer incrémental et itératif||Figure 9 – mixer incrémental et itératif))%%% > Figure 9 : Associer les développements itératif et incrémental%%% > %%% > La figure 9 montre une stratégie dans laquelle chaque cycle incrémental comprend deux étapes d’examen/adaptation du système avant que le résultat soit intégré et prêt à livrer. La figure montre trois phases de développement incrémental, chaque incrément est intégré une fois terminé, le tout est ensuite prêt à être déployé.%%% > %%% > Ceci est un, mais seulement un, des moyens d’associer les deux. Tant qu’ils sont clairement dans l’état « Examen » ou « Prêt à être livré » (ou « Prêt à être déployé », ce qui est encore mieux), les Vs peuvent être combinés dans tous les sens.%%% > %%% > La figure 9 offre un avantage supplémentaire en décrivant les incréments et itérations sous forme de Vs : le diagramme obtenu peut facilement s’insérer dans un calendrier. Chaque marque « Examinez », « Intégrez » ou « Livrez » est un jalon dans le planning du chef de projet. Cela permet au chef de projet de visualiser à l’avance et de maîtriser le temps consacré aux adaptations. De cette façon, nous avons mis à profit le modèle de validation en V avec notre stratégie de développement incrémental-itératif.%%% > %%% > __Gérez les deux__%%% > %%% > A première vue, les deux se ressemblent. Pourtant, ils doivent être gérés différemment. Les incréments sont faciles à repérer, facile à séparer, relativement facile à estimer, et facile à planifier. Toute la stratégie peut être résumée en deux étapes :%%% > %%% > – Divisez le système en fonctionnalités complètes et utiles (ou toute autre façon de découper le système, cela reste votre choix).%%% > – Réalisez-les les unes après les autres.%%% > %%% > Les itérations sont considérablement plus difficiles. Elles sont difficiles à séparer, difficiles à estimer, et difficiles à planifier. Bien sûr, être difficile ne signifie pas que vous n’avez pas à faire toutes ces choses. Vous devez les faire, et répondre aux trois questions suivantes :%%% > %%% > – Quels éléments doivent bénéficier de périodes d’adaptations planifiées ?%%% > – Combien de périodes d’adaptations chaque élément nécessite-t-il ?%%% > – Combien de temps doit durer chaque période d’adaptation ?%%% > %%% > Bien qu’il n’y ait pas de réponse simple et fiable à ces questions, il existe une stratégie simple que vous pouvez librement adapter pour votre projet.%%% > %%% > – Planifiez de façon certaine l’adaptation des interfaces utilisateurs, planifiez l’adaptation des exigences au moment où les utilisateurs finaux commencent à utiliser le système, et attendez-vous à ce que l’architecture soit remise en question pour raison de sous-performance et adaptée.%%% > – Allouez deux périodes d’adaptation pour la conception de l’interface utilisateur, et une de plus pour l’évolution des exigences et l’adaptation de l’architecture.%%% > – Allouez pour la première période d’adaptation le tiers du temps de développement initial, et pour la deuxième période la moitié de cela.%%% > %%% > Vous aurez besoin d’estimer et tester vos propres ratios, mais ceux que j’ai proposé ne doivent pas être si mauvais que ça pour une première estimation.%%% > %%% > Si vous faites des développements Agile avec Scrum ou eXtreme Programming, assurez-vous que toutes les user stories ou cartes du backlog passent à travers le sprint avec un coefficient multiplicateur de trois sur leurs estimations de taille.%%% > %%% > __Trois histoires__%%% > %%% > Pour finir, je vous raconte trois histoires de développement incrémental / itératif qui se sont bien ou mal passées. Le premier, le projet  »Baker », met en jeu de l’itératif mélangé avec de l’incrémental, sachant qu’ils auraient dû faire de l’incrémental lorsqu’ils faisaient de l’itératif. Le second, le projet  »Laddie », témoigne du problème des projets modernes Agile qui font de l’incrémental sans itératif. Le dernier projet,  »Winifred », s’est bien déroulé.%%% > %%% > Le projet Baker était à coût et périmètre fixés et comptait 200 personnes. Elles travaillaient selon un cycle mensuel (une stratégie de développement incrémental).%%% > %%% > Les équipes étaient séparées et travaillaient selon un mode pipeline de telle façon que les spécificateurs rédigeaient pendant 1 mois avant de passer leurs livrables aux concepteurs le début du mois suivant. Un mois plus tard, les concepteurs transmettaient leurs livrables aux programmeurs qui développaient pendant un mois. À la fin, les testeurs recevaient des morceaux de code à tester et intégrer.%%% > %%% > En se méprenant su le terme  »développement itératif », ils ont ensuite donné des instructions à tous comme quoi les spécifications et la conception pouvaient changer à n’importe quel moment (ceci constituait leur stratégie de développement itératif).%%% > %%% > Le tohu-bohu qui a suivi est exactement ce que à quoi vous pensez. Chaque mois, les spécificateurs révisaient des parties des spécifications, qui changeaient des parties de la conception et des développements. Dès le troisième mois, il était évident pour les développeurs qu’ils étaient en train de programmer un système qui était déjà en cours de modification chez les concepteurs qui eux-mêmes étaient simultanément conscients qu’ils étaient en train de concevoir un système qui était déjà en cours de modification chez les spécificateurs. Les testeurs n’ont jamais rien reçu qui corresponde.%%% > %%% > Le projet Baker était en difficulté dès le départ, en partie à cause à cette stratégie de pipeline, mais plus encore à cause de la non maîtrise de chaque itération.%%% > %%% > Penchons-nous maintenant sur un cas d’échec Agile.%%% > %%% > Le projet Laddie utilisait une approche Agile avec des itérations de deux semaines. Toutes les user stories étaient répertoriées dans une longue liste et réalisées à la fin de chaque itération (c’était leur stratégie de développement incrémental). À la fin de chaque itération, on montrait au client ce qui avait été construit durant ces deux semaines. Bien entendu, deux semaines étant un délai très court, il n’y avait jamais assez de temps pour montrer au client ce qui avait été conçu et il y avait donc généralement des corrections à apporter.%%% > %%% > Le client avait le choix de retarder la réalisation de nouvelles user stories afin de corriger les erreurs commises, ou bien alors de repousser ces corrections en fin de backlog (c’était leur stratégie de développement itératif – pas très agréable du point de vue du client).%%% > %%% > Le client s’était plaint après un moment qu’il sentait qu’il fallait bien faire les choses dès la première fois puisque les choix qu’ont lui laissaient sur le comment et quand il faudrait corriger les erreurs n’étaient pas très agréables. Ceci, avait-il correctement estimé, violait l’esprit même du développement Agile.%%% > %%% > Terminons avec une histoire heureuse.%%% > %%% > Le projet Winifred était à prix, périmètre et délai fixé, 18 mois avec une pointe à environ 45 personnes. Le cycle de développement était de trois mois, chaque fin de cycle entraînant un déploiement (c’était la stratégie des petits pas).%%% > %%% > Il n’y avait pas de stratégie incrémentale particulière requise au sein de chaque cycle de développement. Les équipes pouvaient développer les fonctionnalités dans l’ordre qu’elles souhaitaient. Par contre, chaque équipe devait montrer ses travaux en cours aux utilisateurs finaux au minimum deux fois par cycle, de sorte que les utilisateurs pouvaient modifier ou corriger ce qui était en cours de construction (ceci était leur stratégie de développement itératif). Cela devait être le logiciel réel, de l’interface utilisateur jusqu’à la base de données, et non de simples maquettes d’écran bouchonnées.%%% > %%% > Typiquement, chaque équipe montrait aux utilisateurs ce qu’ils avaient construit après six semaines de travail et de nouveau après huit semaines de travail. Lors de la première rencontre utilisateur, peut-être 60 à 80% des fonctionnalités étaient complètes. Les utilisateurs avaient le droit de changer quoique ce soit qu’ils n’aimaient pas, y compris,  »je sais que c’est ce que j’ai dit que je voulais, mais maintenant que je le vois, ce n’est pas du tout ce que je veux. »%%% > %%% > À la deuxième rencontre, peut-être 90 à 95% des fonctionnalités étaient complètes, et les utilisateurs avaient seulement le droit de faire corriger des erreurs flagrantes et de demander des petits ajustements. Cela a permis de corriger à la fois les spécifications et les interfaces utilisateurs tout en conservant encore un sens pour un contrat au forfait.%%% > %%% > Le projet Winifred a été déployé avec succès et les utilisateurs ont obtenus plus ou moins ce qu’ils voulaient. Le système est encore utilisé et est encore maintenu dix ans plus tard, ce qui est un bon indicateur de réussite.%%% > %%% > Notez bien que la stratégie combinant itératif et incrémental du projet Winifred respecte le style de l’histoire de la Joconde citée précédemment.%%% > %%% > __Résumé__%%% > %%% > Le terme  »incrément » signifie à la base  »ajouter ».%%% > %%% > Le mot  »itérer » signifie à la base  »refaire ».%%% > %%% > Malheureusement, le  »développement itératif » renvoie aujourd’hui aussi bien à incrémental que itératif, sans ne faire aucune différence. C’est malheureusement regrettable pour notre industrie logicielle puisque chacun a un objectif différent et doit être géré différemment.%%% > %%% > Le développement incrémental vous donne la possibilité d’améliorer votre processus de développement, ainsi que d’ajuster les exigences à l’évolution de l’environnement.%%% > %%% > Le développement itératif vous aide à améliorer la qualité de votre produit. Oui, cela veut dire remanier (~rework), et oui, vous aurez probablement besoin d’en faire un peu pour obtenir un produit propre.%%% > %%% > Le processus de développement, les fonctionnalités et la qualité du produit ont besoin d’être constamment améliorés. Utilisez une stratégie incrémentale, après réflexion, afin d’améliorer les deux premiers axes. Utilisez une stratégie itérative, après réflexion, afin d’améliorer le troisième axe.%%%

XP, l’essentiel : Carte, Conversation, Confirmation

((/dotclear/public/photos/ron_jeffries.gif|Ron Jeffries|L|Ron Jeffries))Un récent billet de Jean Claude Grosjean sur son blog QualityStreet, ++[« Des User Stories … de qualité »|http://www.qualitystreet.fr/2008/08/25/des-user-stories-de-qualite/|fr]++, m’a fait rebondir sur les __3Cs__ et donc sur le très intéressant article de Ron Jeffries ++[« Essential XP: Card, Conversation, Confirmation »|http://xprogramming.com/xpmag/expCardConversationConfirmation|en]++ du 30 août 2001.%%% %%% Ça m’a intéressé de le traduire pour deux raisons :%%% – je me suis rappelé la remarque de mon collègue Jean-François M. qui s’étonnait du caractère très (très) light des spécifications sous forme de post-its…%%% – je souhaitais constater par moi-même le caractère ++précurseur++ de XP,  »tel le prophète annonçant l’arrivée de Scrum »… mais je m’égare, et si je continue je m’expose à des critiques au vitriol de la part de certains membres de la communauté: ça tombe bien, il y en a un qui s’appelle  »Jean-Baptiste » :-)%%% >  »Le Cycle de Vie XP permet de garder en vie des projets. Un élément clé de ce cycle est le Test d’Acceptation. Les Tests d’Acceptation sont essentiels pour maintenir la communication entre les membres de l’équipe, en particulier entre le client et le développeur. »%%% > %%% > Dans le livre  »Extreme Programming Installed », nous décrivons les quatre éléments du Cycle de Vie XP : le client sur site, travaillant avec les développeurs, utilise le planning game pour sélectionner des user stories afin d’élaborer des versions de petites tailles présentant le maximum de valeur ajoutée. Les user stories constituent le point critique de ce cycle.%%% > %%% > Les user stories présentent trois caractéristiques essentielles, que nous pouvons appeler Carte, Conversation et Confirmation.%%% > %%% > __Carte__%%% > %%% > Les user stories sont écrites sur des cartes. La carte ne contient pas toutes les informations qui constituent l’exigence. Par contre, la carte a tout juste assez de texte pour identifier le besoin, et pour rappeler à tous ce que la story raconte. La carte est un signe représentatif de cette exigence. Elle est utilisée dans la planification. Des notes sont écrites sur la carte pour retranscrire la priorité et le coût. La carte est souvent remise aux développeurs une fois la mise en œuvre de la story planifiée, et redonnée au client une fois qu’elle est terminée.%%% > %%% > __Conversation__%%% > %%% > L’exigence elle-même est communiquée du client vers les développeurs à travers une conversation : un  »échange » de pensées, d’opinions et de sentiments. Cette conversation a lieu au fil du temps, essentiellement lorsque la story est estimée (généralement pendant la planification de la version), et de nouveau lors de la réunion de planification de l’itération lorsque la story est planifiée pour être implémentée. La conversation est essentiellement orale, mais est souvent complétée par des documents. Vous verrez souvent des feuilles de calcul, des dessins d’écran et même des documents ressemblant aux classiques spécifications. Encouragez la discussion quand cela fonctionne, mais notez tous les détails sur format papier ou numérique.%%% > %%% > __Confirmation__%%% > %%% > Peu importe combien de discussions nous avons ou combien de documents nous produisons, nous ne pouvons jamais être suffisamment sûr de ce qui doit être fait. Le troisième C des caractéristiques essentielles de la user story apporte la confirmation dont nous avons cruellement besoin. Il s’agit du test d’acceptation.%%% > %%% > Au début de l’itération, le client communique aux développeurs ce qu’il souhaite, en leur racontant comment il va confirmer qu’ils ont fait ce qui est nécessaire. Il définit les tests d’acceptation qui seront utilisés pour montrer que la story a été mise en œuvre correctement.%%% > %%% > Les développeurs implémentent la user story, et mettent également en œuvre les tests d’acceptation. Certaines équipes construisent des outils qui permettent au client de saisir leurs tests par eux-mêmes, et d’autres équipes ont des personnes de la recette ou des testeurs qui les aident dans ce travail. Mais d’une manière ou d’une autre, les tests d’acceptation sont faits.%%% > %%% > À la fin de l’itération, les développeurs démontrent au client que la story est bien terminée, confirmant le succès en montrant que les tests d’acceptation s’exécutent correctement.%%% > %%% > La confirmation fournie par le test d’acceptation est ce qui rend possible l’approche simple de la carte et la conversation. Lorsque la conversation sur une carte descend jusqu’au niveau du test d’acceptation, le client et le développeur règlent ensemble les derniers détails de ce qui doit être fait. Lorsque l’itération est terminée et que les développeurs démontrent la bonne exécution des tests d’acceptation, le client constate que l’équipe peut, et va, livrer ce qu’il faut. La confirmation, en termes de tests d’acceptation, c’est ce qui permet au Cycle de Vie de fonctionner. Et le Cycle de Vie … c’est ce qui maintient votre projet en vie.%%%

Utilisez une Horloge à 1 seule Aiguille pour Communiquer les Objectifs du Projet

[((/dotclear/public/./.Mike_Cohn_sq.jpg|Mike Cohn|L|Mike Cohn))|/dotclear/public/Mike_Cohn.jpg]J’ai découvert ce concept introduit par ++[Mike Cohn|http://blog.mountaingoatsoftware.com/using-a-one-handed-clock-to-convey-project-goals|en]++ lors de la conférence « Contractualisation Agile » de Frédéric Faure à l’++[Agile Tour 2009 à Bordeaux|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/11/02/Retrospective-de-l-Agile-Tour-2009-Bordeaux-suite-et-fin|fr]++. J’en ai donc profité pour traduire l’article original.%%% > Le « triangle d’acier » est une manière, acceptée depuis longtemps, de parler des quatre paramètres de la réussite d’un projet. Dans le triangle d’acier, le périmètre, le délai et le budget prennent chacun un côté du triangle. La qualité est placée au milieu en partant du principe que nous ne plaisantons pas avec la qualité. Nous pouvons, cependant, adapter les côtés. Parfois, le chef de projet, le ScrumMaster ou le coach dit au product owner ou au stakeholder : « Prenez deux côtés, n’importe lesquels, mais je souhaite ajuster le troisième ». Parfois, on dit au client : « vous ne pouvez verrouiller que l’un des côtés ».%%% > %%% > J’ai récemment décidé qu’il y avait une meilleure façon de communiquer que le triangle d’acier. J’utilise l’Horloge-à-1-seule-Aiguille-pour-Communiquer-les-Objectifs-du-Projet.%%% > %%% > Pour utiliser l’horloge à 1 seule aiguille, positionnez le Périmètre, le Délai et le Budget respectivement à douze heures, quatre heures et huit heures. Peu importe qui est positionné à quel emplacement, mais moi je les positionne comme le montre la figure ci-dessous. La qualité est à nouveau supposée fixe et n’est pas affichée sur l’horloge.%%% > %%% > ((/dotclear/public/traductions/NoHands.png|Pas d’aiguille||Pas d’aiguille))%%% > %%% > Ensuite, demandez au product owner ou à un stakeholder de positionner l’aiguille au meilleur endroit indiquant les objectifs du projet. L’aiguille peut par exemple être directement positionnée sur le Délai. Cela indiquerait que le Délai constitue l’objectif le plus important et que le Périmètre et le Budget viennent ensuite.%%% > %%% > ((/dotclear/public/traductions/1HandedClock-A1.png|Horloge à Unique Aguille – A1||Horloge à Unique Aguille – A1))%%% > %%% > Ou peut-être que l’aiguille est positionnée entre le Périmètre et le Délai montrant que les deux sont importants.%%% > %%% > ((/dotclear/public/traductions/1HandedClock-B.png|Horloge à Unique Aiguille – B||Horloge à Unique Aiguille – B))%%% > %%% > Pour voir comment cette Horloge à 1 seule Aiguille des Objectifs du Projet fonctionne, prenez un moment pour réfléchir. Vous pouvez positionner l’aiguille n’importe où entre deux des trois objectifs, mais un objectif est toujours écarté. Si l’on fait l’analogie avec le triangle d’acier, c’est le côté qui est flexible.%%% > %%% > Il y a beaucoup de choses que j’aime dans cette nouvelle façon de visualiser l’importance relative du Périmètre, du Délai et du Budget. Je vais en citer deux :%%% > %%% > – L’Horloge à 1 seule Aiguille permet aux stakeholders ou aux product owners de transmettre une position plus précisément qu’en disant quelque chose comme « Je choisis le Délai et le Budget ». La capacité à positionner précisément l’aiguille plutôt que d’en parler est essentiel.%%% > – L’Horloge à 1 seule Aiguille est une métaphore visuelle utile qui peut être affichée dans le bureau de l’équipe. Le triangle d’acier n’est vraiment pas visuel sur ce point puisqu’il est difficile de transmettre quels côtés ont été choisis autrement qu’en les assombrissant…%%% > %%% > Essayez cette horloge et dites-moi ce que vous en pensez. Les équipes et les product owners à qui je l’ai présentée jusqu’à ce jour l’ont trouvée très utile. Je suppose que cela sera aussi le cas pour vous. Dites-moi aussi si vous utilisez cette horloge à 1 seule aiguille pour autre chose car c’est un moyen de visualisation utile dès que l’on gère trois paramètres qui rentrent en concurrence.%%% %%% Personnellement, j’ai renommé le « triangle d’acier » en « triangle des bermudes », avec au centre le client perdu au milieu des objectifs de délai, périmètre et budget 🙂

Les 7 caractéristiques d’un code simple (KISS)

((/dotclear/public/programmation.gif|Programmation|L|Programmation, aoû 2009))J’ai traduit un article intéressant de Alberto Gutierrez : ++[« The 7 characteristics of simple code (KISS) »|http://www.makinggoodsoftware.com/2009/10/30/the-7-characteristics-of-simple-code-kiss/|en]++%%% %%% > J’avais l’habitude de croire que la qualité la plus importante d’un code était son extensibilité (~ajouter de nouvelles fonctionnalités). Le code a dû être préparé aux futurs changements donc j’ai codé beaucoup de choses qui ne sont pas tout de suite nécessaires. Mais après avoir réalisé que je n’avais jamais bien deviné les changements à venir, et après avoir eu pas mal de cauchemars lors des maintenances et des passages de connaissance, il y a quelques années j’ai finalement décidé que je prendrai la démarche inverse de ce qui est sensé être un bon code. Depuis que je l’ai fait, je suis chaque jour plus convaincu que la principale caractéristique d’un bon code est sa simplicité. Un code simple est facile à lire et facile à changer. Et parce qu’il est simple, il est le moins susceptible d’avoir des bogues (plus l’algorithme que vous créez est complexe, plus les changements peuvent générer des erreurs).%%% > %%% > Lorsque vous codez, je vous recommande de vérifier chaque fois si votre code est resté simple, et n’oubliez pas : « il n’y a pas de problèmes difficiles, seulement les solutions ».%%% > %%% > __Les sept caractéristiques principales d’un code simple sont :__%%% > %%% > __1. Facile à lire__%%% > %%% > Un code simple n’a pas besoin de documentation supplémentaire, ou alors d’un minimum de documentation pour être compris.%%% > %%% > __2. Facile à utiliser__%%% > %%% > Celui qui utilise votre code considère intuitif d’utiliser vos objets.%%% > %%% > __3. Facile à changer__%%% > %%% > Simplicité veut dire qu’il n’y a pas de logique redondante. Un changement doit correspondre à un seul endroit dans votre code.%%% > %%% > __4. N’utilise aucun outil ou technologie qui ne soit nécessaire__%%% > %%% > D’après mon expérience, j’ai constaté combien certains développeurs adoraient utiliser les technologies, outils et frameworks pour le simple plaisir de rendre le projet plus « cool ». Chaque fois que vous les utilisez, vous ajoutez de la complexité, et de la complexité supplémentaire signifie que c’est plus difficile à comprendre, à maintenir et que c’est davantage vulnérable aux défaillances.%%% > %%% > __5. Ça a l’air simple__%%% > %%% > Si cela n’a pas l’air simple, alors ce n’est pas simple ! Vous savez que votre code est simple si, quand vous avez fini, vous êtes étonné de constater la simplicité de la solution finale et vous vous demandez pourquoi cela vous a pris si longtemps.%%% > %%% > __6. Lean__%%% > %%% > Il ne fait que ce qui est nécessaire, et rien d’autre. Je pense que les développeurs les plus expérimentés seraient d’accord pour dire que tenter d’anticiper les problèmes auxquels votre code devra faire face dans l’avenir est impossible.%%% > %%% > __7. C’est direct__%%% > %%% > Il n’a pas d’indirections inutiles. Les opérations les plus importantes nécessitent seulement un appel direct à une méthode.%%% > %%% > __Comment pouvons-nous développer un code simple ?__%%% > %%% > La clé de la production d’un code simple est de le remanier (~refactoring) continuellement, et la seule façon de le faire est de le tester continuellement.%%% > %%% > Vous allez avoir besoin de le remanier parce qu’à chaque fois que vous allez ajouter une nouvelle ligne dans votre algorithme, vous allez probablement le rendre plus complexe. A partir de maintenant, à chaque fois, vous devez le remanier pour le ramener à un juste niveau de simplicité.%%% > %%% > Vous avez besoin de nombreux tests parce que vous le remaniez constamment et que, si vous n’avez pas un filet de sécurité, vous introduisez des bogues dans votre système.%%%

ScruML

[((/dotclear/public/photos/.HenrikKniberg_t.jpg|Henrik Kniberg|L|Henrik Kniberg))|/dotclear/public/photos/HenrikKniberg.jpg]Je vous ai traduit un billet intéressant écrit par Henrik Kniberg le 25 août 2007 sur son blog : ++[ScruML|http://blog.crisp.se/henrikkniberg/2007/08/25/1187995980000.html|en]++.%%% %%% Cet article permet de mieux comprendre l’évolution du modèle d’organisation Scrum décrit par Henrik dans un de ces autres articles que j’ai déjà traduit : ++[« Rôle des Managers En Scrum »|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/06/01/Managers-Role-In-Scrum|fr]++. %%% > Le monde n’a-t-il pas besoin d’un autre langage de modélisation ? :)%%% > %%% > __ScruML__ signifie « __Scru__m __M__odelling __L__anguage ». Comme UML, mais spécifique à un domaine et non pas aussi stricte et … euh …finalement peut être pas tant que ça comme UML, après tout.%%% > %%% > ScruML est utilisé pour visualiser une organisation Scrum d’une manière si simple que même les managers vont comprendre. Il se concentre uniquement sur les éléments propres à Scrum (les Product Owners, les Équipes et qui fournit à qui), ce n’est donc pas une cartographie complète de l’organisation. C’est un outil qui peut aider une entreprise à essayer de comprendre comment mettre en œuvre Scrum dans son contexte particulier.%%% > %%% > A quoi ressemble une organisation dans sa première étape ? Et à la deuxième étape ? Quelles sont les équipes existantes ? Quelles sont les équipes qui ont besoin de se synchroniser avec les autres ? Quelle partie prenante (~stakeholders) alimente quelle product backlog ? Quels product backlog alimentent quelles équipes? Si il y a plusieurs product owners, qui doit résoudre les conflits de priorité entre eux ? Quelle est la définition de terminé ? Combien de temps durent les sprints? et ainsi de suite. Tout dans un seul dessin, simple et beau.%%% > %%% > __NOTE AUX LECTEURS SENSIBLES :__ Certains des diagrammes ci-dessous montrent des organisations Scrum qui ne sont pas optimales, y compris des choses terribles comme les transferts de responsabilités à l’équipe de recette (~QA). J’ai entendu dire que de telles organisations existaient réellement sur le terrain ;-)%%% > %%% > Vous semblez être une personne intelligente et impatiente de sorte que, au lieu d’écrire de fastidieuses spécifications, je vais donner 3 exemples et vous laisser comprendre les détails vous-même.%%% > %%% > __Exemple 1 : Une seule équipe__ (ou Hello World)%%% > %%% > ((/dotclear/public/traductions/ScruML1.jpg|Une seule équipe (ou Hello World)||Une seule équipe (ou Hello World)))%%% > %%% > Ce diagramme montre les choses suivantes :%%% > – Nous avons une équipe composée de 5 membres, avec ++[Reza Farhang|http://www.crisp.se/reza.farhang|en]++ (RF) en tant que ScrumMaster.%%% > – Il n’y a qu’un seul product owner (bonhomme en fil de fer) et un seul product backlog.%%% > – Le product backlog est essentiellement alimenté par des demandes provenant directement des utilisateurs finaux.%%% > – La définition de terminé est « livré à l’utilisateur final ».%%% > – La longueur d’un sprint est de 2 semaines (~2weeks).%%% > %%% > %%% > __Exemple 2 : Plusieurs équipes__%%% > %%% > ((/dotclear/public/traductions/ScruML2.JPG|Plusieurs équipes||Plusieurs équipes))%%% > %%% > Ce diagramme montre les choses suivantes :%%% > %%% > – Nous avons deux équipes qui travaillent sur le même product backlog.%%% > – La définition de fait est « livré à l’exploitation » (qui à son tour peut déployer tout de suite ou plus tard).%%% > – L’équipe 1 fait des sprints de 2 semaines, L’équipe 2 fait des sprints de 4 semaines.%%% > – Les équipes ont besoin de synchroniser leurs travaux grâce à un Scrum de Scrums (la ligne en pointillée), mais ils livrent à l’Exploitation de façon indépendante. Il n’y a pas d’étape d’intégration.%%% > – Le product backlog est essentiellement alimenté par les commerciaux, les managers, les bêta testeurs et le support.%%% > %%% > %%% > __Exemple 3 : Plusieurs équipes & plusieurs product owners__%%% > %%% > ((/dotclear/public/traductions/ScruML3.JPG|Plusieurs équipes & plusieurs product owners||Plusieurs équipes & plusieurs product owners))%%% > %%% > Ce diagramme montre les choses suivantes :%%% > %%% > – Nous avons 2 product owners et 2 product backlogs (JM et LJ).%%% > – Le product backlog de LJ est alimenté par le support aux utilisateurs.%%% > Le product backlog de JM est essentiellement alimenté par les responsables produits, mais les demandes des autres intervenants se retrouvent là aussi.%%% > – L’équipe 1 et l’équipe 2 sont alimentés par le product backlog de JM, et font toutes les deux des sprints de 3 semaines.%%% > – – > Leur définition de terminé est « intégré et livré à la recette », c’est-à-dire que l’équipe 1 et l’équipe 2 intégrent leurs travaux en une seule release avant de la passer à l’équipe de recette.%%% > – L’équipe 3 est alimenté par le product backlog de LJ, elle fait des sprints de 1 semaine. Elle travaille essentiellement pour le support aux utilisateurs.%%% > – – > Sa définition de terminé est « prêt à déployer ». Elle n’a pas besoin de passer par une étape distincte de recette.%%% > – Les trois équipes ont des dépendances, et se synchronisent donc par le biais de scrum of scrums.%%% > – Si JM et LJ rencontrent des conflits de ressources (par exemple, qui reçoit les nouvelles recrues ou bénéficie d’une super plate-forme), le conflit est résolu par AS.%%% > %%% > Le fait de passer par la recette n’est pas très agile, La version propre de ce schéma est la suivante :%%% > %%% > ((/dotclear/public/traductions/ScruML4.JPG|Utilisateurs finaux||Utilisateurs finaux))%%% > %%% > N’hésitez pas à ajouter d’autres éléments dont vous auriez besoin. Rappelez-vous juste que l’ajout d’un trop grand nombre de nouveaux éléments rendra rapidement le diagramme illisible…%%%

Rétrospective de l’Agile Tour 2009 Bordeaux … suite et fin

((/dotclear/public/logos/.imagine_an_agile_world_m.jpg|Imagine an agile world !||Imagine an agile world !))%%% Je ++[termine|/dotclear/index.php?post/2009/11/01/Retrospective-de-la-conference-SUG-AT-2009-Bordeaux]++ ici ma rétrospective de l’Agile Tour 2009 à Bordeaux.%%% %%% __What Went Well__%%% %%% – 150 inscrits, c’est pas mal !%%% – Lors de sa conférence « Contractualisation agile », Frédéric Faure a introduit des concepts intéressants : le cercle ou plutôt ++[l’horloge « Scope-Budget-Schedule » de Mike Cohn|http://blog.mountaingoatsoftware.com/using-a-one-handed-clock-to-convey-project-goals|en]++ qui s’oppose au traditionnel triangle d’acier des projets informatiques, les clauses contractuelles  »Money for Nothing » (arrêt des développements) et  »Change for Free » (changement des priorités). Il a également bien voulu partager ses ++[bookmarks|http://delicious.com/ffaure32/contract|fr]++ sur le sujet : merci.%%% – Un making-off très sympa lors du discours de clôture des organisateurs : vous avez bien bossé, bravo !%%% %%% __What Went Wrong__%%% %%% – Je me suis pointé avec 20 minutes de retard à la conférence de Samir sur « Scrum » : mea culpassima.%%% – Plantage du portable de Frédéric et un bel écran bleu pendant plus d’un quart d’heure. Frédéric a fait preuve d’agilité.%%% – J’ai fait des photos pourraves avec mon vieux Canon Digital Ixus V3 ! va falloir que j’investisse dans du nouveau matériel…%%% %%% __Puzzles__%%% %%% – Laurent m’a parlé d’une conférence étonnante lors de l’++[Université du SI|http://www.linkedin.com/pub/vincent-lextrait/0/758/211|fr]++ 2008 organisée par ++[Octo Technology|http://www.octo.com/|fr]++ : « Du manufacturing au mindfacturing, ou pourquoi se détourner de la spécialisation ». Cette présentation de ++[Vincent Lextrait|http://www.linkedin.com/pub/vincent-lextrait/0/758/211|en]++ démontrerait pourquoi les méthodes industriels d’organisation du travail s’appliquent très mal aux projets informatiques. J’ose le parallèle avec un billet de Yannick Martel qui vient de paraître (3-Nov-09) sur le blog de Octo Technology : ++[« Devons-nous changer de paradigme pour le développement d’applications informatiques? »|http://blog.octo.com/devons-nous-changer-de-paradigme-pour-le-developpement-d%e2%80%99applications-informatiques/|fr]++%%% – Julie m’a dit que Jean-Baptiste rêvait d’aller au Japon mais on n’a pas eu le temps de se voir pour parler de mon voyage (pour patienter, je vous renvoie sur ma ++[rétro.|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/10/19/Retrospective-de-mon-sejour-au-Japon|fr]++).%%% %%% __Lessons (re-)Learnt__%%% %%% – Customer collaboration over contract negotiation (++[Manifesto for Agile Software Development|http://agilemanifesto.org/|en]++).%%% – Le triangle d’acier « Périmètre-Budget-Délai » avec la Qualité au centre. En fait, le Contrat vient « écraser » la Qualité.%%% – Au démarrage d’un projet, le risque est maximal : erreur de périmètre, erreur d’estimation, …%%% – L’erreur est humaine, ne la refusons pas.%%% – Arrêtons d’appeler les individus des ressources !%%% %%% __Appreciations__%%% %%% ++[ROTI|http://www.stevenmsmith.com/content/view/38/72/|en]++ des différentes conférences auxquelles j’ai assisté :%%% %%% ((/dotclear/public/et_rouge.gif|et_rouge|L|et_rouge))((/dotclear/public/et_rouge.gif|et_rouge|L|et_rouge))((/dotclear/public/et_rouge.gif|et_rouge|L|et_rouge))((/dotclear/public/et_rouge.gif|et_rouge|L|et_rouge))++[Scrum User Group bordelais|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/11/01/Retrospective-de-la-conference-SUG-AT-2009-Bordeaux|fr]++%%% %%% ((/dotclear/public/et_rouge.gif|et_rouge|L|et_rouge))((/dotclear/public/et_rouge.gif|et_rouge|L|et_rouge))((/dotclear/public/et_rouge.gif|et_rouge|L|et_rouge))((/dotclear/public/et_demi.gif|et_demi|L|et_demi))++[Introduction du Lean dans le développement de la webTV d’Orange|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/10/31/Retrospective-de-la-conference-Introduction-du-Lean-AT-2009-Bordeaux|fr]++%%% %%% ((/dotclear/public/et_rouge.gif|et_rouge|L|et_rouge))((/dotclear/public/et_rouge.gif|et_rouge|L|et_rouge))((/dotclear/public/et_rouge.gif|et_rouge|L|et_rouge))((/dotclear/public/et_demi.gif|et_demi|L|et_demi))++[XP|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/10/26/Retrospective-de-l-Agile-Tour-Bordeaux-2009|fr]++%%% %%% ((/dotclear/public/et_rouge.gif|et_rouge|L|et_rouge))((/dotclear/public/et_rouge.gif|et_rouge|L|et_rouge))((/dotclear/public/et_grise.gif|et_grise|L|et_grise))((/dotclear/public/et_grise.gif|et_grise|L|et_grise))Contractualisation agile%%% %%% ((/dotclear/public/et_rouge.gif|et_rouge|L|et_rouge))((/dotclear/public/et_grise.gif|et_grise|L|et_grise))((/dotclear/public/et_grise.gif|et_grise|L|et_grise))((/dotclear/public/et_grise.gif|et_grise|L|et_grise))Scrum%%% %%% ((/dotclear/public/applaudir.gif|Bravo !!!|L|Bravo !!!))- Merci au ++[LaBRI|http://www.labri.fr/|fr]++ qui accueillait l’Agile Tour dans ses locaux%%% – Merci aux sponsors locaux ++[Equitalis|http://www.equitalis.fr/|fr]++, ++[Axialog|http://www.axialog.com/agences/detail.php?ag=bordeaux|fr]++ et ++[AKKA Technologies|http://www.akka.fr/|fr]++%%% – Merci aux organisateurs de l’Agile Tour Bordeaux 2009 : Charles Couillard (Arpinum), Colin Garriga-Salaün (Indépendant/association ++[Okiwi|http://www.okiwi.org/|fr]++), Frédéric Faure (++[Equitalis|http://www.equitalis.fr/|fr]++), Jean-Baptiste Dusseaut (Arpinum), Julie Chozenon (++[Axialog|http://www.axialog.com/agences/detail.php?ag=bordeaux|fr]++), Michael Borde (++[AKKA Technologies|http://www.akka.fr/|fr]++), Samir Hanna (++[Capgemini|http://www.fr.capgemini.com/|fr]++/association ++[Okiwi|http://www.okiwi.org/|fr]++)%%% – Merci à tous les orateurs%%% – Merci à Ivan S., Laurent P., Steeve L., François B., Philippe C., Étienne D., Fabrice A., Alexandre G., …%%% – Finalement, ma société a annulé le RTT employeur que j’avais posé ! Beau geste, merci :)%%% %%% __Feedbacks__%%% %%% – Remplissez le ++[Formulaire de satisfaction|http://agiletour.org/satisfaction.html|fr]++ !%%% – Consultez les ++[supports des conférences|http://agiletour.org/fr/at2009_bordeaux_retours.html|fr]++ grâce à la plateforme ++[Excilys|https://www.excilys.com/|fr]++ !%%% – Consultez les ++[vidéos des conférences|http://www.vcasmo.com/tag/Agile%20tour%202009%20bordeaux|fr]++%%% %%% – Rétrospective par ++[Michael Borde|http://michaelborde.blogspot.com/2009/11/le-repos-de-lagiliste-suite-et-fin.html|fr]++%%% – Rétrospective par ++[Laurent Morisseau|http://www.laurentmorisseau.com/2009/11/feed-back-agile-tour-bordeaux.html|fr]++%%% – Rétrospective par Rachel Dubois sur ++[Agilité et Agitation|http://www.racheldubois.fr/?p=334|fr]++%%% – Rétrospective par Jean-Baptiste Dusseaut sur ++[BodySplash|http://bodysplash.fr/post/2009/10/30/Et-voil%C3%A0|fr]++%%% – Rétrospective par Bruno Bord sur ++[Je Hais Le Printemps|http://jehaisleprintemps.net/blog/fr/2009/11/02/agile-tour-bordeaux/|fr]++%%% – Rétrospective par Guillaume Lebur sur ++[InfOsaurus|http://blog.infosaurus.fr/post/2009/10/30/Agile-Tour-2009-Bordeaux|fr]++%%% – Rétrospective par Antoine sur ++[morphogénèse et chocapics|http://morphocapic.blogspot.com/2009/10/agile-tour-bordeaux.html|fr]++%%%

Rétrospective de la conférence « Scrum User Group » (AT 2009 Bordeaux)

[((/dotclear/public/philippe_launay.jpeg|Philippe Launay|L|Philippe Launay))|/dotclear/public/philippe_launay.jpeg]Je ++[continue|/dotclear/index.php?post/2009/10/31/Retrospective-de-la-conference-Introduction-du-Lean-AT-2009-Bordeaux]++ ma rétrospective de l’Agile Tour 2009 à Bordeaux avec la conférence « Scrum User Group ».%%% %%% __What Went Well__%%% %%% – Orateur : Philippe Launay de la société ++[Agfa Healthcare|http://www.agfa.com/france/fr/he/index.jsp|fr]++, correspondant local du ++[French Scrum User Group|http://www.frenchsug.org/|fr]++, Certified Scrum Master, Certified Scrum Product Owner.%%% – Présentation : il s’agit du 3ème SUG bordelais. Une vingtaine de personnes sont présentes, c’est pas mal.%%% – Philippe démarre en me demandant de présenter lors du prochain SUG ma traduction du support de Henrik Kniberg ++[« Le rôle du Manager dans Scrum »|http://www.fabrice-aimetti.fr/dotclear/public/mes-documents/Role-des-Managers-En-Scrum.pdf|fr]++ : argh !%%% – Après un bref rappel des objectifs du SUG et en l’absence de retour d’expérience ratée d’un projet Scrum (comme initialement planifié dans notre ++[backlog|http://groups.google.fr/group/sug-bordeaux/web/liens-utiles?hl=fr|fr]++), Philippe nous a courageusement présenté les différents points qui font que Scrum ne fonctionne pas, d’un point de vue 1° Product Owner, 2° ScrumMaster, 3° Team, 4° Management et 5° Méthode. C’était complet et mine de rien ça a permis de refaire une présentation des principes inaltérables de Scrum.%%% – Puis un debriefing sur le Scrum Gathering 2009 à Munich auquel il a participé du 19 au 21 octobre (++[supports de l’événement|http://www.scrumalliance.org/resources?tag=2009+Munich+gathering|en]++). Zoom sur « Scrum dans le monde réel » : d’autres métiers, en dehors de l’IT, se mettent au Scrum (ex: ++[Scrum in Church|http://jeffsutherland.com/scrum/ScruminChurch.pdf|en]++, ++[Agile Lawyers|http://www.agilelawyersassociation.org/|en]++, …). Le sous-titre du logo de la ++[Scrum Alliance|http://www.scrumalliance.org/|en]++ a même été revu dans ce sens : {{Transforming the world of work}}. D’ailleurs vous pouvez jeter un coup d’œil à ce sondage de Claude Aubry : ++[Scrum en dehors du développement de logiciel|http://www.aubryconseil.com/post/Scrum-en-dehors-du-d%C3%A9veloppement-de-logiciel|fr]++%%% %%% – Le support de présentation est disponible sur le ++[Google Groupes du SUG Bordeaux|http://groups.google.fr/group/sug-bordeaux/files?hl=fr|fr]++.%%% %%% [((/dotclear/public/./.GG_SUG_Bdx_m.jpg|Google Groupes SUG Bordeaux||Google Groupes SUG Bordeaux))|/dotclear/public/GG_SUG_Bdx.PNG] %%% __What Went Wrong__%%% %%% – A terme, le rôle du ScrumMaster devrait s’effacer au profit du Scrum Coach. Sauf qu’il faut justifier d’au minimum 1 année de pratique Scrum pour être ++[Certified Scrum Practitioner|http://www.scrumalliance.org/pages/certified_scrum_practitioner|en]++ et de 5 années de pratique pour être ++[Certified Scrum Coach|http://www.scrumalliance.org/pages/certified_scrum_coach|en]++ : ça fait 6 ans minimum, c’est long…%%% – J’ai fait des photos pourraves avec mon vieux Canon Digital Ixus V3 ! va falloir que j’investisse dans du nouveau matériel…%%% %%% __Puzzles__%%% %%% – Le Scrum Gathering 2010 sera-t-il vraiment maintenu à Paris ?%%% – ++[Doggy Planning|http://blog.tastycupcakes.com/2009/06/doggy-planning/|en]++ pour se familiariser avec le Planning Poker ?%%% %%% __Lessons (re-)Learnt__%%% %%% [((/dotclear/public/logos/.ScrumButt_sq.jpg|ScrumButt verson Canada Dry|L|ScrumButt verson Canada Dry))|/dotclear/public/logos/ScrumButt.png]- ScrumButt = on fait du Scrum mais on garde tous les processus existants (j’en ai fait une version Canada Dry).%%% – Rétrospective = introspection.%%% – Scrum est là pour rendre les choses visibles.%%% %%% __Appreciations__%%% %%% ((/dotclear/public/applaudir.gif|Bravo !!!|L|Bravo !!!))- Merci au ++[LaBRI|http://www.labri.fr/|fr]++ qui accueillait l’Agile Tour dans ses locaux%%% – Merci aux sponsors locaux ++[Equitalis|http://www.equitalis.fr/|fr]++, ++[Axialog|http://www.axialog.com/agences/detail.php?ag=bordeaux|fr]++ et ++[AKKA Technologies|http://www.akka.fr/|fr]++%%% – Merci aux organisateurs de l’Agile Tour Bordeaux 2009 : Charles Couillard (Arpinum), Colin Garriga-Salaün (Indépendant/association ++[Okiwi|http://www.okiwi.org/|fr]++), Frédéric Faure (++[Equitalis|http://www.equitalis.fr/|fr]++), Jean-Baptiste Dusseaut (Arpinum), Julie Chozenon (++[Axialog|http://www.axialog.com/agences/detail.php?ag=bordeaux|fr]++), Michael Borde (++[AKKA Technologies|http://www.akka.fr/|fr]++), Samir Hanna (++[Capgemini|http://www.fr.capgemini.com/|fr]++/association ++[Okiwi|http://www.okiwi.org/|fr]++)%%% – Merci à tous les orateurs%%% – Merci à Ivan S., Laurent P., Steeve L., François B., Philippe C., Étienne D., Fabrice A., Alexandre G., …%%% – Finalement, ma société a annulé le RTT employeur que j’avais posé ! Beau geste, merci :)%%%