Étiquette : conference

Stoos Connect ! Le 25 Janvier 2013 à Amsterdam

Le par addinquydans Compte-renduLaisser un commentaire

Organisé par le “stoos satellite” d’Amsterdam, la conférence stoos connect se déroulera le 25 Janvier prochain à Amsterdam, proposant en présentiel et en livestream une série de lightning talks des initiateurs de ce mouvement.

debalie1

Stoos est  un nouveau souffle du mouvement agile. Réunis dans la stotion de ski de Stoos (encore une station de ski), 21 signataires on réfléchi au devenir du mouvement agile.

Leurs reflexions les ont amenés à considérer qu’un nouvel élant est nécessaire au niveau des organisations.

Pour en savoir plus sur le réseau Stoos, rendez-vous

Stoos Connect ! Le 25 Janvier 2013 à Amsterdam

1ère conférence Lean Kanban France

Le par addinquydans ArticlesLaisser un commentaire

Cette première édition se déroulera les 18 et 19 Octobres dans les locaux de Valtech au 103 rue de Grenelle.

Cette conférence associera des sessions en Anglais proposées par des grands noms du domaine, à côté de sessions en Français proposant cas d’utilisation et retours d’expérience. Le positionnement de cette conférence, ainsi probablement que la capacité d’accueil limitée des locaux met le ticket d’entrée à un tarif assez élevé : de 450 € (early bird) à 800 € (last minute).

Je n’y serais pas, ayant déjà un agenda chargé et aussi, je dois l’avouer, du fait du tarif du ticket d’entrée. Mais une personne de mon équipe y sera. J’espère luis soutirer quelques informations.

1ère conférence Lean Kanban France

Mes retours sur l’Agile Day Valtech 2012

Le par addinquydans Compte-renduLaisser un commentaire

Ce 19 Juin 2012, Valtech nous accueillait dans ses locaux du 103 rue de Grenelle pour une journée de présentations et d’atliers dédiés à l’agilité. Quelques retours.

Keynote

C’est toujours quelque chose d’écouter Laurent Sarrazin ! Il y a du dynamisme, de la substance, beaucoup d’anglicisme et des phrases choc ! C’est sous un format singulièrement raccourcis que Laurent nous a présenté Sweet Rupture qu’il avait déjà joué au Scrum Day. Je n’avais alors assisté qu’à une partie de cette présentation. Ici, j’ai tout vu, mais en accéléré !

Laurent nous raconte l’odyssée du centre agile de la société générale et ses nombreuses sources d’inspiration qui en font de “l’agilité Benetton” selon ses propres mots. Difficile de raconter cette session, je vous propose plutôt d’en visonner la version longue  celle du Scrum Day.

Kanban game

Laurent Morisseau est probablement l’une des personnes les plus pointues en France sur l’application de Kanban en France. Il est d’ailleurs l’auteur d’un livre qui arrive en librairie ces jours-ci : Kanban pour l’IT. Vous devriez d’ailleurs avoir droit à une note de lecture à ce sujet dans euh … un certain délais, car Laurent a eu la gentillesse de m’en faire parvenir un exemplaire !

Cet agile game est désormais un classique, car Laurent a déjà joué le Kanban Game à de nombreuses reprises. Toutefois je n’avais jamais eu la possibilité d’y participer. J’étais donc bien décidé à combler cette lacune.

Je n’ai pas été déçu, d’autant que Laurent et son complice Dimitri Baeli (visiblement faire collaborer Bretons et Normands est donc possible) sont rompus à l’exercice. Nous avons donc exécuté par équipe de 6, 8 itérations de développement afin de délivrer de la valeur, mais surtout de l’argent (eh oui : la valeur délivrée tôt capitalise et rapporte plus…). Voici ce que j’en ai trouvé:

  • Le jeu est intéressant et prenant, la qualité de l’animation aide sans aucun doute !
  • Des équipes de 6, c’est un peu trop: on se marche sur les pieds et cela génère trop de discussions quand aux différents choix !
  • Le jeu met bien en évidence les “limites de WIP” et le focus sur le flux et les goulots d’étranglements.
  • L’aspect “comptabilité” est un peu complexe et ce n’est pas évident d’en tirer les enseignements. Au minimum, il aurait fallu passer plus de temps (encore !) pour les décoder.
  • Le timing était un peu trop serré, mais c’était lié à l’agenda spécifique de cet Agile Day. Les conditions normales requièrent un peu plus de temps.

Bref, je suis satisfait de cet agile game qui matérialise très bien les aspects principaux du Kanban.

Outside in Design : the BDD way

Cette session présentée par Marcus Anhve de Valtech Suède était pour moi la session hard core de cette journée ! Concrètement, cette session dédiée au Behaviour Driven Developement par l’exemple était d’un abord ardu pour moi : Marcus a réalisé ses exemples en Ruby (que je ne connais pas), en y ajoutant du Rails, de la compilation avec Rake  et évidemment du RSpec pour l’acceptance testing ! Sans oublier un moteur de templating pour le HTML que j’ai justement oublié …

Bref, au-delà de la présentation d’introduction il me fut très difficile de suivre le fil, j’ai juste réussi à ne pas être complètement noyé. Respect pour notre très cool présentateur qui a réussi à faire du “par l’exemple” avec absolument aucun code préparé à l’avance et en réalisant absolument tout en live ! Franchement il faut le faire et c’est la première fois que je le vois ainsi fait intégralement. Marcus m’a confié qu’à son avis c’est vraiment la bonne façon d’exposer la façon dont on avance et on construit les choses : de le faire sans tricher !

