3.0 Introduction à la partie 3 : Expérience du développeur et le cadre SPACE

La partie 2 a mesuré la livraison de l’extérieur : à quelle vitesse et avec quelle sécurité le code se déplace à travers un pipeline. Cette partie mesure l’expérience des personnes produisant ce code, et elle existe parce qu’un ensemble de métriques de livraison seul peut avoir l’air excellent pendant que les humains derrière lui s’épuisent, se noient dans les interruptions, ou se désengagent tranquillement. Une organisation qui ne surveille que les métriques DORA peut les améliorer pendant un an ou deux en pressant une équipe plus fort, jusqu’à ce que l’attrition, l’effondrement de la qualité, ou l’épuisement professionnel efface le gain d’un coup. Cette partie est le contrepoids.

La pièce maîtresse est le cadre SPACE, développé par des chercheurs de Microsoft, GitHub et l’Université de Victoria spécifiquement comme un correctif à l’habitude de l’industrie de mesurer la productivité des développeurs à travers un seul représentant facilement manipulé comme les lignes de code ou le nombre de commits. SPACE couvre cinq dimensions : satisfaction et bien-être, performance, activité, communication et collaboration, et efficacité et flux. La discipline centrale du cadre, et la raison pour laquelle cette partie le traite avec la même rigueur que la partie 2 applique à ses propres métriques de flux, est qu’aucune dimension unique en elle-même n’est fiable ; la valeur vient spécifiquement de garder les cinq en vue ensemble, pour qu’une équipe ne puisse pas avoir l’air bien sur un axe en endommageant tranquillement un autre.

Pour les grandes équipes, les métriques d’expérience du développeur répondent à une question que DORA ne peut pas : cette performance de livraison est-elle durable, et l’organisation retient-elle les personnes qui la produisent. Les organisations d’entreprise qui ignorent cette partie tendent à découvrir le coût à travers les données d’attrition et les entretiens de départ, bien après que le dommage soit fait ; les organisations gouvernementales, opérant souvent sous des contraintes de rémunération du secteur public qui limitent leur capacité à concurrencer purement sur la compensation, ont des raisons particulièrement fortes de traiter l’expérience du développeur comme une préoccupation de premier ordre et activement gérée plutôt qu’une réflexion après coup.

Sujets de cette partie

3.1 Le cadre SPACE : Les cinq dimensions ensemble, pourquoi aucune n’est fiable seule, et comment construire un ensemble de métriques authentiquement équilibré à partir d’elles.
3.2 Métriques de satisfaction et de bien-être : Mesurer l’épanouissement, la frustration et le risque d’épuisement professionnel, la dimension qu’aucune télémétrie système ne peut observer directement.
3.3 Métriques de performance et représentants de résultat : La dimension la plus facilement confondue avec l’activité, et comment mesurer plutôt une véritable contribution au résultat.
3.4 Métriques d’activité et leurs limites : Comptes de commits, lignes de code, et pourquoi c’est la dimension la plus dangereuse à surpondérer.
3.5 Métriques de communication et de collaboration : Comment l’information circule réellement entre les personnes et les équipes, et à quoi ressemble un schéma sain.
3.6 Efficacité et flux : travail profond et interruptions : Protéger le temps ininterrompu que requiert le vrai travail d’ingénierie, et mesurer la friction qui l’érode.
3.7 Sondages d’expérience du développeur et métriques DevEx : Comment mener un sondage qui produit un signal fiable plutôt qu’un concours de popularité, et comment le combiner avec des données objectives.

Comment ces sujets s’articulent

Le sujet 3.1 introduit les cinq dimensions SPACE ensemble, et les sujets 3.2 à 3.6 prennent ensuite chaque dimension à tour de rôle en vraie profondeur, dans l’ordre où les chercheurs de SPACE les présentent. Le sujet 3.7 clôt la partie avec la mécanique pratique de la conception de sondages, puisque la satisfaction, la performance et la collaboration s’appuient toutes partiellement sur des données auto-déclarées (la distinction instrumentation-contre-auto-déclaration du sujet 1.5 est directement pertinente tout au long de cette partie) et un sondage mal conçu mine chacun des sujets précédents.

La discipline centrale de cette partie, l’équilibre entre dimensions plutôt que la force dans une seule, est l’exemple pratique le plus clair que ce livre ait du principe de résultats-plutôt-que-production du sujet 1.3 appliqué aux personnes plutôt qu’à un pipeline de livraison. L’activité (sujet 3.4) est la dimension SPACE la plus analogue à une pure métrique de production, et cette partie la traite en conséquence : utile comme une entrée parmi cinq, dangereuse comme signal autonome. Lue aux côtés de la partie 2, cette partie complète l’image que DORA seule ne peut pas fournir : non seulement si le logiciel est livré rapidement et sûrement, mais si les personnes qui le livrent peuvent soutenir ce rythme.