Retour sur la soirée Scrum User Group

Mardi soir j’ai participé à la soirée anniversaire du French Scrum User Group.

Direction Microsoft à Issy Les Moulineaux.

A propos si vous recherchez des locaux, il y a de la place !

Accueil

J’entre donc dans l’amphi Grand bleu pour l’ouverture de la soirée. Salle très impressionnante que l’on remplit à moitié au début. On commence par une vidéo de Ken Schwaber en personne buvant une flûte de champagne pour fêter cet anniversaire, clin d’oeil plutôt sympa

Ensuite Luc Legardeur, président du Scrum User Group et de Xebia, fait le bilan de la première année. Il remarque que le public se diversifie et qu’il n’y a pas que des SSII dans la salle. Quelques chiffres, le SUG en France c’est 400 membres et 11 rencontres sur l’année pour un budget autour de 13 000 Euros. Un petit scoop pour la fin, le Scrum Gathering d’automne pourrait être organisé en France.

Roman Pichler

On enchaîne par une excellente présentation de Roman Pichler à propos du rôle de Product Owner. Il nous présente plusieurs types de Product Owner à éviter.

Le proxy Product Owner

C’est le cas typique que je retrouve dans ma société. Avec Scrum nos chefs de projet ont un peu de mal à trouver leur place. Comme nos MOE n’ont jamais le temps de jouer le rôle de Product Owner, c’est le chef de projet qui s’y colle. Il gère très bien « l’administratif » mais ce n’est pas lui qui est maître de la « vision produit » c’est la MOE ! Dans ce cas on parle de proxy product Owner. Ca ne fait donc que ralentir les décisions. Roman parle même d’anti Pattern.

Le Product Owner faible

Si le Product Owner doit faire valider toutes ses décisions par son responsable, c’est dur d’avancer sereinement. Le Product Owner doit avoir le pouvoir de réaliser sa vision du produit.

Le Product Owner surchargé

Un Product Owner peut gérer au maximum trois projets en même temps (en fonction de leur importance). Il ne doit pas non plus tout gérer seul, il a surtout un rôle de leader.

Le Product Owner passif

Roman dit qu’il rencontre ce type de Product Owner avec des personnes habituées aux livraisons « Big ban » (j’écris 3 lignes de spec et je reviens 3 mois plus tard pour constater que je n’ai pas ce que je voulais). En Scrum le Product Owner doit s’investir tout au long du projet.

Le Product Owner Distant

Là aussi on rencontre souvent ce cas pendant une prestation où le client n’est pas dans les bureaux de la SSII. Ca ralentit clairement la productivité de l’équipe. Roman préconise que le Product Owner soit au minimum présent avec l’équipe les deux premiers et les deux derniers jours du sprint.

Le Product Owner sans vision

Le Product Owner doit présenter et partager la vision du produit à l’équipe. Il doit savoir ce que la prochaine release va contenir.

Roman est un très bon orateur et ses différentes expériences enrichissent son discours.

Les Ateliers

Après cette présentation très dynamique, plusieurs ateliers dans 4 salles différentes sont organisés. J’en ai suivi trois.

Collaborer avec Scrum grâce à Visual Studio

Xavier Warzee de Microsoft nous présente la nouvelle version de Visual Studio qui intègre la gestion d’un product Backlog. Ca ressemble quand même beaucoup à un MS Project « Scrumisé ». Alors oui ça va plaire à nos managers grâce à tous les chiffres et les graphs que ça génère, mais j’ai quand même la désagréable impression qu’on essaie de nous revendre un Excel en plus cher.

Julien Corioland d’Access it présente son application de gestion d’affectation de tâche sur la table surface. C’est bien-sûr relié à une base Visual Studio. Alors oui c’est beau, amusant mais est-ce que c’est exploitable ? J’en suis moins sûr. Sans oublier qu’une table surface c’est 12 000 $, soit à peu près 1 million de post-it.

Pour finir c’est Mathieu Szablowski de Pyxis qui nous montre une extension qu’il a réalisée pour Visual Studio. Déjà ce qui me choque c’est qu’il fait une démo de Visual Studio depuis son Mac Book Pro. C’est quand même un peu tordu d’utiliser un Mac pour utiliser Visual Studio Sinon pour le fond j’ai toujours du mal à comprendre l’intérêt de ces extensions par rapport à une bonne vieille feuille Excel. Bon si, j’avoue, le seul intérêt que j’y vois c’est le travail collaboratif.

