French Scrum User Group Bordelais : le site est en ligne !

> Le SUG Bordelais est un espace de rencontre et de partage autour de SCRUM et des méthodes Agiles. Il offre à toutes les personnes désirant échanger, partager autour des méthodes Agiles un support pour se rencontrer, discuter, partager ses expériences afin de continuer de progresser sur le chemin de l’Agilité…%%% > %%% > __++[Philippe Launay|http://sites.google.com/site/sugbordeaux/the-team]++__, correspondant local du French Scrum User group pour Bordeaux%%% C’est le message d’accueil que vous trouverez sur ++[le nouveau site du SUG Bordeaux|http://sites.google.com/site/sugbordeaux/]++ :%%% %%% ((/dotclear/public/screenshots/SUGBDX.jpg|Le nouveau site du SUG Bordeaux est en ligne|C|Le nouveau site du SUG Bordeaux est en ligne))%%% %%% * __Visitez le site :__ explorez la barre de navigation qui est très bien faite et qui vous permettra notamment d’accéder aux ++[ressources|http://sites.google.com/site/sugbordeaux/file-cabinet]++ disponibles depuis la naissance du groupe, le 11 juin 2009.%%% * __Rejoignez-nous :__ le forum de discussion est bien sûr toujours actif et des Scrum’Café sont régulièrement animées chez des sponsors locaux (++[inscrivez-vous|http://www.meetup.com/frenchsug/calendar/14992095/]++ pour le prochain qui a lieu le 9 novembre à 18h chez ++[Galilée|http://www.galilee.fr/plan-dacces-bordeaux-lormont-gironde.html]++ à Lormont).%%% * __Parlez-en autour de vous :__ pour vous mettre en appétit, vous pourrez trouver mes rétrospectives des sessions passées ++[ici|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/retrospective:start]++.%%%

Manabé Shima

[((/dotclear/public/lectures/.manabe-shima_t.jpg|Manabé Shima|L|Manabé Shima))|/dotclear/public/lectures/manabe-shima.gif]Le Japon est tellement une île qu’il est un archipel. Dans le catalogue japonais, on trouve des îles industrielles, des îles musées, des îles formol, des îles atoll, des îles musées, des îles bleu-vert, des îles sauvages, des îles sans âge, des îles connues, Shikoku, et même des îles où l’on pêche et l’on boit. Parmi ces miettes de terre, il y a Manabeshima, une île dont on parle peu, mais où poussent très bien les poissons.%%% %%% Après son premier carnet de voyages intitulé ++[« Tokyo Sanpo »|/dotclear/index.php?post/2010/02/14/Tokyo-Sanpo]++, Florent Chavouet remet ça, et c’est toujours aussi drôle et magnifiquement dessiné !%%% %%% ++[Blog de l’auteur|http://florentchavouet.blogspot.com/|fr]++

Rétrospective de l’Agile Tour 2010 Toulouse

((/dotclear/public/skatt/at2010speaker.jpg|Orateur à l’Agile Tour 2010 Toulouse||Orateur à l’Agile Tour 2010 Toulouse))((/dotclear/public/skatt/at2010sponsor-atosorigin.jpg|Atos Origin sponsor de l’Agile Tour 2010 Toulouse||Atos Origin sponsor de l’Agile Tour 2010 Toulouse))%%% !!!What went well%%% * J’ai commencé par la session de __Alexandre Boutin__ (++[Agilex|http://www.agilex.fr/]++ sur la blogosphère) avec __ »La fable du PO et du MOA »__. Avec des retours d’expérience très intéressants, le Bout(e-en-tra)in a revisité les fables de Jean de La Fontaine :%%% ** La mouche et la fourmi ou… comment définir le besoin ?%%% ** Le combat des rats et des belettes ou… comment commencer ?%%% ** Contre ceux qui ont le goût difficile ou… comment impliquer le business ?%%% ** L’hirondelle et les petits oiseaux ou… comment engager l’équipe ?%%% ** Le corbeau et le renard ou… comment éviter les conflits ?%%% ** Le loup plaidant contre le renard par devant le singe ou… comment dire ce que je pense ?%%% ** L’âne chargé d’éponges et l’âne chargé de sel ou… comment planifier ?%%% ** Le petit poisson et le pêcheur ou… comment livrer à temps ?%%% ** Le coche et la mouche ou… comment être efficace ?%%% ** Le bûcheron et Mercure ou… comment gérer mon reporting ?%%% ** Le milan et le rossignol ou… comment intégrer les feedbacks ?%%% ** Le renard et le bouc ou… comment faire les UAT ?%%% ** Le fou qui vend la sagesse ou… suis-je devenu un PO ?%%% ** L’ours et les deux compagnons… attention ! l’Agile n’est pas facile !%%% * J’ai continué avec la session de __Pascal Fortin__ __ »Agilité & Logiciel critique »__. J’avais déjà croisé Pascal lors de l’évènement ++[« Embarquez Agile ! »|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2010/03/18/Retrospective-Embarquez-Agile-le-18-mars]++ organisé par Aerospace Valley en mars dernier à Bordeaux. Ben c’est toujours aussi intéressant : il nous fait un bilan de plusieurs années d’expérimentation autour de XP, Scrum et Lean. Par contre il faudrait vraiment qu’il rende ses slides plus visuels, il y a beaucoup trop de texte… alors qu’il a un ++[super dessinateur|http://picasaweb.google.com/emmanuel.chenu/Scrum#]++ à portée de la main dans ses équipes ! J’ai bien aimé la conclusion sous forme de 3 questions non répondues à ce jour :%%% ** Comment faire l’estimation initiale avant le début du projet ?%%% ** Abandonner la contractualisation coté client : comment avoir suffisamment confiance ?%%% ** Il ne suffit pas de se déclarer agile pour l’être : c’est quoi être agile ? quel est le minimum ?%%% * J’ai terminé la matinée avec la session de __Jean-Michel Inglebert__ __ »(Enseigner les) Atouts et faiblesses des approches agiles : une présentation Scrum »__ qui est prof. à l’IUT de Blagnac. Je qualifierais la présentation de courageuse avec des concepts abordés intéressants :%%% ** Équilibre programme de tests / programme testé : apporte de la confiance au programmeur qui l’a construit > apporte de la confiance au programmeur qui l’utilise > on gagne en fonctionnement interne > donc on gagne en relations humaines dans l’équipe%%% ** complexité = combinatoire des états possibles d’un système%%% ** confiance = processus statistique de réduction de la complexité ; pas symétrique puisqu’on l’instaure en quelques mois au minimum et on la perd en quelques minutes !%%% ** cycle zéro = il faut les meilleurs à l’estimation 0 !%%% * J’ai repris en début d’après-midi avec la session de __Thierry Cros__ (et Angèle Batanero) __ »XP : le projet social »__. Bon, j’avais déjà parlé sur mon blog de cet ++[être agile|http://etreagile.thierrycros.net/]++ qu’est Thierry… mais sa foi dans l’humain m’a encore une fois laissé pantois… il est persuadé que nous ne sommes pas pourris à la base et que l’on doit prendre conscience que la clé c’est la solidarité ! ça y est, j’ai encore fait une rechute, à chaque fois je reprends une leçon d’humanité et d’humilité !%%% * J’ai terminé l’après-midi avec la session de __Claude Aubry__ (que je ne présente plus, allez ++[ici|http://www.google.fr/search?hl=fr&rlz=1C1SKPH_enFR393FR393&q=claude+aubry+scrum&aq=f&aqi=g1&aql=&oq=&gs_rfai=]++), __Antoine Vernois__ (++[Son blog à lui qu’il a|http://antoine.vernois.net/dotclear/]++) et moi-même : __ »Kanban et Scrum : tirer le meilleur des 2″__. Rachel Dubois – little theatre oblige – nous a fait le plaisir d’annoncer la pièce de théâtre que nous avons jouée devant le public : Kanban (moi) et Scrum (Antoine) se chamaille puis Scrumban (Claude) les réconcilie… et j’ai pris mon pied ! Nous avons fièrement arboré nos T-shirts pour incarner les personnages (le  »trio infernal » comme dirait Olivier) :%%% [((/dotclear/public/skatt/.skatt2010_m.jpg|Kanban et Scrum : tirer le meilleur des 2||Kanban et Scrum : tirer le meilleur des 2))|/dotclear/public/skatt/skatt2010.jpg]%%% * Les ++[Arpinum|http://www.arpinum.fr/]++ étaient là (Michael B., Charles C. et Jean-Baptiste D.)%%% * J’ai fait la bise à Rachel D., c’était un des objectifs que je m’étais fixé pour cette journée, je l’ai atteint (et même touché).%%% * C’est avec un grand plaisir que j’ai recroisé Delphine B. qui était à l’époque stagiaire commerciale dans ma société. Delphine avait laissé une très (très) bonne impression aux collaborateurs bordelais.%%% !!!What went wrong%%% * KFC (Kentucky Fried Chicken) à midi : bof !%%% * Je dois prendre des cours de rugby…%%% * J’ai fait des photos pourries… faut aussi que je prenne des cours de photographie !%%% !!!Puzzles%%% * Blitz Planning par ++[Alistair Cockburn|http://alistair.cockburn.us/Blitz+Planning|en]++ ?%%% * ++[Pi-calcul|http://fr.wikipedia.org/wiki/Pi-calcul]++ ? ++[Erlang|http://fr.wikipedia.org/wiki/Erlang_(langage)]++ ? ++[CouchDB|http://couchdb.apache.org/|en]++ ?%%% * 10’Building ? cf. ++[« Continuous Integration »|http://www.martinfowler.com/articles/continuousIntegration.html|en]++%%% * ++[Principe de Dilbert|http://fr.wikipedia.org/wiki/Principe_de_Dilbert]++ qui aggrave le principe de Peter ?%%% * Go & See => ++[Genshi Genbutsu|http://en.wikipedia.org/wiki/Genchi_Genbutsu|en]++ ?%%% * ++[AMAP|http://www.reseau-amap.org/]++ ? Associations pour le maintien d’une agriculture paysanne.%%% * @Charles : oui, normalement on prononce les ‘n’ dans le mot Kanban.%%% * @Michael : le ++[« Peer » Programming|http://www.citerus.se/download/18.4b231cd511170eec10e800066226/pnehm_1_2007_peerprogramming.pdf]++, ça existe !%%% * @Olivier @Thierry : même le ++[Copyleft|http://fr.wikipedia.org/wiki/Copyleft]++ ne laisse pas la possibilité de ne pas citer l’auteur.%%% * Qu’est-ce-qu’ils ont tous à passer sur Twitter ?%%% !!!Lessons (re-)learnt%%% * Agile Product Charter : l’équipe ne fait pas du code, elle fait un produit !%%% * Les valeurs sont plus importantes que la méthode, pas l’inverse !%%% * Au départ, décrétez la confiance, ensuite construisez-la…%%% * La rétrospective ne marche que s’il y a de l’honnêteté et une réelle volonté d’amélioration.%%% * Ne pas mentir sur le reporting : rouge pour l’équipe, qui devient orange pour le DP puis vert pour le VP ? dire les choses comme elles sont…%%% * Espérer avoir des spécifications exhaustives, c’est un leurre !%%% * Les systèmes de revues mis en place aujourd’hui sont là plus pour rassurer que assurer.%%% * Difficile de capitaliser sur des projets durant plus d’un an : l’équipe s’est dissoute et on recommence les mêmes erreurs ailleurs…%%% * L’Agilité, c’est l’intégration des changements.%%% * L’Agilité nécessite une prise de risque initiale.%%% * L’Agilité c’est juste un cadre, pas une solution. On remet l’individu au centre du système.%%% * C’est la fin des usines à gaz qui « tombent en marche » : le code est redevenu vivant !%%% * Restez rigoureux : il faut une spécification partielle mais mâture !%%% * Cycle de vie XP = cycle de vie du produit (exploration, engagement, pilotage par feedback et mort de l’appli)%%% * Valeur = norme de conduite personnelle et/ou sociale%%% * Le refactoring est une conséquence de la conception émergente (cf. ++[YAGNI|http://c2.com/xp/YouArentGonnaNeedIt.html|en]++)%%% * Managez votre manager.%%% * L’anarchie, c’est l’ordre sans le pouvoir (Léo Ferré).%%% * Le propos d’XP est le changement social (Kent Beck).%%% * L’utopie est simplement ce qu’on n’a pas encore essayé (Théodore Monod).%%% !!!Appreciations%%% * Merci aux participants : plus de 200 !%%% * Merci à l’IUT de Blagnac de nous avoir reçu.%%% * Merci aux sponsors : Akka I&S, Atos Origin, Ekito, SII et Sogeti.%%% * Merci aux organisateurs.%%% * Merci aux orateurs : Claude Aubry, Olivier Azeau, Angèle Batanero, Alexandre Boutin, David Brocard, Yann Coste, Thierry Cros, Luc Delamotte, Frédéric Duffau, Cyrille François, Jean-Michel Inglebert, Kryakos Konstantopedos, Laurent Meurisse, Pascal Pratmarty, Guillaume Saint-Etienne, Antoine Vernois.%%% * Merci à Frédéric Faure qui était en pensée avec nous lors de la présentation « Kanban et Scrum : tirer le meilleur des 2 ».%%% * Je n’ai pas l’habitude de faire beaucoup de publicité ou propagande pour ma société sur mon blog personnel. Il faut savoir que non seulement elle sponsorisait les évènements Agile Tour Bordeaux et Toulouse mais qu’en plus elle m’a offert les deux journées… ce qui en SSII reste un luxe. Donc merci ! notamment à Yann Collin et Bruno Vernier.%%% [((/dotclear/public/skatt/.ao-stand1_t.jpg|Avec Cécile P. et Emmanuel de B.||Avec Cécile P. et Emmanuel de B.))|/dotclear/public/skatt/ao-stand1.jpg] [((/dotclear/public/skatt/.ao-stand2_t.jpg|Avec Cédric C. et Yann C.||Avec Cédric C. et Yann C.))|/dotclear/public/skatt/ao-stand2.jpg] [((/dotclear/public/skatt/.ao-stand3_t.jpg|Cédric C. et Yann C.||Cédric C. et Yann C.))|/dotclear/public/skatt/ao-stand3.jpg]%%% %%% A l’année prochaine !%%% !!!Links%%% * Présentations :%%% ** ++[« XP : le projet social »|http://etreagile.thierrycros.net/home/?post/2010/10/22/XP-:-le-projet-social]++ par Thierry Cros%%% ** ++[« Trouver des fournisseurs agiles »|http://www.davidbrocard.org/node/101]++ par David Brocard%%% * Allez voir le film de Thales Avionics sur ++[Dailymotion|http://www.dailymotion.com/video/x9pv7w_le-lean-engineering-chez-thales_tech]++, vous y verrez des développeurs motivés… ce ne sont pas des acteurs !%%% * Le site de Rachel Dubois ++[« Agile & Creative Product Management »|http://www.racheldubois.fr/]++ est de retour !%%% * Blog de Pierre Rabhi : ++[« Pour une insurrection des consciences »|http://www.pierrerabhi.org/blog/]++%%% !!!Events * ++[Agile Grenoble|http://agile-grenoble.org/]++ le 23 novembre 2010 (site fait avec DokuWiki !)%%% !!!Feedback%%% * Antoine Vernois : ++[« 21 octobre 2010 — Agile Tour Toulouse »|http://antoine.vernois.net/dotclear/index.php?post/2010/10/22/21-octobre-2010-Agile-Tour-Toulouse]++%%% * Alexandre Boutin : ++[« Agile Toulouse 2010″|http://www.agilex.fr/2010/10/agile-toulouse-2010/]++%%% * Olivier Azeau : ++[« Agile Tour Toulouse 2010″|http://agilitateur.azeau.com/post/2010/10/23/Agile-Tour-Toulouse-2010]++%%% * Claude Aubry :%%% ** ++[« Agilité et anarchie »|http://www.aubryconseil.com/post/Agilite-et-l-anarchie]++%%% ** ++[« Les photos du TOC »|http://www.aubryconseil.com/post/Les-photos-du-TOC]++%%% ** ++[« Présentation Kanban et Scrum à l’Agile Tour »|http://www.aubryconseil.com/post/Presentation-Kanban-et-Scrum-a-l-Agile-Tou]++%%% * Rachel Dubois : ++[« Agile Tour Toulouse 2010″|http://www.racheldubois.fr/2010/10/agile-tour-toulouse-2010/]++%%% * Antoine sur morphogénèse et chocapics : ++[« Un projet social de Scrum ? »|http://morphocapic.blogspot.com/2010/10/un-projet-social-de-scrum.html]++%%% * Laurent Meurisse : ++[« Innovation pour une DSI plus agile »|http://laurentmeurisse.wordpress.com/2010/10/23/innovation-pour-une-dsi-plus-agile/]++%%% %%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes rétrospectives sur le wiki ++[Rétrospectives Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/retrospective:start]++.

Inscrivez-vous à l’Agile Tour Toulouse 2010

((/dotclear/public/at2010/agile-tour-toulouse.jpg|Agile Tour Toulouse|L|Agile Tour Toulouse))L’Agile Tour Toulouse 2010, c’est __le jeudi 21 octobre__ avec 6 conférences, 6 ateliers et 7 retours d’expérience autour des approches agiles, c’est __toute la journée__ et c’est… __gratuit__. Donc profitez-en pour venir rencontrer des professionnels, échanger sur vos problématiques ou tout simplement découvrir et __participer à une révolution en marche !__%%% %%% N’oubliez pas de ++[vous inscrire|http://www.agiletour.org/fr/toulouse_inscription.html]++ !

Gérer le développement Lean des logiciels avec les diagrammes de flux cumulé

[((/dotclear/public/photos/.David-J-Anderson_t.jpg|David J. Anderson|L|David J. Anderson))|/dotclear/public/photos/David-J-Anderson.jpg]J’ai traduit cet article de __David J. Anderson__ ++[« Managing Lean Software Development with Cumulative Flow Diagrams »|http://conferences.embarcadero.com/jp/article/32096|en]++ qu’il a présenté lors de la Conférence Borland (BorCon) 2004.%%% %%% Claude Aubry, Antoine Vernois et moi-même aborderont en effet ce concept lors de notre présentation « Kanban et Scrum – Tirer le meilleur des deux » lors de ++[l’Agile Tour Toulouse|http://www.agiletour.org/fr/at2010_toulouse.html]++ du 21 octobre. Claude avait déjà traité le sujet dans une suite de billets en 2007, notamment ++[« Les courbes de croissance d’un projet (3) »|http://www.aubryconseil.com/post/2007/07/16/261-les-courbes-de-croissance-d-un-projet-3]++%%% !!!Résumé Les Diagrammes de Flux Cumulé (CFD) fournissent une méthode pour suivre les progrès des projets agiles, un peu comme les burnups. Parce qu’ils illustrent à la fois le périmètre total et le progrès des Features / Stories / Tâches / Fonctions / Cas d’utilisation, ils communiquent à la fois sur l’état d’avancement total et sur le ratio de complétude totale. Les CFD nous offrent également une méthode simple de suivi du travail en cours (WIP) et illustre visuellement la tendance du Lead Time pour livrer un code opérationnel. Ils fournissent une mesure de premier plan qui permet aux équipes et aux managers de réagir plus tôt aux problèmes croissants qui pourraient apparaître dans le flux entre les exigences et la livraison d’un code opérationnel. Les CFD fournissent une grande transparence sur le cycle de vie complet. Suivre un projet avec un CFD est un élément clé pour évoluer vers un système Lean de développement logiciel.%%% !!!Introduction%%% Les méthodes agiles de développement de logiciels tels que Scrum et Feature Driven Development gèrent et mesurent l’avancement du projet d’une manière très différente des chemins critiques en gestion de projet traditionnelle. Scrum a commencé avec l’utilisation d’un burndown qui illustre le nombre estimé d’heures restant pour terminer le backlog du sprint. Plus récemment, les burnups ont gagné en popularité. Ils suivent le nombre de Stories, Tâches ou Features terminées sur le projet par rapport à un objectif de fin prévisionnelle. Il est possible d’extrapoler la courbe avec une ligne de tendance pour estimer la date de fin du projet.%%% %%% Le concept du burnup a été utilisé en Feature Driven Development depuis sa création dans les années 1990. Cela s’appelle le Graphe des Features Finies, comme le montre la Figure 1.%%% %%% ((/dotclear/public/skatt/1671b.gif|Feature Complete Graph||Feature Complete Graph))%%% __Figure 1. FDD – Graphe des Features Finies__%%% %%% Toutefois, les burnups ne sont pas vraiment suffisants pour gérer un projet. Ils n’ont aucune notion du travail en cours (WIP) et simuler la date prévisionnelle de fin est problématique. Dans mon livre __ »Agile Management »__ (Anderson 2003), j’ai présenté les Diagrammes de Flux Cumulé (CFD) comme de meilleurs outils de visualisation. Cet article explique pourquoi et montre comment utiliser les CFD pour mieux apprécier l’état de santé d’un projet et prévoir ses résultats.%%% !!!La Courbe en S%%% L’achèvement des Features tend à suivre un modèle de Courbe en S, comme le montre la Figure 2. L’effet de courbe en S rend difficile la prédiction de la date de fin d’un projet à partir d’un tracé de fonctionnalités terminées.%%% %%% ((/dotclear/public/skatt/1671c.gif|The S-Curve||The S-Curve))%%% __Figure 2. Courbe en S pour les Features terminées__%%% !!Bas de la Courbe en S%%% Il est très difficile de sprinter dès le départ. Il est probablement impossible d’atteindre une production optimale dans le développement logiciel au début d’un projet. Il y a plusieurs raisons à cela : le stock des Features est bloqué en raison d’exigences ambiguës, la formation du personnel, le manque de compréhension du domaine du projet, le travail insuffisant en équipe, les changements de conception, la disponibilité des outils, la disponibilité des environnements, les équipements, le manque d’infrastructures techniques, l’insuffisance d’outils spécifiques au domaine et le niveau de recrutement. Certaines raisons peuvent être éliminées grâce à une meilleure planification, d’autres semblent être endémiques. Elles représentent la spécificité du développement de logiciels.%%% !!Formation de l’équipe%%% Lorsqu’une nouvelle équipe est formée pour un projet, il y a un impact sur la vélocité. C’est propre au métier. L’équipe doit travailler en traversant les phases de forming et storming (Tuckman 1965, Weaver 1997) avant de s’installer dans ses nouvelles habitudes. Au fur et à mesure que les membres l’équipe apprennent à connaître les forces et les faiblesses de chacun d’entre eux, des frictions apparaîtront. Ces frictions auront pour effet de réduire le rendement de l’équipe.%%% !!Dysfonctionnement de l’équipe%%% De temps en temps, une équipe fait preuve de dysfonctionnements. Cela se manifeste par un faible rendement et une courbe plate. Le dysfonctionnement peut entraîner une mauvaise conception ou de mauvaises revues par les pairs, ou même de petites disputes qui vont bloquer le développement. La maîtrise des Diagrammes de Flux Cumulé fournit au manager des informations pouvant montrer les dysfonctionnements d’une équipe, mais seul le manager peut réellement enquêter et découvrir un mauvais comportement. Il est important de comprendre qu’un différend entre deux individus peut pénaliser les performances de l’équipe entière.%%% !!Partage des connaissances%%% Le partage des connaissances est important pour la performance. Une équipe qui fonctionne bien ensemble, partage ses connaissances. Une équipe qui ne fonctionne pas bien et qui ne partage pas beaucoup ne sera pas performante. Il est important de créer un environnement qui encourage les individus à ne pas cacher les informations et à ne pas mesurer et récompenser les individus plutôt que les équipes. Toutefois, je ne traiterai pas ce sujet plus avant dans le présent document. Encourager l’ouverture et le partage des connaissances et mettre en oeuvre des moyens de communiquer la connaissance, comme un serveur de news, ou une base de connaissances sur intranet, permettra d’améliorer la performance de l’équipe.%%% !!Outils & Environnements%%% Si une équipe de développement est prête à démarrer un projet, mais qu’elle n’a pas tous les outils et environnements nécessaires pour progresser alors le rendement en souffrira gravement. Les limites de capacité des ressources de développement doivent être pleinement exploitées. Elles ne doivent pas être ralenties parce que les outils ou les environnements ne sont pas disponibles. Par conséquent, il est important que le manager s’assure que les outils et les environnements soient en place dès le début. Une ligne plate au début d’un projet peut être une forte indication que l’équipe ne dispose pas des outils ou environnements dont elle a besoin.%%% !!Ambiguïté dans les Exigences Les modifications de conception nuiront à tout moment du projet. Quand quelqu’un découvre une exigence qui nécessite la modification d’une interface largement utilisée, l’effet de toute régression dans le système peut causer une chute dramatique de la vélocité. Ce problème est endémique. Il y aura toujours un peu d’incertitude liée à l’analyse et la conception.%%% !!Haut de la Courbe en S%%% Il y a quatre raisons pour lesquelles le rendement a tendance à s’écrouler dans les projets quel que soit la méthode de développement logiciel utilisée : l’augmentation de l’effort d’intégration, la correction des bugs, le stock des besoins bloqué en raison de problèmes non résolus et le refactoring.%%% !!Intégration L’augmentation de l’effort d’intégration est presque inévitable. Au fur et à mesure que le projet grandit, le code d’une nouvelle itération doit être intégré à la grosse base de code existante. Le nombre de problèmes rencontrés pendant le build et les tests d’intégration est susceptible d’augmenter. La seule façon d’éviter cela est de ne jamais travailler sur un gros projet ou un système, même si les effets peuvent être atténués par une bonne architecture à couplage faible. Ainsi, les grands projets, même ceux construits en plus petites itérations, doivent anticiper cet effet et en tenir compte dans la planification du projet.%%% %%% L’effet de l’augmentation des problèmes dus au build peut être mesuré depuis le début du build jusqu’à ce que le build soit déclaré réussi. C’est le lead time spécifique aux test d’intégration. Le manager peut alors évaluer ce que pourrait être le temps d’arrêt global de l’équipe de développement. Dans les cas extrêmes, tout développement s’arrête jusqu’à ce que la compilation soit déclarée réussie. L’effet sur le rendement de l’équipe peut être calculé. L’évolution du temps de build peut être utilisée pour prédire l’impact futur du build sur la vélocité de l’équipe. Par conséquent, la contribution du build peut être prédite sur le Diagramme de Flux Cumulé.%%% %%% Il devrait également être possible d’utiliser un outil, tel que Borland Together, pour calculer le degré de couplage dans l’architecture. L’évolution de ce paramètre pourrait être utilisé pour prédire l’augmentation du temps d’intégration.%%% !!Bugs Au fur et à mesure que le projet mûrit et que davantage de code est disponible pour les tests système et produit, le nombre de bugs signalés peut augmenter. Alors que la base de bugs augmente, il y a une tendance à mélanger la correction des bugs avec le codage en cours de nouvelles fonctionnalités pour les clients. Le résultat est que la vitesse globale de l’équipe est maintenue, mais une part croissante de l’effort est consacré à la correction des bugs. Ces corrections de bugs sont liés aux Features déjà en stock et complètement codées, donc il n’y a pas de valeur supplémentaire gagnée sur le Diagramme de Flux Cumulé lorsqu’on travaille dessus.%%% %%% Pour minimiser l’effet des bugs sur la courbe du code terminé et afin de maintenir la vélocité, il est essentiel de maintenir des standards de haute qualité. Moins de bugs ont un effet positif direct sur le taux de production du système. La courbe en S montre clairement comment et pourquoi des standards de haute qualité peuvent faire qu’un projet aille plus vite.%%% !!Problèmes non résolus%%% Lorsqu’un projet approche de sa fin, le stock des besoins qui a été bloqué en raison de questions en suspens soulevées lors de l’analyse ou de conception, revient dans le chemin critique. Finalement, toutes les fonctionnalités à valeur ajoutée pour le client seront codées, ou alors le client doit accepter de les déclarer hors-périmètre. Si elles sont maintenues dans le périmètre, les problèmes doivent être résolus. Les questions qui restent encore ouvertes à la fin d’un projet, ont pour effet de réduire le nombre de fonctionnalités à valeur ajoutée qui peuvent être terminées. Le résultat est donc que la vitesse de l’équipe ralentit. Certains développeurs peuvent devenir inoccupés, ou de plus en plus d’efforts sont consacrés aux corrections de bugs, puisque le stock des besoins est bloqué.%%% %%% Pour éviter une baisse de vélocité, il est essentiel de résoudre les problèmes avant que les fonctionnalités à valeur ajoutée pour le client soient sur le chemin critique. Par conséquent, le manager devrait se concentrer sur la résolution rapide et efficace des problèmes. Cela permet de maintenir le débit global du système. Un aplatissement de la courbe est un bon indicateur visuel qui signale que le manager doit redoubler d’efforts pour résoudre les questions en suspens.%%% !!Refactoring Le refactoring aura également un impact sur la vélocité, s’il concerne des Features déjà terminées. Lorsque du code opérationnel fini doit être remanié alors ce n’est pas une nouvelle production. Pour toute fonctionnalité à valeur ajoutée pour le client qui doit être remaniée, le système perd la possibilité d’une nouvelle unité de production. Pour cette raison, je préfère tracer le refactoring comme étant de nouvelles Features baptisées « Matière Noire » qu’on ajoute au stock total sur le Diagramme de Flux Cumulé.%%% %%% Lorsque le remaniement du code est inévitable en raison d’un changement des conditions du marché qui impose de nouvelles contraintes sur l’architecture du système ou sur du code bâclé qui a limité la capacité de l’équipe à aller jusqu’au bout de l’itération, il est vital de transmettre à la haute direction, le coût réel du refactoring. Le coût réel peut être calculé à partir de la baisse du rendement, l’augmentation du lead time, l’augmentation du WIP sur le stock et l’occasion perdue d’augmenter le débit. Si le bénéfice tiré du refactoring l’emporte financièrement sur le coût, il devrait être réalisé.%%% %%% Pour avoir un aperçu supplémentaire sur la courbe en S, vous aimerez peut-être aussi lire le livre __ »Tracking Software Process de Betsy Clark »__ (Yourdon 2002). Elle baptise les petits morceaux de fonctionnalités à valeur ajoutée pour le client, des unités de travail et observe qu’elles dessinent une courbe en S.%%% !!!Ratio de complétude%%% Pour communiquer une image plus complète de la santé d’un projet, j’ai trouvé nécessaire de compléter le Graphe des Features Finies avec un ratio de complétude et un diagramme. Une courbe de l’évolution du ratio de complétude en FDD donne du crédit aux Features qui sont en cours. Chacune des six étapes pour une Feature est créditée d’un pourcentage de la valeur acquise, comme le montre la Figure 3.%%% %%% ((/dotclear/public/skatt/fig3.jpg|Earned value percentages||Earned value percentages))%%% __Figure 3. Jalons des Features et pourcentage de valeur acquise__%%% %%% Les graphes de Features Finies ne parviennent pas à communiquer sur le travail en cours, mais le Ratio de complétude et le graphique génèrent un faux reporting. Pourquoi ? Parce que tout développeur agile vous dira qu’ils ne valorisent qu’un logiciel fini. Il n’y a donc pas de valeur pour du code partiellement terminé. Ce résultat est compatible avec le livre __ »Theory of Constraints management accounting method, Throughput Accounting »__ (Corbett, 1997). La valeur doit être uniquement reconnue à la livraison.%%% %%% Par conséquent, il était nécessaire d’arrêter de suivre le ratio de complétude. Suivre uniquement la seule valeur acquise avec des Features terminées ou trouver une meilleure façon de communiquer sur le travail en cours, c’est à dire une méthode qui ne suit pas la valeur du WIP, mais qui communique sur le fait que le travail progresse, même lorsque des Features ne sont pas terminées tous les jours.%%% !!!Travail en cours S’il est mauvais de communiquer sur la valeur acquise à partir d’un WIP partiellement terminé, alors devrions-nous ignorer le WIP ? Non, je ne crois pas ! Nous devrions plutôt nous inquiéter plus avant de ce sujet. Pourquoi ?%%% %%% Le travail en cours peut être considéré comme du stock. Dans ce cas, ce stock est capturé à un certain moment dans un processus de transformations telles que l’analyse, la conception, le plan de test, le code, les tests unitaires et la revue de code (en fonction de la méthode que vous utilisez). En suivant le WIP par une série de transformations, nous pouvons mieux comprendre la santé d’un projet et prévoir son résultat. Ces idées sont développées à partir des travaux de Donald Reinertsen, mais pour le comprendre, nous devons d’abord comprendre la contribution de Marvin Patterson.%%% !!!Modèle de conception de Patterson%%% Avec son livre __ »Accelerating Innovation »__ (1993), Marvin Patterson a présenté un concept pour la modélisation des processus de conception. Il nous a demandé d’envisager que la conception soit un processus de découverte de l’information. Avant qu’une conception commence, il y a peu ou pas d’information, peut-être même uniquement une vague idée. Au fur et à mesure que la conception émerge peu à peu, il y a de plus en plus d’informations et de moins en moins d’incertitude jusqu’à ce que la conception soit terminée.%%% %%% Mary Poppendieck (2003) a suggéré que le développement de logiciels puisse être appréhendé avec le même modèle. En d’autres termes, tout développement de logiciel est un problème de conception. Cela nous permettrait de modéliser les flux de valeur grâce à un système de génie logiciel comme la réduction progressive de l’incertitude et la découverte de l’information de plus en plus détaillée jusqu’à ce que soit produit un code opérationnel qui passe des tests de contrôle de qualité appropriés.%%% !!!La conception est périssable%%% Dans son livre __ »Managing the Design Factory »__ (1997), Donald Reinertsen a développé les idées de Patterson en allant un peu plus loin et en introduisant deux concepts. La première observation est que le stock en cours de conception peut être suivi à l’aide de Diagrammes de Flux Cumulé, comme illustré à la Figure 4. Les CFD étaient déjà en usage dans la Production Lean pour suivre le flux de valeur dans une usine. La seconde et peut-être la plus précieuse vision, c’est que la valeur des informations de conception se déprécie au fil du temps. Il y a plusieurs raisons à cela. La principale est que l’information ne doit être créée qu’une seule fois, que le coût de reproduction est proche de zéro. Si la conception est de l’information, alors le temps qu’il faut à un concurrent pour dupliquer la conception, c’est le délai pendant lequel la conception (et les informations associées) a une valeur de différenciation. L’information sur la conception est également périssable en raison des changements de mode possibles sur le marché, comme les lois, les règlements, les matériaux, les composants fournis, les réseaux de distribution et les modèles métiers. Pour avoir une réelle valeur, une conception doit être appropriée en termes de durée et doit arriver sur le marché dans cette fenêtre d’opportunité. Si le logiciel c’est la conception, alors cela doit également s’appliquer. Les exigences pour un logiciel doivent être périssables. Ainsi, plus les exigences peuvent être rapidement réalisées sous forme d’un code opérationnel mis sur le marché, plus une grande quantité de valeur sera livrée. Les observations de Reinertsen et de Poppendieck ancrent solidement le génie logiciel aux principes du Lean et le lead time permettant de transformer une idée en un logiciel opérationnel doit être essentiel à la réussite financière de toute activité de production logicielle.%%% %%% ((/dotclear/public/skatt/1671d.gif|An idealized Cumulative Flow Diagram for an FDD project|An idealized Cumulative Flow Diagram for an FDD project))%%% __Figure 4. Un Diagramme de Flux Cumulé dans le cadre d’un projet FDD__%%% !!!Loi de Little%%% La Loi de Little stipule qu’une file d’attente de matériaux peut être analysée de deux manières : selon le stock, ou selon le lead time. Il suffit de considérer que la taille du stock est directement proportionnelle au lead time de traitement du stock. Ainsi, la taille du stock en cours de traitement est problématique parce que dans le développement agile nous voulons terminer le logiciel selon des cycles courts et livrer de la valeur aussi souvent que possible. La Figure 5 montre comment lire le stock en cours de traitement (WIP) et les Lead Time à partir d’un CFD.%%% %%% ((/dotclear/public/skatt/1671e.gif|Reading WIP and Lead Time from a CFD for Day 40 of a project||Reading WIP and Lead Time from a CFD for Day 40 of a project))%%% __Figure 5. Lecture du WIP et du Lead Time à partir du CFD à J40 d’un projet__%%% !!!Taille du lot%%% La Figure 5 montre également comment la taille des lots et les transferts de lots affectent le Diagramme de Flux Cumulé. Les transferts de lots peuvent être clairement vue par la forme hâchée de la courbe. Avec des tailles de lots plus importants, il y a plus de WIP et les lead times sont plus longs. Avec des tailles de lots plus petits comme dans la Figure 6, le WIP est réduit et le lead time tombe en conséquence. Notez le lissage de la courbe sur la Figure 6. Il s’agit d’un véritable projet FDD avec des paquets (petits lots de Features) terminés en moins de 2 semaines. Les lead times peuvent être clairement lus à partir du diagramme.%%% %%% Il est facile de voir que les CFD peuvent être utilisés pour indiquer en un coup d’œil, la taille des itérations et le type de méthode utilisés pour le développement.%%% %%% ((/dotclear/public/skatt/1671f.gif|CFD showing lead time fall as a result of reduced WIP||CFD showing lead time fall as a result of reduced WIP))%%% __Figure 6. CFD montrant que le lead time baisse suite à la réduction du WIP__%%% !!!Le WIP est une mesure importante Reinertsen décrit le WIP comme une métrique de premier plan. Ce qu’il veut dire, c’est que le WIP peut prédire à l’avance le lead time et la date de livraison. Il peut donc être utilisé pour corriger les problèmes avant qu’ils ne deviennent trop graves. Si nous attendons trop pour mesurer le lead time ou la date de livraison, nous aurons plus de difficultés à traiter les nombreux problèmes. Une fois, j’ai eu un projet dont l’état d’avancement a été estimé à 53% après 8 semaines, mais seulement 4 Features étaient terminées. Un CFD de ce projet aurait attiré mon attention, en tant que manager, beaucoup plus tôt. Non seulement le CFD m’aurait averti, mais cela m’aurait également orienté vers la cause du problème. Le reste de cet article explique comment utiliser les CFD, pour diagnostiquer les problèmes de santé d’un projet.%%% !!!Dérive du Périmètre et Matière Noire%%% J’aime faire la distinction entre deux types de changements dans la globalité du stock de Features pour un projet. La première représente l’évolution des besoins ou de nouvelles demandes de la part du client. Ceci est souvent appelé la dérive du périmètre. Ce sont de nouvelles Features qui n’étaient pas dans le périmètre lorsque le projet a démarré. Cependant, il y a un deuxième type de nouvelle Feature qui doit être connu. Ce sont des Features qui émergent au cours du projet, au fur et à mesure que l’analyse gagne en profondeur et que la conception avance et que l’équipe obtient une image plus complète du travail à réaliser. J’appelle ces Features émergentes, la matière noire, parce qu’elles ont toujours été là, mais jusqu’à ce moment-là, l’équipe ne pouvait pas les voir. Ainsi, la matière noire est une réflexion sur l’incertitude dans la phase d’analyse initiale. Plus un domaine est inconnu de l’équipe impliquée, plus il est probable qu’ils ont manqué quelque chose. Par conséquent, il y aura plus de matière noire sur des projets avec une plus grande incertitude en raison du manque de connaissance du domaine. Lorsque vos experts ne sont pas aussi experts que vous souhaitiez qu’ils soient, la matière noire sera plus importante. La Figure 7 montre comment tracer le périmètre initial, la matière noire et les nouvelles Features. Ces données sont tirées du même projet FDD que la Figure 6.%%% %%% ((/dotclear/public/skatt/1671g.gif|Scope showing dark matter and new features||Scope showing dark matter and new features))%%% __Figure 7. Périmètre avec matière noire et nouvelles fonctionnalités__%%% !!Incertitude sur le Périmètre%%% Pour comprendre la valeur de ce graphique, nous devons d’abord comprendre la notion d’incertitude sur le périmètre. Lorsque la liste des features est établie au début du projet, l’équipe est invitée à deviner si elle est bien certaine d’avoir identifiée toutes les Features. Dans le cas particulier illustré, l’équipe a utilisé une technique baptisée « Yesterday’s Weather » et avec laquelle elle a réfléchi sur la matière noire qui a émergé lors de l’itération précédente. Cela a été utilisé en s’appuyant sur l’expérience et l’équipe est tombée d’accord sur le fait que le périmètre total était maintenant probablement de 220 Features alors que le périmètre initial était de 185 Features. Par conséquent, l’équipe s’attendait à une matière noire de 35 Features. L’incertitude sur le périmètre était donc de 35. Le calendrier du projet a alors été refait en se basant sur un échantillonnage de la vélocité et multiplié par 220. Cela a donné une date de fin au 22 Mars.%%% !!Graphique de Suivi du Périmètre%%% Pour suivre le périmètre quotidiennement, un graphique de suivi du périmètre peut être créé comme illustré à la Figure 8. L’idée est que si le périmètre tombe en-dessous de 170 alors l’équipe tolère une évolution du périmètre dans la release. Toutefois, si le périmètre dépasse 220, il est probable que le projet sera en retard, à moins que la vélocité devienne plus grande que prévu. La vélocité peut être lu sur la CFD et la limite de suivi peut donc être réajusté si nécessaire.%%% %%% ((/dotclear/public/skatt/1671h.gif|Scope Control Chart||Scope Control Chart))%%% __Figure 8. Graphique de Suivi du Périmètre__%%% %%% Maintenant, considérons ce qui s’est réellement passé sur le projet. Initialement, la portée totale tombe. Cela est dû à des Features reportées à une version ultérieure lorsqu’il est apparu que le client n’en avait pas vraiment besoin. Ensuite, l’effet matière noire commence à entrer en action et le stock augmente un peu. Ensuite, quelques features sont reportées à une version ultérieure, car une fois de plus, le client n’en a pas vraiment besoin. Vers le 8 Mars, le client soumet une demande d’évolution. Cela provoque une augmentation du stock, mais l’équipe l’accepte parce qu’elle croit qu’elle est en voie d’atteindre la date de livraison. Toutefois, la matière noire continue de croître jusqu’à la mi-Mars et le 16 Mars le périmètre total passe à travers la limite de contrôle. Le projet va être en retard. À ce stade, le manager doit intervenir.%%% %%% Il s’avère que la demande d’évolution n’est pas requise pour la livraison du 22 Mars mais pour celle du 14 avril (et même plus tard, elle a été repoussée à la mi-été). Donc, la demande d’évolution est sortie du périmètre et le projet revient sur les rails. Un accord a été trouvé pour réaliser la demande d’évolution et la livrer spécifiquement avant le 14 avril. En fait, ça n’est jamais arrivé. Cela souligne clairement la valeur de l’approche agile et la visibilité apportée par cette approche, facilitée par l’utilisation de CFD.%%% !!Incertitude sur les Exigences%%% Comme illustré à la figure 9, où il y a un écart croissant entre les Features commencées mais pas entrées en conception, cela indique une incertitude dans les exigences. Cela devrait normalement ressortir par de nombreuses questions demandant des éclaircissements sur les exigences. Avec des Features bloquées en raison d’informations insuffisantes ou ambiguës, ou un manque de cohérence interne dans les exigences, l’équipe de développement va commencer davantage de Features avec l’espoir de réaliser des progrès avec ces dernières tandis que les autres sont bloquées. Le WIP total va donc augmenter.%%% %%% Sans un expert compétent sur le site du client, il peut ne pas être possible d’obtenir des réponses instantanées. Le client peut même ne pas connaître la réponse correcte ou l’analyste métier ou le chef produit ne sont peut être pas habilités à fournir une réponse complète. Malgré tout, le Diagramme de Flux Cumulé révèle le symptôme et la cause racine doit être cachée dans la liste des problèmes.%%% %%% ((/dotclear/public/skatt/1671i.gif|Growing Gap between Started and Designed||Growing Gap between Started and Designed))%%% __Figure 9. Écart croissant entre le Début et la Conception__%%% !!!Problèmes de conception ou d’architecture%%% La figure 10 montre un écart croissant entre la conception et le codage. La cause de cela ne peut être déterminée à partir de la courbe seule, mais elle fournit un avertissement qui devrait inciter le manager à enquêter.%%% !!Mauvaise conception%%% La première possibilité est la mauvaise qualité de la conception ou un conception impossible à réaliser. L’équipe déclare la conception terminée et la courbe est mise à jour, mais quand l’équipe commence à coder la conception, elle découvre qu’elle n’y a pas suffisamment bien réfléchi. Cela signifie que le travail de conception réelle va se faire pendant le codage. Ainsi, la courbe est fausse et ne reflète pas l’état réel d’avancement. Un manager pourrait choisir de résoudre ce problème de deux façons : envoyer l’équipe en formation pour une meilleure conception Orientée Objet, ou tout simplement changer la méthode de reporting afin de ne pas tenir compte de la conception. Ma préférence personnelle va à la première. Je crois qu’une bonne conception améliore la productivité.%%% %%% ((/dotclear/public/skatt/1671j.gif|Growing Gap from Designed to Coded||Growing Gap from Designed to Coded))%%% __Figure 10. Écart croissant entre la Conception et le Codage__%%% !!Problèmes de développement Une autre raison qui expliquerait l’écart entre la conception et le codage est le manque de connaissance du langage de développement ou des APIs utilisées. Si une nouvelle technologie est utilisée pour la première fois, l’équipe a peut être du mal à l’apprendre.%%% %%% Sinon, il pourrait aussi y avoir des problèmes d’environnement ou d’outils. Il n est pas rare de commencer un projet avec une licence temporaire pour un outil, une plateforme ou un environnement en attendant que les achats passent l’ordre d’achat de la licence complète. J’ai aussi vu des cas où un nouveau projet poussait à bout l’environnement de gestion de configuration et exigeait un nouveau matériel ou un rebuild ou une reconfiguration. Cela prend aux outils ou à l’équipe de support un certain temps et peut entraver le gros de l’effort de développement.%%% !!Refactoring La présence officieuse de refactoring peut être une autre raison pour expliquer un écart de plus en plus grand entre la conception et le codage. Il peut s’avérer que les dernières conceptions nécessitent des changements dans le code écrit plus tôt dans le projet. Ce remaniement du code ne serait pas considéré comme de la matière noire, sauf si l’équipe est très honnête à ce sujet. Dans un cas extrême, il se pourrait que l’architecture du système soit invalidée par la dernière conception des Features et que tout le système soit en cours de réécriture. Cela s’illustrerait par un grand écart ou une sévère descente de la courbe de codage sur le CFD.%%% !!!Références%%% * ++[Blog de David J. Anderson|http://www.agilemanagement.net/|en]++ * (Anderson 2003) Anderson, David J., __ »Agile Management for Software Engineering Applying the Theory of Constraints for Business Results »__, Prentice Hall, Upper Saddle River, NJ 2003%%% * (Corbett 1997) Corbett, Thomas, __ »Throughput Accounting »__, North River Press, Great Barrington, MA 1997%%% * (Patterson 1993) Patterson, Marvin, __ »Accelerating Innovation »__, Van Nostrand Reinhold, New York, NY 1993%%% * (Poppendieck 2003) Poppendieck, Mary and Tom Poppendieck, __ »Lean Software Development, an agile toolkit »__, Addison Wesley, New York, NY 2003%%% * (Reinertsen 1997) Reinertsen, Donald G., __ »Managing the Design Factory, A Product Developers Toolkit »__, Free Press, New York, NY 1997%%% * (Tuckman 1965) Tuckman, Bruce W., __ »Development Sequence in Small Groups »__, Psychological Bulletin, 63(6)%%% * (Weaver 1997) Weaver, Richard G. and John D. Farrell, __ »Managers as Facilitators, a Practical Guide to Getting Work Done in a Changing Workplace »__, Berrett & Koehler, San Francisco, CA, 1997%%% * (Yourdon 2002) International Function Point User Group, __ »IT Measurement Practical Advice from the Experts »__, Foreword by Ed Yourdon, Addison Wesley, New York, NY, 2002%%% —- ((/dotclear/public/traductions/Kanban-sign-icon.png|Kanban sign|L|Kanban sign))Retrouvez l’intégralité de mes traductions sur le wiki ++[Traductions Agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/traduction:start|fr]++.

Kanban et Scrum

Tirer le meilleur des deux… le 21 octobre à ++[l’Agile Tour Toulouse|http://www.agiletour.org/fr/at2010_toulouse_programme.html#ScrumKanban]++.%%% %%% [((/dotclear/public/skatt/.skatt01_t.jpg|skatt01.jpg))|/dotclear/public/skatt/skatt01.jpg] [((/dotclear/public/skatt/.skatt02_t.jpg|skatt02.jpg))|/dotclear/public/skatt/skatt02.jpg] [((/dotclear/public/skatt/.skatt03_t.jpg|skatt03.jpg))|/dotclear/public/skatt/skatt03.jpg] [((/dotclear/public/skatt/.skatt04_t.jpg|skatt04.jpg))|/dotclear/public/skatt/skatt04.jpg] [((/dotclear/public/skatt/.skatt05_t.jpg|skatt05.jpg))|/dotclear/public/skatt/skatt05.jpg] [((/dotclear/public/skatt/.skatt06_t.jpg|skatt06.jpg))|/dotclear/public/skatt/skatt06.jpg] [((/dotclear/public/skatt/.skatt07_t.jpg|skatt07.jpg))|/dotclear/public/skatt/skatt07.jpg] [((/dotclear/public/skatt/.skatt08_t.jpg|skatt08.jpg))|/dotclear/public/skatt/skatt08.jpg] [((/dotclear/public/skatt/.skatt09_t.jpg|skatt09.jpg))|/dotclear/public/skatt/skatt09.jpg] [((/dotclear/public/skatt/.skatt10_t.jpg|skatt10.jpg))|/dotclear/public/skatt/skatt10.jpg] [((/dotclear/public/skatt/.skatt11_t.jpg|skatt11.jpg))|/dotclear/public/skatt/skatt11.jpg] [((/dotclear/public/skatt/.skatt12_t.jpg|skatt12.jpg))|/dotclear/public/skatt/skatt12.jpg] [((/dotclear/public/skatt/.PosterLeVoyageEstPlusImportantQueLaDestination_t.jpg|PosterLeVoyageEstPlusImportantQueLaDestination.jpg))|/dotclear/public/skatt/PosterLeVoyageEstPlusImportantQueLaDestination.jpg]

Itérations courtes (2)

[((/dotclear/public/logos/.logo_ao-toulouse_t.jpg|Atos Origin – site de Toulouse|L|Atos Origin – site de Toulouse))|/dotclear/public/logos/logo_ao-toulouse.jpg]Ce midi, j’ai présenté au site de Toulouse de ma société l’utilisation des itérations courtes dans le cadre d’un développement logiciel Agile & Lean : 55 inscrits ! salle comble, des gens intéressés, plein de questions…%%%

Lean Software Development

((/dotclear/public/logos/atosorigin-fish-sidebar.jpg|Atos Origin|L|Atos Origin))Ce soir, j’ai présenté à ma société une session sur le Lean Software Development et j’ai osé faire un parallèle entre l’état d’esprit Agile et Lean. Une quinzaine de personnes intéressées… Par contre, il faut que je retravaille l’intro, c’était trop laborieux.%%%

Nouveau site de l’Aïkido Club de Parempuyre

[((/dotclear/public/aikido/.new-site-aikido-parempuyre_m.jpg|Nouveau site Aïkido Parempuyre||Nouveau site Aïkido Parempuyre))|/dotclear/public/aikido/new-site-aikido-parempuyre.jpg]%%% Je vous annonce la publication du ++[nouveau site du Club Aïkido Parempuyre|http://www.aikidoparempuyre.com/]++, qui s’est modernisé avec l’utilisation de l’outil de gestion de contenu Joomla et qui est visuellement superbe.%%% %%% Félicitations à notre professeur André Hénay qui va pouvoir développer sa pratique du web 🙂 %%% %%% Une nouvelle occasion de vous inviter à venir pratiquer l’Aïkido dans un groupe très sympa !%%% %%% Et parlez-en autour de vous !%%%