Jidoka et Autonomation

[((/dotclear/public/./.jidoka_s.jpg|Jidoka|L|Jidoka, aoû 2009))|/dotclear/public/jidoka.jpg]Le mot __Jidoka__ ou « __autonomation__ » (自働化) est un mot emprunté à la langue japonaise lui-même basé sur un jeu de mots :%%% – le mot « automatisation » (自动化), écrit en utilisant trois caractères kanji : « auto » (自), « mouvement » (动) et « -nisation » (化)%%% – dans le système de production Toyota, le deuxième caractère est remplacé par « travail » (働), lui-même dérivé de l’original 动 en ajoutant le radical représentant « humain ».%%% %%% On peut donc traduire Jidoka par « automatisation avec une touche d’humain » : lorsqu’une machine commence à constater que les pièces qu’elle produit sont de moins bonne qualité, qu’elle surchauffe ou qu’elle manque d’huile, elle s’arrête automatiquement en activant un andon, ce qui alertera l’ouvrier chargé de la maintenance…%%% %%% L’__andon__ (行灯), composé des caractères « aller » (行) et « lampe électrique » (灯), pourrait se traduire tout simplement par « lumière où il faut aller ».%%% %%% Recherche effectuée après la lecture du billet d’Emmanuel Chenu : ++[INTEGRATION CONTINUE + ANDON = JIDOKA|http://emmanuelchenu.blogspot.com/2009/08/lean-andon.html|fr]++

Forming, Storming, Norming, Performing and Adjourning

[((/dotclear/public/./.form-storm-norm-perform-adjourn_t.jpg|Forming, Storming, Norming, Performing and Adjourning|L|Forming, Storming, Norming, Performing and Adjourning, aoû 2009))|/dotclear/public/form-storm-norm-perform-adjourn.jpg]__Bruce Wayne Tuckman__ (né en 1938) est un psychologue américain, qui a effectué des recherches sur la théorie de la dynamique des groupes. En 1965, il a publié une de ses théories appelées « Phases de Tuckman » (« Tuckman’s Stages ») et qui répond à une logique de « cycle de vie » : « __Forming__ », « __Storming__ », « __Norming__ » et « __Performing__ ». En 1977, il a ajouté une cinquième étape nommée « __Adjourning__ ». Il soutenait que ces phases sont toutes nécessaires et inévitables pour que l’équipe grandisse, fasse face aux défis, résolve les problèmes, trouve des solutions, planifie son travail et produise des résultats.%%% %%% Pour résumer, le groupe est émotionnel et fonctionnel, il « vit », s’auto-organise jusqu’à sa dissolution, d’où les problèmes qui interviennent à chacune des phases.%%% %%% __Forming__ (Composition / Découverte et formation / Naissance du groupe / Gestation)%%% %%% Le groupe n’est pas une équipe mais une collection d’individus.%%% Tout à l’excitation de bosser sur un nouveau projet, le groupe se rassemble. C’est une phase facile puisque tous les espoirs sont permis.%%% Susciter l’intérêt, mettre en relation.%%% Comportement individuel motivé par le désir d’être accepté et d’éviter la controverse ou le conflit et recueil d’information sur les autres.%%% Niveau élevé de dépendance au leader formel pour l’orientation.%%% Peu de clarté des rôles et responsabilités des individus.%%% Évitement des confrontations sérieuses et des émotions fortes. Travail de routine.%%% Courtoisie, prudence, confusion, banalités.%%% %%% __Storming__ (Implication / Turbulence / Bouillonnement / Conflits et négociations)%%% %%% Après les premières esquisses communes vient la tempête, les confrontations et critiques voire les affrontements. Le groupe peut devenir une équipe si elle passe cette étape.%%% Brainstorming entre les membres ; peut être créatif (innovation, fertilisation) ou destructif (conflit d’idées, luttes d’influence).%%% Maintenir la cohésion, gérer les conflits.%%% Luttes de pouvoir, formation de cliques.%%% Augmentation de la clarté de l’objectif.%%% %%% __Norming__ (Harmonisation / Normalisation / Maturation / Acceptation et pérennisation)%%% %%% La tempête dépassée, on peut maintenant mettre en place une vraie structure de travail en équipe. C’est une phase où sont produits bon nombres d’outils communs.%%% Légitimer et incarner les normes de fonctionnement.%%% Définition des objectifs du groupe et des contributions de chaque membre. Formalisation de procédures.%%% Consolidation des « règles du jeu ».%%% Plus grande écoute entre les individus.%%% Cohésion, coopération, collaboration, implication.%%% Résistance au changement.%%% Plus grande clarté des rôles individuels.%%% %%% __Performing__ (Réalisation / Performance / Rendement / Délivrance / Optimisation du processus)%%% %%% Le travail collaboratif permet au groupe de réussir des performances qui dépassent la simple juxtaposition collaborative : la création de valeur est à son maximum.%%% L’équipe existe, les outils sont en place, les référentiels sont créés. L’équipe devient irrésistible…%%% Coordonner, motiver, arbitrer, « manager ».%%% L’équipe devient un méta-objet à part entière, qui subsume ses membres (Prax, 2003).%%% Interdépendance et flexibilité (tous les groupes n’atteignent pas cette étape).%%% Confiance qui permet les activités indépendantes des membres.%%% Identité et moral du groupe élevés.%%% Équilibre entre orientation vers la tâche et orientation vers les personnes.%%% Défi, créativité.%%% %%% __Adjourning__ (Conclusion / Dissolution ou Transformation / Acceptation de la séparation)%%% %%% L’équipe se sépare. Soit parce que le projet est terminé, soit par usure, après des échecs ou des déceptions, quand certains membres commencent à quitter l’équipe. Dans les deux cas, la situation peut être difficile à vivre.%%% Accompagner ou impulser.%%% %%% Recherche effectuée après la lecture du billet de Eric Laramée sur le Blog de Pyxis : ++[What about the team?|http://pyxis-tech.com/blog/2009/08/30/what-about-the-team/|en]++%%% %%% Voir aussi le billet de Mathieu Gandin ++[« Les différentes étapes d’une équipe pour devenir performante »|http://blog.octo.com/les-differentes-etapes-d%E2%80%99une-equipe-pour-devenir-performante/|fr]++ du 26/01/2010.

Centre de Services Agile pour Atos Origin Intégration

[((/dotclear/public/./.logo_atos_t.jpg|Atos Origin|L|Atos Origin, juin 2009))|/dotclear/public/logo_atos.jpg]Ca y est, l’avis d’attribution est paru le 21 août 2009 !%%% %%% Atos Origin Intégration a remporté le lot n°2 de l’++[appel d’offres réf. 2009/S 160-232532|http://ted.europa.eu/Exec?DataFlow=ShowPage.dfl&Template=TED/N_one_result_detail_orig.htm&docnumber=232532%202009&docId=232532-2009&StatLang=FR&TableName=TED_FR|fr]++ : « Développements agiles .Net et Java et architecture orientée services » de la ++[Banque de France|http://www.banque-france.fr/|fr]++.%%% %%% Valeur totale finale du marché : 6 722 210 € HT.

Mon blog a 1 an !

((/dotclear/public/feu_artifice.gif|Feu d’artifice|L|Feu d’artifice, aoû 2009))Ben voilà, 1 an, c’est passé vite. Au départ, c’était simplement pour enregistrer mon carnet d’entraînement d’Aïkido de n’importe où (chez moi, en vacances, au boulot, …).%%% %%% J’aurais pu simplement utiliser ++[Google Docs|docs.google.com/]++ mais je souhaitais aussi découvrir ce qu’il pouvait bien y avoir d’intéressant à tenir un blog !%%% %%% Finalement, ça m’a apporté :%%% %%% – une certaine indépendance vis-à-vis de mon entreprise ;-)%%% %%% – une grande liberté et convivialité pour créer ou entretenir mon réseau sur les sujets qui me tiennent à cœur ; du coup j’ai laissé tomber le réseautage social « officiel » : ++[LinkedIn|http://www.linkedin.com/]++, ++[Viadeo|http://www.viadeo.com/]++, ++[Copainsdavant|http://copainsdavant.linternaute.com/]++ et autres…%%% %%% – une certaine interdisciplinarité compte tenu des différents sujets abordés qui peuvent, de façon imprévu, s’entremêler…%%% %%% – un réflexe quotidien de veille (merci ++[GoogleReader|www.google.fr/reader/]++), de prise de notes, de synthèse voire de traduction d’articles de fonds (un ++[KM|http://fr.wikipedia.org/wiki/Knowledge_Management|fr]++ light et gratuit !)%%% %%% – un intérêt croissant pour rencontrer (virtuellement ou non) les auteurs des autres blogs dont je lis les billets chaque matin%%% %%% – enfin, la rencontre du moteur de blog libre ++[Dotclear|http://fr.dotclear.org/]++, à défaut de rencontrer son créateur français ++[Olivier Meunier|http://fr.dotclear.org/blog/post/2009/06/01/Au-revoir-et-a-bientot|fr]++.%%% %%% En tout 256 billets, soit environ 1 billet tous les 1,5 jours…%%% Je viens d’ajouter le ++[plugin Visites|http://www.k-netweb.net/blog/?post/2006/10/16/62-plugin-dotclear-2-visites|fr]++ pour afficher un compteur de visites.%%%

Estimation Agile et Cône d’incertitude

((/dotclear/public/logos/agile101_logo.png|Logo Agile101|L|Logo Agile101, aoû 2009))J’ai traduit un article intéressant de Agile101 : ++[Agile Estimation and the Cone of Uncertainty|http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/|en]++%%% %%% > Le __Cône d’incertitude__ est un terme utilisé en Gestion de Projet pour décrire le __degré d’incertitude existant aux différents stades d’un projet__.%%% > %%% > En bref, nous __devenons de plus en plus certains de nos estimations lorsque nous en apprenons plus__ sur ce que nous devons estimer.%%% > %%% > Dans les environnements de Gestion de Projet Agile, nous acceptons que les __projets portent une part d’incertitude__. Cette incertitude diminue à mesure que les décisions sont prises autour du périmètre et de la démarche – plus nous comprenons, plus nous sommes certains de nos estimations.%%% > %%% > Pour atténuer le risque d’estimations incorrectes, nous __réduisons la précision de nos estimations en fonction de ce que nous savons__ de ce que nous devons estimer. Cela nous aide à être plus exact.%%% > %%% > (Voir ++[Estimation logicielle : Le plus précis vous êtes, le moins exact vous serez|http://agile101.net/2009/07/17/software-estimation-the-more-precise-you-are-the-less-accurate-you-will-be/|en]++)%%% > %%% > __Exigences Agiles par ordre d’Incertitude__%%% > %%% > 1. Thème%%% > 2. Epic%%% > 3. User Story%%% > 4. Tâche%%% > %%% > (Voir ++[La différence entre les termes Agiles Thèmes, Epics et User Stories|http://www.fabrice-aimetti.fr/dotclear/index.php?post/2009/08/20/La-difference-entre-les-termes-Agiles-Themes-Epics-et-User-Stories|fr]++)%%% > %%% > __Techniques d’Estimation Agile dans une recherche de Précision__%%% > %%% > 1. Heures%%% > 2. Story Points%%% > 3. Taille de T-shirt%%% > %%% > __Estimer en Heures vs Fibonacci__%%% > %%% > Comme indiqué dans mon post ++[Estimation logicielle : Le plus précis vous êtes, le moins exact vous serez|http://agile101.net/2009/07/17/software-estimation-the-more-precise-you-are-the-less-accurate-you-will-be/|en]++, des études suggèrent que les __estimations qui ont lieu au cours de la Phase de Définition du Produit représentent entre 300% de moins et 0,75% de plus que ce que cela prend réellement pour construire le logiciel soit un coefficient multiplicateur de 16__. Le cône d’incertitude se rétrécit au fur et à mesure que vous éliminez les incertitudes.%%% > %%% > Dans les environnements Agile, nous utilisons __deux principales métriques d’estimation : Fibonacci et les Heures__.%%% > %%% > __L’Estimation basée sur les Heures__ s’explique de soi-même, toutefois, il convient de mentionner que les Équipes Agiles __estiment uniquement des Tâches en heures__. Par Tâches, je veux dire « Parties de User Story »… quelque chose de très petit qui devrait prendre quelques heures, certainement pas plus d’une seule journée à réaliser.%%% > %%% > Pourquoi ?%%% > %%% > Généralement, les __très grosses fonctionnalités sont plus complexes__ et devront/pourront probablement être décomposées en plus petits éléments : il __reste donc un certain nombre de décisions en suspens__ qui pourraient affecter la quantité d’effort requise pour réaliser la tâche.%%% > %%% > __Plus la tâche est importante, moins il y a de chances que vous soyez en mesure d’estimer__ le nombre exact de minutes/heures pour la réaliser (interruptions téléphoniques, pauses toilettes, réunions différées, …).%%% > %%% > En d’autres mots, __estimez de PETITES tâches en heures__.%%% > %%% > L’__Estimation basée sur Fibonacci__ est la deuxième métrique d’estimation Agile. Nous appelons cela Estimation en Story Points. Nous utilisons des Story Points pour estimer de grosses fonctionnalités : User Stories et Epics.%%% > %%% > Cela fonctionne comme suit :%%% > %%% > 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89%%% > %%% > En d’autres termes, un « 5 » équivaut à 5 fois plus d’effort qu’un « 1 » et un « 8 » à 8 fois plus d’effort qu’un « 1 ».%%% > %%% > Les Story Points __permettent de mesurer des choses que nous ne pouvons pas mesurer en heures__ – par exemple la complexité – comptabilisez vous une tâche pour chacune des discussions dont vous aurez peut-être besoin, à chaque fois que vous prenez 10 minutes pour répondre à une question ? Il est cependant relativement facile (lorsque vous vous y mettez) de comparer la taille d’une tâche / ensemble de tâches avec une autre tâche / ensemble de tâches. Estimer en __Story Points__ vous permet de prendre en considération toutes sortes de « choses » intangibles que vous pressentez sans pouvoir précisément les nommez.%%% > %%% > (Voir ++[Estimation logicielle : Le plus précis vous êtes, le moins exact vous serez|http://agile101.net/2009/07/17/software-estimation-the-more-precise-you-are-the-less-accurate-you-will-be/|en]++)%%% > %%% > L’__Estimation basée sur les Tailles de T-Shirts__%%% > %%% > Le « T-shirt Sizing » est une méthode d’Estimation Agile : elle est utilisée pour __estimer les exigences de haut niveau c’est-à-dire des Epics__, mais peut être aussi utilisée pour une User Story « bizarre ».%%% > %%% > En bref, __vous attribuez un nombre de story points à une taille de t-shirt__ par exemple, un XXL pourrait valoir « 55 points » comme le montre le schéma ci-dessous. Les tailles de T-shirt sont très utiles pour les Product Owners et/ou des non techniciens étant donné qu’elles sont totalement abstraites et non menaçantes (sans que cela devienne paternaliste… si vous voyez ce que je veux dire !). Elles sont faciles à comprendre.%%% > %%% > Lorsqu’on estime en taille de T-shirt, il est toujours important de définir l’échelle – __convenez à l’avance de ce que vaut un « Small », « Large » et « XX Large »__.%%% > %%% > Le __T-shirt sizing aura normalement lieu lors des Ateliers Exigences__ – ce qui aide le Product Owner et le Product Manager à avoir une idée de l’échelle, et ce qui aidera donc grandement au processus de priorisation.%%% > %%% > Comme toujours, __c’est l’Équipe Scrum qui attribuent les tailles de T-shirt aux Epics__. Le Product Owner et/ou le Product Manager ne sont pas autorisés à participer au processus d’estimation – ils peuvent en effet communiquer la vision du produit et des préconisations, mais les estimations appartiennent à l’équipe Scrum.%%% > %%% > __L’Estimation basée sur les Story Points__%%% > %%% > Une fois que les Epics ont été évaluées et priorisées pour la livraison, elles seront ventilées en User Stories par le Product Manager et le Product Owner.%%% > %%% > Les User Stories seront ensuite présentées aux ateliers exigences ultérieurs et estimées en Story Points lors du Planning Poker.%%% > %%% > (Voir ++[Réunions de planification de Sprints en Scrum : Qui, Quoi, Quand, Où, Pourquoi|http://agile101.net/2009/07/24/scrum-sprint-planning-meetings-who-what-when-where-why/|en]++)%%% > %%% > ++[Pour en savoir plus|http://agile101.net/category/project-management/agile-estimation/|en]++.%%% ((/dotclear/public/./.cone-of-uncertainty_t.jpg|Cône d’incertitude|L|Cône d’incertitude, aoû 2009))Pour voir le schéma dans sa taille normale, rendez-vous sur le ++[billet de l’auteur Tara Lee Whitaker|http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/|en]++.

5 conseils pour mener de bonnes revues de code

((/dotclear/public/programmation.gif|Programmation|L|Programmation, aoû 2009))J’ai traduit un excellent article de Alberto Gutierrez sur son blog : ++[« 5 tips to make good code reviews »|http://www.makinggoodsoftware.com/2009/08/06/5-tips-to-make-good-code-reviews/|en]++%%% %%% > Les revues de code sont l’une des plus importantes pratiques d’ingénierie.%%% > %%% > 1° __Les revues de code améliore la qualité du code grâce aux suggestions faites par le réviseur du code.__%%% > 2° __Les revues de code sont un excellent outil pour enseigner indirectement à d’autres développeurs les parties du système qu’ils auront à maintenir plus tard.__%%% > 3° __Les revues de code encouragent les gens à apprendre les bonnes pratiques avec d’autres développeurs.__%%% > 4° __Les revues de code peuvent être utilisées comme une validation de la clarté et la simplicité du système.__%%% > %%% > Vous avez peut-être remarqué que je n’ai pas mentionné dans cette liste que les revues de code pouvaient aider à trouver des bugs et veiller à faire respecter les normes de codage ; c’est parce que :%%% > %%% > 1. __Les revues de code NE DOIVENT PAS être effectuées pour trouver des erreurs dans le code.__%%% > 2. __Les revues de code NE DOIVENT PAS être effectuées pour faire respecter les normes de codage.__%%% > %%% > Il y a 10 ans, ces deux derniers points auraient effectivement eu un sens dans vos revues de code, mais plus maintenant. Aujourd’hui, cela doit normalement être couvert par vos tests automatisés et par certains outils d’audit de code qui devraient pouvoir vous encourager à respecter vos normes de codage. Cela dit, cela ne signifie pas qu’il est mauvais de détecter un bug ou un problème de respect des normes de codage, cela signifie que les trouver ne constitue pas un objectif de la revue de code.%%% > %%% > A partir de là, suivent mes cinq conseils pour faire de bonnes revues de code.%%% > %%% > __1. Faites fréquemment des revues de code__%%% > %%% > Moi-même, j’ai déploré que des revues de code soient menées tardivement, j’ai l’habitude de travailler dans une société où une énorme revue de code de l’application était censée être la dernière étape du développement, et c’était tout simplement inutilisable, avoir des revues de code tardives présentent les inconvénients suivants :%%% > %%% > – __Plus il y a de code à examiner, plus grande est la probabilité que le développeur n’accepte pas une suggestion de refactorer son code.__%%% > – __Plus le code est ancien, plus grande est la probabilité que le développeur soit personnellement attaché à son code.__ Je voudrais rappeler ici ++[l’un des plus grands problèmes des développeurs logiciels|http://www.makinggoodsoftware.com/2009/07/07/5-top-non-technical-mistakes-made-by-programmers/|en]++, leur ego, si un développeur conçoit quelque chose, le fait fonctionner, peu importe que ce soit infect, il y a beaucoup de chances que son ego interfère avec toute suggestion d’améliorer la conception.%%% > – __Plus la date de livraison est proche, moins on accorde d’importance aux améliorations du code.__%%% > %%% > Mon approche personnelle est de faire des revues de code à chaque fois que je viens de terminer de coder quelque chose de non trivial, et cela veut donc dire généralement plusieurs fois par jour.%%% > %%% > __2. Faites des revues de code informelles et courtes__%%% > %%% > Oubliez la check-list, tournez lui autour et demandez 5 minutes d’attention à votre collègue à côté de vous, si vous avez une check-list, l’une des 2 choses vont arriver :%%% > %%% > 1° Les revues de code seront uniquement limitées à ce qui est dans la check-list.%%% > 2° Les revues de code deviendront des formalités, les gens s’assiéront ensemble le moins longtemps possible et prétendront qu’ils se soucient du code.%%% > %%% > Mener des revues de code courtes et informelles vous aidera à engager des conversations ouvertes dans lesquelles la personne ne se sent pas « auditée », mais plutôt conseillée.%%% > %%% > __3. Réalisez vos revues de code avec différents réviseurs__%%% > %%% > C’est une bonne idée, si possible, de ne pas toujours passer par la même réviseur de code, il y a trois raisons principales pour rechercher différents réviseurs chaque fois que vous voulez mener une revue de code :%%% > %%% > 1° C’est bien de disposer de différents points de vue.%%% > 2° Plusieurs personnes seront capables de maintenir votre code dans l’avenir.%%% > 3° C’est une équipe qui mène cette activité.%%% > %%% > __4. Conservez une attitude positive__%%% > %%% > Encore une fois, rappelez-vous ++[l’un des pires problèmes des développeurs|http://www.makinggoodsoftware.com/2009/07/07/5-top-non-technical-mistakes-made-by-programmers/|en]++, leur ego, avoir une attitude positive contribuera à rendre la revue de code beaucoup plus agréable, et tous les participants seront plus enclins à accepter vos suggestions, et n’oubliez pas : vous n’êtes pas le code !%%% > %%% > __5. Apprenez à apprécier les revues de code__%%% > %%% > C’est le plus important conseil, si vous êtes dans une équipe où les gens apprécient les revues de code, vous entrerez dans une dynamique où tout le monde sera engagé à fournir un code de qualité qui ne semble pas bon uniquement pour eux-mêmes, mais à toute l’équipe.%%%

La différence entre les termes Agiles Thèmes, Epics et User Stories

((/dotclear/public/logos/agile101_logo.png|Logo Agile101|L|Logo Agile101, aoû 2009))Je viens de traduire un article intéressant de ++[Agile101|http://agile101.net/|en]++ : ++[« The Difference Between Agile Themes, Epics and User Stories »|http://agile101.net/2009/08/10/the-difference-between-agile-themes-epics-and-user-stories/|en]++. Franchement, je ne connaissais pas les termes agiles Thèmes et Epics…%%% %%% > __Thèmes__%%% > %%% > Un Thème est un __objectif de très haut niveau qui englobent les projets et les produits__. Les Thèmes peuvent être divisés en sous-thèmes, qui sont plus spécifiques au produit. Sous sa forme la plus fine, un Thème devient un Epic.%%% > %%% > Les Thèmes peuvent être __utilisés aussi bien au niveau d’un Programme que d’un Projet pour le cadrer__ et __donner une vision claire__.%%% > %%% > __Epics__%%% > %%% > Une Epic (Epopée ?) est un __ensemble de User Stories__. Vous aurez peu de chance d’introduire un Epic dans un sprint sans d’abord le décomposer en User Stories, afin de réduire le niveau d’incertitude.%%% > %%% > Les Epics __peuvent également être utilisés aussi bien au niveau d’un Programme que d’un Projet__. Pour plus de détails, je vous renvoie sur ++[Agile Epic Board|http://agile101.net/category/programme-management/agile-epic-board/|en]++.%%% > %%% > __User Stories__%%% > %%% > Une User Story est une exigence __Indépendante, Négociable, de grande Valeur, Estimable, Succincte et Testable (« Acronyme INVEST »)__. En dépit d’être indépendantes, c’est-à-dire qu’elles n’ont pas de dépendance directe avec d’autres exigences, les User Stories peuvent être regroupées en Epics sur la Roadmap du Produit.%%% > %%% > Les User Stories sont géniales pour des Equipes de Développement et Chefs Produits car elles sont faciles à comprendre, à discuter et à prioriser ; elles sont plus largement utilisées au niveau du Sprint. Les ++[User Stories seront souvent décomposées en Tâches|http://agile101.net/category/project-management/product-backlog-sprint-backlog/|en]++ au cours du processus de Planification d’un Sprint, sauf bien sûr si les stories sont assez fines pour être directement chiffrées.%%% > %%% > __Hiérarchie des différents Formats d’Exigences (Thèmes, Epics, User Stories, Tâches) :__%%% > %%% ((/dotclear/public/./.themes-epics-user-stories-tasks_t.jpg|Themes, Epics, User stories, Tasks|L|Themes, Epics, User stories, Tasks, aoû 2009))Pour voir le schéma dans sa taille normale, rendez-vous sur le ++[billet de l’auteur Tara Lee Whitaker|http://agile101.net/2009/08/10/the-difference-between-agile-themes-epics-and-user-stories/|en]++.

Orange Business Services et les méthodes agiles

((/dotclear/public/logos/OBS.jpg|Orange Business Services|L|Orange Business Services, aoû 2009))Je viens de tomber sur une page du site ++[Orange Business Services|http://www.orange-business.com/fr/|fr]++ qui vante auprès de ses clients les mérites des méthodes agiles (Scrum + XP) sur ses projets : ++[« Relation client multimédia : pourquoi Orange ? »|http://www.orange-business.com/fr/entreprise/thematiques/relation-client-multimedia/pourquoi-orange/index.jsp|fr]++