Google et le French Scrum User Group nous ont accueilli mardi 17 Avril matin dans les locaux de Google Paris pour une matinée consacrée à l’Agilité, incluant une présentation de la mise en pratique de l’Agilité chez Google par Petra Cross. L’événement a fait salle plus que comble, et a été l’occasion de présentations faites par des intervenants de Google :
- “Human Ressource Management Handbook for Software Development Team”, par Martin Görner,
- “Behind the Scenes of Day-To-Day Software Development at Google”, par Petra Cross.
La suite du billet est le résultat de ma prise de note, et où j’ai essayé de retranscrire au mieux l’ensemble des éléments présentés à cette occasion.
- - - - - -
“Human Ressource Management Handbook for Software Development Team”, par Martin Görner
Martin a présenté une typologie des membres d’une équipe de développement basée sur un rapprochement avec les personnae classiques de l’heroic fantasy (libellés librement traduits de l’anglais). Or tous les archétypes n’ont pas leur place dans une équipe qui se veut efficace !
- le Barbare : le développeur / expert technique, doté de compétences de haut niveau
- le Clerc : le détenteur de la la connaissance, ayant comme mission d’en assurer la diffusion au sein de l’équipe
- le Mage : le solutionneur de problème, détenteur de techniques très puissantes mais secrètes. Or c’est justement cet aspect “secret” qui est gênant au niveau d’une équipe, a fortiori d’une équipe de développement. Au final la présence d’un Mage n’est pas si souhaitable que cela, surtout si vous pouvez recruter à la place …
- le Maître : l’équivalent du Mage, mais ayant en plus un vrai talent pour le partage de connaissances, ayant à coeur de faire évoluer les autres aventuriers du groupe
- l’Amazone : l’incontournable élément féminin d’une équipe performante, dotée de réelles aptitudes faisant d’elle l’égal des autres aventuriers. Martin a insisté sur l’importance d’une certaine mixité dans les équipes de développement, ce qui d’après son expérience en augmente l’efficacité.
- la Bête issue de la 27ème dimension : le membre de l’équipe adepte (fanatique ?) des dernières nouveautés, qui vous proposera / imposera une solution technique combinant tout ce qui se fait / s’est fait / se fera “de mieux”, en gros un empilement de technologies et langages disparates. Au final votre aventure risque bien de se transformer en combat sans fin contre un monstre tentaculaire suite aux agissements de ce compagnon. Autant éviter de partir à l’aventure avec lui, cela risque fort de mal se terminer.
- l’Eclaireur : celui qui apporte l’espoir au reste de l’équipe, le vrai “team player”
- le Chevaucheur de Dragon / Chevalier Dragon (“Dragon Rider”) : le seul membre de l’équipe apte à dompter le dragon, la personne disposant des compétences métiers nécessaires à un projet portant sur un contexte métier très spécifique (par exemple : projet fortement lié à l’industrie nucléaire).
- - - - - -
“Behind the Scenes of Day-To-Day Software Development at Google”, par Petra Cross
Après une rapide présentation de son parcours et de ses centres d’intérêts, Petra a introduit sa conférence en présentant / rappelant la devise de Google, par rapport à laquelle tout est évalué :
“Google’s mission is to organize the world’s information and make it universally accessible and useful.”
Petra a ensuite fait un point sur les gaspillages monumentaux commis par l’industrie informatique aux Etats-Unis, illustrés par des chiffres qui mettent en avant l’ampleur des dégâts : 70 milliards de dollars “investis” chaque année sur des projets qui seront abandonnés en cours de route, chiffre ne tenant pas compte des projets qui une fois mis en production se révéleront être des échecs. Les causes en sont multiples et sont globalement liés à un problème général de gestion des projets : vision déconnectée des besoins des utilisateurs, cycle projet très / trop long, etc.
Equipes et rôles
La taille et l’organisation de Google sont des paramètres à prendre en compte impérativement pour comprendre les contraintes et enjeux :
- plus de 10 000 développeurs répartis sur plus de 40 pays
- 50% du code existant change tous les mois
- plus de 20 modifications sont décomptées par minute
Petra a présenté rapidement les rôles identifiés dans les équipes Google :
- Engineering Director : en charge de la traduction des besoins business en exigences techniques
- Product Manager : détenteur de la vision produit et en charge de la définition des exigences produit
- Engineering Manager / Project Manager : responsable du projet, alloue les ressources et élimine les points de blocage non techniques
- Software Engineer / Tech Leader : responsable de la partie technique du projet, priorise les fonctionnalités en accord avec le “product manager” et élimine les points de blocage techniques
- Software Developper : développe les produits, crée et gère les tests unitaires
- Software Engineer in test : définit les stratégies de test
- Software Tester : crée et gère les tests
Equipes :
- hiérarchie plate, typiquement 2 ou 3 niveaux maximum
- taille réduite, de 3 à 5 personnes (“size of a family”), incluant des personnes jouant des rôles différents
- espace de travail ouvert, du type “open space” finalement assez classique en France (par opposition aux traditionnels cubicles et autres bureaux fermés), permettant à toute personne de l’équipe de voir les autres membres.
Processus général de développement
Les fonctionnalités sont gérées via une file d’attente :
Petra a très rapidement présenté les différentes étapes, en indiquant notamment que :
- chaque développeur est responsable de la bonne exécution des tests sur le code produit. Cette responsabilité est aussi bien morale (cela fait partie des bonnes pratiques et du cadre méthodologique que tout développeur s’est engagé à respecter) que technique (le code doit être revu par deux autres personnes avant de pouvoir être versé dans le référentiel de livraison).
- les livraisons sont gérées par une équipe dédiée de “release engineers”, qui sélectionnent les changements à livrer, génèrent une version “snapshot” et la livrent en mode “beta live / canary” auprès d’une petite partie des utilisateurs (environ 2% de la population totale)
Le but des équipes Google est triple :
- développer rapidement
- développer uniquement ce qui est nécessaire
- réduire voire éliminer les gaspillages
Petra présente ensuite rapidement les différentes familles de méthodologies projet :
- Cycle en V / “waterfall” (que l’on ne présente plus),
- le modèle en spirale, caractérisé par des itérations longues (plus de 6 mois), basées sur le prototypage et qui conduisent donc à la production de multiples prototypes,
- l’approche Agile, et plus particulièrement Lean. Au quotidien les équipes Google utilisent une combinaison de pratiques issues de XP, Scrum et Kanban et appliquent au maximum les principes exposés via la liste “Ten things we know to be true“.
Les tâches de développement doivent impérativement inclure la description des tests d’acceptation correspondant. Une tâche est réputée terminée à partir du moment où les tests d’acceptation passent avec succès. Le but étant de fournir le minimum d’effort pour être conforme aux critères d’acceptation, les Product Managers apprennent rapidement à être très précis dans la formulation de leurs demandes.
Les fonctionnalités et tâches sont réparties en 4 sous groupes, qui correspondent globalement aux principaux états de traitement :
- “icebox” : nouvelles idées et demandes d’évolution non qualifiées, en attente de prise en charge. Toutes ne seront pas forcément traitées, c’est une sorte de “boîte à idées”.
- “backlog” : la seule liste utilisée par les équipes pour alimenter le flux de travaux, contenant environ 2 semaines de travail pour les équipes
- “current / working on” : tâches en cours
- “done and verified” : tâches terminées, fonctionnalités prêtes à être livrées.
Le backlog est généralement géré via fichier de type tableur (Google spreadsheet) comportant 2 onglets :
- un onglet listant les user stories : géré uniquement par les Product Managers
- un onglet listant les tâches : sous la responsabilité de l’équipe de développement
Les tâches en cours sont gérées plus finement via un tableau comportant plusieurs couloirs (“swimlanes”), par exemple :
- tâches prévues (“scheduled”)
- tâches en développement (“working on”)
- tâches en revue (“in review”)
- etc.
Le tableau utilisé n’est donc pas un tableau Scrum, et comporte autant de couloirs que nécessaires pour donner un maximum de visibilité sur les travaux en cours sur l’itération. Les personnes en charge des tâches sont identifiés par des stickers portant leur photo, collés sur les post-it du tableau.
Exemple de planning hebdomadaire :
- Lundi : stand up meeting
- Mardi : stand up meeting
- Mercredi : démo + rétrospective + planning
- Jeudi : stand up meeting
- Vendredi : stand up meeting
La rétrospective est courte : de 15 mn environ pour une rétro hebdo à 1h pour une rétro mensuelle.
La rétrospective et la réunion de planification se déroulent sans participation du Product Manager : la rétrospective est centrée sur le fonctionnement de l’équipe, et la réunion de planification se fait sur la base du découpage des fonctionnalités en tâches réalisé en amont par le Tech Lead et le Product Manager.
Dans certaines équipes le stand up meeting a été supprimé car jugé inutile / inefficace : toutes les informations nécessaires sont affichées à la vue de tous sur les tableaux de suivi des projets et les gens sont plus qu’encouragés à discuter en face à face pour tout complément d’information.
La réunion d’estimation est conduite selon les principes suivants :
- Les estimations doivent représenter la taille des tâches, et surtout pas le temps de travail correspondant.
- le facilitateur traite les items du backlog selon leur priorité
- il en lit la description à l’équipe
- il fait un décompte et au signal les membres de l’équipe montrent à tous la carte représentant leur estimation (principe du planning poker)
- si la majorité n’est pas atteinte le facilitateur demande aux personnes ayant fournis les estimations inférieure et supérieur d’expliquer leur choix en indiquant précisément les travaux à réaliser pour traiter la tâche en question. Afin d’être efficaces ces échanges ne doivent comporter ni discussion multi-directionnelle ni émotion. Une fois les arguments exposés le facilitateur organise une nouvelle estimation et recommence tant que la majorité n’est pas atteinte.
- les membres de l’équipe ne doivent jamais utiliser des phrases du type “c’est facile” : ils doivent impérativement expliquer leur évaluation en utilisant une phrase du type “pour faire X il faut faire a, b, c …”
- si la description d’une tâche n’est pas suffisamment claire, il faut la réécrire afin qu’il ne subsiste aucune ambiguïté, tant au niveau de la tâche que des exigences associées.
Une réunion d’estimation efficace n’a pas forcément besoin d’être faite avec tous les membres de l’équipe : une réunion de 4 personnes est en général suffisamment satisfaisante.
Concernant le découpage des tâches fait en amont, il n’est pas toujours fait par le Tech Lead : il peut aussi être pris en charge par un des développeurs, avec rotation au sein de l’équipe.
Les développeurs prennent les tâches en charge selon leur ordre de priorité. Quand un développeur est bloqué, il sélectionne la tâche à traiter ayant la priorité la plus élevée dans la backlog. Le but est d’éviter la spécialisation : une tâche est prise par un développeur même s’il ne sait pas exactement comment la traiter. Dans ce cas là il trouvera les informations nécessaires en discutant avec les autres membres de l’équipe.
Il n’y a pas d’équipe dédiée de type QA : les tests et les revues sont placés sous la responsabilité des développeurs, à charge pour eux d’intégrer ces travaux dans le flux de traitement des tâches. Petra cite par exemple le cas de tâches restées bloquées en attente de revue lors d’une itération. Lors de la revue suivante l’équipe a acté que la revue des développement devait avoir la priorité absolue et qu’elle devait être traitée dès que possible (par ex au retour de la pause déjeuner dans le cas d’une tâche passant au statut “en attente de revue” au cours de la matinée). Une revue est donc prioritaire par rapport au fait de terminer un développement en cours et un développeur bloqué ne doit pas hésiter à relancer les personnes en charge de la revue, quitte à ce que la revue soit réaffectée à une personne disponible si besoin.
“Unblocking your peers is the best thing you can do for your team”
Une itération a généralement une durée de 2 semaines, et est alimentée par une backlog comportant environ 3 semaines de travaux afin de toujours avoir une liste de tâches à traiter, même en cas d’évaluations trop pessimistes.
Le Product Manager ne participe pas aux standup meetings ni à la réunion de planification, mais reste disponible au quotidien pour échanger avec les équipes, que ce soit pour des demandes de précisions ou pour évaluer les propositions faites spontanément par les développeurs.
Comme indiqué précédemment, la rétrospective est courte et centrée sur l’équipe. En ce qui concerne son déroulement, les éléments présentés par Petra sont classiques. Elle a par exemple mentionné le fait de noter sur 3 post it différents les éléments à partager avec le reste de l’équipe (“mad/sad/glad”).
L’absence du Product Manager a par contre soulevé un certain nombre de questions dans l’assistance, notamment en ce qui concerne le feedback utilisateurs. Petra a indiqué que les échanges avec les utilisateurs sont gérés par une équipe spécialisée (“Consumer Operations”) et que ces informations sont remontées aux équipes par d’autres canaux.
Ce que j’ai retenu de cette présentation
- L’approche Google est plus centrée sur Lean que sur Scrum, mais reste très pragmatique : les équipes ont toute latitude pour piocher dans la boite à outils agile afin de trouver le mode de fonctionnement le plus efficace possible
- Les réunions sont identifiées comme ayant un fort potentiel de gaspillage : elles sont donc réduites au minimum
- La présence de l’équipe complète n’est pas nécessaire pour la phase d’estimation : 4 personnes suffisent
- Une équipe ne traite pas l’ensemble d’un projet mais juste une macro-fonctionnalité (par exemple la gestion des dossiers sous GMail). Elles sont donc loin d’être stables dans le temps.
- Le pair programming n’est globalement pas mis en place car cette pratique est généralement mal perçue par les équipes. Google favorise à la place la revue par les pairs, ce qui fonctionne a priori bien grâce au niveau technique élevé des développeurs.
- Les fameux 20% de temps alloué aux employés Google pour travailler sur tout sujet de leur choix (un minimum lié à l’entreprise) ne sont pas une légende urbaine : Petra a justement présenté cette session dans ce cadre.
Ce que j’aurais aimé savoir à l’issu de cette présentation
- comment est-ce que le Product Manager communique la vision du produit à l’équipe ?
- jusqu’à quel niveau l’équipe s’engage t’elle ? A priori il n’y a pas d’engagement de réalisation sur l’itération …
- comment est-ce que le retour des utilisateurs est communiqué / exploité par les équipes ?
- comment est-ce que la “ice box” est gérée ? Est-ce que les éléments très anciens sont purgés ? Comment se passe la sélection et le transfert des éléments de la “ice box” vers la backlog ?
- - - - - -
Malheureusement les supports de ces présentations ne sont pas disponibles en ligne et je n’ai pas réussi à prendre de photo correcte. Cependant Pierre Merlin a filmé la session et devrait bientôt publier la video correspondante. La présentation de Petra sera de plus a priori filmée dans le cadre de Devoxx puis diffusée ultérieurement. Une vidéo d’une précédente version de cette présentation, faite en 2011 en Tchécoslovaquie est disponible en ligne. Quelques photos prises pendant la présentation ont été publiées sur le site MeetUp du SUG.
