GitLab s’organise pour le Quality at Speed continu.
C’est aujourd’hui l’un des produits de références permettant aux entreprises d’accélérer leur livraison logicielle. GitLab est également connu pour son modèle organisationnel en remote-first et la transparence de ses mécanismes internes.
L’organisation a su grandir depuis 2011 au travers des différentes levées de fonds pour fournir une véritable expérience de développement. Cette amélioration continue de sa proposition de valeur est soutenue par des pratiques de Quality Engineering.
Cet article se focalise sur les éléments à plus forte valeur ajoutée et différenciants de son organisation de Quality Engineering sous le prisme du framework MAMOS: Methods, Architecture, Management, Organization & Skills.
Suivez la QE Unit pour plus de contenu exclusif de Quality Engineering.
La Qualité fait partie intégrante de l’entreprise
GitLab doit pouvoir itérer sur sa proposition de valeur en y intégrant la qualité au plus tôt. Des modèles de collaboration étendus sont nécessaires pour soutenir la scalabilité de l’organisation et de ses pratiques. Le recours à des mécanismes de coordination d’acteurs à moindre effort est donc nécessaire.
La mission commune permet de fédérer les acteurs autour d’un objectif commun au-delà de leur appartenance locale. Les valeurs d’entreprises et les principes viennent clarifier les codes d’intéractions valorisés et reconnus par l’écosystème. Les objectifs et résultats attendus sont ensuite animés en continu au trimestre.
Vision, mission et valeurs d’entreprise #1
La mission commune de GitLab est de permettre à ses clients de se focaliser sur leur produit. La qualité est clairement définie comme étant une responsabilité individuelle pour chaque acteur de l’entreprise.
La contribution du département qualité est ensuite définie vis-à-vis des équipes produit. Les valeurs complémentent les comportements valorisés comme la collaboration transverse, incrémentale et transparente focalisée sur l’atteinte de résultats.
Les principes de Qualité #2
Les principes fixent un cadre d’exécution. GitLab clarifie les attentes des différentes équipes pour contribuer à la qualité par la définition de principes de qualité. Chaque principe est illustré par les comportements supportant l’atteinte des objectifs définis.
Le département Qualité de GitLab possède quatre grands piliers déclinant les comportements permettant de les développer. Deux axes principaux se dégagent : supporter les équipes produit et améliorer les indicateurs de qualité.
Objective Key Results (OKR) #3
GitLab explicite ses objectifs au trimestre et rend public leur progression via des Objectives Key Results (OKR). Une attention constante existe pour garantir que les activités contribuent à la création de valeur au global. Cet exercice permet un meilleur alignement des initiatives d’entreprises entre les différentes équipes.
L’alignement des priorités des différentes équipes est supporté par des objectifs et résultats associés à atteindre. Leur mesure est régulièrement mise à jour sur une mesure factuelle. Chaque ligne possède une personne responsable pour son animation dans le trimestre.
Une structure organisationnelle intégrant et supportant la qualité
Les choix d’organisation impactent directement la capacité de performance. Un réel investissement en architecture organisationnelle est nécessaire pour aligner les objectifs, périmètres et moyens associés aux différentes équipes.
GitLab a structuré des équipes focalisées sur différents objectifs du produit. Ces mêmes équipes sont supportées par des fonctions accélératrices en transverse, comme la qualité. Les contributions respectives sont explicitées pour clarifier les intéractions attendues afin de limiter les ambiguïtés.
Un département Qualité #4
Le département Qualité de GitLab possède 4 grandes structures d’équipes. Les équipes de Contributor Success, Engineering Productivity et Engineering Analytics doivent contribuer horizontalement dans l’organisation.
En complément, des équipes de Quality Engineering alloués à chaque équipe produit sous regroupées dans la notion de Sub-Department. Ces unités de Quality Engineering collaborent donc directement sur des domaines spécifiques du produit.
Des unités de Quality Engineering #5
L’alignement de périmètres avec les objectifs d’entreprise permet de composer des équipes au-delà de silos fonctionnels. Cette structuration se retrouve dans des modèles de type cross-fonctionnel ou de feature teams.
GitLab affecte ses unités de Quality Engineering sur les équipes produit comme de Dev, Ops, Security & Enablement ou Fulfillment & Growth. Elles contribuent à la qualité par des intéractions et livrables clairement définis.
Des modes intéractions #6
Le concept de whole team approach to quality est séduisant mais pose néanmoins la question de la responsabilisation. Si tout le monde est responsable, personne ne l’est véritablement. Les contributions à cet objectif commun doivent donc être définies.
GitLab explicite à plusieurs égards les comportements attendus des équipes pour contribuer directement à la qualité, ou au contraire, comment supporter d’autres unités à y arriver. Ce travail est réalisé pour les différents départements, de l’UX, Engineering aux Opérations.
L’organisation favorise des intéractions transverses
Les intéractions sont au cœur de la capacité de collaboration et d’apprentissage de l’entreprise. Ces échanges découlent de la structure organisationnelle et des partages informels prenant place entre les acteurs.
GitLab distingue deux modèles pour des équipes d’engineering: les “Cross-functional team” et les “Fullstack team”. Des modèles de collaboration en transverses viennent compléter ces structures.
Cross-functional team #7
Les “Cross-functional team” sont composées d’expertises verticalisées par rôle, par exemple entre Frontend et Backend. C’est le modèle le plus répandu dans l’engineering de GitLab pour une meilleure stabilité et capacité d’itération.
La cohérence fonctionnelle des rôles permet de plus facilement gérer la rotation des profils. Il faut à la fois balancer les capacités des profils disponibles à court-terme et la performance de l’équipe à moyen et long-terme.
Fullstack team #8
Les “Fullstack team”, moins répandues, possèdent des profils capables de combiner des expertises. C’est un modèle plutôt réalisé par opportunité et en fonction des profils disponibles.
L’avantage de ce modèle est de pouvoir itérer parfois plus rapidement sur des composants en ayant moins d’acteurs et une capacité de réalisation transverse. L’inconvénient est la stabilité et la scalabilité de ce modèle. Il est plus complexe de trouver des profils mixtes pour les remplacer ou en ajouter aux équipes.
Gouvernance transverse #9
La communication en transverse des silos organisationnels est essentielle à la performance. Les acteurs combinent des mécanismes formels et informels pour collaborer au mieux dans un système imparfait.
Les acteurs doivent s’aligner sur leurs priorités et les livrables respectifs sur des méthodologies formelles d’OKR et de Release Planning Day (RPD). Les échanges informels permettent de créer des relations transverses utiles au partage des bonnes pratiques, à l’amélioration continue.
Trois compétences clés pour le Quality Engineering
Les acteurs sont le cœur de l’organisation, donnant vie au produit par leur collaboration et contributions. Le Quality Engineering nécessite une composition de compétences pour devenir une réalité dans l’entreprise.
Gitlab distingue 3 principaux rôles dans son département Qualité : Software Engineering in Test, Engineering Productivity Manager & Quality Engineering Manager.
Software Engineer in Test #10
Les Software Engineers in Test sont les piliers du Quality Engineering chez GitLab. Leurs compétences et contributions vont bien plus loin que le test pour permettre aux équipes de réaliser des boucles d’itérations le plus rapidement possible.
Ces acteurs collaborent avec les équipes produit pour améliorer la testabilité, la vélocité et la maintenance des applications. Ils agissent pour cela proactivement en amont pour améliorer l’architecture, la testabilité ou le code. Ils contribuent également de manière continue notamment pour améliorer les tests, les environnements, les pipelines de déploiement. La plupart des profils sont Senior chez GitLab pour répondre à ces exigences.
Engineering Productivity #11
Une usine où chaque ligne de production est spécifique pour des besoins similaires souffre d’une performance dégradée. L’effort de coordination et les surcoûts limitent la capacité d’adaptation de l’entreprise. Une meilleure organisation est nécessaire.
L’Engineering Productivity vise à supporter une expérience de développement alliant efficacité et efficience. Les gains sont captés par des itérations plus rapides pour les développeurs qui peuvent se focaliser au maximum sur le produit. L’harmonisation et le support apportés apportent une capacité d’adaptation continue de l’organisation de sa chaîne de production logicielle.
Le département Qualité de GitLab possède une équipe dédiée d’Engineering Productivity. Des contributeurs à la fois individuels de Backend Engineer et de Backend Engineering Manager collaborent au service de la productivité de développement logiciel.
Quality Engineering Leaders #12
Une organisation performante a besoin de leaders. Leur défi est de développer un écosystème permettant la livraison de valeur continue. Ils doivent pour cela être inspirants, co-construire une vision et l’animer en transverse dans l’entreprise.
GitLab attend des leaders de Quality Engineering d’être des acteurs ambassadeurs de la Qualité. Ils doivent démontrer une passion et une énergie capable de déployer une réelle force de Quality Engineering au sein de l’organisation. Ils ont en responsabilité directe les compétences du département Qualité, même si leurs intéractions sont majoritairement transverses.
Ces rôles de leadership sont positionnés à trois niveaux : Quality Engineering Manager, Quality Engineering Director, VP of Quality.
L’organisation du Quality Engineering, fondamentale au Quality at Speed
L’écosystème organisationnel de Quality Engineering est structurant pour GitLab. Les investissements réalisés en engineering productivity et en senior testing sont de véritables avantages pour permettre aux équipes produit d’accélérer.
Le fait de responsabiliser chaque acteur de l’entreprise en explicitant leurs contributions à la qualité est essentielle à la clarté des rôles. Un Quality Engineering d’entreprise réussi nécessite bien un cadre clairement défini de collaboration.
Une organisation s’inspire de bonnes pratiques mais doit en priorité s’adapter au contexte et aux objectifs visés. La valeur d’un leader sera dans sa capacité d’effet levier sur les talents, propres à chaque entreprise.
Notre responsabilité en tant que leader de Quality Engineering est de structurer l’organisation pour permettre aux acteurs d’y performer. Leurs périmètres influent sur les ressources, le pouvoir, et in fine leur capacité de Quality at Speed.
Organisons donc le Quality Engineering dans nos entreprises.
Suivez la QE Unit pour plus de Quality Engineering.
Références
GitLab Story, https://about.gitlab.com/company/history
GitLab Quality Department, https://about.Gitlab.com/handbook/engineering/quality/
Quality Management Roles at GitLab, https://about.Gitlab.com/job-families/engineering/engineering-management-quality/
Quality Department Career Framework, https://about.Gitlab.com/handbook/engineering/career-development/matrix/engineering/quality/
GitLab Working Group on improving Ops Quality, https://about.Gitlab.com/handbook/engineering/development/ops/package/quality/