Accueil > Java EE, Méthodes Agiles, Mobile > Mix It, début d’après-midi

Mix It, début d’après-midi

Lightning Talks

Après un repas fourni par l’organisation (excellents sandwich / muffin soit dit en passant) et avoir papoté avec de vieilles connaissances et des collègues, je me suis décidé pour les Lightning Talks. J’étais intrigué par le format très court (5 min), et curieux de voir si on pouvait efficacement faire passer un message dans ce délai.

Pour les 5 min, elles ont été respectées quasiment à la seconde, les organisateurs veillaient au grain, chronomètre à la main. Certaines présentations étaient tout simplement excellentes, d’autres plus moyennes et certaines m’ont laissé assez perplexe. Mes coups de cœur ont été par ordre de passage “La voie du programmeur”, “Developper Experience” et “De l’organisation X vers l’organisation Y”, même si plusieurs autres valaient également le détour.

La voie du programmeur

Jean-Baptiste Dusseaut – @BodySplash

Un vibrant plaidoyer pour les développeurs : non, devenir chef de projet n’est pas l’alpha et l’oméga de tout programmeur! Comme disait Jean-Baptiste, “il existe une voie” pour faire carrière en tant que développeur. Gros succès pour ce petit talk très bien maitrisé.

Developper experience

Pamela Fox@pamelafox

On parle souvent “d’expérience utilisateur”, mais rarement “d’expérience développeur”. Pamela voulait nous montrer que pour qu’une librairie ou un framework soit utilisé et réellement approprié par une communauté de développeurs, il est important qu’un développeur puisse facilement l’intégrer dans un projet, ait accès à une documentation de qualité, puisse discuter avec la communauté des problèmes et améliorations potentielles…

De l’organisation X vers l’organisation Y

Alexis Monville – @alexismonville

Une organisation en X part du postulat que les gens ne veulent pas travailler, et l’organisation vise donc à les contraindre au travail. Au contraire, une organisation en Y part du postulat que travailler est naturel, et vise donc à leur faciliter le travail. L’organisation interne est donc complètement différente, et Alexis nous a montré comment l’organisation en Y était au final plus créatrice de valeur que celle en X.

Chapeau en tout cas pour ceux qui ont présenté un Talk : c’est sans doute moins de travail qu’une présentation d’1h, mais le format très court rend la réussite de l’exercice tout aussi difficile.

Development workflow at Google

Petra Cross@petracross
“ Focus on the user and the rest will follow ”

Comment est ce que Google s’organise en interne pour créer tous leurs produits, avec la réussite globale que l’on sait? C’est ce qui m’a motivé à assister à cette présentation. La speakeuse est Petra Cross, “Googleuse” ayant travaillé 5 ans sur le moteur de recherche et 4 ans sur GMail. Au passage, je vais donc pouvoir réviser mon anglais. Un coup de Youtube pour m’assurer que son accent ne pose pas problème, et mon choix était fait.

Alors, comment font-ils pour créer leurs produits et les faire évoluer?

Déjà, d’un point de vue hiérarchie, la structure est peu profonde pour une entreprise avec 10000 développeurs. Les équipes sont construites généralement autour de 4 personnes avec un tech leader pour les gérer, avec un périmètre précis pour l’application sur laquelle ils travaillent. Si on remonte vers le sommet, on trouve engineering manager, product manager et engineering director.

Pour l’organisation, on s’en doutait, il y a de notamment l’agilité là dessous… Petra nous cite quelques méthodes : Scrum, XTreme Programming et Kanban, pour dire immédiatement qu’ils n’appliquent aucune d’entre elles, tout en s’en inspirant.

Tout le monde peut proposer des idées : du product manager au simple ingénieur. Toutes les idées intéressantes sont placées dans une “Icebox” : ceci constitue le vivier de fonctionnalités potentielles. Certaines restent dans cet état quelques jours, d’autres plusieurs années.

Leurs itérations sont basées sur des cycles très courts, de 1 à 2 semaines. Le chef de projet sort un ensemble de features de l’icebox puis les priorise pour constituer la prochaine version.

Ces features sont découpées en tâches puis chiffrées (en complexité, pas en jours) par les ingénieurs grâce à un planning poker. Toute tâche trop importante est redécoupée pour avoir une complexité maximale de 5.

Ensuite, les tâches sont obligatoirement implémentées par priorité décroissante. Lorsqu’une personne a terminé une tâche, elle prend obligatoirement la plus prioritaire restante, indépendamment de son niveau de compétence sur telle ou telle partie.
Tout le monde est encouragé à poser des questions s’il a à réaliser une tâche sur une partie qu’il connait mal, mais le but est que personne ne soit un rouage essentiel dont le départ met le projet en péril. A noter également : toute tâche terminée passe par du code review, effectué par une autre personne.

Lorsque tout est terminé et validé par la QA, la nouvelle version passe au stade “canary” : la version est déployée pour un petit sous ensemble des personnes utilisant l’application (mettons 1%.)
Grâce aux métriques et compteurs implémentés, on peut vérifier que le but de la version est atteint avec les statistiques sur l’utilisation de l’application. Si cette étape est franchie avec succès, elle est déployée pour l’ensemble des utilisateurs.

Au final, la présentation a pour moi tenu ses promesses, expliquant assez bien l’organisation interne qu’a Google. Le talk était agréable à suivre malgré, encore une fois, pas mal de pub et de “Google c’est trop bien”. L’agilité à la sauce Google est plutôt sympa, j’aime bien notamment l’idée de l’Icebox ou du “canary”, et moins d’autres points comme l’interchangeabilité des personnes, même si j’en comprends le but.

  1. Pas encore de commentaire
  1. Pas encore de trackbacks