Scrum ou XP ? Scrum ET XP !

[((/dotclear/public/./.scrumxp_t.jpg|Scrum et XP, les bons amis|L|Scrum et XP, les bons amis, fév 2009))|/dotclear/public/scrumxp.gif]Scrum (méthode agile pour la gestion de projets) et XP (eXtreme Programming, méthode agile pour l’ingénierie logicielle) sont complémentaires et semblent de plus en plus souvent utilisés ensemble :%%% Selon un ++[rapport Version One|http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf|en]++ :%%% – 49 % des Équipes Agile utilisent SCRUM,%%% – __22 %__ utilisent un mélange SCRUM / XP,%%% soit au total 71% sur SCRUM ! %%%

L’organisation d’une équipe de développement logiciel

[((/dotclear/public/./.ecu_orga_equipe_dev_t.jpg|L’organisation d’une équipe de développement logiciel|L|L’organisation d’une équipe de développement logiciel, fév 2009))|/dotclear/public/ecu_orga_equipe_dev.jpg]Cet ++[article|http://manu40k.free.fr/articlePratiquesDEquipe.pdf|fr]++ décrit l’organisation vers laquelle une équipe de développement de logiciels a convergé pour améliorer son efficacité et sa motivation. Il ne s’agit pas d’un standard d’organisation a priori pouvant être mise en place sur un projet. Il s’agit plutôt d’une solution empirique décrite a posteriori. Cette description est une photo des pratiques d’une équipe à un moment donné dans l’évolution de son organisation pour mener un projet. Dans leur démarche, les développeurs se sont largement inspirés du Lean et du développement logiciel Agile, en particulier de Scrum et de l’eXtreme-Programming :%%% * l’Espace partagé : l’équipe s’approprie un espace partagé de travail * le Pair-programming : * la War-room : ce qui est important pour le projet est visible * le Produit : vugarisation du Produit * le Processus de développement : vulgarisation du Processus de développement * l’Architecture : vulgarisation de l’architecture de la solution retenue * le Value-Stream-Mapping : * le Task-board (Kanban des exigences + Kanban des activités techniques non fonctionnelles) : l’équipe se gère au jour le jour * le Daily-stand-up-meeting : l’équipe reste synchronisée * la Composition des équipes * le Blocking-board * la Boîte à idée * le Backlog (Backlog produit + Backlog de l’itération en cours) : chaque membre de l’équipe a rapidement accès aux priorités du projet * le Burndown-chart (Release burn-down chart + Iteration burn-down chart) : chaque membre de l’équipe sait où et comment va le projet * les Métriques * les Jalons * le Niko-Niko : vérifier la corrélation entre la santé de l’équipe et la santé du projet * « Done » c’est « Done » : la définition partagée du travail terminé * le Gizmo ou sémaphore d’intégration : synchronisation avec la base commune de code * le Safe deliver : script de livraison si tous les tests passent avec succès * Bob the Builder : le poste d’intégration continue * le Groove : flux constant de travail terminé * le Vidéo-projecteur : à demeure * Chef de projet, ScrumMaster et ProductOwner * le Chaos : l’équipe fusionne, s’affirme et s’identifie * la Bande à part * le Management : style adapté à des équipes solidaires * Objectifs individuels vs Objectifs d’équipe * la Main courante * la Montée en charge de l’équipe * Apprendre : un wiki est disponible pour publier sans contrainte %%%  »Vu sur le ++[Blog d’Emmanuel Chenu|http://emmanuelchenu.blogspot.com/|fr]++. »

Principe de l’utilité marginale décroissante

((/dotclear/public/utilite_marginale.png|Utilité marginale décroissante|L|Utilité marginale décroissante, fév 2009))Le point de départ est la fonction d’__utilité__. On distingue :%%% – l’__utilité totale__, qui est l’intensité de satisfaction obtenue par la consommation d’une quantité, d’un bien.%%% – l’__utilité marginale__, qui est le niveau de satisfaction procurée par la dernière unité consommée d’un bien ou par chaque unité supplémentaire d’un bien.%%% En 1854, l’allemand Heinrich Gossen a énoncé la loi dite de Gossen : « l’intensité d’un bien plaisir qui se prolonge diminue et finit par disparaître quand l’individu parvient à satiété ». %%% Ainsi, si la première gorgée de bière procure un plaisir ineffable, la seconde est déjà moins bonne, et ainsi de suite, jusqu’à arriver au moment où l’envie se tarit. Cela signifie que l’utilité de chaque nouvelle gorgée de bière est inférieure à celle de la précédente : l’utilité marginale est décroissante.%%% C’est ce qui sera repris par l’école néoclassique en retenant l’hypothèse selon laquelle __l’utilité marginale procurée par chaque dose supplémentaire d’un bien consommé va en diminuant et devient nulle à partir d’un certain seuil appelé « point de satiété »__. Au-delà de ce point, l’utilité marginale de doses supplémentaires peut devenir négative et se transformer en __désutilité__.%%% %%% Principe mis en pratique dans un article très intéressant de Guillaume Bodet sur le Blog Xebia France : ++[Pourquoi les projets agiles ne peuvent pas (vraiment) être menés au forfait|http://blog.xebia.fr/2009/02/04/pourquoi-les-projets-agiles-ne-peuvent-pas-vraiment-etre-menes-au-forfait/|fr]++%%% %%% Extrait : > « Logiquement, lorsque la valeur totale du logiciel atteint le prix du forfait, le projet devrait s’interrompre. A ce moment, la marge du fournisseur est positive, et le client a obtenu une valeur d’usage à hauteur de son investissement. Malheureusement, rien n’incite dans ce modèle le client à déclarer le projet achevé. En effet, ici, le coût marginal d’un cycle est nul – réaliser une itération supplémentaire n’impute pas le budget total. Le client est donc incité à prolonger les développements aussi longtemps que la valeur marginale d’une itération est positive, poussant virtuellement le fournisseur à boire le calice jusqu’à la lie.%%% > Le seul moyen pour le fournisseur de maîtriser ce risque est de définir en amont – contractuellement – le périmètre de sa production logicielle. Il demande au client de s’engager dès le départ sur des spécifications détaillées du logiciel, et protège ce périmètre en le plaçant sous un strict contrôle du changement – chaque évolution faisant l’objet d’un juteux avenant. Dès lors le changement devient un coût pour le client, qui a le choix entre le refuser (au risque de mécontenter ses utilisateurs) ou le payer (au risque de voir son budget exploser de façon incontrôlée). L’un des principes cardinaux des méthodes agiles, l’acceptation du changement, devient tout simplement impraticable. »

Différence entre Implication et Engagement (Agile/Scrum)

Ken Schwaber (who co-developed the Scrum process with Jeff Sutherland in the early 1990s) introduced the concept of chickens and pigs with the daily scrum. Each attendee is either a chicken or a pig. The metaphor comes from the idea of a project to open a restaurant of bacon and eggs. In such a project, the pig is said to be committed but the chicken is merely involved.%%% %%% [((/dotclear/public/./.scrumtoon_m.jpg|Chicken and Pig Fable|C|Chicken and Pig Fable, fév 2009))|/dotclear/public/scrumtoon.jpg]%%% [((/dotclear/public/./.scrumtoon-french_m.jpg|Scrumtoon in French|C|Scrumtoon in French, juin 2009))|/dotclear/public/scrumtoon-french.jpg]%%% The various translations of these cartoon are available on ++[Implementing Scrum site|http://www.implementingscrum.com/translations/|en]++.%%% %%% Committed and involved could be mapped to the RACI designations for roles and responsibilities. This might help to map an agile process into a more formal or traditional organization : * Committed (pig) is the equivalent of R(esponsible) and A(ccountable) * Involved (chicken) is the equivalent of C(onsulted) and I(nformed)%%% %%% [((/dotclear/public/./.poulet_t.jpg|poulet|L|poulet, avr 2009))|/dotclear/public/poulet.jpg][((/dotclear/public/./.cochon_t.jpg|cochon|L|cochon, avr 2009))|/dotclear/public/cochon.jpg]((/dotclear/public/poule_32x32.gif|Poule|L|Poule, mai 2009))((/dotclear/public/cochon_32x32.gif|Cochon|L|Cochon, mai 2009))%%% %%% %%% On Agile projects the term Pig has come to describe all the developers, designers and testers who commit to the actual work. The term Chicken is applied to everyone else who make intellectual contributions but do not commit to any work.%%% %%%