Atlassian, Gitlab, Unity ont déployé le Quality Engineering.
Ces organisations sont capables de croître et de fournir en permanence de la valeur dans un environnement en évolution. Alors que les meilleures entreprises technologiques ont des produits différents, elles déploient généralement les éléments de Quality Engineering.
Nous avons couvert dans les articles précédents comment Atlassian, Manomano et OpenClassrooms font du Quality Engineering. Cet article partage le framework de Quality Engineering contenant les meilleures pratiques de ces entreprises technologiques.
Dans cette page, chaque pratique a un pointeur principal sans backlinks ni publicités. Vous pouvez compléter la pratique en consultant des contenus librement accessibles. L’objectif est de les compléter par la suite.
Méthodologie
Ce guide est un chantier à adapter en fonction des retours d’expérience et susceptible d’évoluer au sein du framework de Quality Engineering, MAMOS : Methods, Architecture, Management, Organization, Skills.
Chaque pratique a été classée parmi la qualité, la rapidité et la complexité par un score maximum représentant la priorité de mise en œuvre. Cet article n’est qu’un extrait, vous pouvez accéder à la hiérarchisation complète de ces pratiques disponible ici.
Suivez la QE Unit pour plus de Quality Engineering.
Les méthodes des organisations de Quality Engineering
Le Quality Engineering se matérialise par une somme de petits changements qui modifient au fil du temps la façon dont le logiciel est construit et exploité. L’écosystème organisationnel, ses acteurs et sa culture ont besoin de temps pour changer leurs habitudes pour devenir visibles. Changer les processus est le moyen le plus efficace pour conduire la transition vers une organisation de Quality Engineering en modifiant les activités quotidiennes des acteurs.
Les méthodes d’Quality Engineering doivent permettre le changement, diffuser la qualité et s’améliorer continuellement. Par conséquent, les méthodologies de gestion du changement sont essentielles pour initier, conduire et maintenir le changement.
La diffusion de la qualité se fait par la mise en place de processus spécifiques de Quality Engineering dans les équipes. Un modèle est fourni où l’adaptation et la simplification continues permettent de continuer à augmenter le niveau de qualité.
Enfin, la mesure continue des extrants avec les résultats garantit que les activités créent effectivement de la valeur. Ces méthodologies sont réalisées en collaboration pour maintenir l’engagement des acteurs.
Methods Framework
Voici la courbe de mise en œuvre du Quality Engineering recommandée par impact pour le domaine des méthodes..
Pratiques
Gestion du changement
1. Analyse des parties prenantes
La gestion des parties prenantes est un vaste thème en soi. Pour le Quality Engineering, l’analyse des parties prenantes est la technique la plus importante pour interagir avec les influenceurs à plus forte valeur ajoutée. En identifiant, en cartographiant et en hiérarchisant les parties prenantes, le leader permet à la coalition directrice de tirer parti du pouvoir dans les organisations pour initier et maintenir les changements au sein des équipes.
2. Sentiment d’urgence
Tous les systèmes changent plus rapidement sous pression. Prenons l’exemple du COVID et de l’évolution de la digitalisation et du travail à distance. Un sentiment d’urgence est indispensable pour initier le changement vers le Quality Engineering. Il peut être construit à partir des pratiques « Warning signs, benchmark » du domaine du Management. La guiding coalition doit être ambassadrice du sentiment d’urgence et remporter des victoires rapides.
3. Vision, mission, valeurs
Le Quality Engineering nécessite de définir une nouvelle étoile à atteindre pour l’organisation. La vision et la mission permettent un objectif commun de qualité au-delà des frontières organisationnelles. Les valeurs permettent de fixer les règles du jeu et les principes selon lesquels les activités doivent être réalisées. Voir les « Shared mission » et « Quality Principles » du domaine Management pour plus de détails.
4. Plan de communication
Les bonnes idées non développées restent seulement des idées. Un leader de Quality Engineering doit construire et exécuter un plan de communication adapté à chaque transition. Divers modèles doivent être utilisés comme des communications globales, des ateliers et des interactions en 1to1. Différents contenus tels qu’un portail public, des vidéos et des articles peuvent être mis à disposition dans une variété de médias. L’important est que la communication soit continue, impactante et disponible pour les acteurs.
5. Point de bascule
La guiding coalition doit diffuser le modèle de Quality Engineering jusqu’à 15-25% de l’organisation pour bénéficier de l’effet du point de bascule ou Tipping Point. À partir de ce point, le reste de l’organisation adoptera les pratiques avec beaucoup moins d’efforts et de coordination. Il faut donc se concentrer dans la première transition et des premières victoires pour ensuite déployer les méthodologies sur les équipes ayant le plus de potentiel d’adoption et de création de valeur.
6. Gestion de transition
Il n’y a pas de changement du jour au lendemain ni de changement radical dans le Quality Engineering. Les responsables du Quality Engineering doivent être capables de conduire des transitions incrémentales pour atteindre des jalons visibles et à valeur ajoutée. Sans cette approche, le risque est grand de rester dans l’existant avec un effet tunnel semant le doute, le manque de confiance et la démotivation dans l’organisation.
7. Culture Organisationnelle
Le Quality Engineering nécessite de faire évoluer la culture d’entreprise vers la Qualité. Cela nécessite d’agir sur les codes, croyances et valeurs partagés par les différents acteurs. L’analyse des parties prenantes peut être utilisée pour tirer parti des influenceurs de l’organisation pour partager les messages clés du changement et les intégrer progressivement dans l’organisation. Le plus percutant est le partage d’exemples concrets sur une base continue. Par exemple, en ayant des interactions régulières sur la qualité, des discussions menées par les équipes interfonctionnelles ou des événements informels.
8. Matrice de compétences
Les compétences de qualité doivent être affectées à des personnes différentes que celles historiques de la “QA”. Elles évoluent en continu avec l’apprentissage, la formation et le recrutement de profils. Une matrice est indispensable pour cartographier les différentes compétences, identifier et combler les lacunes par priorité. Cette tâche doit être coordonnée entre les différents managers opérationnels appuyés par les partenaires RH.
9. Rétrospective
Les équipes doivent continuellement améliorer la qualité dans leur contexte respectif. Les rétrospectives sont un mécanisme efficace pour les apprentissages des équipes et l’amélioration de leurs défis. Ils doivent être mis en œuvre dans le cadre d’une pratique systématique des rituels de l’équipe. Il est préférable d’organiser des rétrospectives précieuses lorsque vous disposez des ingrédients restants des compétences de Quality Engineering. Les rétrospectives font également partie de la catégorie des mesures ci-après décrites.
Quality Engineering
(*) Les processus à plus forte valeur ajoutée sont marqués de ce symbole astérisque. Ils sont généralement conservés même avec un haut niveau de maturité de Quality Engineering.
10. QA Kick-off
L’objectif est de réunir les membres de l’équipe pour réfléchir aux attributs des risques et aux exigences de test associées. Cette activité est en préparation des « Test Notes ». Cette méthodologie est issue de la démarche qualité d’Atlassian. Comme le peer-review est généralement fait par des QA advisors, il s’agit d’une méthodologie de transition qui devient optionnelle avec plus de maturité pour éviter tout goulot d’étranglement.
11. Test Notes*
Les Test Notes couvrent les risques qui doivent être testés. Ils ne sont pas une explication de la façon de tester. Cette méthode permet de hiérarchiser efficacement les tests dans le modèle de Quality Engineering : les tests sont l’acte minimal de vérification qui devrait idéalement ne pas exister et ne rien trouver. Cette approche allégée concentre l’équipe sur la valeur et l’optimisation de leurs efforts de test.
12. Peer review*
Cette méthodologie peut être appliquée à n’importe quel processus et doit être priorisée dans votre contexte. L’examen par les pairs est le moyen le plus efficace d’augmenter la qualité dans des boucles de rétroaction courtes et de manière évolutive. Les pairs impliqués sont capables d’interagir de manière asynchrone, d’apprendre et d’adapter rapidement leurs livrables.
13. Développer in test
Ce processus affecte un ingénieur logiciel différent de celui de la mise en œuvre des tests. C’est un bon moyen d’augmenter la sensibilité aux tests et de sécuriser la mise en œuvre des notes de tests. Cependant, il n’est pas recommandé de conserver cette pratique dans le temps, car l’ingénieur logiciel doit mettre en œuvre les tests correctement en premier lieu.
14. QA Demo*
Le paradigme agile pousse pour un produit fonctionnel plutôt que de la documentation. La logique d’une QA demo est la même en Quality Engineering : les attributs qualité et le produit sont systématiquement partagés au sein de l’équipe pour aligner les exigences. Cette pratique aide également l’équipe à atteindre des résultats viables en supprimant les activités non nécessaires.
15. Blitz Test
Tester avec le produit dans une session timebox pour trouver des bogues est un Blitz Test. Cette pratique vient aussi d’Atlassian. Elle est effectuée après la QA Demo et avant la sortie anticipée du produit. Il s’agit d’une protection supplémentaire pour trouver des bogues qu’un processus précédent aurait manqué. Il est également utile comme exercice de consolidation d’équipe pour l’équipe interfonctionnelle. Cette méthodologie devrait devenir optionnelle avec une maturité qualitative croissante.
16. Dogfooding
Découpler la construction, le déploiement et l’action est l’une des douze meilleures pratiques en matière d’applications dites 12-factor. Le Dogfooding consiste en un déploiement graduel en interne pour les employés. Il permet aux utilisateurs internes de tester le produit avant de le distribuer aux clients finaux et de détecter tout problème plus difficile à détecter dans le processus et les infrastructures standard. Avec plus de maturité en termes de tests, d’infrastructure, les équipes peuvent limiter l’utilisation de cette méthodologie. Les tests exploratoires et de crowdtesting peuvent être un bon complément dans certains cas.
17. Communauté de pratique (CoP)
Les équipes doivent continuellement améliorer leur niveau de qualité et leur contribution dans leur contexte. Les communautés de pratiques constituent un moyen efficace de diffuser les connaissances pratiques au sein de l’organisation. En ayant des interactions transversales régulières, les individus sont capables d’apprendre de leurs pairs en dehors des frontières. Il prend en charge la diffusion rapide des connaissances et des meilleures pratiques dans une organisation ainsi que la création d’interactions entre des pairs qui, autrement, n’interagissent pas beaucoup.
18. Quality Culture Guide
Ce guide disponible en version préliminaire a été rédigé par Alan Page et Brent Jensen, le fondateur des principes de test modernes. Il contient une référence à diverses pratiques qu’une équipe peut exploiter pour augmenter son niveau de qualité en fonction des stades de maturité.
Lier les outputs aux outcomes
19. Quality Engineering NPS
Le Net Promoter Score est l’une des mesures de satisfaction client les plus utilisées. Il consiste à calculer un score basé sur le ratio de promoteurs, neutres et détracteurs de l’entreprise. Chaque catégorie dépend de l’option choisie pour recommander l’expérience de service sur une échelle de 0 à 10. Elle est utilisée par les principaux acteurs spécifiquement sur la « probabilité de recommander l’équipe de Quality Engineering à un ami ou à un pair ». La méthode permet d’être en contact avec la réalité de la perception de l’équipe, d’augmenter l’engagement et de résoudre les problèmes les plus importants.
20. Quality Engineering Monitoring
Une mesure systématique et collaborative est mise en place par des équipes performantes. En étant régulier, il oblige à évaluer les performances de manière factuelle et à garder l’équipe consciente de l’écart à combler, favorisant l’amélioration continue. L’aspect collaboratif permet de renforcer les interactions avec les acteurs et d’augmenter l’engagement en laissant les acteurs s’approprier leur qualité.
Ce monitoring provient d’Atlassian dans le cadre de leurs pratiques Qualité. C’est un moyen efficace de mettre en œuvre la surveillance d’un ensemble de pratiques de qualité définies.
21. Business metrics
Les métriques suivantes permettent à l’équipe de se concentrer sur les interactions des utilisateurs et les performances de l’entreprise. Alors que des actions isolées peuvent difficilement être corrélées à un indicateur, les actions de l’équipe doivent améliorer ces indicateurs au fil du temps. Ils peuvent être identifiés grâce à un exercice de Objective Key Results (OKR). Voici un échantillon des possibilités.
- Recrutement utilisateurs
- Valeur moyen de commande (AOV)
- Taux de transformation
- Engagement journalier
- Referrals
22. Accelerate
L’étude Accelerate a démontré le lien entre capacité de livraison logicielle et performance des entreprises. Quatre indicateurs marqués ci-dessous font partie de l’étude.
- Deployment frequency
- Lead-time for changes
- Mean-time to restore
- Change failure rate
23. Developer Experience
Le flux de travail quotidien des ingénieurs logiciels a un impact direct sur les performances et le bien-être des équipes. La mesure de l’expérience du développeur (DevEx) nous permet de rester en contact avec la réalité de la création et de livraison logicielle dans l’organisation. De plus, l’adoption de la plateforme est un élément clé à suivre pour atteindre le Quality at Speed. Les métriques suivantes peuvent être utilisées.
- DevEx NPS : l’organisation peut avoir un retour direct sur l’expérience de l’équipe d’ingénierie en appliquant le modèle d’enquête NPS. Il est utile lorsqu’il est appliqué régulièrement et pour favoriser l’amélioration continue.
- Cycle-time : mesure le temps écoulé entre le début d’un travail sur un élément (histoire, tâche, bug, etc.) jusqu’à ce qu’il soit prêt à être livré. Le cycle-time indique combien de temps (en temps calendaire) il faut pour terminer une tâche et aide à rationaliser la livraison du logiciel en éliminant le gaspillage et les temps d’attente.
- Adoption : la plate-forme de l’entreprise prend en charge un processus de livraison de logiciels réplicable et rationalisé, y compris les exigences non fonctionnelles de manière standard. L’adoption peut être mesurée à travers des ratios d’adoption sur les projets, l’activité quotidienne, les projets non conformes.
24. Value Stream
Un flux de valeur est l’ensemble des actions qui ont lieu pour ajouter de la valeur aux clients depuis la demande initiale jusqu’à la réalisation de la valeur par les clients. Il permet de cartographier les processus clés en se concentrant sur la valeur pour ensuite conduire à une amélioration continue pour accélérer et augmenter la valeur délivrée.
Framework
Ces pratiques vous prépareront à un parcours de transformation vers une organisation de Quality Engineering. Les pratiques vous aideront à maintenir une amélioration et une adaptation continues avec des capacités, des processus systématiques et un apprentissage organisationnel.
Ce contenu était limité au pilier des méthodes, laissant les pratiques restantes d’architecture, de gestion, d’organisation et de compétences dans un document séparé. L’objectif est de l’enrichir au sein de la communauté et d’améliorer son contenu.
Vous pouvez accéder au framework complet de Quality Engineering contenant le classement des pratiques en termes de qualité, de vitesse et d’effort. Il contient également une option pour personnaliser la priorité de certaines pratiques et vous laisse déjà avec un plan d’action.
Suivez la QE Unit pour plus de Quality Engineering.
The Quality Engineering Definition, Manifesto and Framework are available through a Creative Common Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0).