InfOsaurus

Aller au contenu | Aller au menu | Aller à la recherche

dimanche 30 septembre 2012

Visual Studio 2012

La version finale de Visual Studio 2012 étant sortie très récemment, j'ai pu le prendre en main et le tester pendant quelques heures. Je vous propose une petite visite guidée et commentée de cette nouvelle mouture de l'IDE.


Look & feel

Quand le sage lui montre la lune, le fou regarde les majuscules


C'est probablement le sujet qui a fait le plus jaser à la sortie de la RC de Visual Studio 2012 il y a quelques mois. Beaucoup se sont d'abord indignés contre les menus tout en lettres capitales dans la barre du haut. Franchement, je trouve la controverse un peu surfaite - les menus sont un tout petit détail de l'IDE, personnellement je vais assez peu dedans et le passage en majuscules ne m'a pas du tout gêné une fois la surprise initiale passée.

Penchons-nous plutôt sur la charte graphique et l'aspect général de cette nouvelle version.

Je trouve la page de démarrage simple, claire et lisible. C'est grosso modo la même que VS 2010 avec des informations mieux organisées et plus de matière sur les nouveautés de l'IDE. L'onglet Vidéos contient notamment des tutoriels instructifs sur ces dernières.


Page de démarrage

Dans tout l'IDE, Microsoft a fait le choix d'une interface graphique de type "ligne claire" à fort contraste avec très peu de couleurs et des zones carrées à la Metro Style. Les bords et les espaces non remplis, autrefois de couleur foncée, sont maintenant sensiblement de la même couleur que toutes les autres zones (éditeur de texte, explorateurs...) c'est à dire blancs ou gris très clair dans la charte par défaut. J'avoue que j'ai du mal avec ce style très lumineux (high key dirait-on en photographie) qui m'éblouit un peu. Les petits icônes, généralement noirs ou très peu colorés, sont aussi souvent peu reconnaissables et mal choisis.


Thème clair

J'ai donc essayé le thème sombre également proposé de base et... c'est un peu l'excès inverse, je suis vite revenu à l'autre.


Thèeme sombre

Du côté des performances, j'ai constaté une amélioration nette par rapport à VS 2010, que ça soit au lancement ou en termes de réactivité globale de l'IDE. Je n'ai pas non plus fait l'expérience de crashes intempestifs comme avec son prédécesseur à sa sortie. Tout paraît plus fluide - grâce à l'interface allégée ? Cela reste néanmoins à vérifier dans un contexte d'utilisation intensive, avec de nombreux fichiers ouverts, des designers UI, des tests unitaires et des recherches qui tournent, etc.