Innovation needs waste

Ce fut ma sesion préférée de la journée ! L’animateur de cette session, Dirk Lässig de Valtech Germany était venu nous initier au Design Thinking. Dirk a intelligemment combiné une présentation limpide avec un exercice hélas un peu trop sous la contrainte du temps !

Le Design Thinking, quest-ce que c’est ? Une approche et un ensemble de pratiques pour permettre l’innovation radicale, celle qui n’est pas une simple amélioration d’idées existante mais l’émergence d’un concept nouveau en rupture avec l’existant !

Les approches agiles parlent souvent de “vison” et de son importance. Mais d’où vient-elle ? D’une personne particulièrement géniale qui l’a sortie de son chapeau à l’aide d’un quelconque tour de magie ? Faire émerger les Visions innovantes ne doit plus être comme le-boulot-de-quelqun-d’autre-car-nous-on-écrit-du-code ! Le design thinking nous apprend à mettre ensemble des personnes d’horizons différents justement pour élargir le champs du possible. Et justement pour élargir ce champs il faut générer des idées sans se censurer, même si au final la plupart et peut-être même toutes seront écartées.

Nous avons donc tenté (avec un succès mitigé, je le crains) d’abord d’identifier des cibles et des contextes d’utilisation pour une application smartphone, puis de développer ce concept à l’aide de techniques de brainstorming. Bien sûr en si peu de temps, il ne pouvait s’agir que de jeux de l’esprit. Toutefois un peu plus de temps aurait certainement produit un résultat plus pertinent.

Mais j’ai appris une nouvelle chose, un nouveau territoire à explorer qui fait le lien avec d’autres que je connais. J’ai aussi remarqué et apprécié la synergie très importante entre cette approche et le Lean Startup. D’ailleurs cette technique est fugitivement évoquée dans le livre d’Eric Ries. Ici aussi on parle d’emettre une hypothèse, de confronter celle-ci à la réalité le plus vite possible, d’apprendre sur cette base et d’itérer en s’appuyant sur ce que l’on a appris.

Bravo Dirk !

L’agilité au service du marketing, une révolution en marche

Une mauvaise pioche m’a fait choisir cette session que j’ai trouvé la plus décevante de la journée ! J’étais impatient de voir et comprendre l’agilité projeté dans le domaine du marketing. Hélas la présentation de Laura Guillemin manquait cruellement de substance ! Certes, la bonne idée de cette présentation était d’y faire participer des acteurs métier (mais aussi un consultant). Alors oui, on peut facilmement se douter que les plan marketing à long terme se voient balayés par les itérations rapides et les possibilités qui nous sont offertes de mesurer les impacts dans l’économie numérique ! Mais même un gros bourrin d’informaticien comme moi sait cela depuis longtemps.

Il existe une substance, des concepts dans le marketing numérique dont j’ignore même l’existence. Un question venant de la salle (mais vite balayée) sur les modèles d’attribution en a été l’un des exemples. Bref, je n’ai rien appris !

Keynote de cloture

A la session de Laura Guillemin, j’ai largement préféré la cloture que nous a proposé Scott Brinker ! Difficile de résumer cette intervention vraiment très riche. Je vous recommande la présentation qui est en lien, ce support est vraiment très bon (avec un petit arrêt sur le slide 16). Le(s) message(s) de base de cette présentation est (sont):

  • Tout est marketing !
  • Tout le monde doit être agile !

Un grand merci à Valtech d’avoir organisé cette journée !

Agile Games France 2012 (en images)

Le par addinquydans Compte-renduLaisser un commentaire

Il était une fois…

Il était une fois un (petit) groupe d’agilites bien décidés à faire quelque chose du côté des “agiles games”. Il n’étaient pas nombreux, mais très motivés. Il n’étaient pas voisins mais se créerent une mailing list pour pouvoir échanger sans même se connaitre.

Puis vint un jour où ils décidèrent de passer du virtuel au réel, de se rencontrer afin d’expérimenter, de créer et d’échanger.

Cela prit forme sous l’impulsion de quelques membres particulièrement actifs du groupe (je ne vais pas les citer, de peur d’en oublier). Rendez-vous fut prit et un lieu trouvé. c’était le week-end dernier, et c’était à Nantes.

Bienvenue à Agile Games France 2012

Agile Games France

Nous nous sommes donc retrouvés à presque 40 à Nantes, venus d’un peu partout. Une bonne moitié d’entre-nous sommes arrivés la veille, l’occasion de diner entre nous avant d’emtamer les choses sérieuse, ou les choses ludiques, devrais-je dire !

Vendredi !

Les arrivées des uns et des autres s’échelonnant entre 8h30 et 9h30, nous avons débuté par la création collaborative d’un “low tech social network”. Une première en france !

Untitled

Une bien belle oeuvre, mais heuresement que l’on était pas trop !

Comme dans tout bon forum ouvert, nous avons ensuite planifié la journée (enfin la matinée déjà pour commencer).

Untitled

Deux activités essentiellement pour moi durant cette matinée : la reflexion et l’essai d’une “beta version” d’un jeu orienté RH et le “jardinier agile”.