Bref une première session assez décevante. On a beaucoup parlé de Microsoft et très peu de Scrum au final. L’agilité en ce moment c’est à la mode et on a vraiment l’impression que les éditeurs ajoutent le mot Scrum un peu partout pour vendre leur produit. La session d’après n’a fait que confirmer cela.

Modélisation pour SCRUM avec RSA

C’est le titre qui m’a attiré. J’étais curieux de voir comment IBM (les rois du RUP) allait nous parler de Scrum. Et bien j’ai pas été déçu. Dès le premier slide j’ai failli m’étouffer. Regardez sur l’image la phrase « Adoption de Scrum avec un phasage RUP ». En fait ce n’est pas Adoption qu’il fallait noter mais plutôt Adaptation à mon avis. Alors oui RUP intègre la notion d’itération, mais c’est bien le seul point commun avec Scrum.

Par contre je suis toujours fan de modélisation et reste convaincu que cela peut tout à fait s’intégrer dans une démarche agile. On peut même faire du MDA ! Sur ces points j’étais en phase avec IBM. Mais si on regarde de plus près RUP, comment gérer la douzaine de rôles différents définis par RUP en Scrum ? C’est juste impossible. Et quand IBM nous a dit que l’architecture de l’application présentée était gérée par des personnes ne faisant pas partie de l’équipe de dev, on sent bien que la notion de Team est encore loin.

Avec tout ça je ne vous ai même pas parlé de Team Concert et de RSA, mais franchement là encore c’est vraiment intégrer Scrum dans un outil pour des raisons marketing. Comme si RSA n’était pas déjà assez lourd et lent, ils ont ajouté un mini Excel. Ca m’a un peu énervé, je n’insiste pas.

IceScrum

La dernière présentation va-t-elle sauver ma soirée ? Et bien oui ! Vincent Barrier va enfin faire une présentation « Scrum centrique ». La grosse différence c’est que Ice Scrum a été créé pour faire du Scrum contrairement aux deux autres ou Scrum a été intégré au chausse pied.

Donc IceScrum permet de faire du suivi de projet Agile en respectant toutes les phases et tous les rôles définis par Scrum. C’est un outil Open Source (GPL) disponible sous la forme d’un WAR. Je compte bien l’essayer rapidement pour l’utiliser sur nos projets.

Avant IceScrum était géré par des étudiants encadrés par Claude Aubry, mais maintenant une société a été montée pour prendre en charge le développement. IceScrum Technologies va donc vendre support et évolutions spécifiques. Claude Aubry reste sur le projet en assurant le rôle de Product Owner du produit.

Bilan

Ouf enfin à manger et à boire !

Comme vous l’avez compris je n’ai pas été emballé par toutes les présentations. Il ne faut pas oublier que ce n’est pas grâce aux outils qu’un projet agile va réussir ou non. Vous pouvez avoir la plus belle table interactive connectée à un serveur qui génère des rapports dans tous les sens, ça vous fait une belle jambe si votre Product Owner n’est pas sérieux, que votre Scrum Master est un charlot ou que les membres de votre équipe n’arrivent pas à communiquer entre eux. Car c’est bien l’humain la clé de la réussite d’un projet agile.

C’est moi ou tout le monde a oublié le manifeste agile ?

• Personnes et interaction plutôt que processus et outils
• Logiciel fonctionnel plutôt que documentation complète
• Collaboration avec le client plutôt que négociation de contrat
• Réagir au changement plutôt que suivre un plan

Je répète : Personnes et interaction plutôt que processus et outils. Alors oui c’est dur à entendre pour des éditeurs mais il va falloir s’y faire. Donc essayons déjà de construire des équipes agiles, de former nos Product Owner et nos Scrum Master et seulement après cela on pourra se poser la question des outils à utiliser.

Après j’ai peut être simplement fait une erreur dans mes choix d’atelier. Sur les 12 disponibles j’ai participé aux trois qui parlaient d’outillage, ce n’était pas forcément très malin de ma part

Liens :

• Résumé par Antoine
• Vidéo de Ken Schwaber
• Sildes de l’atelier forfait Agile
• Compte rendu de Bruno

Anniversaire du Scrum User Group

Le Mardi 30 Mars le Scrum User Group fête son premier anniversaire dans les locaux de Microsoft à Issy-Les-Moulineaux.

Plus d’informations sur ce lien.

Comme je suis justement sur Paris à ce moment là, je vais en profiter pour y participer

Retour sur l’acceleo day