Au final, en bon adepte du dépouillement, je salue l'effort des concepteurs de VS 2012 pour simplifier l'habillage de l'outil et se concentrer sur l'essentiel ("La perfection, ce n'est pas quand il n'y a plus rien à ajouter mais plus rien à enlever", disait quelqu'un). Il va juste falloir trouver un thème plus confortable pour les yeux sensibles.


Navigation et éditeur de texte

Le retour de la vengeance des pin's


Autant le dire tout de suite, comparé à VS 2010, les innovations ne sont pas énormes en matière de navigation et d'édition du code dans ce cru 2012. On y trouve :

  • Une fonction "preview" très pratique. Il suffit de simple-cliquer sur un fichier dans l'explorateur de solutions pour afficher celui-ci comme si on l'avait ouvert. Simplement, son affichage est temporaire, un fichier en preview chasse l'autre. L'onglet du fichier preview s'affiche à droite, pour le distinguer des fichiers déjà ouverts. C'est une excellente fonction que je me suis retrouvé à utiliser énormément.


Fonction Preview

  • L'épinglage de fichiers, plus anecdotique. Les fichiers épinglés restent de façon permanente à gauche de la rangée d'onglets et ne sont jamais masqués même lorsqu'on a énormément de fichiers ouverts en même temps.


Pin's !

  • Un icône "Tout réduire" est maintenant présent par défaut dans l'explorateur de solution pour replier complètement l'arbre de la solution. Ce n'est pas trop tôt, cette fonctionnalité quasi-obligatoire à mon avis devant auparavant être ajoutée via un add-in ou une macro.


  • Surlignage de la ligne actuelle : elle peut paraître mineure, mais cette fonction apporte un confort non négligeable en nous indiquant instantanément où le code va s'insérer si on continue à taper au clavier. En effet, lorsqu'on part se balader de part et d'autre dans le fichier on perd souvent ce repère et le curseur n'est pas toujours clairement distinguable. Dommage que la ligne surlignée soit assez peu visible en thème clair, et plutôt trop visible en thème foncé.


Il y a aussi la fameuse zone de Lancement rapide qui se présente comme un champ de recherche "environnemental" pour retrouver un menu, une action, un fichier récemment ouvert...


Lancement rapide

L'idée est bonne sur le papier mais 95% de mes actions dans l'IDE étant des tâches familières déclenchées par des raccourcis clavier, j'en ai eu très peu l'utilité. Pour chercher dans des fichiers, je préfère utiliser l'excellent Ctrl-virgule apparu dans VS 2010. L'avenir nous dira si cela change.

En revanche, les manques de fonctions de productivité déjà signalés dans la version 2010 (mais pourtant présents depuis longtemps dans des outils tiers comme Resharper) sont toujours là :

- Toujours pas de "add reference and use"
- Toujours pas de fermeture automatique d'accolades
- Pas de suggestion de noms de variable
- Pas de goto base/inheritor depuis l'éditeur de texte
- etc.

Cette absence d'évolution est particulièrement criante dans le domaine du refactoring où il faut vraiment chercher pour trouver une nouveauté, à part peut-être une entrée de menu pour chercher de la duplication de code sur le code actuellement sélectionné (baptisé de manière amusante rechercher les clones en français).
Pendant ce temps, JetBrains nous ajoute des refactos à la pelle, dont le fameux Extract Class -Resharper reste à des années-lumières de ce que l'environnement de Microsoft sait faire par défaut.


Tests unitaires

Un petit pas pour le Shim, un grand pas pour l'humanité


Selon l'aveu même de représentants de Microsoft, dans un exercice d'auto-critique assez rare pour être souligné, l'équipe de Visual Studio s'est rendu compte que l'environnement de tests de 2010 était orienté testeurs et très peu pratique pour les développeurs.
En effet, le même type de projet Visual Studio servait pour les tests qualité et les tests unitaires des développeurs. Le test runner de VS 2010 était tout sauf confortable car lent, avec une interface verbeuse et peu visuelle obligeant à raisonner selon une notion de "liste de tests" peu familière. Tout cela a été corrigé dans VS 2012 où on a maintenant :

Un test runner digne de ce nom.

Il s'inspire bien sûr fortement des runners déjà existants, que ça soit celui de TestDriven.net, celui de Resharper ou d'autres. On y retrouve l'habituelle barre rouge ou verte ainsi que des pastilles des mêmes couleurs pour chaque test. A noter qu'on peut enfin écrire de nouveau tests et relancer le runner directement, il les prendra en compte sans besoin de passer par une fastidieuse opération d'ajout de tests à la liste. VS 2012 va même plus loin avec quelques fonctionnalités supplémentaires à saluer :

  • Une option permettant d'exécuter automatiquement les tests après chaque build. On est "presque" dans le continuous testing.
  • Dans ce mode, les tests les plus susceptibles d'échouer (ceux qui étaient déjà rouges, etc.) sont réexécutés en premier et les tests qui étaient verts ne sont pas réexécutés si d'autres échouent. On est "presque" dans l'intelligent test running à la JUnit Max.
  • On peut analyser la couverture de code d'un ou plusieurs tests.
  • Des raccourcis clavier sont présents de base pour exécuter un ou tous les tests (d'ailleurs on ne peut pas lancer des tests en faisant un clic droit depuis l'explorateur de solutions, il faut forcément utiliser un raccourci ou le test runner, radical mais étrange pour du Visual Studio...)


Test Runner

Plusieurs types de projet de test au lieu d'un seul.

Les tests d'intégration "pour les testeurs" ont été séparés des tests unitaires automatisés "pour les développeurs". Le Projet de test unitaire est à privilégier lorsqu'on veut faire du TU avec MSTest. Mais la bonne nouvelle, c'est qu'il n'y a même pas besoin d'utiliser ce type de projet pour tirer parti du test runner de Visual Studio, une bonne vieille bibliothèque de classes suffit pour peu qu'on ajoute les références adéquates.

Une plateforme unifiée pour tous les frameworks de test :

la VS Unit Test Platform. Elle fournit une API pour que des adaptateurs pour les différents frameworks de test puissent être développés (ceux de XUnit et NUnit sont déjà disponibles). Cela veut dire que virtuellement n'importe quel framework de test peut maintenant fonctionner avec le test runner de base de Visual Studio, alors qu'auparavant on devait installer soit des runners spécifiques aux frameworks, soit des runners génériques tiers (Gallio, Resharper...)


Un autre gros morceau de l'environnement de tests de VS 2012 est le framework Microsoft Fakes. Cet ambitieux composant inspiré du travail de MS Research sur Pex & Moles n'est ni plus ni moins qu'un framework d'isolation intégré à Visual Studio. Il permet de générer deux types de doublures de test : les Stubs et les Shims. Les premiers sont l'équivalent des Mocks des frameworks déjà existants et peuvent seulement remplacer des interfaces ou des classes abstraites, et les seconds sont plus lents mais peuvent mimer des classes concrètes (MS Fakes marche ici sur les plates-bandes d'outils payants comme TypeMock Isolator). Les Stubs sont recommandés pour mocker des classes de son propre projet alors que les Shims sont utiles comme doublures de classes d'assemblies tiers. On peut ainsi modifier des classes comme DateTime pour simuler une date courante différente, etc.
Au passage, on peut se demander où les concepteurs du framework sont allés chercher le terme Shim ("cale"), signe que le champ lexical de la doublure de test commence à sérieusement s'épuiser. Ceux qui avaient déjà du mal avec les fakes, stubs, mocks, dummies, etc., et on peut les comprendre, seront probablement désormais totalement perdus avec les nouvelles dénominations à la Microsoft....


Techniquement, la mise en oeuvre de ces doublures est assez inédite bien qu'un peu contraignante. Pour pouvoir utiliser MS Fakes, il faut sélectionner une référence à un assembly dans le projet de test et "Ajouter un assembly Fakes" :


Ajout d'assembly Fake

Une nouvelle DLL va alors se rajouter à nos références ; à l'intérieur, tous les Stubs et Shims possibles pour les types de l'assembly de base auront été générés et sont prêts à être utilisés dans nos tests. Malgré le surcoût initial d'ajouter l'assembly fake, cette approche est intéressante puisqu'il y a des chances que ces classes déjà présentes à la compilation soient plus performantes que des proxies générés au runtime, comme dans les frameworks d'isolation actuels.
Le setup des fakes se fait avec une syntaxe classique utilisant des lambdas. Pas de dépaysement de ce côté-là, en revanche un gros point noir : le framework ne semble pas proposer les méthodes d'assertion avancées de ses concurrents -vérifications sur le nombre d'appels d'une méthode d'un Stub, vérification simple des paramètres passés à une méthode, syntaxe fluent, etc.


Utilisation d'un Stub


Application Lifecycle Management

Du pain et de l'Agile


Je n'ai pas pu tester la partie ALM de Visual Studio 2012 par manque de serveur Team Foundation, mais le remaniement a l'air assez considérable et Scrum semble plus que jamais la méthodologie par défaut promue par Microsoft. On sent que l'équipe TFS a mis le paquet pour que Visual Studio, dans ses versions supérieures, devienne un centre complet de gestion du cycle de vie d'un projet.

Parmi les nouveautés que j'ai pu voir,

  • Une nouvelle vue Backlog plus claire (et pas juste un résultat de query TFS)
  • Un Task Board électronique présent par défaut, avec drag & drop et autres joyeusetés.
  • Un écran de planification de sprint
  • Un écran "My Work" dans Team Explorer avec les tâches de l'utilisateur
  • Un cadre pour les revues de code
  • Un système de gestion de feedback utilisateur