Le jardinier agile, c’est la construction d’un jardin en mode itératif, avec des évènements venant émailler notre activité. Deux équipes s’affrontent en parallèle et nous avons botté les fesses à nos adversaires. C’est bien fait !

Untitled

Nous ne sommes pas arrivés au bout de ce que nous souhaitions faire sur ce jeu RH. Pourtant j’en ai retiré un certains nombre de réflexions, assez simples mais qui, comme toujours, ne naissent pas spontanément:

  • Ne pas complexifier outre mesure le jeu, sinon on consacre notre attention à comprendre le jeu et non à en tirer les enseignements.
  • Ne pas chercher à démontrer trop de choses. En fait, il faut se focaliser sur une seule !

Bon, il y a aussi d’autre petites choses que cela m’a appris, mais c’est trop compliqué à développer dans ce billet, donc je passe !

Je me rend compte que cela va être pénible si je passe en revue les différents jeux auxquels j’ai participé, donc passage au mode “avance rapide” ! Ah, si: je dois mentionner “The big Payoff”, car il sera joué à la Scrum Night ! Verdict : il marche et il est bien !

Untitled

Voilà : fin de la journée ! Une petite bière, un restau ensemble et au dodo !

Samedi !

Tout d’abord, un petit coup de balais !

Untitled

Puis de nouveau un Open-Space pour commencer la journée. On y décide d’y rejouer certains jeux de la journée précédente.

Untitled

L’agile Beer (on m’a bien précisé que l’on n’y buvait pas) d’Alexis Monville semble être un beau succès. Hélas je n’y participerais pas !

Untitled

Pas plus qu’au “petit oiseau”. Mais l’animation exhubérante d’Alex Boutin nous a permi d’en profiter de partout !

Untitled

Une idée intéressante à reproduire en cette seconde journée : Les jeux qui ont été rejoués sur la seconde journée ont été animés par des participants de la journée précédente !

Nous nous somme aussi livrés à un essai de création de jeu depuis zéro. J’aime bien le titre “range ta chambre”. Mais je pense que l’itération 1 ne saurait être la dernière. Ce n’est pas convainquant en l’état. Créer un jeu, ce n’est pas si facile !

Le premier Agile Games France se termine. Quel jeu remporte les suffrages ?

Untitled

C’est Alexis Monville, avec l’Agile Beer !

Voilà il est temps de ranger et clore. A l’année prochaine !

Untitled

Rencontre avec Bertrand Meyer

Le par addinquydans Compte-renduLaisser un commentaire

Ce 9 Mai, Valtech nous avait invité à rencontrer Bertrand Meyer. Figure emblématique de l’objet à la fin des années 1980 / début des années 1990, j’avoue que je n’avais plus entendu parler de cette sommité depuis de nombreuses années. L’objet s’est effacé du devant de la scène dans la seconde moitié des années 90 tandis que le Web tractait toute l’attention, et le nom du créateur d’Eiffel a disparu des titres.

C’est donc avec grand plaisir que je suis venu l’écouter, entendre parler d’objet à nouveau et en savoir plus sur ses sujets d’investigation d’aujourd’hui.

Un peu de Biographie

Diplomé de Polytechnique (X-Telecom), Bertrand Meyer a rejoint la direction des études d’EDF en 1974. Parti pour un an en Californie, à Santa Barbara, il y restera quatre, entre 1983 et 1986. Il y rencontrera des sommités de l’informatique, tel que Donald Knuth, mais il créera surtout le language Eiffel

Depuis 2001, Bertrand Meyer occupe une chaire de professeur à l’EPFL de Zurich, où il succède à Niklaus Wirth, le créateur du language Pascal.

Parlons maintenant d’Eiffel

Pour débuter, Mr Meyer nous propose de commencer… par évoquer les points négatifs !

Les points négatifs

  • Eiffel n’est supporté par aucun acteur majeur de l’industrie. C++ Le fut par AT&T, puis par Sun. Java l’a été par Sun et désormais par Oracle.
  • Mais il s’est fait sa place chez certains industriels qui lui sont fidèles.

Il s’agit d’une petite communauté. Toutefois cette communauté n’a jamais cessé d’exister depuis 25 ans. Donc si ce mouvement est discret il est solide.

  • De manière assez curieuse, après avoir essuyé les reproches d’être un langage “trop jeune”, Eiffel est presque directement passé au statut de “legacy” !

Pas de phénomène de mode autour du langage. A aucun moment, il n’a eu la réputation d’être le langage “dans le vent”. Absence de composants réutilisables. Ce dernier point est paradoxal, car le langage a été imaginé et créé au départ avec cette finalité en tête.

  • Aujourd’hui les librairies existent mais restent peu nombreuses comparées aux standards du marché.
  • Mais le langage est simplement interfaçable vers le C et le C++ (le compilateur fonctionne en “C front”). L’interfaçage se fait également sur la machine virtuelle .NET de Microsoft. L’interfaçage vers Java est possible, mais difficile.