Vendredi 10 juillet avait lieu à Nantes les Rencontres Mondiales du Logiciel Libre. C’est dans ce cadre qu’Acceleo a choisi d’organiser une journée dédiée à leur outil de transformation M2T.

Etienne Juliot commence cette journée par une présentation de l’outil. Il a reussi à faire une présentation à la fois pour les débutants et pour les plus aguerris en y ajoutant quelques petites astuces bien pratiques. Le reste de la matinée était consacrée aux retours clients. Il y en aura quatre de Capgemini, Atos, Bull et OrangeLabs.  C’est celui d’ Atos qui m’a vraiment marqué et pas forcément dans le bon sens du terme. J’ai été frappé par le fossé qu’ils creusent entre les développeurs et les architectes. Attention je ne stigmatise pas Atos, beaucoup de grands groupes (le mien en premier) partage cette approche et voient l’Architecte comme un dieu dans sa tour d’argent dictant sa loi aux gueux développeurs.

Pour ma part je ne l’approuve absolument pas et la distribution des rôles en scrum me donne raison. En effet en scrum les rôles architecte et développeur n’existent pas. Seul le rôle team compte. L’équipe doit bien sûr être composée d’experts en architecture et en développement mais ils doivent travailler ensemble. Pour moi un bon architecte doit mettre les mains dans le code et un bon développeur doit maîtriser l’architecture et même y contribuer.

Pour revenir à acceleo day, j’ai donc présenté très rapidement comment notre chaîne de génération a évolué avec le temps.

Je me suis bien amusé à le faire et ça a été partagé si j’en crois le premier retour que j’ai pu lire. Retour fait par Cedric Vidal qui avait le créneau le plus dur, celui d’après le repas. Il a fait une très bonne présentation sur le Scaffolding. Technique intéressante qui propose d’enrichir le modèle par une ou plusieurs transformations M2M (Model to Model) avant la génération de code. Ca permet de garder la main sur certains éléments pour les enrichir. L’exemple type est le service CRUD (Create, Read, Update, Delete) d’un entité, c’est intéressant de le générer et de garder le lien avec l’entité tout en l’ayant modélisé pour le compléter et le documenter.

Je n’ai malheureusement pas pu assister à la dernière présentation de Goulwen Le Fur car je devais reprendre la route. Vous pouvez lire ses slides sur leur site.

Journée qui a donc été très enrichissante. C’est toujours intéressant de partager avec d’autres industriels pour comparer nos façons de faire.

Résumé de la formation Scrum

Comme je l’avais promis, je vous fais un retour sur les points qui m’ont paru importants dans la formation SCRUM organisée par Xebia. L’objectif n’est pas de vous raconter entièrement les deux jours de formation mais de mettre en avant plusieurs points que j’ai trouvé intéressants.

Read the rest of this entry »

Certifié SCRUM et UML

Comme je l’avais annoncé, après deux jours de formation SCRUM avec Jeff Sutherland en personne, j’ai été certifié SCRUM Master. C’est un titre un peu pompeux et il faut plus le voir comme un « permis de conduire », c’est après l’avoir mis en pratique qu’on le maitrise vraiment.

Et ce matin j’ai passé la certification IBM 834 « Object Oriented Analysis and Design – Part 2″ avec succés. C’est surtout la partie UML de la certification IBM qui m’intéresse.

Au premier abord, ça peut paraitre étrange de mettre RUP et SCRUM côte à côte. Mais si on regarde de plus près SCRUM n’apporte pas de solution pour bien faire l’analyse et le design de son application.

Je ferai un retour plus important sur la formation SCRUM très bientôt.

Formation Scrum

Xebia organise une formation Scrum de deux jours les 1 et 2 Décembre. C’est Jeff Sutherland en personne qui va officier cette messe.

Je vais participer à cette formation, j’aurai donc l’occasion de vous en faire un retour. Même si je continue à pousser les approches MDA je suis persuadé que l’utilisation des méthodes agiles ne peut être que bénéfique dans nos projets. J’avais déjà parlé du côté agile du MDA dans le poste Le MDA c’est Agile !, je compte bien convertir Jeff au MDA !… Enfin s’il arrive à comprendre mon anglais, c’est pas gagné !

Sur ce sujet je vous invite à lire de récentes discussions :

• http://emmanuelchenu.blogspot.com/2008/11/model-driven-et-agilite.html
• http://www.touilleur-express.fr/2008/11/17/mda-scrum/
• http://www.aubryconseil.com/dotclear/index.php/2008/11/17/496-controverses