Task Board

En parallèle de cela, on peut noter que Microsoft a fait des efforts pour rendre ses outils plus compatibles avec la philosophie agile -notamment après les mini-vagues d'indignation qui ont eu lieu lors de la sortie des premières version beta de VS 2012. On a toujours la possibilité d'assigner les tâches à chaque développeur (façon Waterfall/micro-management) dès le sprint planning, mais ce n'est plus obligatoire ni recommandé (dans l'exemple donné dans la documentation TFS, l'équipe ne le fait pas). De même, j'ai l'impression que la référence au diagramme de Gantt qui apparaissait dans l'écran de planification de sprint a été enlevée.


Conclusion

Ce soleil qui ne voulait pas devenir une Etoile noire


Il y aurait bien d'autres choses à dire sur Visual Studio 2012, qui est un univers à lui tout seul. Comme d'habitude, Microsoft court après son écosystème - une foule de fournisseurs d'add-in tiers innovants - dont il "officialise" dans VS 2012 quelques fonctionnalités, tout en prenant bien garde à le faire assez lentement pour ne jamais rattraper tout son retard sur ces satellites, de peur d'anéantir la galaxie.
Ainsi, l'accent est surtout mis dans cette nouvelle version sur l'expérience utilisateur, l'ergonomie et la gestion de projet, et moins sur des fonctionnalités de développement "de fond" (je ne parle pas ici de la plateforme .Net et de ses langages qui ont bien évolué avec la version 4.5 du framework).

Toutefois, l'intégration d'un test runner potable fait bien progresser l'IDE dans le domaine des tests unitaires. Elle rend Visual Studio "nu" enfin utilisable de façon à peu près correcte dans un contexte de développement agile piloté par les tests - il n'en demeure pas moins que si l'on veut une bonne productivité, un plugin tiers comme Resharper me parait encore indispensable.

dimanche 1 avril 2012

Code Retreat Montpellier

Le 24 Mars dernier se déroulait le premier Code Retreat à Montpellier, animé par Antoine Vernois et organisé par Julien Lafont, Vivian Pennel et Sylvain Fraïssé. L'événement avait lieu dans les locaux de l'école Epitech. Je ne vais pas rappeler les règles d'un code retreat en détail, mais il s'agit d'une rencontre où on développe en pair programming sur un problème donné - en général le Conway's Game of Life, sous forme d'itérations de 45 minutes en changeant de binôme à chaque fois. Voici mon petit retour (tardif) sur la journée.

Ce que j'ai aimé :

  • La bonne humeur générale propice aux échanges, avec des développeurs venus d'un peu partout (Montpellier mais aussi Marseille, Toulouse, etc).
  • La variété des langages présents, de Java à Python en passant par Scala, Ruby et plein d'autres.
  • Le cadre d'Epitech sympa, dans une bâtisse ancienne montpelliéraine rénovée.
  • L'efficacité d'Antoine qui avait visiblement reçu 5/5 l'unique conseil avisé de Corey Haines :)

Ce que j'ai appris :

  • Le pouvoir des contraintes. Se mettre des restrictions très pénibles (pas de if, de boucles, pas de getters/setters...) force en fait à réfléchir autrement et paradoxalement on en tire plein d'enseignements à mettre en application plus tard.
  • Un Code Retreat, ça passe très vite, aussi bien la journée que les itérations elles-mêmes. Au bout des 45 minutes, on est systématiquement frustré d'être si loin de voir notre monde en vie, surtout quand de précieuses minutes ont été passées en contingences matérielles annexes. Mais c'est le jeu, ma pauvre Lucette :)
  • Ruby, ça a l'air de roxxer. Il faut que je m'y penche de plus près.
  • Décidément, j'ai du mal à convaincre mes petits camarades que C#, c'est bien. Pourtant, C#, c'est bien ;)

Si c'était à refaire :

  • Eviter de se pointer avec un langage ou un environnement qu'on maîtrise mal. Je pense qu'il est crucial qu'un des deux membres du binôme connaisse très bien la techno utilisée pour pouvoir se concentrer uniquement sur les tests et l'émergence du design. J'ai le sentiment d'avoir passé trop de temps à cerner des détails de langages, c'est intéressant mais pas forcément dans les clous de la journée.
  • Peut-être expliquer un peu mieux au début de la journée ce qu'est TDD, ou demander aux gens de se renseigner dessus avant. J'ai l'impression qu'il y avait un taux assez haut de "totale découverte TDD" dans la salle ce qui est bien sûr enrichissant au niveau du partage, mais a peut-être généré une certaine perplexité.

Dans la catégorie "j'ai testé pour vous" :

  • Casser la cafetière du code retreat dès le matin (encore désolé Julien)... j'ai un peu fait mon boulet sur ce coup-là.
  • Le Conway's Game of Life en Python avec un binôme qui n'avait fait que du C et pas familier du développement objet. Tout ça sans if et sans boucle sinon c'est pas drôle... Ou comment expliquer le polymorphisme à quelqu'un en 5 minutes :)
  • Le ping-pong programming à 3 sans avoir le droit de se parler et avec un test runner JUnit qui crashe de temps en temps. Un grand moment... d'incompréhension, mais très instructif sur notre dépendance à la communication !


Debriefing entre deux sessions

En tout cas, très bonne expérience que ce premier code retreat, encore merci aux organisateurs et aux participants ! A quand la prochaine ? ;)

lundi 2 janvier 2012

Podcasts

Ayant fait pas mal de déplacements fin 2011, j'ai occupé mon temps notamment en écoutant divers podcasts sur le développement logiciel. Pour tous ceux qui prévoient de passer du temps dans les transports cette année, je vous propose ma sélection avec mes 5 podcasts favoris en 2011 :

1. .NET Rocks! : un show très sémillant à l'américaine autour de .NET et des technologies Microsoft animé par Carl Franklin et Richard Campbell. Le podcast est de qualité professionnelle avec un très bon son, l'inconvénient étant les pubs. Bons invités (récemment Corey Haines) et toujours à la pointe de l'actualité et des sujets qui buzzent. Je le mets en premier pour la fréquence soutenue des épisodes qui fait qu'on a toujours quelque chose d'intéressant à se mettre sous la dent.