Les points négatifs … qui n’en sont pas

  • “Cette fonctionnalité finira par arriver dans mon langage favori”. Les ajouts de fonctionnalités après coup dans les langages s’avèrent générallement boiteuses. Par exemple les “code contract” de .net fonctionnent comme des pièces rapportées.
  • “Il n’y a pas de programmeur Eiffel”. Eiffel n’est pas une religion. Tout développeur aguerri à l’objet peut se mettre aisément à Eiffel. Il est apte à être pris en main par des débutants, plus qu’il ne s’avère possible avec C++ qui est un langage difficile à maîtriser.
  • Pas de covariance pour l’instant. Il s’agit d’un problème avec le système de type sui sera résolu bientôt.
  • Pas fait pour le Web. Là aussi il s’agit d’un point en cours de résolution. Le framework EWF adressera cela.

Ce pour quoi Eiffel est fait

  • Il ne cible pas les réalisations “quick and dirty”. Les langages orientés script tels que Perl et Python sont mieux ciblés pour cela.
  • Il ne cible pas non plus le temps réel: la présence d’un garbage collector est une source d’alea trop importante pour répondre aux exigences du temps contraint

Et les types de développements ?

  • Les développements “casual” ne sont pas non plus le coeur de cible du langage (cf le “quick and dirty”)
  • Le développement professionnel en entreprise est clairelment la cible du langage. C’est par ailleurs la très grande majorité des développements informatiques.
  • Les développements critiques (money critical, life critical) : pas non plus la cible privilégiée du langage, malgré la présence de fonctionnalités adaptées (typage forts, contrats).

Quels sont les argumentaires d’Eiffel ?

Par rapport à sa cible, ce sont les arguments liés à la qualité sur le long terme:

  • Extensibilité
  • Fiabilité
  • Scalabilité
  • Portabilité (grâce au compilateur “C front”, il a le niveau de portabilité du C sous-jacent).
  • Intégration méthode / langage. Nous reviendrons sur ce point.

Cet argumentaire qualité passe hélas peu. Il est pourtant très aligné sur les principes sous-jacents à l’agilité au niveau du code, selon l’analyse qu’en fait Bertrand Meyer, suite à sa formation “Scrum Master”.

Alors quels sont les projets classiquement dévolus à Eiffel ?

  • Ceux pour lesquels tout le reste n’a pas marché !
  • Ceux qui sont soumis à des évolutions fréquentes.
  • Ceux pour lesquels il y a un “champion local” supportant ce choix.

Et justement, ces développeurs à quoi ressemblent-ils ?

  • Ce sont tout autant des concepteurs que des codeurs … et certainement pas de simples codeurs: comme dans tout langage objet, les principes de conception sont liés au langage, mais pour Bertrand Meyer, c’est encore plus le cas avec Eiffel !
  • Ce sont des développeurs dont la volonté de se perfectionner est plus importante que celle de suivre le plus grand nombre.
  • Il semblerait aussi que la pratique d’Eiffel rende beau et donne un charme irrésistible auprès des femmes ! Et voilà : Bertrand Meyer nous a pris par surprise, car sous une apparence disons classique, le créateur d’Eiffel a un sens de l’humour tout à fait aiguisé, et il nous délivre ses traits sous un air pince sans rire redoutablement efficace !

La réalité d’Eiffel aujourd’hui

Eiffel est à la fois une méthode, un langage et un environnement.

En tant que méthode

Eiffel suit les principes de la conception orientée objet, tels du moins que son auteur les a décrits dans son ouvrage disponible dans toutes les bonnnes librairies.

Eiffel suit le principe du “single model”, c’est à dire que le code du langage porte le code d’exécution, mais aussi des informations d’analyse, comme celles concernant les pré/post conditions et les invariants.

L’approche orientée obets est l’axe principal (unique ?) de l’approche d’Eiffel, la méthode (et le langage) supportent donc le paradigme des types abstraits de données, ce qui signifie :

  • Une description abstraite des propriétés des opérations.
  • Une organisation des types en hiérarchies supportant le polymorphisme (principe de substitution de Liskow).

En tant que language…

Eiffel a été normalisé par l’ISO en 2006. L’implémentation du compilateur est donc ouvert à la concurrence, du moins en principe.

La classe est le seule mécanisme de modularisation. Pas de “package”, de “namespace” ou de “module” !

Par ailleurs, Eiffel est un des rares langage qui supporte l’héritage multiple, position que Bertrand Meyer défend avec ardeur. Si je le suis sur ce terrain, l’exemple qu’il nous a présenté ne m’a pas paru terriblement percutant: le cas du vélo qui hérite de “véhicule” et de “Liste” me semble boiteux, car ces deux abstractions sont de niveaux très différents. Ainsi la liste devrait être un simple élément d’implémentation dans le vélo…

Eiffel supporte aussi depuis le départ la notion de générique. Contrairement à C++ et surtout par rapport à Java, cette fonctionalité n’est pas une pièce rapportée … surtout quand elle est aussi faible que le “type erasure” de Java !

… Toujours vivant !

Le langage est désormais “void safe”. Cet ajout arrivé il y a 6 ans interdit le déréférencement de pointeurs pouvant être nuls ! Et ceci est même vérifié à la compilation.

Les agents. Il permet de construire des clases qui sont des “observer” du pattern MVC. D’autres classes pouvant évidemment publier des évènements. C’est le MVC intégré dans le langage !

En tant qu’environnement

Eiffel Studio est le standard “de facto” du langage. Il intègre 2 compilateurs:

  • 1 compilateur “C front” qui est le compilateur historique d’Eiffel. Ce passage par le C est le couche qui assure au langage sa portabilité, comme je l’ai évoqué précédemment.
  • Un compilateur sur la machine virtuelle .NET de Microsoft.

