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:
- Idée
- Décliné en Feature
- Planifié
- En cours de travail
- En revue de code
- En test
- En beta test “Canary”
- 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).