2. Visual Studio Talk Show : encore du .NET, mais comme son nom ne l'indique pas c'est un des rares podcasts francophones que j'aie trouvé sur le développement. Il est animé par les excellents Québecois Guy Barrette et Mario Cardinal. J'aime bien ce podcast pour son approche didactique et accessible, la variété des sujets et les acteurs de la communauté (québécois mais aussi français) invités.

3. Software Engineering Radio : un podcast généraliste sur le développement, les méthodes agiles... avec des invités de marque : Jurgen Appello, Lisa Crispin, Uncle Bob, Rich Hickey (créateur du langage Clojure) ont été reçus par le passé, sans compter un épisode assez mémorable avec Kent Beck.

4. Hanselminutes : le podcast de Scott Hanselmann assez orienté Web et Microsoft. J'aime bien le ton sérieux et toujours posé de Scott qui est un peu à l'inverse des compères de .NET Rocks!

5. The Java Posse : le podcast le plus populaire sur Java, avec son générique culte et sa bande de joyeux lurons assez marrants à écouter débattre en long et en large sur plein de sujets (spécial longs trajets donc). Et ça ne fait pas de mal de prendre des nouvelles de ce qui se fait du côté de Java de temps en temps ;)

Une mention également à The Agile Toolkit, Deep Fried Bytes et The Pragmatic Podcast qui valent le détour malgré une parution plus épisodique.

Je suis aussi preneur de vos suggestions de podcasts, notamment en français !


Sur ce, je vous souhaite une très bonne année 2012 :)

jeudi 3 novembre 2011

Agile(s) Tour(s) 2011

Cette année, j'ai eu la chance de participer à deux dates de l'Agile Tour : le 20 Octobre à Montpellier suivi de celui de Bordeaux le 21. Voici un petit retour sur les 2 événements.

Agile Tour Montpellier


Agile Tour Montpellier

Le lieu

Ce premier Agile Tour montpelliérain avait lieu à l'école Polytech sur le campus de l'Université Montpellier 2. Quatre salles dont un grand amphi avaient été réservées pour l'occasion. Du côté du programme, la volonté affichée était de cibler 2 types de publics : les décideurs ("boss") et les développeurs ("geeks") plus les étudiants et universitaires.


Sessions

Software Craftsmanship par Jean-Laurent de Morhlon

J-L de Morlhon
Beaucoup de choses intéressantes dans cette présentation qui couvrait plein de sujets sur la théorie et la pratique de Software Craftsmanship, de l'historique du mouvement au manifeste en passant par les pratiques comme TDD et SOLID. Quelques morceaux choisis :

  • Ne pas s'en tenir au Craftsmanship Manifesto, flou et difficile à comprendre, voire même l'oublier.
  • Besoin de rétablir l'équilibre entre process et pratiques de développement, ces dernières sous-estimées notamment dans certaines implémentations actuelles de Scrum.
  • Une des techniques d'apprentissage les plus efficaces reste le mentoring ("conduite accompagnée").
  • Notion "d'heures de vol" accumulées nécessaires pour atteindre un certain niveau, comme un pilote d'avion.
  • Pair Hero et Ping Pong Programming permettent de pratiquer en s'amusant.

A noter que la slide "! Art" (le développement n'est pas de l'art) a fait réagir et suscité un vif débat philosophique sur la signification de l'art ;-)

Au final, une session maitrisée et fort sympathique ; même si on connait déjà un peu le sujet, c'est toujours enrichissant d'avoir le point de vue de personnes éclairées surtout sur un domaine peu exploré en France comme Software Craftsmanship.

Le pilotage par les tests par Jérôme Avoustin

Cette session présentait TDD, ATDD et BDD avec des démos et en filigrane un retour d'expérience sur un projet piloté par les tests. Jérôme nous avait prévenu que le rythme allait être élevé pour tout faire tenir en une heure, et en effet le contenu était riche.

  • J'ai bien aimé l'approche "top-down" mise en place sur le projet qui est une sorte de méta-cycle red-green-refactor où on crée un test BDD rouge avant d'écrire les tests de plus bas niveau en TDD, et on reboucle sur le passage à vert du test BDD pour finir.
  • Enseignement instructif sur l'évolution de la façon de développer : avec cette approche, le temps passé en tests a beaucoup augmenté mais celui passé à debugger a énormément diminué.
  • Définition de la qualité qui me plait bien : c'est quand le coût d'ajout d'une fonctionnalité est stable.

En tout cas, encore une présentation qui donne envie de faire du BDD :) Il est intéressant d'avoir des retours d'expérience sur de vrais projets qui l'ont mis en place, finalement pas si nombreux.

Contractualisation agile par Jean-Francois Jagodzinski

La session de cet Agile Tour qui m'a laissé le plus perplexe. J'ai l'impression que toute la présentation tournait autour du pot des contrats agiles sans jamais vraiment attaquer le sujet. Jean-Francois Jagodzinski était un peu en mode questionnement socratique et je n'ai pas vraiment vu où il venait en venir...
Heureusement des membres du public ont posé les "questions qui fâchent" à la fin en allant droit au but, ce qui a permis d'amorcer une discussion sur les difficultés des contrats agiles.

Une autre présentation de Jean-François est disponible sur slideshare mais ce n'est pas exactement celle de l'AT Montpellier.

Bref, je sors mon joker pour celle-là, je devais être trop endormi après le buffet...

Transformation agile au delà des équipes projet, par Romain Vignes

Un retour d'expérience instructif sur la transformation agile menée au sein de la société Wyplay, éditeur de logiciels de TV numérique, avec notamment comme clients SFR et Vodafone. Voici ce que j'ai noté :

  • Points de difficulté dans l'adoption de Scrum : organigramme à revoir, auto-organisation et discipline, transparence, disponibilité du client.
  • Autre difficulté importante : passage d'équipes multi-projets mais mono-métier à des équipes mono-projet mais inter-disciplinaires.
  • Une métrique intéressante utilisée chez Wyplay pour limiter l'éparpillement : Team Turn Over = Nb développeurs à cheval sur 2 projets ou + / nb total de dev.
  • Point d'accord avec la présentation de Jérôme Avoustin : le temps de debug s'est rapidement raccourci suite à l'adoption de l'agilité.