Le compilateur utilise la technique dite de “la glace fondue”, en fait une compilation incrémentale qui rend les temps de compilation non pas dépendants de la taille du projet, mais de l’importance des changements depuis la dernière compilation.

Design by contracts

L’un des apports originaux (repris depuis par d’autres langages) est la notion de contrats. Ceux-ci sont intégrés au code selon le principe du “modèle unique” que nous avons évoqué plus haut. L’environnement dispose quand à lui d’outils pour extraire ces informations à différents niveaux (modèle, documentation, tests…). Il y a 3 types de contrats:

  • Les préconditions : Il s’agit des conditions que l’apellant doit respecter avant l’appel à la méthode.
  • Les postconditions : Il s’agit des conditions que l’apellé doit respecter avant de rendre la main.
  • Les invariants: Ils doivent être respectés à tout moments..

Dans le cas du polymorphisme, les préconditions appartenant à l’abstraction sus-jacente doivent être respectées au moment de la liaison tardive entre appelant et apellé.

Les contrats permettent de vérifier les domaines de validité des paramètres en entrée, de valeurs de retour en sortie et les conditions de stabilité des objets. Dans le cas de l’explosion d’Ariane 5, la vérification du domine de validité des paramètres d’entrée aurait suffit à prévenir l’explosion de la fusée !

En développement, la violation de contrat nous emmène directement dans le debugger, celui-ci précisant la nature du contrat non respecté et le contexte.

Eiffel et les tests unitaires

Bertrand Meyer s’inscrit dans la logique de mise en place des tests unitaire instillée par les pratiques agiles et plus particulièrement TDD ! Cependant il juge que ceux-ci souffrent encore de points faibles, parfois simplement passés sous silence dans la littérature:

  • Génération des tests unitaires: les tests passants et surtout les tests non-passants.
  • L’enrichissement des tests unitaires sur la base des échecs d’exécution.
  • La minimisation des tests afin d’en optimiser l’exécution.

L’environnement Eiffel propose un outil à cet effet nommé Autotest qui permet la génération des tests à partir de contrats, mais égallement leur enrichissement sur la base des échecs d’exécution. Bertrand Meyer n’a rien dit sur le volet de la minimisation, j’imagine donc que c’est toujours un sujet en cours de travail.

Le parallélisme avec SCOOP

Il s’agit d’une nouvelle extension d’Eiffel : Simple Concurrent OO Programming. Il s’agit bien d’une extension car au moins un nouveau mot-clé (separate) est introduit dans le langage avec SCOOP. Le problème de la concurence n’est pas nouveau et nous savons tous qu’il n’est pas simple à adresser. Son importance augmente pourtant de manière importante, avec la progression des processeurs “multi-coeurs”.

SCOOP met en avant les notions d’action, d’asynchronisme et surtout de “région”. SCOOP prend en charge les mécanismes de synchronisation de bas niveau afin de permettre ce que Bertrand Meyer juge important : pouvoir raisonner sur les programmes.

Le principe de base de SCOOP est le “wait rule”: une action ne démarre pas tant que toutes les ressources nécessaires ne sont pas disponibles.

Les développements en cours

Depuis qu’il a repris en 2001 la chaire de professeur de Niklaus Wirth, Bertrand Meyer poursuit ses travaux autour d’Eiffel:

  • La notion de “preuve” formelle, et de vérification statiques ou dynamiques des programmes.
  • La persistence
  • Le “cloud based developpement”. Dans cet environnement, le VCS (ou même le DVCS à la Git) disparait. Les changements se font et sont répercutés en temps réel, à la Google doc.
  • EVE: une évolution de l’environnement Eiffel permettant la vérification des programmes minute par minute.
  • Autofix, qui l’étape suivant d’Autotest: l’idée ici est de proposer des corrections automatiques des programmes pour les cas simples. Actuellement le ratio de succès de cet outil est de 2/3, testé sur les correctifs apportés au fil du temps sur les librairies Eiffel elle-mêmes.

En conclusion

Eiffel existe, il est toujours en cours d’évolution. Mais il ne deviendra jamais “mainstream”. L’auteur l’avoue et s’en accommode. Certaines choses qui sont acquises dans des langages modernes : la covariance, la présence de frameworks Web sont encore très récentes ici ou en cours de développement. Le langage reste ancré sur ses choix initiaux : purement objet, sans mécanisme de modularité à grande échelle ni intégration de paradigme tiers comme la programmation fonctionnelle. Ces choix ont nécessairement un impact pour rendre le langage attrayant pour le plus grand nombre, mais c’est une bataille que Bertrand Meyer ne cherche plus à mener.

Paradoxalement, cette position de niche lui confère certains avantage, comme la possibilité de ne pas rester fixé sur la stricte compatibilité ascendante lors des évolutions du langage. Et si la communauté est petite, elle est très fidèle à Eiffel. Car le langage reste remarquable, certes doté d’un ecosystème de librairies sans commune mesure avec Java, mais avec un design de base qui n’a rien à lui envier, bien au contraire !

Si vous voulez aller de l’avant avec Eiffel, vous pouvez rejoindre le Groupe des Eiffelistes Francophones (la page Google Group est ici). Merci à Jocelyn Batton de l’avoir créé !

