Blog Technologique 
En route pour le JUG Summer Camp 2010 à La Rochelle
26/08/2010 par Eric SIBERLe JUG Summer Camp 2010 c'est quoi ?
On ne présente plus le principe du JUG (Java User Group), population devenue depuis maintenant 2 ans implantée dans nos contrées française. L'année 2010 correspond à une nouvelle étape dans l'évolution de l'animation de ces groupes d'utilisateurs, avec l'apparition de formats plus longs que les rencontres en soirée.
Il y a eu en début d'été l'évènement SophiaConf co-organisé par le Riviera JUG, un autre évènement est imminent et se déroulera à La Rochelle : Le JUG Summer Camp 2010.
Cet évènement d'une journée complète, organisé par le Poitou-Charentes JUG se tiendra le vendredi 10 septembre et sera constitué de plusieurs présentations animées par des professionnels francophones (point très important) reconnus dans l'écosystème Java.
Pourquoi s'y rendre ?
Ce genre d'évènement est encore rare en France et il est plus accessible que les conférences européennes comme Devoxx et Jazoon (que nous vous encourageons tout de même fortement à fréquenter).
Mais ce n'est pas tout : les organisateurs ont fait le maximum pour vous encourager à venir :
- dernier jour de la semaine
- lieu proche de la gare de La Rochelle
- conférence non seulement gratuite, mais également éligible au DIF (Droit Individuel à la Formation)
- des speakers francophones et de qualité
- des sujets récents et novateurs
Novédia sera représenté
Nous seront 3 consultants Novédia à profiter de la conférence, Matthias, Jean-Max, et Eric.
Outre l'objectif évident de veille et de rencontre de nos pairs, l'un de nos objectifs sera aussi de restituer les sessions suivies aux autres collaborateurs et de les partager avec les lecteurs de ce blog.
Les sessions
Le détail des sessions est disponible sur le site des organisateurs.
La session à ne pas rater :
- Eric : Quoi de neuf dans Hibernate : une perspective de JPA (Emmanuel Bernard)
- Jean-Max : Google App Engine : le cloud façon Google (Christophe Jollivet)
- Matthias : Maven 3 au coeur de la forge logicielle (Nicolas De Loof)
Tags: Conference Java EE jug
L'agilité dans une organisation traditionnelle - rétrospective et perspectives
30/07/2010 par Eric SIBER
Ce billet fait suite à « L'agilité dans une organisation traditionnelle - un sprint de transition » Son objectif est de proposer un premier bilan du sprint de transition dont la préparation avait été décrite. Je vous propose également une restitution de la rétrospective faite par l'équipe sur les 6 derniers mois, avec pour principal objectif de préparer la suite.
Ayant pris du retard dans ma série de billets, il faut savoir qu'à l'heure où je rédige ce billet :
- l'application est en production
- la suite des développements est en cours et une mise en production est espérée pour fin septembre
- l'équipe en est dans son second sprint (sprints de 2 semaines)
Je ne me ferais pas l'écho des interrogations levées à la fin du précédent billet, cela fera l'objet d'un billet à venir se focalisant sur l'analyse des deux premiers sprints.
Retour sur le sprint de transition
Le sprint de transition n'était pas borné dans le temps : sa fin était implicitement définie par le démarrage officiel des nouveaux développements.
Pendant ce sprint, l'équipe a également été sollicitée :
- pour corriger les dernières anomalies identifiées en recette
- pour préparer la mise en production
- pour de premières présentations de spécifications fonctionnelles (générales et détaillées)
Il était clair que tous les items techniques identifiés ne pourraient être traité. En fait l'équipe n'a même pas pu traiter la moitié des items qui avaient été estimés (ceux qui avaient recueilli le plus de suffrages), soit 41 points sur le total de 118 points du périmètre priorisé.
Pour autant, l'équipe n'a pas chômé et a nettement avancé dans la lutte contre la dette technique, mais aussi dans les pratiques de test.
Outre les tâches incontournables concernant la préparation de la production, on notera par exemple les réalisations suivantes :
- Améliorer la couverture de code en renforçant les tests unitaires : objectif atteint avec une augmentation de plus de 40 tests et 6% de la couverture sur le module core (nous partions d'environ 60%).
- Renforcer les tests Selenium : tâche qui s'est avérée très coûteuse pour un résultat assez décevant et une maintenance périlleuse en prévision. L'objectif initial (nombre de scénarios) n'a pas été atteint, mais l'équipe a accumulé de l'expérience sur les bonnes pratiques dans le contexte applicatif qui est le sien.
- Initier les tests Wicket : la bonne surprise avec des objectifs initiaux atteints et un début d'engouement de l'équipe pour les tests unitaires côté IHM. A l'issue du sprint, la couverture du module web avoisinait les 6% et les bonnes pratiques étaient documentées.
- Mettre en place des versions locales de WDSLs pour une utilisation en développement : objectif atteint avec désormais un build local (génération des clients via plugin Maven) s'appuyant sur des versions locales de WSDLs, évitant d'être bloqué (freeze Eclipse du fait de l'intégration Maven) en cas d'indisponibilité, tout en ayant un build sur les Urls cibles au niveau du serveur d'intégration continue (permettant de détecter de potentielles erreurs en cas de désynchronisation des WSDLs).
- Mettre en place des mocks pour les WebServices utilisés : objectif également atteint, celui de ne pas être bloqué lors de développements par une indisponibilité durable et de pouvoir démarrer l'application avec des mocks. Une variable d'environnement, un alias pour les beans Spring reprenant la valeur pointée correspondant à l'implémentation à utiliser, un peu de configuration Maven et Jetty et il nous est désormais très facile de basculer entre les deux modes.
D'autres éléments à relever :
- Le Scrum quotidien a perduré, et à heure fixe (9h45).
- L'équipe s'est approprié le nouvel espace Wiki et a largement documenté les éléments les plus pertinents et critiques.(environnements, éléments techniques, base de connaissance sur les pratiques de tests et outils mis en place). Elle est d'ailleurs très loin devant les autres équipes dans son adoption et usage du Wiki.
- L'ajout de critères d'atteinte des objectifs d'une tâche au dos des post-its est une vraie révolution dans le rapport de l'équipe avec les tâches : chacun est attentif aux critères et s'assure qu'ils sont biens remplis avant de passer la tâche à « Fait », des discussions s'engagent même en cas de besoin sur l'interprétation des objectifs. Un très bon pas vers l'idée de définition de « Fait ».
- Pendant 2 à 3 semaines, l'équipe avait un (tout au plus deux) objectif(s) précis : réduire la dette technique (notamment via le renforcement des tests) et préparer la mise en production. Cela s'est révélé très important en ce qui concerne la motivation de l'équipe, bien plus manifeste que sur de longues périodes lorsqu'elle avançait au radar.
- Sans aller jusqu'au binômage, le niveau d'interactions de l'équipe a augmenté : sollicitations pour avis externe, pour relecture de documentation, feedback sur des améliorations pouvant être apportées. Tout le monde est concerné par l'ensemble des tâches présentes dans le backlog de sprint.
Nous verrons dans un billet ultérieur que ce sprint est le point de départ de la montée en puissance de l'équipe dans l'adoption et la diffusion des principes agiles. A cela s'ajoute également la rétrospective d'une bonne demi-journée que j'ai eu l'occasion d'animer et que je vais vous restituer.
Rétrospective des 6 derniers mois
Un programme assez dense :
- Inventaire des satisfactions, identification des facteurs clés et des éléments à maintenir / renforcer ;
- Projection du projet sur les 12 principes du Manifeste Agile (niveau d'adoption) ;
- Petit jeu destiné à faire prendre conscience des méfaits de la parallélisation des tâches (à titre individuel) ;
- Déceptions / insatisfactions relevées par l’équipe ;
- Définition du FAIT ;
- Définition des initiatives complémentaires que l’équipe souhaite mener au cours du projet à venir.
Inventaire des satisfactions, identification des facteurs clés et des éléments à maintenir / renforcer
Pour démarrer la rétrospective, rien de tel que de parler des satisfactions. En voici quelques unes relevées par l'équipe :
- Organisation agile de l’équipe de développement, ainsi que la communication qui l’accompagne ;
- La transparence au sein de l’équipe de développement et à destination des autres membres du projet / service ;
- Richesse du contexte technique ;
- Mise en pratique / apprentissage de pratiques agiles ;
- L’entraide dans l’équipe de développement ;
- La qualité du code ainsi que les feedbacks reçus sur la qualité de l’application ;
- Inspiration mutuelle sur le thème de l'agilité : il n’y a pas un unique chef d’orchestre, tout le monde contribue à l’adoption et adaptation des pratiques au contexte projet ;
- Les engagements pris par l’équipe ont été tenus.
En matière de facteurs clé amenant à ces satisfactions, ont été mentionnés :
- L’implication de l'équipe de développement ;
- Les moyens mis en œuvre pour favoriser la circulation de l'information (Daily Scrum notamment) ;
- Des développeurs interchangeables et non spécialisés ;
- Les échanges et feedback (relecture de code, pédagogie) entre les membres de l’équipe de développement.
Enfin, d'après l'équipe, pour que ces satisfactions perdurent et s'améliorent, les points essentiels à garder dans le viseur sont :
- Le Daily Scrum ;
- Le courage : avoir du courage même pour les tâches rébarbatives ;
- La documentation sur le Wiki et l'appropriation collective du code (cf. syndrome du bus et de la perte brutale d'un membre de l'équipe).
Projection du projet sur les 12 principes du Manifeste Agile (niveau d'adoption)
L'une des motivations de la rétrospective était d'examiner le niveau d'adoption des pratiques agiles à l'échelle du projet (à nuancer, compte-tenu de la configuration en MOA/MOE, par rapport à l'échelle de l'équipe). Se projeter sur les 12 principes du Manifeste Agile m'a donc paru un bon moyen.
Je vais me limiter à décrire l'analyse faite pour quelques uns (l'adoption étant évaluée sur une échelle allant de 0 – nulle – à 5 – totale) des principes agiles, même si chacune des 12 analyses est extrêmement précieuse et sert à guider l'équipe / le projet.
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
- Evaluation : 5/5
- Analyse : L'équipe en est convaincue et l'applique au quotidien dans les interactions touchant au projet.
“Continuous attention to technical excellence and good design enhances agility.”
- Evaluation : 4/5
- Analyse : L’équipe le met en œuvre, dans la limite du temps qu’elle peut y consacrer (cf. sprint technique de transition), positionne les tests et le refactoring dans ses priorités techniques.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
- Evaluation : 4/5
- Analyse : Les membres de l’équipe sont motivés et ont le sentiment d’avoir la confiance de leur management (libertés et autonomie). Quelques progrès lui paraissent cependant possible concernant l’environnement, les moyens, et l’écoute.
“The best architectures, requirements, and designs emerge from self-organizing teams.”
- Evaluation : 3/5
- Analyse : Même si l’équipe n’a pas atteint une maturité d’auto organisation, elle a l’impression que son mode de fonctionnement contribue à l’émergence de solutions réfléchies. Difficilement applicable sur l’ensemble du périmètre (ex. relation SAP).
“Simplicity--the art of maximizing the amount of work not done--is essential.”
- Evaluation : 3/5
- Analyse : Tentatives de pratique de TDD. Volonté de faire simple. A l’opposé, beaucoup de temps passé sur les briques complexes d’interopérabilité (SAP / SOA Suite).
“Business people and developers must work together daily throughout the project.”
- Evaluation : 2/5
- Analyse : Si on considère que « Business people » = MOA, les échanges quotidiens se renforcent de plus en plus malgré la distance et la contrainte organisationnelle. Si on considère que « Business people » = Métier, pas la moindre interaction ni de retour sur l’application qui n’arrive jusqu’aux oreilles des développeurs.
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
- Evaluation : 2/5
- Analyse : Le rythme des derniers mois était trop soutenu, avec des phases de pics par moment, pour que l’équipe puisse le maintenir. L’équipe pense que son investissement est bien plus important que celui des sponsors et utilisateurs.
Avec des évaluations allant de 2/5 à 5/5, l'adoption sur le projet a été estimé en moyenne à un peu plus que 3/5. Néanmoins, avec un peu de recul, on notera que l'évaluation est parfois confuse car l'équipe a du mal à rester dans un même référentiel (l'équipe de développement vs. l'ensemble des acteurs du projet).
Petit jeu destiné à faire prendre conscience des méfaits de la parallélisation des tâches (à titre individuel)
J'ai voulu faire faire à l'équipe un petit exercice pour la sensibiliser aux problématiques de productivité et notamment les méfaits de la réalisation par une personne de plusieurs tâches en parallèle.
Le principe du jeu est de demander aux participants d'écrire les suites 1..10, A..J et I..X sur une feuille de papier, chaque suite occupant une colonne :
- scénario 1 : en construisant chaque suite en parallèle (on commence par une ligne 1 – A – I, suivie de 2 – B – II, etc.)
- scénario 2 : en construisant chaque suite en série (première colonne avec les chiffres arabes, puis seconde colonne avec les lettres de l'alphabet, et enfin dernière colonne avec les chiffres romains)
Chronométrer le tout, observer et mesurer :
- un ratio allant de 2 pour 1 à 3 pour 1 dans le temps nécessaire à l'exécution de l'exercice entre les deux scénarios (maximum de 115 secondes pour le 1er, minimum de 23 secondes pour le second) ;
- des erreurs commises lors de l'exécution du premier scénario (« fini ! … ah non mince ... ») ;
- une concentration beaucoup plus grande nécessaire pour le premier scénario.
L'exercice a permis à l'équipe de prendre conscience de l'importance de se focaliser sur une seule tâche à la fois. La petite discussion qui a suivi l'exercice a également été l'occasion de reparler de la notion de perturbation (externe et interne) pour déboucher sur la mention du Pomodoro (même si l'équipe n'est pas forcement mature pour ce genre de pratique).
Un bon point pour l'avenir (imaginez si l'équipe, grâce à du bon sens, arrivait à multiplier sa productivité par 2 ...).
Déceptions / Insatisfactions relevées par l’équipe
Passons aux mauvaises nouvelles. En effet, la situation est loin d'être idéale et la rétrospective est également l'occasion pour l'équipe d'exprimer ses déceptions et mécontentements.
Nous avons fait une première passe de déceptions / insatisfactions, chacun pouvant s'exprimer et les autres l'interroger pour bien comprendre le point soulevé. Nous en sommes arrivés à une liste de 15 items, ce qui fait bien évidemment beaucoup.
Nous sommes ensuite passé au vote : chaque membre disposait d'un jeu de cartes de planning poker et pouvait voter à face cachée (sans être influencé par les autres) de 0 (pas concerné) à 100 (extrêmement impactant). Ainsi, nous sommes arrivés à hiérarchiser les déceptions et avons pu nous concentrer sur les plus marquantes.
Pour chacun des 8 items ayant retenu le plus de vote, l'équipe a réfléchi aux axes et sources d'amélioration. En voici quelques uns.
Jusqu’à peu, le Daily Scrum n'était pas à heure fixe
- Impact : 353/500
- Axe d'amélioration : Daily Scrum à 9h45 jusqu’à fin juillet, puis rechercher un consensus sur l’horaire satisfaisant toute l’équipe.
Le workflow JIRA empêche l’équipe de s’auto-organiser et le chef de projet devient un point de contention
- Impact : 333/500
- Axe d'amélioration : Sans révolutionner le workflow, permettre aux développeurs de s’attribuer un ticket serait une amélioration notable pour l’équipe.
Scrum Master n'est pas un véritable rôle dans l'équipe. Soit il est combiné au rôle de chef de projet, soit il est absent à défaut de libérer du temps pour un développeur
- Impact : 320/500
- Axe d'amélioration : L’équipe souhaiterait prendre le temps de réfléchir aux objectifs du Scrum Master sur Aecetia, et de définir son rôle de manière explicite. L’équipe souhaiterait que chacun puisse endosser le rôle de Scrum Master le temps d’un sprint.
L’équipe a le sentiment de ne pas être prise au sérieux
- Impact : 300/500
- Axe d'amélioration : A l’image des présentations DBA faite dans le pôle, saisir l’opportunité de faire des présentations courtes sur Scrum et le vécu / l’expérience de l'équipe. Exposer les règles du Daily Scrum et convier les gens en tant que spectateurs.
Nous verrons en conclusion la suite donnée à cette réflexion sur les insatisfactions.
Définition du FAIT
Ayant noté des divergences (post-it déplacé alors que le code n'est pas commité) et difficultés (navigateur cible Internet Explorer, la majorité de l'équipe étant rompue à l'utilisation de Firefox) sur la vision du FAIT, j'avais également mis comme objectif une première définition écrite du FAIT.
Arrivant en fin de journée, le premier jet ne m'a pas paru satisfaisant (la fatigue aidant) et nous avons repris la réflexion plus tard, ce qui nous a amené à la liste suivante :
- Code commité sur toutes les branches concernées ;
- Existence de test(s) unitaire(s) passant ;
- Si l’IHM est concernée, présence de test(s) Wicket ;
- Avoir testé la fonctionnalité dans son ensemble sur un cas le plus proche de la réalité possible ;
- Avoir réfléchi à la pertinence d’enrichir la documentation ;
- Testé avec IE7.
D'autres éléments ont été évoqué, mais n'ont pas obtenu l'unanimité (raison entre parenthèses) :
- Fonctionnalité potentiellement livrable (définition floue)
- Déploiement avec JBoss (perte de temps)
- Testé avec JBoss (perte de temps)
Voilà l'équipe armée avec SA définition de FAIT (portant sur les User Stories), prête à l'appliquer sur les prochains sprints.
Définition des initiatives complémentaires que l’équipe souhaite mener au cours du projet à venir
Dernière réflexion menée par l'équipe en marge de la rétrospective, l'identification d'initiatives que l'équipe peut/doit porter.
En résumé, 3 thèmes ont été abordés :
- Les tests d'IHM ;
- La méthodologie et gestion de projet ;
- Le Scrum Master.
A l'image de la priorisation du backlog technique, chaque membre de l'équipe avait 12 points de valeur à attribuer sur le backlog de 12 tâches identifiées, ce qui a permis de dégager les priorités, à savoir dans l'ordre :
- Définir clairement la responsabilité des tests Wicket vs. tests Selenium ;
- Faire un suivi des estimés et tracer le burndown de sprint ;
- Impliquer toute l’équipe et non le seul Scrum Master ;
- Estimer les User Stories / Fonctionnalités en points ;
- Faire une démo en fin de chaque sprint (nice to have : en présence d’utilisateurs) ;
- Faire une rétrospective tous les 2 sprints ;
- L’équipe doit réfléchir continuellement aux rôles qu’elle souhaite que le Scrum Master ait, et les expliciter à l’image de la définition du « FAIT » ;
- Permettre à chacun d’endosser le rôle de Scrum Master à tour de rôle. Sprints de 2 semaines, 2 sprints successifs par Scrum Master ;
- Découper les User Stories / Fonctionnalités en tâches estimées en heures. Ne pas accepter de tâches de plus de 8h.
Une première définition du rôle du Scrum Master
L'une des décisions à effet quasi immédiat, pour laquelle l'équipe s'est réunie peu après la rétrospective, a été la définition du rôle du Scrum Master.
Cette définition avait plusieurs objectifs :
- adapter le rôle à l'organisation et aux conditions dans lesquelles évolue l'équipe ;
- permettre à chaque Scrum Master potentiel d'avoir un référentiel suffisant pour mener à bien sa mission sans nécessiter d'avoir reçu une formation ;
- diffuser la vision de l'équipe au delà de l'équipe ;
- pouvoir rétroagir et affiner les composantes du rôle au fil des sprints.
La vision générale de l'équipe est que le Scrum Master (malgré certaines formulation pouvant laisser penser cela) n'est pas un substitut de chef de projet, n'a pas d'autorité sur l'équipe, mais plutôt doit aider l'équipe à s'améliorer.
Différents thèmes ont été formalisés :
- Au service de l’équipe : moyens, protection, amène l'équipe à s'interroger sur la répartition de la charge ;
- Respect des pratiques agiles : garant ultime du Daily Scrum, s'assure de l'appropriation de la définition du « FAIT », organise les démos de fin de sprint et s'assure que l'équipe les prépare ;
- La gestion du Product / Sprint Backlog : proxy Product Owner ou coaching de ce dernier, backlog priorisé, mesure la vélocité et les indicateurs, facilite les séances de planification ;
- Amélioration continue et ambiance : préparation et facilitation des rétrospectives, célébrations, suivi des garants/porteurs d'améliorations/initiatives.
Bilan et actions entreprises
Les retours sur la rétrospective ont été plutôt positifs, permettant à l'équipe de s'exprimer et d'oser communiquer sur ce qui va mais aussi ce qui ne va pas, de s'engager dans la voie de l'amélioration continue en rendant sa réflexion visible de tous. L'équipe a désormais une identité. Le fait d'avoir une vision commune permet à chacun d'en parler, de s'impliquer, par ce qu'il sait (et c'est indéniable : cela rassure les plus discrets / prudents) qu'il a le soutien de l'ensemble de l'équipe.
Faire une rétrospective est une chose, rendre visible le résultat et les enseignements en est une autre. Pour ce faire, j'ai sacrifié un peu de temps dans la rédaction d'un compte-rendu (qui m'aura mine de rien été très utile dans la rédaction de ce billet) déposé dans le wiki et dont les principaux éléments ont été restitués par l'équipe sur son scrum board pour les communiquer à toute personne curieuse :
- définition de « FAIT » ;
- insatisfactions, pistes d'amélioration, avec une colonne « Garant(s) » permettant à quelqu'un de se désigner pour veiller à ce que les choses évoluent dans la bonne direction ;
- liste des initiatives envisagées, avec une colonne « Garant(s) » permettant à quelqu'un de se désigner comme pilote de l'initiative ;
- définition du rôle de Scrum Master ;
- niveau d'adoption des principes agiles ;
- etc.
Si la colonne « Garant(s) » tarde un peu à se remplir (essentiellement remplie avec le garant "Scrum Master" en cohérence avec la définition du rôle de ce dernier) cela ne veut pas pour autant dire que les actions sont oubliées : la grande visibilité garantit que cela ne tombera pas dans l'oubli et même sans garant les choses peuvent évoluer grâce à l'action collective et la vision partagée par l'équipe.
Cette communication a eu pour effet ces dernières semaines de susciter la curiosité de personnes concernées ou non par le projet sur lequel travaille l'équipe (autres équipes de développement, architectes, responsable technique, chargé d'étude, direction, etc.) que les gens passent et marquent un léger temps d'arrêt ou qu'ils lisent et engagent la conversation avec l'équipe.
Le virus est libéré et se propage naturellement par la méthode douce (devrait-je plutôt parler d'inception en référence au film qui tient l'affiche en ce moment ?). Affaire à suivre.
Tags: methodes agiles scrum
Ma seconde journée à l'USI 2010
13/07/2010 par Eric SIBER
La première journée de l'Université du SI a mis la barre relativement haut. Pour ma part, aucune des sessions suivies le jeudi ne m'a déçue, ce que je ne pourrais pas dire pour celles du vendredi malgré un démarrage sur les chapeaux de roues avec Neal Ford et Martin Fowler.
Mon top 3
- Keynote « Pourquoi, pas comment » de Neal Ford et Martin Fowler (ThoughtWorks)
- Performance des sites web, quoi et comment, par Eric Daspet (SQLI)
- Keynote de Derrick de Kerckhove (Université de Toronto)
Les différentes sessions en concentré
Pourquoi, pas comment. Par Neal Ford et Martin Fowler (ThoughtWorks)
Une idée forte : Le pair-programming c'est la combinaison d'un hémisphère gauche d'un hémisphère droit, compensant l'impossibilité pour un être humain d'activer ses deux hémisphères en même temps.
La présentation par deux des modèles des plus Geeks d'entre nous avait pour but de mettre en avant la pensée agile. Notamment axée autour de valeurs prônées par le Manifeste Agile, la présentation a été largement illustrée par des exemples et anecdotes.
Le premier aspect abordé a été le passage d'une approche prédictive (planification) à une approche adaptative. En effet, le succès d'une planification prédictive repose sur le contenu de la planification, lui même dépendant de la stabilité du besoin, chose assez rare. Il est donc bien plus sain d'avoir une planification qui s'adapte à l'évolution du besoin, et ceci avec un délai de réaction / ajustement le plus faible possible.
Le second thème abordé est l'inversion de la relation entre le process et les hommes, illustré par l'expression « people first ». Cela passe notamment par la communication, le feedback et la visibilité (mesure du progrès), des pratiques comme le binômage ou la tenue de rétrospectives.
Dernier thème cher aux intervenants : le fun. En effet, cette composante n'est pas à négliger et contribue à la bonne ambiance tout en améliorant le quotidien des équipes (l'exemple de la lecture d'un son personnalisé par membre après un build passant illustre bien la combinaison du côté fun et de l'amélioration de la communication et de la productivité).
How the web was won, and other useful stories, par Mark Surman (Mozilla)
Une idée forte : « Open is the logic that wins in the digital world »
Mark Surman a retracé l'histoire du Web et notamment la situation du Web en 2003 qui a été l'un des déclencheurs de la création de la fondation Mozilla. Selon lui, les caractéristiques clés de l'internet sont la transparence, l'ouverture, le contrôle partagé, donnant lieu à un phénomène participatif. Il nous a expliqué que le point de départ de la fondation Mozilla a été le constat en 2003 d'une domination à plus de 98% d'Internet Explorer comme navigateur, marquant l'absence totale de standards et donnant lieu à des sites allant jusqu'à réclamer le navigateur à l'utilisateur.
Une affirmation percutante de la part du speaker a consisté à dire que l'ensemble du web était Open Source (on comprend mieux les détracteurs de la technologie Flash entre autres) puisqu'on peut afficher la source d'un document et réutiliser du code à souhait. C'est c'est aspect que défend la fondation par l'intermédiaire d'un extrait de son manifeste : « guard the open nature of the Internet ».
Kanban in Operations, par Mattias Skarin (Crisp)
Une idée forte : L'implication du management est primordiale
Mattias Skarin, co-auteur de Kanban et Scrum - tirer le meilleur des deux, nous a présenté un retour d'expérience sur l'amélioration de la productivité d'une équipe d'exploitation chez l'un de ses clients.
Il a illustré la mise en place d'un board Kanban destiné à aider l'équipe à gérer les priorités et la collaboration entre l'équipe d'exploitation et celle de développement, amenant au fil du temps l'organisation à évoluer vers une service exploitation partie intégrante du service développement (au départ les services étaient indépendant). Un bel exemple illustrant les bénéfices du Kanban en matière de communication, collaboration, et gestion de flux de travail.
A noter que le speaker a insisté sur l'importance d'impliquer le management dans ce type d'initiatives. Pour l'anecdote, le manager avait lui aussi un tableau Kanban à 2 slots pour traiter des points de blocages externes à l'équipe. Et c'est à l'équipe de libérer un slot en décidant si le manager a débloqué la situation ou non.
Performance des sites web, quoi et comment. Par Eric Daspet (SQLI)
Une idée forte : « Moins, c'est plus (de performance) »
L’objectif du speaker était de nous sensibiliser à l’optimisation du frontend des sites web. En effet, il nous a expliqué que bien souvent les mesures de performance se focalise sur le backend, à savoir le temps de génération d’une réponse HTTP. Il préconise justement des mesures complètes incluant l’affichage complet de la page (images, scripts d’initialisation, etc.) pour se rendre compte que la partie liée au frontend (le rendu dans le navigateur) peut représenter parfois 95% du temps total et donc justifier qu’on s’attache à optimiser cette partie.
Parmi les conseils prodigués (dont certains ressembleront sans doute à du bon sens pour les spécialistes du domaine), on notera la diminution du nombre de requêtes HTTP (utilisation du cache HTTP, regroupement d’images en sprites), la diminution du volume (compression HTTP et images pouvant être pris en charge par le serveur Web), le contournement de la séquentialité des appels (répartir des ressources sur plusieurs domaines pour pouvoir les charger en parallèle, utiliser des appels JavaScripts asynchrones). Eric nous a également présenté quelques astuces et recommandé des outils comme Yslow et Google Page Speed.
« Un regard sur l’ouverture ». Keynote de Jean-Philippe Courtois (Microsoft)
Une idée forte : Microsoft veut être parmi les leaders sur le Cloud
Dans le cadre du thème de la demi-journée (Ouverture), Jean-Philippe Courtois nous a communiqué un certain nombre d’informations illustrant le fait que Microsoft s’investit sur le sujet bien plus que ce que les clichés usuels peuvent laisser à penser (mention de Codeplex, des différentes initiatives et collaborations avec de petits éditeurs, ). Il a notamment invoqué des sujets comme la propriété intellectuelle et les brevets, présentant notamment les contraintes que nous avons en Union Européenne (traduction dans toutes les langues des Etats membres) et des initiatives en cours. Il estime notamment qu’il est important que les règles sur les brevets évoluent vers une description précise des concepts à protéger, afin d’éviter les situations qu’on a pu rencontrer par le passé.
Autre sujet abordé, l’interopérabilité entre les produits et concernant les données. Il en ressort que la notion de choix est primordiale. Quelques chiffres pour conclure sur la tendance Cloud : le nombre d’applications payantes déployées sur Azure dépasse les 10 000, 90% des 300 00 développeurs MS sont sur des projets Cloud, 9.5 milliards de dollars d’investissements.
Jean-Philippe Courtois a consacré une bonne partie de sa keynote pour laisser l’audience l’interroger sur des sujets parmi lesquels on aura eu entre autres les brevets, Internet Explorer, la prochaine version de Windows, la position de Microsoft concernant les DRM.
Keynote de Derrick de Kerckhove (Université de Toronto)
Une idée forte : Marshall McLuhan (1911-1980) avait tout prédit dans les années soixantes
Derrick de Kerckhove est le directeur du programme McLuhan « Culture and Technology » et professeur au département de français de l'Université de Toronto. Il nous a invité à prendre de la hauteur sur l’évolution des usages à travers les siècles passés et la prédominance / importance de l’imprimerie et de l’écriture, pour en arriver à la seconde phase de l’ère numérique et l’appropriation du langage.
Il nous a parlé de ce qu’il considère être l’ère du tag, l’a abondamment illustré par des phénomènes plus ou moins connus comme Twitter, Chatroulette, etc., ainsi que des initiatives comme Airtag.
Unleash your Domain, par Greg Young
Une idée forte : L'approche DDD permet de répondre plus aisement à des problématiques d'audit des modifications sur les objets métier
Greg Young, l'un des spécialistes du Domain Driven Design, a essayé de sensibiliser l'auditoire sur les problèmes que se propose de résoudre le DDD. L'un des messages délivrés concerne notamment la notion d'impedance mismatch qui est d'après lui résolue par l'approche DDD, tout comme elle permet un meilleur suivi et plus facile des opérations menées sur un objet métier (être capable de distinguer la différence entre l'ajout de 3 éléments suivi du retrait d'un élément dans un panier, et l'ajout de 2 éléments, l'information de retrait pouvant être très utile).
Session malheureusement trop courte/speed coupée dans son élan.
The challenges of long-term software quality in Open Source, par Juergen Höller (SpringSource)
Une idée forte : Le succès sur le long terme de Spring repose sur un modèle de type Benevolent Dictator
Juergen Höller, après avoir présenté la genèse du framework Spring et dressé l'inventaire du portfolio Spring, a expliqué les enjeux de la maintenance du framework. Ainsi, même si le framework ne repose que sur peu de librairies obligatoires, il intègre un grand nombre de third parties (framework et serveurs d'application) pour en simplifier l'usage pour les développeurs, ce qui nécessite de s'adapter aux évolutions et d'être compatible une gamme de versions.
Il nous a également expliqué que la nature même d'un projet Open Source comme Spring impose à ses développeurs d'être très attentif sur la qualité du code, lequel est visible de tout le monde, car la moindre erreur sera inévitablement vue et rappelée. Sur les échanges de l'équipe de développement avec la communauté (suggestions, rapport de bug, forums, etc.), il estime qu'il est important de répondre dans un délai le plus court possible afin de fidéliser les membres et les encourager à poursuivre le feedback et à s'investir, ce qui est également favorisé par la mise à disposition de builds quotidiens (nightly build) et la présence aux conférences.
Concernant l'évolution du framework au fil du temps, il a décrit celle-ci comme opposée à une révolution (ex. Struts 1 vers Struts 2) qui serait très préjudiciable quant à l'adoption de Spring.
Enfin, parmi les facteurs clé de succès mentionnés, on retrouvera l'importance des outils de communication pour des équipes distribuées à travers toute la planète comme celles de SpringSource (Skype, rencontres physique au moins 2 fois par an), l'importance de se connaître, et le choix d'un modèle de “Benevolent Dictator” (à l'opposé de celui de l'Apache Software Foundation qui se base sur la méritocratie). Ce modèle, prônant une gouvernance par un leader technique s'inscrivant sur la durée, est selon lui adapté à la mise en oeuvre et maintenance de frameworks.
Libérer les énergies de la DSI, par Pierre Pezziardi (Octo Technology)
Une idée forte : La DSI 2.0 passe par la mise en place d'équipes produit
Pierre Pezziardi nous a délivré des conseils basés sur l'accompagnement qu'il a mené au sein de la DSI de Gefco. Il nous propose notamment une nouvelle façon de mixer les gens autour d'un produit et non les regrouper par spécialités, de s'appuyer sur la définition d'un manifeste (référence à Tribes par Seth Godin) et de standards ouverts et émergents.
Parmi les facteurs permettant d'augmenter les performances d'une équipe, il cite notamment l'autonomie, la maîtrise et l'accomplissement, ainsi que le sens / objectif.
Keynote de Juan Enriquez (Biotechonomy LLC)
Une idée forte : “Read it, copy it, write it”
Cette keynote, dont le sujet portait sur la génétique, est difficile à restituer. Juan Enriquez, lequel se dit “I'm not a futurist, I'm an historian” nous a rappelé quelques chiffres fondamentaux liés à la génétique et à la constitution de l'ADN des hommes et autres formes de vie animales. Il a par la suite tiré quelques parallèles entre la génétique et la notion de code (binaire) tel qu'on le perçoit dans le milieu IT : par exemple, la faible différence dans la constitution de la signature génétique d'un homme et d'un rat, avec une différence considérable sur le résultat montrant qu'une simple inversion de 0 et de 1 provoque des changements importants.
Il a axé sa présentation sur l'affirmation “Read it, copy it, write it” largement applicable à notre domaine, en illustrant différentes expérimentation réalisées. Je ne saurais pas tout vous restituer avec fidélité mais une anecdote qui m'a marqué a été la “création” (write it) d'une souris à partir d'une cellule de souris (si j'ai bien compris, une cellule contenant toute la signature génétique, il suffit de “lui indiquer” la fonction qu'elle doit prendre : oreille, pate, etc.).
Un sujet passionnant, peut-être un peu éloigné du métier de l'IT à première vue. C'est sans compter sur le bestseller “As the Future Catches You” dont Juan Enriquez est l'auteur et vous propose une analyse de l'impact de la génétique sur le business et la société.
Conclusion
L'Université du SI est un événement unique de par son positionnement à cheval sur un auditoire Geek et un auditoire Boss : de quoi y trouver son compte, mais aussi aller voir ce qui se passe dans « l'autre monde ».
Dans un lieu soigné et agréable, avec des conditions météo parfaites (même s'il manquait de climatisation dans une des salles), l'organisation a été au rendez-vous notamment sur la logistique (accès internet, espace de recharge des mobiles, fléchage, écrans d'information, etc.) et la restauration.
Parmi mes regrets, on retrouve l'enchaînement des sessions et la contrainte de la diffusion simultanée à Casablanca entraînant l'interruption brutale de certaines sessions et l'impossibilité d'échanger avec le speaker sur des questions / réponses (même si nous étions invités à aller voir le speaker individuellement, ce n'est pas la même chose en terme de partage avec l'ensemble des participants). J'aurai préféré davantage de temps entre les sessions, ce qui aurait permis ces échanges, quitte à rogner sur les 90' de pause déjeuner.
En amont de la conférence les participants étaient invités à remplir leur profil et notamment la liste des sujets d'intérêt, malheureusement ce fameux « Parlez moi de » est resté vierge sur les badges personnalisés distribués à l'entrée : dommage.
Pour autant, le niveau général des sessions a été tel que je ne regrette pas (quasiment un sans faute pour la 1ère journée) ma participation et que je garde en tête les dates du 4 et 5 juillet 2011 tout en espérant que la part de speakers anglophones restera modeste et que la conférence continuera à propulser les professionnels francophones sur le devant de la scène.
Retrouvez également mon résumé de la 1ère journée qui contient en fin d'article l'inventaire des autres retours / compte-rendu de participants.
L'essentiel de la première journée de l'USI 2010
02/07/2010 par Eric SIBER
L'Université du SI se déroule sur 2 jours les jeudi 1er et vendredi 2 juillet. J'ai la chance d'y représenter Novédia et je vais partager avec vous la première journée de l'intérieur.
L'organisation
Contrôle d'identité à l'entrée par une hôtesse équipée d'un iPad, retrait du sac du participant, dépôt au vestiaire, puis passage dans le hall pour un petit déjeuner. 15 minutes après le démarrage de la keynote de Chris Anderson, on nous fait le coup de la panne (10 bonnes minutes sans électricité, meublées par une séances de questions / réponses).
Les sessions s'enchaînent, un buffet pour la pause de midi d'une durée d'1h30 avec accès extérieur, suffisant pour se restaurer et discuter. N'oublions pas les postes avec accès Internet, la possibilité de recharger son téléphone, un écran reprenant l'actualité de l'USI via les réactions sur Twitter.
L'après-midi reprend avec une keynote. Les enchaînements rapides du matin, conséquence du retard pris suite à la panne, laissent place à des transitions entre sessions plus calmes, ponctuées par la keynote de Leo Apotheker.
Puis les participants se sont vus offerts une soirée de dégustation de vin.
Mon top 3
- Keynote « Let I.T. be » d'Yves Morieux du Boston Consulting Group
- Les explorateurs de l'innovation, par Xavier Boileau (Generali)
- Keynote de Chris Anderson (Magazine Wired)
Les différentes sessions en concentré
Pour chaque session suivie, en complément de mes réactions à chaud sur Twitter, je vous propose une idée forte perçue ainsi qu'un petit résumé.
Keynote de Chris Anderson (Magazine Wired)
Une idée forte : « give (the enterprise) us freedom, don't stop us to find/explore new solutions to do our job »
Chris Anderson, auteur du livre « The Long Tail: Why the Future of Business Is Selling Less of More », nous explique en analysant la ressource qu'est l'électricité , que l'IT a la chance de disposer aujourd'hui de 3 ressources en abondance : la bande passante, le stockage, et la capacité de calcul. La baisse de leur coût va de paire avec l'augmentation de leur utilisation. Il cite notamment l'annonce en 2007 par Yahoo de la mise à disposition de ses utilisateurs d'un quota illimité pour les mails.
Il en vient à opposer la rareté (scarcity) à l'abondance, en illustrant par des oppositions telles :
- Supermarché vs. Amazon
- Top down vs. Bottom up
- Command & Control vs. Out of Control
Sa réflexion aboutit au constat de limitations/restrictions dans les entreprises allant au détriment des attentes des salariés, pouvant aller jusqu'à brider la performance de ces derniers.
Désordinateurs : quand la fonction des technologies consiste à rebattre les cartes, par Daniel Kaplan (Fondation pour l'Internet de Nouvelle Génération)
Une idée forte : L'un des enjeux de l'internet de demain est la mise en visibilité de ce qu'on ne savait pas voir avant.
Daniel Kaplan dresse le constat d'une informatique limitante pour les entreprises en citant des grands noms : « obstacle à l'innovation » (Jean-Pierre Corriou) ou encore « symbole du côté poussiéreux de l'entreprise » (Philippe Lemoine). Il nous rappelle que depuis le début, l'informatique a deux histoires parallèles : celle sous l'angle positif de l'optimisation (simplification), et celle sous l'angle parfois négatif de la transformation/adaptation.
Il nous propose un monde résultant du mariage du physique et du numérique, faisant éclore de nouveaux objets et des applications pertinente d'un point de vue social mais sujettes à conflit d'intérêt (partage d'information vs. Surveillance), tel l'exemple de la « montre verte » (mesure de l'air et de la pollution sonore).
Les explorateurs de l'innovation, par Xavier Boileau (Generali)
Une idée forte : L'innovation est l'affaire de tous (Marketing, Métier, DSI) et nécessite qu'on libère du temps aux personnes volontaires pour y travailler.
Après avoir rappelé les enjeux de l'innovation, Xavier Boileau a présenté les démarches menées chez Generali qui a notamment suivi une approche Top Down en lançant sur des thématiques (territoires) des similis de Startups internes constituées de personnes (explorateurs) de tout bord volontaires et auxquels du temps a été mis à disposition pour participer au processus d'innovation. Il a notamment expliqué que l'innovation reposait sur un état d'esprit, qu'il était primordial d'être prêt à accepter les échecs et erreurs, et que chez Generali la récompense pour les acteurs de l'innovation était la reconnaissance par les pairs (présentation à la Direction Générale d'un projet issu du processus d'innovation).
Jardinage et innovation : comment cultiver son potentiel ? Par Yves Casseau (Bouygues Télécom)
Une idée forte : L'innovation va de paire avec le Lean et l'Entreprise 2.0
L'originalité de la présentation réside dans la mise à disposition d'une référence bibliographique sur chaque idée/slide. Parmi les idées véhiculées : innover c'est adapter, le taylorisme s'arrête à la communication, ne pas négliger les « liens faibles » et participer (mais aussi partager) au delà de ce qui est interne à l'entreprise.
Let I.T. be, par Yves Morieux (Boston Consulting Group)
Une idée forte : Si on réduisait tous les projets à 9 mois, les gens seraient davantage impliqués car contraints d'assumer leurs actes.
Je ne résumerai pas la session, comme je l'ai dit à chaud sur Twitter : « Let I.T. Be par Yves Morieux #usi2010 un must see. Grande prestation et maîtrise pour expliquer des choses de façon simple. ». Il ne vous reste plus qu'à attendre patiemment la mise à disposition de la vidéo.
Le Lean ou le management par la résolution de problèmes, par Michael Ballé (ENST)
Une idée forte : Faire les bonnes choses avant de faire les choses bien.
Michael Ballé a commencé par nous sensibiliser sur la différence entre le système de production de Toyota et le TPS (Toyota Production System). Puis, il a rappelé un certain nombre de principes Lean pour l'apprentissage (Kaizen, Kaikaku) et à insister sur le fait que la mise en place d'un principe Lean comme le Kaizen nécessite une rupture destinée à placer le Kaizen avant le travail quotidien. Selon lui, le succès repose sur la vision du produit et la somme des compétences individuelles, et non sur les processus.
La société numérique, l'économie de la contribution : l'ère postconsumériste, par Bernard Stiegler (Philosophe, Centre Georges-Pompidou)
Une idée forte : Les entrepreneurs et investisseurs d’antan se sont transformés en managers et spéculateurs. Toute la société est en train de se désinvestir.
Le philosophe analyse la société actuelle qu'il qualifie de société de l'obsolescence (en référence aux cycles courts de vie des produits) qui produit des déchets toxiques. Il illustre la société de consommation par le résultat d'un sondage de 2004 lors duquel 54% des personnes interrogées affirmaient que ce qu'il y avait à la télévision était nul mais qu'elles la regardait néanmoins : un vrai discours de toxicomane. Bernard Stiegler, après avoir lourdement insisté sur le désinvestissement de la société, nous explique, en citant l'exemple de Wikipédia et décrivant certains sujets sur lesquels il travaille, qu'une nouvelle révolution industrielle est à venir.
Collaboratif, Réseaux Sociaux, 2.0 : on y va, on y va pas ? Laetitia Riveron (OCTO Technology) et Sara Lucet (SL & Partners)
Une idée forte : Choisir l'information et non la subir
Après avoir rappelé les statistiques des principaux réseaux / outils sociaux grand public, quelques facteurs clé de succès ont été présentés (notamment « Oser faire confiance ») et les outils et pratiques d'OCTO Technology ont été mentionnés. Après un slide matérialisant un panel d'outils du marché destinés aux entreprises, il nous a été expliqué que l'outil ne suffit pas et qu'il fallait chercher à définir la valeur métier attendue. Pas mal de bon sens : commencer petit, voir grand ; s'appuyer sur les « champions » et impliquer le management. Pour finir, le public a également été sensibilisé sur les risques en cas d'usage détourné des outils collaboratifs (discussions de type remise en question de la stratégie de l'entreprise).
La stratégie des tribus chez les Geeks : recruter, conserver, et développer les talents. Nicolas Martignole (Indépendant)
Une idée forte : Pour conserver ses talents, il faut permettre le partage dans et en dehors de l'entreprise.
Difficile de résumer une session dont j'ai pu suivre l'élaboration, comme bon nombre de personnes de la communauté Java, tout au long des derniers mois. Nicolas a présenté son parcours et son épanouissement en tant que Geek. Il a présenté les résultats des différents sondages menés auprès des Geeks et recruteurs pour en arriver à sensibiliser ces derniers sur les attentes des passionnés du développement informatique, soulignant certaines initiatives d'entreprises alignées avec ces attentes.
Building the Next Generation of Technical Leaders, par Patrick Kua (ThoughtWorks)
Une idée forte : The unspoken truth about managing geeks
Patrick a expliqué qu'actuellement les regards sont encore trop tournés vers les outils, les processus et les technologies, et pas assez vers les hommes. Or le succès ou l'échec de projets dépend également fortement des personnes qui le mènent. Le leader technique est-il un « super dévéloppeur » ? Pas du tout, et le speaker l'illustre en opposant les attentes qu'on peut avoir de chacune de ces populations (et en mentionnant certains comportements de « mauvais » leaders techniques). On peut notamment attendre du leader technique d'être l'acteur de la résolution de conflits, de contribuer au développement des talents, et de porter une vision auprès des équipes.
Keynote de Leo Apotheker (ex. SAP)
Une idée forte : Nous allons passer de l'informatique à l'information
Leo Apotheker partage avec l'assemblée sa vision de l'avenir : une révolution initiée par le hardware (ex. mémoires vives d'1To, processeurs plus rapides et moins consommateurs, etc.) permettant l'émergence de bases de données temps réel. Il nous a expliqué que le backoffice étant désormais automatisé grâce aux solutions de type ERP, le challenge à venir sera dans la communication inter-entreprise : joindre des processus et données non structurées dans une collaboration inspirée des réseaux sociaux. Il considère d'ailleurs que l'émergences de futurs systèmes temps réel, qui nécessiteront de fait 40% de code en moins par rapport aux systèmes existants (suppression de tiers comme la persistance et de problématiques comme la mise en cache), qui générerons beaucoup de challenges et de réécriture de SI.
Il envisage également l'éventualité d'une disparition dans une dizaine d'années des sociétés de Software, ce dernier étant amené à devenir une composante essentielle des entreprises.
D'autres retours de participants ou compte-rendu
Liste complétée au fil du temps :
- USI 2010 : résumé de la première journée en attendant plus et USI 2010 : journée 2 par Nicolas Martignole (ensemble des articles)
- USI 2010 – Premières impressions
- Retour sur l'Universite du SI 2010 : geek et boss une equipe qui gagne par Emmanuel Bernard
- Pourquoi recruter un geek ? Le Monde Informatique
- Accompagner le développement collaboratif en entreprise Le Monde Informatique
L'agilité dans une organisation traditionnelle - un sprint de transition
25/06/2010 par Eric SIBERLe contexte
- Une organisation interne sur un modèle MOA/MOE avec une MOA détachée de la DSI depuis peu
- Des équipes de réalisation d'un bon niveau technique, composées d'internes et de prestataires. L'équipe type : un chef de projet et des développeurs
- Une infrastructure technique encourageante (projets structurés, intégration continue)
- Un projet démarré il y a 6 mois avec la volonté initiale du middle management de faire les choses bien et de se réconcilier avec des applications existantes qui coûtent cher à maintenir
- Une mise en production prévisionnelle pour mi mars qui aura finalement lieu ces prochains jours
Lorsque le projet a démarré, il y avait cette volonté unanime dans l'équipe de réalisation (composée de 5 personnes dont certaines formées / sensibilisées à Scrum) de mettre en oeuvre un ensemble de pratiques agiles. Les objectifs ? Améliorer la communication, l'autonomie de l'équipe, favoriser les prises d'initiatives, combattre l'effet tunnel, entre autres.
Bien entendu, à la vue du contexte, le lecteur avisé devinera que cette initiative est locale et non globale, qu'il n'y a aucune adhésion de la part du top management dans les démarches agiles, et que le périmètre ne s'étend pas aux interlocuteurs MOA.
Résumé des 6 derniers mois
Vous vous doutez bien de la difficulté d'introduire des pratiques agiles à un niveau local dans un tel contexte. Après une première tentative lors de la mise en place du projet à partir des informations contenues dans le draft des spécifications fonctionnelles du premier lot, l'équipe accuse le coup. Manque de repères, des tâches techniques estimées tant bien que mal, des spécifications fonctionnelles qui n'en finissent pas de bouger et de décaler le véritable démarrage des développements, obligeant l'équipe à s'impliquer dans la relecture proactive des spécifications.
Le management veut des dates, l'équipe finit par constituer son carnet de produit (product backlog) à partir des spécifications et en estimant les histoires (user stories) … en jours. Le Scrum quotidien (Daily Scrum) tourne vite au reporting des activités au chef de projet (Scrum Master volontaire et désigné) ainsi qu'à des séances collectives de conception / résolution de problèmes peu productives : l'équipe subit et personnellement j'ai l'impression de perdre mon temps lors du daily De plus, l'équipe, avec son Scrum board, ses post-its et ses rituels, devient vite l'attraction de l'Open Space : moqueries maladroites et décrédibilisation pas évidentes à accepter pour une équipe qui se veut volontaire et sérieuse.
Enfin, la complexité des histoires rend le premier sprint fonctionnel très peu productif et l'équipe, après avoir fait le constat de l'impossibilité de constituer des sprints de durée fixe (pas de priorisation, livraisons en recette par lots), amène l'équipe à mettre en suspens le Scrum quotidien tout en maintenant l'utilisation d'un Scrum Board (à faire / en cours / fait) avec désormais un découpage des histoires en tâches.
Quelques semaines plus tard, au cours d'une rétrospective improvisée, l'équipe dresse un bilan dont un des constats est la faible circulation de l'information (imputée à l'abandon du Scrum quotidien). L'équipe décide donc de remettre au goût du jour le Scrum quotidien en prenant soin d'éviter les travers du passé. Les délais se faisant de plus en plus pressants, l'organisation évolue de façon à spécialiser les développeurs par domaines fonctionnels, situation délicate par rapport à l'appropriation collective du code. Les retours de la recette du premier lot sont extrêmement positifs : encourageant !
Quelques évolutions fonctionnelles plus tard, nous avons livré il y a plus de deux semaines l'application en recette, commençons à traiter les premiers retours et absorber les ajustements occasionnés par les incohérences détectées et problématiques d'intégration. C'est également officiel : l'équipe va enchaîner sur un nouveau périmètre dont la mise en production est fortement souhaitée pour septembre.
Que faire donc pendant cette période de creux ? Fort d'une formation récente de type Scrum Master, et compte-tenu de ma frustration à voir l'équipe s'investir dans la douleur (l'équipe est "sans cesse en train de sprinter") sans obtenir de satisfaction, j'ai donc décidé la semaine dernière de porter mon énergie sur cette période transitoire afin de donner à l'équipe les moyens de se mettre dans de bonnes conditions pour la suite.
Préparation d'un sprint transitoire à connotation technique
L'équipe a tout au long du projet fait des efforts sur le thème des tests, mais elle a conscience que la couverture est plus que moyenne. L'équipe est également en souffrance dans certaines tâches qui lui coûtent beaucoup (trop) de temps.
Construction d'un backlog
Objectif : identifier les tâches, actions, que l'équipe juge pertinente de faire durant les prochains jours en prévision du démarrage des développements sur le nouveau périmètre
J'ai réuni l'équipe, expliqué l'objectif, puis l'équipe s'est mise à discuter et à décrire de manière concise des items touchant à des sujets comme :
- le partage d'informations critiques sur le Wiki
- la documentation technique
- les préparatifs pour la mise en production
- la maintenance et l'enrichissement des tests
- la réorganisation de code existant
- la recherche ou construction d'outils améliorant la productivité de l'équipe
- etc.
Durée : 1h30'
Résultat : 36 items sous la forme de post-its
Rendez-vous fût pris avec l'équipe pour le lendemain 10h et une journée supposée riche en contenu.
Objectif : classer les items identifiés la veille en en estimant la valeur ajoutée relative
Je distribue à chaque membre de l'équipe une feuille reprenant les 36 items (que j'ai pris soin de numéroter) et leur permettant de prendre des notes pour préparer l'identification de la valeur ajoutée relative de chacun d'entre eux.
1ère étape : Présentation des 36 items pour que l'équipe se les approprie
J'ai proposé à l'équipe que chacun présente à tour de rôle un item, l'illustre, ou à défaut pose des questions à l'équipe pour préciser sa compréhension.
Durée : 20'
Résultat : Une bonne vision du backlog et une amorce de réflexion individuelle sur l'apport de chaque item
2ème étape : définition des valeurs ajoutées relatives
J'ai distribué à chaque participant 30 pastilles de couleur à coller au dos des post-its en fonction des valeurs ajoutées estimées. Chacun emploie la méthode qui lui convient, pioche dans les post-its et leur attribue des points de valeur.
Court débriefing et confrontation de points de vue en attendant un membre pris par d'autres priorités, lequel finira pas apporter sa pierre à l'édifice en attribuant lui aussi ses 30 points (sans être influencé par la vision des post-its).
Nous écartons pour la suite les 15 post-its ayant le moins de valeur ajoutée.
Durée : 30' en groupe + 20' avec le retardataire
Résultat : Un backlog ordonné par valeur ajoutée
Estimation des items constituant le backlog
Objectif : Définir les attentes et critères d'acceptation pour chaque item constituant le backlog
Toujours au dos des post-its, l'équipe décrit pour chaque item ce qui est attendu pour considérer que la réalisation de ce dernier est terminée. Un mélange d'échange de visions et de prémices de conception : le tout s'avérera très utile pour la suite.
Durée : 90' pour 21 items
Résultat : un référentiel commun à l'équipe permettant de mieux cadrer les estimations de complexité
Objectif : Estimer la complexité de chaque item
Un classique avec le Planning Poker. J'impose néanmoins au préalable à l'équipe de se mettre d'accord sur l'une ou l'autre tâche qui lui paraît élémentaire et sur laquelle un consensus d'estimation peut être trouvé. Je lui impose également une estimation en points de complexité et non en jours. L'équipe trouve son étalon et lui attribue la complexité de 1. Les estimations démarrent et se passent relativement bien. Grâce aux critères d'acceptation définis auparavant, l'équipe converge beaucoup plus facilement (parfois dès le premier vote) tout en focalisant la négociation sur la complexité et non le périmètre.
Durée : 90' pour 21 items
Résultat : Un backlog à la fois estimé en priorités et en complexité
Consolidation et remplissage du Scrum Board
Après un repos bien mérité, j'attaque la matinée suivante par le calcul du ROI (la valeur ajoutée relative ramenée à la complexité) de chaque item et le report sur la face avant de chaque post-it du triplet (valeur ; complexité ; ROI).
Je réordonne le tout dans un tableur pour classer les 21 items par ROI, puis nous reprenons l'ensemble dans le backlog du sprint (de durée indéterminée) de transition.
Peu de surprise quand à la présence d'items touchant à la mise en production. Voici quelques exemples de couples (résumé - ROI) :
- Recherche d'une solution de visualisation d'un (ensemble) de DataSets DBUnit - 2 (4 / 2)
- Préparation préproduction et production - 2 (10 / 5)
- Décrire le processus de livraison - 1 (5 / 5)
- Restructurer le code lié aux écrans de recherche / résultat et du mécanisme de recherche, et le documenter - 0.3 (6 / 20)
- Ecran de consultation / recherche : évaluer les requêtes SQL jouées et en optimiser la quantité pour les scénarios de recherche - 0.6 (8 / 13)
- Améliorer la couverture de code en renforçant les tests unitaires - 1.1 (9 / 8)
- Initier les tests Wicket - 1.6 (8 / 5)
- Renforcer les tests Selenium - 0.5 (7/13)
- Mutualiser la règle de gestion pour la date XX - 6 (6 / 1)
- Mettre en place des versions locales de WDSLs pour une utilisation en Développement - 2.5 (5 / 2)
Quelques ajustements pour le lancement du sprint :
- Une tentative de Scrum quotidien à heure fixe (9h45, soit 15' avant que certains ne soient potentiellement indisponibles pour cause de réunion)
- L'ajout d'une colonne « JIRA » sur le Scrum Board pour accueillir les tickets, présentés à l'équipe et affectés (traités en priorité) au cours du Scrum quotidien. L'ajout de colonnes « Livré » et « Recetté » dédiées à cette catégorie d'items.
Quelques observations
21 items allant d'une complexité de 1 à 13, c'est amplement suffisant (peut-être trop sachant que réunions et corrections d'anomalies agrémentent notre quotidien) pour occuper l'équipe pendant les 2 à 3 semaines de transition.
Nous travaillons bien entendu sur 2 branches : l'une pour le produit destiné à partir en production, l'autre pour préparer l'avenir. Si les corrections d'anomalies sont reportées sur chaque branche, nous n'excluons pas de faire de même pour certaines tâches dont le risque de mettre en péril la mise en production est faible.
Nous nous surprenons à retourner les post-its pour nous assurer de bien garder en tête les objectifs de l'item traité ainsi que les conditions qui nous permettent de le passer dans la colonne « Fait ».
Nos deux pilotes côté MOA ne se sont jamais autant arrêtés devant le Scrum Board, la faute sans doute aux post-its de type JIRA et aux quelques items relatifs à des tâches fonctionnelles. L'un d'entre eux nous a même déplacé des post-its de « Livré » à « Recetté » et a participé à quelques Scrum quotidiens. Et jusque là, personne ne s'est plaint de l'abandon partiel de l'application JIRA (qui reste utilisée pour expliciter les tickets et décrire leur résolution, mais dont la contrainte du workflow imposant une affectation des tickets par le chef de projet a été contournée pour une meilleure implication de l'équipe et appropriation du processus).
Conclusion
Ce sprint un peu particulier s'avère riche en enseignements et semble avoir une portée bien plus importante que ce qu'on pouvait penser au départ en le qualifiant de sprint technique. L'équipe a bon espoir de s'en servir pour démarrer les prochains développements fonctionnels dans de bonnes conditions. Elle pourra également compter sur une rétrospective à venir portant sur les 6 derniers mois.
Il nous reste néanmoins quelques inconnues pour l'instant :
- Allons nous réussir à tirer profit de ce sprint pour enchaîner avec des estimations en points de complexité et non en jours ?
- Allons nous réussir à impliquer la MOA pour fonctionner sous forme de sprint avec une priorisation des histoires, même si « tout ce qui sera spécifié sera indispensable » pour la mise en production de septembre ?
- Allons nous pouvoir agrémenter les prochains sprints de quelques items « techniques » extraits de notre backlog technique afin de combattre la dette technique ?
Tags: methodes agiles scrum