Projet et Cycle de vie agile par Thierry Cros


Thierry Cros

Une présentation classique mais efficace sur le cycle de vie des projets agiles. Quelques points que j'ai relevés :

  • Nécessité d'apprendre le "jeu de la planification agile"
  • La phase projet et la phase maintenance d'une application ne formeraient qu'une seule phase de pilotage par feedback
  • "Estimation belote" est plus proche de la réalité que Planning Poker :)


Ce que j'ai aimé

  • L'accueil très pro des organisateurs
  • Bonnes présentations "Geek"
  • Pas mal d'ateliers
  • Le buffet servi à midi
  • Les conférences de l'amphi retransmises sur Lanyrd


Ce que j'ai moins aimé

  • Peut-être moins de mélanges entre "populations" du fait de la séparation très marquée des sessions "geeks"/"boss"

Quoi qu'il en soit, pour une première c'était très réussi, chapeau bas aux organisateurs et orateurs qui ont parfaitement su faire prendre la mayonnaise !


Agile Tour Bordeaux


Agile Tour Bordeaux

Le lieu

Pour la seconde fois, l'AT Bordeaux se déroulait à l'Enseirb. Là aussi, 4 salles dont un grand amphi étaient réservées, avec un sympathique espace ouvert au rez-de chaussée. Le programme était un peu plus orienté ateliers que les années précédentes, avec un coding dojo, un Kanban Game, un atelier Billes Rouges, l'espace ouvert... mais les présentations techniques ou orientées projet étaient bien entendu présentes.


Sessions

Kata Marrant par Emmanuel Gaillot et Jonathan Perret


E. Gaillot et J. Perret

Si vous n'avez pas encore vécu une prestation de ces deux hurluberlus, je vous conseille vivement d'en faire l'expérience. On assiste à une vraie pièce de théâtre d'impro, où le public participe en déposant des suggestions de thèmes ou de manières de coder dans une corbeille.

Chaton interstellaire, arc-en-ciel de sodium... difficile de décrire ce qui est sorti de ce kata mais le fun était bien là !

J'ai découvert par la même occasion CoffeeScript, un petit langage sympa qui dépouille JavaScript de ses accolades et points-virgules.

Ni gladiateurs, ni bisounours par Christophe Thibaut

Sans doute la présentation la plus radicale et la plus propice à réflexion à laquelle j'ai eu l'occasion d'assister lors de ces Agile Tour. La première partie recensait des anti-patterns d'équipes très bien vus ("Nez dans le guidon", "Maillon faible", "Feu de camp"...) dans lesquels je pense la majorité du public s'est reconnu. Venaient ensuite des propositions de solutions avec les Core Protocols. Je ne vais pas tous les décrire mais il s'agit de techniques (dont certaines assez déconcertantes) favorisant la communication d'équipe. Je ne sais pas si elles sont toutes applicables telles quelles partout, mais c'est en tout cas certainement une bonne source d'inspiration.

2 moments de "déclic" parmi d'autres :

  • "On peut influer sur la motivation d'une personne uniquement négativement"
  • "Les membres d'une équipe sont comme les cartes composant une quinte flush, elles n'ont d'intérêt que par les relations qui les lient"

Quarante ans de crise, dix ans d'agilité par Laurent Bossavit


Laurent Bossavit

J'avais déjà vu cette présentation en vidéo, mais en vrai, c'est quand même vachement mieux... Laurent y met en perspective - ce qui à ma connaissance a rarement été fait auparavant - l'histoire du génie logiciel depuis ses origines à une conférence de l'OTAN en 1968 jusqu'à nos jours, avec l'état actuel de la discipline. L'exercice est riche en enseignements et force est de constater que la plupart des questions posées il y a 40 ans n'ont toujours pas trouvé de réponse.

La présentation explique ensuite pourquoi Agile est une innovation de rupture et s'ouvre enfin sur la perspective de l'avenir de l'agilité et la proposition de passer d'une culture agile orale à une culture plus formalisée avec l'Institut Agile et une prise en compte accrue de l'agilité dans les programmes des universités.

Si vous n'avez pas encore vu cette vidéo, je vous la conseille vivement.

TDD, je commence demain ! par Fabien Bézagu