FrenchSUG@Google

Le par addinquydans Compte-renduLaisser un commentaire

Avant-propos

J’ai mis du temps a écrire ce compte-rendu. Ce genre de travail est toujours plus long qu’on ne s’y attend en premier lieu. Anne gabrillagues m’a devancé de presqu’une semaine et a rédigé un excellent compte-rendu que vous retrouverez sur le blog Ippon. Anne est également présente sur Tumblr.

Dans le même ordre d’idées, je vous recommande aussi la lecture du Blog de Jean-Charles Meyrignac. Nous différons sur l’analyse de certains points et c’est d’autant plus intéressant, d’autant que le post est d’excellente qualité !

Google, c’est toujours un peu l’actualité en permanence. Si la présence de Petra Cross en France attire notre attention sur la place des femmes chez Google, je vous recommande aussi l’article sur Marissa Mayer sur IEEE Spectrum.

Vous retrouverez des photos de l’évènement sur Meetup. Place aux orateurs !

L’évènement

Le Scrum User Group Français était accueillis ce 17 Avril par Google, pour nous faire partager la pratique de l’agilité dans leurs équipes de développement. Un accueil excellent par ailleurs, avec beaucoup de gentillesse de la part de notre hôte, Martin Görner et un petit déjeuner offert. Nous étions certainement un peu serrés dans les locaux de l’avenue de l’Opéra, mais il faut dire que cet évènement a créé un engouement sans précédent, nous avions élargi le plus possible le nombre de places disponibles, mais malgré cela, toutes les places sont parties en une journée créant une liste d’attente assez conséquente sur Meetup.

Martin Görner

Après un (rapide) mot d’ouverture de votre serviteur, Martin Görner nous a servi en guise d’introduction un portrait savoureux d’une équipe de développement sur la base des personnages d’héroïc fantasy ! Avec dans l’ordre:

  • Les Barbares, à savoir l’équipe de développement.
  • Le Clerc, l’ancien qui a la connaissance et la sagesse.
  • Le Mages, capable d’opérer une magie que lui seul sait faire … mais qu’hélas aussi lui seul détient !
  • Le Maître, celui qui enseigne à l’équipe, diffuse sa connaissance et sa sagesse.
  • Les Amazones (si, si) Symbole de la diversité de l’équipe.
  • La Bête, celui qui va mettre dans vos projets un nouveau langage chaque jour. On n’en veut pas.
  • Le Scout, qui va explorer des territoires inconnus,
  • Le “dragon rider” qui comprend les aspects métier complexes.

Petra Cross : Behind the day to day at Google

Petra Cross en Bref

Petra travaille chez Google depuis 7 ans. Elle a débuté sa trajectoire sur le moteur de recherche, avant de rejoindre l’équipe GMail. Depuis cette année elle fait partie de l’équipe Google Wallet localisée à San Francisco.

Les équipes Google en quelques faits

  • L’engagement des membres des équipes ? “Achieve mission ! Whatever we’re doing !”
  • Les équipes: 10000 développeurs, répartis dans plus de 40 bureaux à travers le monde.
  • 20 “check in” par minutes
  • 50% de la base de code est modifiée chaque mois.

Les rôles

  • VP (vice-president) : Un par grand domaine de Google: Search, Social, etc…
  • Engineering Director 
  • Engineering Manager : Il gère les ressources et les personnes. Il n’opère pas de “micro-management”, mais opère selon le principe du “servant manager” cher à nos principes agiles.
  • PM (Product Manager) : C’est la personne qui a la vision client sur un projet. Il joue en gros le rôle du PO de Scrum
  • SWE (Software Engineer) : Ce sont les développeurs.
  • SWE / TL (Team Leaders) : Ce sont des développeurs comme les autres, mais ils jouent le rôle d’interface avec les autres équipes et avec le PM quand c’est nécessaire. Leur rôle est de faire gagner du temps aux autres développeurs en leur épargnant des tâches annexes. Il sont plus ou moins l’équivalent du Scrum Master de Scrum. Petra a joué ce rôle au sein des équipes Google Mail.
  • SET (Software Engineer in Tests) : Ce sont des développeurs dont le travail est spécifiquement focalisé sur l’intégration continue et les tests unitaires.
  • TE (Testers) : Leur travail est spécifiquement dirigé vers l’écriture de tests d’acceptante.

Chaque Engineering Manager gère un ensemble d’équipes formés typiquement de 6 personnes : 5 SWE et 1 SWE/TL. Les équipes ne sont pas complètement fixes dans le temps, le manager crée un peu de mouvement entre les équipes. On eut dire que ce concept se rapproche quelque peu des Feature Teams de Scrum.

Au niveau de l’agencement des locaux, Petra nous a montré quelques photos des locaux de San Francisco. Outre son propre poste simplement situé près d’une fenêtre donnant directement sur le Golden Gate Bridge, on voit que les développeurs sont regroupés en de larges open-spaces. Chaque poste de travail comporte typiquement une station de travail, souvent un PC fonctionnant probablement sous Linux, équipé de 2 écrans 24 pouces, et un portable qui peut être un MacBook ou un PC. Certains disposent l’affichage de leurs écrans 24’’ verticalement !

Le workflow du développement

