2009/06/30
Newsletter Mai et Juin 2009
Last changed: 30 juin 2009 23:27 by Antoine Vernois
EditoPar Luc Legardeur C'est l'été. Déjà !. Que le temps passe vite ! Pour le SUG ces 6 premiers mois d'activité ont été riches en activités. Nous sommes plus de 340 membres, nous nous sommes rencontrés deux fois à Paris (à l'occasion de la soirée inaugurale et au World Café mais aussi en Province grâce à Meetup à Rennes, Nantes et Bordeaux, publié 3 newsletter avec celle-ci, lancé une enquête nationale à laquelle plus de 200 personnes représentant quelques 150 entreprises ont répondu. Merci à toutes et à tous A propos de l'enquête, où en est on ? Elle est finie mais nous avons dû procéder à une traduction en anglais pour la faire diffuser au-delà de la communauté francophone et obtenir la co-signature de Jim Cundif, le Président de la Scrum Alliance. Nous devrions donc la rendre disponible sous huitaine. Les résultats, vous le constaterez, sont très encourageant et nous sentons un véritable tournant dans l'histoire agile française. Merci donc aux nombreuses et nombreux participants. C'est Borland qui a gagné la Wii au tirage au sort du 18 Juin. En ce qui concerne les activités du bureau du SUG, nous nous sommes réunis afin d'élire un nouveau secrétaire et c'est Nicolas Martignole qui prend cette responsabilité. Nous nous verrons le 24 Septembre à l'EPITA également. L'agenda de la soirée vous sera fourni dès la rentrée. Bonnes vacances à toutes et à tous. Luc Legardeur. Retour sur XP Day France 2009Par Yannick Ameur Organisateurs :
PO :Laurent Bossavit et le board de XP France Aides :
XP day en quelques chiffres :
Nos enjeux et chalenges
Ma conclusionAvec tous les retours positifs que nous avons : Liste des retours sur le dernier XP Day 2009 Je ne prends pas vraiment de risque en vous disant que ce fut une "Success Story". Actuellement, nous préparons l'édition 2010 qui se nommera ... ??? à suivre dans le prochain numéro Retour sur le Scrum Café à Bordeaux le 11 juin 2009Par Philippe Launay Le 11 juin est une date importante à Bordeaux. En effet, pour la première fois, SCRUM a réuni une vingtaine de personnes autour de ce sujet. Après un accueil convivial, chacun a pu se présenter et indiquer son niveau de connaissance ou d'attente en ce qui concerne SCRUM. Après une introduction de la part de nos hôtes Capgemini, une première thématique a été lancée, en rapport avec le changement de modèle économique sous-jacent à l'emploi d'une méthode agile, en particulier SCRUM. La question est lancée, mais reste pour l'instant d'actualité. La rencontre s'est poursuivie par un retour d'expérience, ce qui a permis ensuite d'échanger autour. La discussion a été très ouverte, très enrichissante et alimentée par des opinions divergentes, plus ou moins radicales. Tout cela était tellement prenant, que le temps accordé à la discussion a été totalement insuffisant : de trente minutes nous sommes passés à presque une heure trente. Au plus grand plaisir de tous les participants. De nombreux sujets ont été abordés, certains très passionnés comme faut-il garder de la documentation et laquelle ?, ou le rôle du Product Owner, mais la confrontation des divers points de vue ou des diverses expériences a permis à chacun de sortir de cette rencontre avec une certitude : Avancer avec SCRUM. Ce premier rendez vous s'est conclu sur la volonté de renouveler ce type d'évènement, probablement sur un créneau horaire en fin de journée pour attirer plus de monde. Alors qu'on se le dise, en Septembre, SCRUM aussi fera sa rentrée à Bordeaux et gageons que nous serons encore plus nombreux! Retour d'expériencePar Claude Aubry et Antoine Vernois Interview de Julien Patou de la société People In Action SUG : Tu peux nous présenter la société et le projet ? Julien Patou : People In Action (PIA) est une société qui a 5 ans avec un effectif d'une quinzaine de personnes qui se positionne sur les applications internet riches (RIA). Les projets sont des logiciels sur mesure livrés clés en mains souvent orientés cœur de métier et stratégiques pour le client. Dernièrement, nous avons travaillé sur des sujets assez critiques notamment pour les banques. Au niveau technologie, c'est Adobe/Flex pour l'IHM. Du coté serveur c'est J2EE/Hibernate/Spring/Oracle/.... Le projet en question porte sur la gestion d'assurances vie pour l'un des leaders mondiaux de la gestion de fortune (souscription, arbitrages, versements, ...). SUG : Qui a demandé à introduire Scrum ? JP : Scrum a été introduit chez PIA en juin 2007 sur un projet auquel je n'ai pas participé. Le bilan a été très positif et la Direction a souhaité le généraliser à tous les projets dès 2008. SUG : Une question critique dans ce genre de relation : qui va jouer le rôle de Product Owner ? JP : Un des deux dirigeants de notre société avait la casquette AMOA et Product Owner. SUG : Le PO était donc de chez vous ? JP : Oui, complètement. Une fois le projet signé, dans une première phase, le PO a rédigé les use cases de la V1 avec le chef de projet de la banque. SUG : Use cases ou user stories ? C'est bien des use cases. SUG : Combien de temps a duré le sprint 0 ? JP : Un bon mois et demi. SUG : C'est à ce moment là que le backlog de produit a été constitué ? JP : Oui après, à partir des use cases on a fait un backlog de produit. Deux versions de l'application ont été prévues : la v1 en 6 mois et la v2 6 mois de plus. SUG : Des sprints de quelle durée ? JP : Au départ, on a fait des sprints de 3 semaines. Puis on est revenu sur des sprints de 2 semaines car c'était trop long. On a fait 23 sprints en tout. SUG : A Paris ou à Toulouse ? JP : 1 fois sur trois, c'était à Paris ou Toulouse pour qu'on se voit tous. 2 fois sur 3, cela se faisait à distance en vidéoconférence. SUG : Le client était toujours là ? C'était plusieurs personnes ? JP : En général, il y avait toujours au moins 2 ou 3 personnes plus le PO. SUG : Le client et le PO ? JP : Oui, ils se voyaient quelques jours avant la fin de sprint, parfois même pendant, pour établir les nouvelles fonctionnalités et les prioriser. SUG : Vous utilisiez un outil ? JP : Oui, Rally Dev, qui permet bien le travail à distance. SUG : Les clients utilisaient Rally ? JP : Oui, ils s'en servaient pour rentrer des bugs et des defects. SUG : Le client a t'il pu redéfinir le périmètre des fonctionnalités ? JP : Oui, en continue. Pour les petites fonctionnalités, ils le faisaient directement via des defect-request de Rally. Pour les choses plus importantes c'était fait en concertation avec le PO. Parfois, en plein cours de sprint, une nouvelle fonctionnalité arrivait nous poussant à en sortir d'autres du sprint backlog en cours. SUG : C'est pas tout à fait la règle ? JP : Non, mais le projet était très critique pour le client. Au départ, on pensait utiliser Scrum de façon stricte, au final on est resté assez souple par rapport à ça. SUG : L'équipe était globalement à Toulouse ? JP : Sur Toulouse on a été jusqu'à 4 développeurs, et 2 3 maximum sur Paris en plus du PO et du Scrum Master. SUG : Le projet a été livré ? JP : oui, la v2 a été livrée fin mai, la v1 en octobre 2008. On n'a pas livré à chaque fin de sprint, mais entre la v1 et la v2 il y a eu des livraisons intermédiaires, des bug fixs, mais aussi de nouvelles fonctionnalités. 4 ou 5 livraisons après la v1. SUG : C'était pour mettre en production ? JP : Oui, sur Paris d'abord puis à l'échelle nationale ensuite. SUG : C'était un appel d'offre, comment avez-vous géré les changements de périmètre ? JP : D'un point de vue client, on peut voir la gestion de projet avec deux approches : soit c'est à budget fixe, soit c'est à périmètre fixe. SUG : Vous avez mesuré la vélocité ? JP : A chaque fin de sprint on mesurait la vélocité. On ne s'en est pas servi de façon très efficace : dans le sens où la vélocité était très SUG : La satisfaction du client au final ? JP : Très bonne. D'autant que ceux qui ont initié le projet étaient soumis à une pression importante de la part de leur direction car il s'agissait d'un point vraiment critique pour eux, le véritable cœur de leur métier. Ils étaient donc vraiment contents que les délais aient été respectés tout comme les fonctionnalités avec une application robuste. SUG : Il y avait une anticipation sur l'IHM ? JP : Oui, chez PIA on insiste beaucoup sur l'ergonomie, l'ergonomie cognitive même. Il y a un designer, transverse à tous les projets, qui ne fait que ça. Après les story boards low fidelity dont je parlais tout à l'heure, il réalise des story boards high fidelity qui définissent les interfaces au pixel près. Cela est fait en étroite collaboration avec le client dans le respect de sa charte graphique. SUG : Il y a eu des modifications de cette interface ? JP : oui, à chaque démonstration le client faisait ses remarques. Pour nous, au dev, ce qui importait le plus c'était les fonctionnalités. Le client, lui, voyait en premier les défauts graphiques : un trait mal placé, une couleur mal adaptée, etc. Grâce aux démonstrations régulières, on a pu faire les retouches en continu. Avec une unique revue, il aurait listé cinquante pages de commentaires qu'on n'aurait jamais pu traiter. C'était du refactoring permanent. SUG : Le client utilise Scrum pour ses développements internes ? JP : Non, pas du tout. A ma connaissance en tout cas. SUG : Vous avez tout de même un fonctionnement peu standard: PO interne, équipe sur deux sites,... Vous avez eu des problèmes ? JP : Le PO interne n'a posé aucun problème. En fait, il avait une mission officielle d'AMOA donc il était censé vraiment connaitre le produit. Il faisait réellement office de client. Le fait que l'on travaille en offshore ou nearshore n'a posé aucun problème. On faisait les daily meeting tous les matins ponctuellement en mettant à jour le sprint backlog. Dès qu'il y avait des problèmes ou des questions, on s'appelait. Au bout d'un moment, on avait toute la connaissance fonctionnelle à Toulouse et on pouvait passer plusieurs jours sans avoir de questions à poser. Dans l'utilisation de Scrum, je dirais que même au bout d'un an, même en connaissant bien le produit, on se trompait souvent dans les estimations. En général on se trompait dans les deux sens, et en moyenne ça s'équilibrait. Ça impliquait tout de même que parfois on avait à rajouter ou enlever des User Stories au sprint backlog. Ça n'était pas vraiment gênant. Les développeurs ont été complètement satisfaits de ce fonctionnement. SUG : Vous avez mis des pratiques d'ingénierie en place ? JP : On travaillait en Test Driven Developpment. Écriture des tests d'abord et écriture du service/couche business ensuite. On pratiquait aussi le refactoring et l'intégration continue. SUG : Vous aviez des post-it au mur ? JP : Non, nous avons essentiellement utilisé l'outil. Nous utilisions les post-it pour les rétrospectives : la timeline des évènements du sprint, ce qui s'est bien passé, ce qui était moins bien, les actions à mettre en place au prochain sprint. SUG : Comment s'est passée la transition à Scrum ? JP : Scrum, c'était un choix de la direction. A Paris, nous avons une personne qui est le responsable méthode et qualité qui connait très bien cette approche. SUG : Merci Julien pour ce très beau retour d'expérience. JP : Merci à vous. Des nouvelles de nos régionsLes Bretons AgilesLes mois de Mai et Juin ont été particulièrement chargés sur Rennes autour de l'agilité:
il était temps de faire un premier bilan: Les forums Grafotech Agile Les échanges lors de cette session démontrent un réel interêt pour ces méthodes. La communauté AgileRennes Pacte Novation a accueilli une douzaine de personnes le 17 Juin pour une session Le groupe Nantais compte aujourd'hui une vingtaine de membres.
Ces deux groupes Rennes-Nantes travaillent ensemble à la promotion de l'Agilité en générale et Scrum en particulier et ont créé depuis le début de l'année une dynamique locale qui permet aux acteurs de l'Agilité d'être visibles, aux early adopters de partager leur expérience. Cette dynamique va encore s'accentuer à la rentrée avec Agile Tour dont Rennes sera ville étape le 1er Octobre Apports d'un coach accompagner le chef de projet vers son nouveau rôle (4)Par Véronique Messager « Les individus et leurs interactionsavant les processus et les outils » Extrait, Manifeste Agile, 2001
Face à l'adoption d'une nouvelle méthodologie agile, le chef de projet est confronté à deux changements : le premier concerne l'évolution de son propre style de management, le second concerne la transformation de son équipe (évolution méthodologique et technique, mais aussi culturelle et comportementale).
Premier apport du coach : aider le chef de projet à intégrer et s'approprier la dimension du changement (voir newsletter de Mars 2009). Ce changement concerne son style de management, moins directif, peut-être, plus « délégatif » pour permettre à l'équipe de s'auto responsabiliser et de gagner en autonomie ; son mode de communication, plus « sincère et honnête » (XP). Le coach sensibilise le manager à l'intérêt qu'il a à écouter ses collaborateurs et à entrer en communication avec eux.
Le deuxième apport du coach est d'amener le chef de projet à accepter de ne plus « faire » mais de « faire faire ». En effet, le chef de projet agile n'est plus un apporteur de solutions ni un donneur d'ordres, mais un « leveur d'obstacles ». Ses compétences techniques, « prétendument supérieures » ou son autorité de facto ne légitiment plus son positionnement. Il doit consentir à se consacrer davantage aux interactions au sein de l'équipe et à celles de l'équipe avec l'extérieur. Avec bienveillance, le coach permet au coaché de s'interroger sur sa capacité à se détacher de l'envie de tout contrôler ; il l'assiste dans sa recherche de nouvelle légitimité.
Écoute et efficacité dans la levée d'obstacles sont deux moyens de gagner l'adhésion et la reconnaissance des membres de l'équipe. Mais la délégation soulève la question du droit à l'erreur. Souvent, un manager qui ne délègue pas assez argue du fait que « l'on n'est jamais aussi bien servi que par soi-même », ou que « ce n'est pas assez rapide » ou encore qu' il « ne peut compter sur les autres ! »... Dans une démarche d'amélioration continue, l'expérimentation est un droit ; l'erreur est donc acceptée ainsi que le droit à reconnaître ses erreurs. Le troisième apport du coach peut être de susciter, chez le chef de projet, une réflexion sur son rapport à l'erreur ; il peut l'aider à réfléchir sur les bénéfices qu'il peut tirer, en termes de sérénité et de liberté, de la responsabilisation et de l'autonomie de son équipe. Il l'amène à réfléchir sur ses propres erreurs et sa façon d'appréhender les erreurs commises dans l'équipe.
Voici quelques exemples où le rôle du coach facilite cette transformation du rôle du chef de projet, progressivement, et non dans la douleur. Bien d'autres circonstances peuvent bénéficier de l'apport d'un coach...
A suivre....le mois prochain. Les prochains événementsPar l'équipe de la Rédaction Evénements en France
Formations ScrumMaster certifiantes
Formations "ScrumMaster avancé" certifiantes
Formations Scrum
Formations Scrum Avancées
Formations Product Owner certifiantes
Formations Product Owner
|
06 juil. 2009
04 mai 2009 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