Le pari de cette session était osé - faire découvrir Test Driven Development et convaincre les développeurs présents de franchir le cap dans leur job. Tout cela en commençant par une démonstration en PHP (qui a dit qu'il y avait des sous-langages ?...) L'ensemble était bien mené par Fabien malgré un public que j'ai senti pas aussi avide d'échanges qu'espéré.


Ce que j'ai aimé

  • Beaucoup de sessions techniques orientés "geek" (même si je n'aime pas ce mot) et d'ateliers
  • Le mot des sponsors beaucoup plus agréable, avec moins de concours de qui a la plus grosse agilité que l'année dernière (qui a dit normal, il n'y avait pas de SSII ?...)
  • L'organisation toujours au poil
  • Les orateurs toujours disponibles pour discuter, un plaisir


Ce que j'ai moins aimé

  • L'espace ouvert qui manquait de prise en charge des nouveaux arrivants
  • Le coding dojo dur à rattraper en cours de route si on n'avait pas suivi au début
  • Les coups de gong du Sky Castle Game qui ont semblé perturber les acteurs du Kata Marrant (qui ont quand même essayé de rivaliser, avec leur petite sonnette !)
  • Les 2h de retard du TGV de la nuit précédente, heureusement j'ai pu tenir avec moult café pendant la conférence ;)


L'équipe de l'Agile Tour Bordeaux


Pour conclure, un grand merci à tous les organisateurs et participants des deux Agile Tour et à l'année prochaine !

mardi 5 octobre 2010

L'auto-organisation : analyse d'un concept subversif

« The best architectures, requirements, and designs emerge from self-organizing teams. »

Cet extrait du Manifeste agile met en lumière un des points importants de la réussite d'une démarche agile : la capacité d'une équipe projet informatique à s'organiser elle-même. Mais même si la notion est connue et souvent évoquée comme qualité première d'une équipe agile, qu'entend-on précisément par auto-organisation et quelles peuvent être ses limites ?

Auto-organisation 3

Un phénomène émergent

Voici la définition que donne Wikipedia de l'auto-organisation dans le domaine des sciences physiques et de la systémique :

« Le terme auto-organisation fait référence à un processus dans lequel l'organisation interne d'un système, habituellement un système hors équilibre, augmente automatiquement sans être dirigée par une source extérieure. Typiquement, les systèmes auto-organisées ont des propriétés émergentes (bien que cela ne soit pas toujours le cas). »

Il est amusant de constater une certaine ressemblance avec la définition agile de l'auto-organisation, bien qu'elle recouvre d'autres réalités. L'auto-organisation n'est pas une valeur, ni une pratique ou même une compétence. Le manifeste agile la classe parmi les principes, mais on peut aussi parler de phénomène d'auto-organisation car c'est en réalité le résultat de plusieurs façons de fonctionner qui se mettent en place progressivement au sein d'une équipe :

Répartition collective des tâches. Alors que dans un système hiérarchisé traditionnel de type command and control c'est le plus souvent le chef de projet qui assigne individuellement les tâches aux développeurs, les équipes agiles se répartissent le travail de manière collective. Plus exactement, il s'agit d'une auto-attribution libre du travail avec accord tacite du collectif : le membre de l'équipe choisit lui-même sa prochaine tâche mais il le fait en présence et avec l'approbation de tous ses coéquipiers. Le moment précis pour cette attribution est celui du standup meeting / daily scrum dont la fréquence journalière permet un ajustement du partage du travail au plus près de la réalité du moment. Effet collatéral : exit les diagrammes de Gantt planifiés des semaines à l'avance ; une partie importante des prérogatives du chef de projet disparait, ce qui n'est pas sans poser problème à certains comme nous le verrons plus loin.

Engagement collectif. Dans un mode de fonctionnement agile, l'équipe s'engage auprès du client à produire au cours de l'itération suivante un certain nombre de fonctionnalités représentant une valeur métier pour ce dernier. C'est un des moments importants où l'équipe en tant que bloc solidaire prend ses responsabilités vis-à-vis de l'extérieur. Cela contraste fortement avec la gestion de projet classique où la responsabilité est plutôt individuelle, chaque développeur s'engageant à respecter l'estimation qu'il a chiffré (ou que quelqu'un d'autre a chiffré pour lui !) et des "fusibles" hiérarchiques successifs sont en place : si quelque chose dysfonctionne, c'est d'abord le chef de projet qui est responsable puis il va chercher le membre de l'équipe qui a fauté pour en tirer les conséquences.

Appropriation collective du projet. Une équipe auto-organisée se caractérise ensuite par une cohésion interne forte assortie d'une réelle prise en main des enjeux du projet, obligatoire du moment où l'équipe ne reçoit plus d'ordres extérieurs directs sur la façon de faire. Ce sentiment d'appartenance à la une même tribu, d'adhésion à une même cause est renforcé par les "rituels" agiles tels le daily standup (et qui gravitent autour du task board, comme le décrit très bien Tobias Mayer) ainsi que des pratiques comme le pair programming qui permettent de propager la connaissance du logiciel efficacement parmi les membres de l'équipe.

Amélioration collective. Ce point rejoint la deuxième partie de la définition scientifique de l'auto-organisation : "Typiquement, les systèmes auto-organisées ont des propriétés émergentes". En effet, un système auto-organisé ne naît pas avec un fonctionnement parfait, il l'adapte et l'améliore au fil du temps. En agilité, ce sont bien sûr les rétrospectives et autres dispositifs inspect & adapt qui jouent ce rôle en vue d'une évolution continue.


Auto-organisation4

Les raisons du débat

Voilà pour les traits principaux d'une équipe auto-organisée, mais force est de constater que le concept est loin de faire l'unanimité parmi les acteurs de l'informatique et suscite beaucoup de réticences. Pourquoi cette subversivité alors que les méthodes agiles se veulent être de plus en plus courantes ? Je pense que cela tient essentiellement à trois raisons :

  • Comme je l'ai dit plus haut, le déplacement vers l'équipe de beaucoup des prérogatives du chef de projet (pouvoir d'assigner et de planifier les tâches de développement comme bon lui semble, interface avec le client...) fait grincer des dents, en particulier chez les premiers concernés. On peut les comprendre, d'autant plus qu'en étant tout à fait honnête, il reste quand même aujourd'hui un gros flou autour de ce qui se passe une fois que la méthode a dit "le Scrum Master/coach n'est pas un chef de projet", voire "il n'y a plus de chef de projet du tout". A qui reviennent les responsabilités comme le suivi budgétaire et comptable, les aspects administratifs, les procédures internes, le recrutement... ?
    Piste intéressante : dans un récent billet, Laurent Bossavit, fondateur de l'Institut agile, fait appel à une théorie de l'économiste Ricardo sur la spécialisation du travail pour apporter un début de réponse à cette crainte. Il pose la question suivante : dans un environnement agile, est-il obligatoire de conserver des rôles personnels rigides regroupant un cortège de responsabilités bien fixées, ou s'il ne serait pas plus judicieux de les éclater en répartissant les responsabilités en fonction des compétences de chacun ?
  • Deuxième crainte soulevée par l'auto-organisation : le renversement de paradigme que cela implique. Aplatissement de la hiérarchie, bouleversement des canons de l'organisation du travail et des rôles de chacun, et pas seulement à l'intérieur des équipes de développement... C'est tout le problème de la douloureuse transition d'une structure pyramidale de type command & control à un contexte agile où l'encadrement s'apparente plus à du servant leadership, ce qui touche uniquement les équipes projets dans un premier temps mais a vocation à être assez viral dans toute l'entreprise. A ce propos je vous recommande la très bonne présentation de Roman Pichler sur le changement de rôle des managers dans Scrum.
  • En dernier ressort, inutile de se le cacher, l'idée d'auto-organisation déclenche chez beaucoup et surtout les anglo-saxons, par un réflexe quasi-psychologique, un rapprochement avec des concepts revendiqués par des mouvements d'extrême-gauche : pouvoir au peuple, anarchisme, libertarisme... et aussi l'auto-gestion, cousine lointaine de l'auto-organisation. La crainte implicite sous-jacente est que l'équipe devienne un électron libre, hors de contrôle de l'entreprise, ou, pire, que le rapport de contrôle s'inverse.

Auto-organisation2

Le spectre de l'auto-gestion

Apparu à la fin du XIXème siècle, le concept d'auto-gestion caractérise un groupe, souvent producteur de biens ou services en petite quantité, dont le principe est justement d'être un électron libre. Les décisions se prennent exclusivement parmi ses membres qui sont en général sur un pied d'égalité. Au cours de l'histoire, l'auto-gestion a été expérimentée dans des environnements multiples : coopératives ouvrières, agricoles, jardins partagés, regroupements de salariés... Certaines entreprises d'ingénierie informatique s'y essaient même de nos jours.
Malgré le succès d'un certain nombre de ces entreprises, on retient souvent les mésententes fréquentes entre membres de l'organisme auto-géré ou l'embourbement dans des pourparlers interminables qui peuvent paralyser l'activité du groupe et faire avorter l'initiative. Souvent qualifiés d'utopistes, de doux rêveurs, les participants de ce type d'aventure n'ont malheureusement pas une grande réputation de sérieux. Et c'est précisément cela que craignent les managers : remettre un pouvoir de décision entre les mains de l'équipe ne revient-il pas à le confier à des personnes peu habituées à la responsabilité et trop nombreuses pour trancher, résultant en un "grand n'importe quoi" ? Quels que soient les termes, la question mérite d'être posée.

Dans la même mouvance sociale, il est aussi intéressant de voir que certains agilistes se définissent explicitement comme anarchistes et contribuent activement à porter les méthodes agiles à d'autres domaines que l'informatique, comme par exemple Tobias Mayer (oui, encore lui). Ils restent pourtant rares.

Pour finir

Revenons à la définition de l'auto-organisation en agilité : il est utile de noter que le manifeste agile ne s'aventure pas à la prôner en-dehors de l'équipe projet et des "architectures, requirements, and designs". Pas de volonté affichée de révolution sociale à l'échelle de l'entreprise toute entière de la part des "pères fondateurs", donc. Mais essayer de faire fonctionner le phénomène auto-organisation au niveau développement ne serait déjà pas si mal. Si davantage d'entreprises engagées dans une démarche agile faisaient preuve de confiance et de lâcher-prise vis-à-vis de leurs équipes et abandonnaient pour de bon le sacro-saint besoin de contrôle et de pilotage individuel, sans doute ferait-on un grand pas dans la réussite des projets, la qualité du logiciel livré et le bien-être des collaborateurs.

lundi 5 juillet 2010

Surplus cognitif et contraintes sociales

Je me balade souvent sur le site de la fondation TED, bien connue pour ses conférences. On y trouve des vidéos de présentations très inspirantes sur des sujets comme les nouvelles technologies, l'environnement, les sciences...

Cette fois-ci, je suis tombé sur une intervention récente de Clay Shirky : "How cognitive surplus will change the world", que j'aimerais vous faire partager :

 

Quels enseignements peut-on tirer de ce que dit Shirky ?

  • L'ère d'un peuple de "couch potatoes" vautrées devant la télé est sur le déclin. Grâce à Internet et aux nouvelles technologies, la motivation dispose d'un nouveau carburant, les initiatives sont permises et chacun devient capable de créer et de partager - pour le meilleur et pour le pire.
  • Les contraintes contractuelles sont souvent bien moins efficaces que les contraintes sociales. Les contraintes contractuelles peuvent paradoxalement fausser le jeu en déculpabilisant les acteurs qui les subissent au détriment du bien général de l'organisation, et ainsi déteriorer durablement la culture de celle-ci.
    "Social collaboration over contract negotiation" en quelque sorte... ça ne vous rappelle rien ? ;)

 

PS : j'ai aussi réalisé une version française de la vidéo, mais le lecteur TED avec sous-titres ayant refusé de se laisser embedder, vous pouvez la retrouver [ici].

lundi 4 janvier 2010

En 2010, sachons lâcher du lest !

Ballon

En ce début d'année, je vous propose de prendre un peu de hauteur en nous élevant au-dessus des nuages.

En Juillet dernier, l'aéronaute suisse Bertrand Piccard était invité à la conférence TedGlobal 2009. Dans la vidéo de sa présentation récemment publiée sur le site de TED, Piccard nous raconte son tour du monde en ballon avec Brian Jones et en tire une leçon que je trouve étonnamment en phase avec les valeurs agiles.

Dans cette discipline, explique le navigateur, s'opposer frontalement à un fort vent contraire en voulant garder la même direction coûte que coûte, c'est comme résister obstinément au changement dans la vie : cela peut rapidement devenir un cauchemar.
Comment y remédier ? En comprenant que l'atmosphère est faite de couches dans lesquelles le vent circule dans des directions diverses, et qu'il faut se servir de l'axe vertical pour naviguer entre ces couches, par exemple en lâchant du lest.
Pour Piccard, les pionniers, les découvreurs ne sont donc pas ceux qui font face avec le plus d'acharnement aux difficultés rencontrées, ni même nécessairement ceux qui ont les idées les plus nombreuses ou les plus brillantes. Ce sont avant tout ceux qui osent jeter par-dessus bord leurs convictions, leurs certitudes, leurs habitudes pour accéder à des courants qui les mèneront à ce qu'ils cherchent par des voies de navigation différentes.
On apprend que c'est aussi cet esprit précurseur et un peu utopiste qui a gouverné le prochain projet de Bertrand Piccard, Solar Impulse, un avion fonctionnant uniquement à l'énergie solaire et qui pourrait bientôt prendre son envol autour du monde.

Voici la vidéo :

Voilà, je vous souhaite donc vous aussi de pouvoir lâcher tout le lest nécessaire en cette nouvelle année afin de piloter votre ballon dans la direction de vos rêves :)