Le développement est plutôt “orienté Kanban”, bien qu’il ne semble pas y avoir de limite de WIP explicite. C’est ce que Petra nomme “Features Development as a Queue”. Le workflow est le suivant:

  1. Idée
  2. Décliné en Feature
  3. Planifié
  4. En cours de travail
  5. En revue de code
  6. En test
  7. En beta test “Canary”
  8. En production Live !

Les développeurs sont responsables de la qualité du code qu’ils poussent dans le gestionnaire de version. Le code intégré dans l’intégration continue doit être totalement testé par le développeur qui le considère LGTM (Looks Good To Me).

Le Release Manager  a la responsabilité de prendre régulièrement un snapshot de code qui a passé l’étape “tests” et de le mettre à disposition en “canary build” pour 2 jours, afin que ces évolutions soient pleinement testées en situation réel par des beta testers. A l’issu de ces 2 jours, si le build est accepté, il passe en production !

Ce que Google cherche à faire avec son processus

C’est essentiellement gagner en efficacité, en:

  • Raccourcissant ce temps de cycle
  • Travaillant rapidement
  • En ne développant que ce qui a réellement besoin de l’être !

Ce que Google ne cherche pas à faire :

  • Echouer
  • Gaspiller de l’argent

Le processus de développement est en fait très largement “Kanban”, mâtiné d’itérations, comme on le verra bientôt.

Les User Stories sont définies et écrites par le PM. Sans que cela soit explicitement définit dans Scrum, les deux processus se rapprochent ici. Le PM évalue la taille de ses stories en utilisant des “PM points”. Les  users stories sont découpées en tâches par le PM et le Tech Lead. Oui, vous avez bien lu: l’équipe n’est pas directement impliquée (en tout cas pas en premier lieu) dans le découpage en tâches !

L’équipe fait ensuite, lors des planning meeting, l’estimation des tâches. Le PM n’est pas présent au planning meeting. Les tâches sont estimées par l’équipe, avec le teck lead. Le critère retenu est celui que nous connaissons bien avec Scrum: savoir quand la tâche est “done”. Si ce critère ne peut être clairement déterminé, c’est au Tech Lead de retravailler la tâche avec le PM. J’y vois une faiblesse du processus qui génère du délais dans ces cas, délais qui pourraient être éliminés simplement par la présence du PM lors des planning meetings ! Mais peut-être que ce problème ne se pose que très rarement ?

Tout cela est bien entendu géré. Mais plutôt que d’utiliser un outil de gestion de projet, c’est une simple feuille de calcul (Google Spreadsheet, bien sûr) qui est utilisée. Elle est divisée en 2 onglets :

  • L’onglet “PM” : Utilisé pour lister les users stories.
  • L’onglet “équipe” dans lequel on retrouve le découpage en tâches.

Les User stories suivent aussi un cycle de vie de haut niveau:

  • Icebox: C’est le congélateur. Les US qui ne seront pas prises dans les 2 ou 3 prochaines semaines sont simplement stockées ici sans être analysées plus avant. Pas question de perdre du temps sur des fonctionnalités dont on est pas sûr qu’elles seront implémentées un jour ! Implicitément cela en dit long sur la façon dont Google gère la notion de roadmap : il n’y a pas de roadmap ! Il y a bien une Vision, mais celle-ci n’est pas déclinée en roadmap / releases ! Le congélateur sert à garder trace des idées, à permettre de les exhumer quand ou si on veut les réaliser à un moment donné.
  • Backlog : Seules 2 ou 3 US sont prises dans une itération de 2 semaines (il n’y a pas de durée standard d’itération chez Google, cela est ajusté par équipe). Tout ce qui n’est pas pris pour cette prochaine itération retourne au congélateur. Le PM et le Tech Lead priorisent les tâches lors du travail de découpage.
  • En cours: Il n’y a pas de “limite de WIP” sur les tâches comme il y en a de manière formelle avec Kanban. En pratique, chaque développeur aura au maximum 3 tâches en cours. il peut être amené à prendre une tâche supplémentaire quand:
    • Il est bloqué ou que sa tâche est en cours de revue.
    • Il ressent la besoin de changer pour éviter la saturation !
  • Terminé et vérifié.

En pratique !

Les équipes ont pas mal de l’attitude sur la façon de gérer leur matière première, c’est à dire les tâches. Pour l’équipe GMail, par exemple, c’est l’utilisation d’un tableau de tâches qui a été retenue, chaque “swimlane” représente une des étapes de progression de la tâche.

Le planning meeting est traditionellement court, de l’ordre de 20 minutes pour des itérations d’une ou deux semaines (et on estime toujours un peu plus de tâches que ce qui peut être pris dans l’itération) ! La seule chose qui y est faite est réellement l’estimation des tâches, car leur découpage a déjà été opéré précedemment par le PM et le Tech Lead, comme je l’ai dit précédemment. On ne cherche pas à y reconstruire de “big picture”, on prend juste les tâches les unes après les autres…

L’estimation est faite en points, selon une échelle de Fibonacci modifiée. Le fonctionnement du planning meeting est globalement très codifié:

  • On ne donne pas d’avis ou d’impression sur la tâche du genre: “c’est difficile”, “ça va être facile”, etc.. 
  • On est seulement autorisé à poser des questions fermées auxquelles le Tech Lead peut répondre par “oui” ou par “non”.
  • Il y a un ordre strict de parole !