vendredi 30 octobre 2009

Agile Tour Bordeaux 2009

Agile Tour 2009 Bordeaux

Jeudi 29 Octobre 2009, l'Agile Tour faisait étape à Bordeaux, au LaBRI. J'étais de la partie et ma foi, le bilan est plus que réjouissant. Au cours de la journée, les 150 participants ont pu apprécier :

  • Des petites viennoiseries et du café pour bien entamer la journée.
  • L'accueil des gentils organisateurs aux brassards roses très seyants ;-)

Mais surtout,

  • Une foule de présentations et ateliers intéressants et instructifs... on aurait parfois aimé pouvoir se dédoubler pour être dans plusieurs salles à la fois.

Du côté des coups de coeur, j'ai été bluffé par le retour d'expérience Scrum de Philippe Launay de la société Agfa. Réussir à introduire l'agilité dans un projet avec des équipes multi-localisées sur plusieurs pays, des milliers d'utilisateurs, un périmètre tentaculaire et en partant avec de sévères handicaps techniques et organisationnels relève du tour de force. L'amélioration continue des équipes permise par la méthode est assez spectaculaire, et les leçons à en tirer très instructives.


Badge Agile Tour

J'ai cependant regretté :

  • Ne pas avoir pu participer à la session TDD donnée par C. Couillard et J-B Dusseaut tellement c'était blindé de monde...
  • Certains ateliers alléchants (dont le "bateau ivre" animé entre autres par Raphaël Pierquin) très limités en nombre de places. Dommage, mais je n'ai pas perdu au change avec le retour d'expérience de Philippe Launay.
  • Un vidéoprojecteur rebelle a décidé de saboter la présentation "Contractualisation agile" qui du coup a pris du plomb dans l'aile malgré toute la bonne volonté de l'orateur...


Le mot de la fin

Au final, cet Agile Tour fut pour moi très instructif et enrichissant. Bravo aux organisateurs qui ont su rassembler autant de talents et favoriser rencontres et échanges d'expériences tout au long de cette journée très réussie !

mardi 27 octobre 2009

Tous des moutons ! Peut-être, et alors ?

Connaissez-vous la doyenne de l'agilité ? La super mamie des itérations ? La matriarche des rétrospectives ? Non ? Et bien laissez-moi vous présenter Linda Rising.

J'aime bien Linda car en plus d'être un peu barrée, elle nous emmène dans des sujets scientifiques originaux et passionnants qui restent tout de même en rapport avec une des choses qui intéressent la bande de geeks que nous sommes : les projets informatiques.

Cette fois-ci Linda revient pour nous parler des Placebos. Pas le groupe de rock, les médicaments... Il s'avère que ces traitements (en fait des non-traitements) sont employés plus souvent qu'on ne le pense par les médecins, et que leur effet se révèle dans certains cas autant voire plus efficace que celui de médicaments classiques. Un chercheur a essayé d'en savoir plus sur cet effet difficilement explicable, et en particulier sur les gens les plus susceptibles de développer un effet placebo. Il a appelé ces personnes les "moutons" (sheep). De manière assez singulière, au fil des recherches, les moutons se sont avérés être des personnes particulièrement créatives, innovantes, curieuses, ouvertes à de nouvelles idées et expériences. En somme, les plus enclins à appliquer avec enthousiasme le célèbre adage de Fox Mulder : "I want to believe".


Bande de curieux

Linda s'est alors aperçue que ce genre de bestiole constituait, entre autres, un assez bon portrait des enthousiastes de l'agilité. Et en effet le parallèle ne parait pas usurpé : les valeurs mises en avant dans les méthodes agiles sont l'ouverture d'esprit, le désir d'expérimenter en permanence, de tester et de tirer les leçons de ses actions pour s'améliorer. En y réfléchissant bien, cela relève d'une volonté primordiale de croire en ce qu'on fait, d'avoir foi en sa propre inventivité. Si nous n'y croyions pas un petit peu, nous ne mettrions pas autant d'efforts à essayer.

Mais du coup, les méthodes agiles ne seraient-elles pas elles-mêmes des placebos ?

Les équipes agiles ne fonctionneraient-elles pas uniquement parce que leurs membres, en bons moutons, s'auto-persuadent du bien fondé de la vision et de la démarche de leur méthode préférée, et avancent ainsi de manière plus sereine, plus impliquée et donc plus productive ?

Si c'était le cas, cela remettrait-il en cause l'efficacité intrinsèque de l'agilité ?

Est-ce qu'on devrait s'en inquiéter ?

La meilleure réponse à toutes ces questions consiste peut-être à se rappeler que l'effet placebo n'est pas seulement l'apanage des cachets en sucre et autres gélules remplies de farine. Même les vrais médicaments peuvent avoir un effet placebo, certaines recherches le montrent. Dans quelle proportion cet effet rentre dans le processus de guérison, cela dépend sans doute du traitement et de la personne, et le "vrai" effet est certainement très difficile à dissocier de la part de placebo.
Mais dans bien des cas, cette part existe bel et bien, et elle n'est pas forcément négligeable...

mercredi 30 septembre 2009

Formation Scrum Master par Pyxis

Formation Scrum Master Pyxis

Il y a quelques jours, j'ai eu la chance de suivre la formation Certified Scrum Master donnée par François Beauregard, fondateur de la société Pyxis. Le tout se déroulait dans un bel endroit, le Centre culturel canadien situé à deux pas des Invalides.

Au programme de ces deux jours très remplis, théorie (rôles, cérémonies, artefacts, 4 piliers de Scrum), bonnes pratiques, ateliers, séances de questions/réponses avec le formateur... Du forfait agile au sprint zéro en passant par les équipes distribuées, de multiples débats ont été soulevés. J'en aborderai peut-être quelques uns ici.

Au-delà de l'aspect formation certifiante (que François a d'ailleurs beaucoup mitigé), je suis surtout reparti tel un gamin après une récréation fructueuse, avec un sac de billes Scrum bien rempli !

Centre culturel canadien La salle de formation Atelier Product Backlog Atelier Product Backlog Les post-its de clôture

- page 1 de 2