Un chose importante à noter est que si le planning meeting rythme le travail en permettant d’alimenter le flux de travail, cela ne stigmatise pas le début ou la fin d’un cycle de travail: il est courant d’avoir un reste de tâches ou des tâches en cours au moment du planing meeting !

Comme avec Scrum, les tâches ne sont pas attribuées. On prend les tâches dans l’ordre de priorité qui a été défini. Cela signifie qu’une personne nouvelle sur un sujet prendra plus de temps ou demandera de l’aide pour mener à bien sa tâche. Cela n’est pas considéré comme un handicap, mais comme un aspect positif: les équipes Google ne souhaitent pas créer des ilots de connaissance !

Le peer review est systématique, alors que le pair programming ne l’est pas (il peut être pratiqué occasionnellement). Chaque tâche de revue de code est systmatiquement de la plus haute priorité : débloquer ses pairs est considéré comme l’apport le plus important que l’on puisse faire !

Le daily standup n’est pas pratiqué par de nombreuses équipes ! Cet aspect est également laissé au grée de l’équipe. Par exemple:

  • L’équipe GMail pratique le planning meeting, mais pas le stand-up
  • L’équipe Google Wallet fait des stand-up, mais n’a pas de planning meeting.

Petra par ailleurs ne semble pas fan du daily meeting.

Les rétrospectives sont pratiquées de diverses manière mais sont extrêmemnt courtes

  • Si la rétrospective est effectué chaque semaine, sa durée sera d’environ 15 minutes.
  • Pour une rétrospectives mensuelle, on comptera 1 heure.

Une rencontre mensuelle se tient avec le l’équipe, le PM et le directeur de l’ingénierie pour dresser les grandes lignes de ce qui est à venir.

Et l’environnement ?

Les développeurs bénéficient de beaucoup de liberté par rapport aux outils qu’ils peuvent utiliser. Beaucoup utilisent Eclipse, ils peuvent alors bénéficier de l’aide d’une cellule dédié à cet outil.

Pour ce qui est des outils d’intégration:

  • Git est utilisé pour la gestion de version au niveau des développements.
  • Perforce est utilisé par le Release Manager et les équipes de test, pour travailler en terme de “change set”.
  • L’environnement d’intégration continu (désolé, je ne sais pas ce qu’il y a derrière) est standardisé entre les différentes équipes Google à travers le monde.

Ainsi, si chaque développeur peut bénéficier du confort d’un ensemble d’outils qu’il connait, le passage d’une équipe ou même d’un site à un autre est facilité par des outils de travail en équipe qui sont eux standardisés !

En conclusion

Google est-il agile ou non ?

La réponse à cette question ne semble pas avoir d’importance pour eux. Sans doute ont-ils raison !

Ma réponse serait oui, non en regard des pratiques, mais de la mentalité. Tel que l’a dit Petra en début de présentation, c’est “achieve mission, whatever it is !”.

Google suit-il Scrum : non ! Bien que certaines pratiques soit très proches. Encore une fois , cela semble d’une importance secondaire. L’axe prédominant est clairement Kanban, l’importance est sur le flux et l’efficacité de celui-ci, les cérémonies qui vont autour sont réduite au maximum. Cela est aussi probablement dû à la très grande maturité des équipes de développement.

Deux aspects de moyenne ou faible maturité agile m’ont surpris :

  • Une stratification assez importante des fonctions PM / Tech Lead, avec par exemple un découpage en tâche dans lequel l’équipe n’est pas impliqué, et l’absence du PM lors du planning meeting, le travail ayant été “mâché” par le PM et le Tech Lead. Le but semble être de gagner en efficacité et d’éviter de faire perdre du temps à l’équipe ! Mais on perd sur l’aspect participatif et l’implication de l’équipe…
  • Le cycle de release : s’il est plutôt court, on reste en deça des pratiques devops ! Je me serais attedu sà ce que devops fasse partie de l’ADN de Google !

Google a adopté un processus ad hoc, pragmatique. Il est agile de mon point de vue, car focalisé sur l’efficacité, la mis en ligne fréquente et aussi rapide que possible des fonctionnalités développées. Il est très “lean” par nature, avec un focus particulier sur le flux et l’élimination du gâchis (tout ce qui ne participe pas à la création de valeur).

Scrum Day 2012 : appel à orateur

Le par addinquydans ArticlesLaisser un commentaire

Le Scrum Day 2012 Arrive, ce sera le 27 mars à l’espace CAP 15 !

http://www.frenchsug.org/display/FRSUG/Scrum%2BDay%2C%2B27%2Bmars%2B2012

Vous pouvez dès à présent soumettre vos propositions de présentations via le formulaire en ligne prévu à cet effet :

https://docs.google.com/a/frenchsug.org/spreadsheet/viewform?hl=en_US&formkey=dG43VHNhLUNkcmVUWFp6N1EySTdqRmc6MQ#gid=0

Vous avez jusqu’au 22 février pour soumettre vos propositions, la sélection finale des sujets retenus s’opèrera fin février, les orateurs seront notifiés à ce moment là et le programme du Scrum Day mis à jour au même moment sur le site.

Les inscriptions à la conférence elle-même seront ouvertes très bientôt, vous en serez prévenus par les canaux habituels.

Si vous avez des questions concernant la soumission de sujets, merci de de les envoyer à orateur@frenchsug.org