Il y a deux ans, j'ai étudié l'impact de l'épuisement professionnel des développeurs sur les ingénieurs logiciels, révélant que . Au cours des derniers mois, j'ai travaillé sur des recherches plus approfondies sur les perceptions du développement logiciel dans diverses organisations, notamment en révélant que 75 % des ingénieurs logiciels et que 89 % des chefs d'entreprise étaient . 83 % d'entre eux souffraient d'épuisement professionnel ont fait l'objet de représailles la dernière fois qu'ils ont signalé un acte répréhensible préoccupés par la situation. livraison à temps des logiciels L'équipe DORA de Google mène depuis plusieurs années son propre sondage auprès des ingénieurs logiciels et les auteurs originaux du cadre de mesure ont maintenant produit d'autres cadres, notamment SPACE et DevEx. Même si, au départ, j'avais confiance dans les recherches réalisées par ces équipes, au fur et à mesure que j'ai mené des recherches plus approfondies, les défauts sont devenus évidents. Pendant les vacances, j'ai lu le livre du Dr Andrew Jenkinson "Pourquoi nous mangeons (trop) : la nouvelle science de l'appétit", dans le livre où le Dr Jenkinson critique une étude connue sous le nom d'étude des sept pays du Dr Ancel Keys. Le Dr Jenkinson décrit ainsi le succès du Dr Key : « Il avait gagné la bataille contre son plus grand rival, le frappant avec des faits incontestables, révélant sa logique erronée. L'adulation de la foule l'a rempli de joie et d'extase. L’œuvre de sa vie avait porté ses fruits. Le financement de ses recherches arriverait, sa réputation de scientifique de premier plan dans son domaine serait assurée pendant des années. La renommée, c'était bien, mais il avait désormais obtenu les deux premiers véritables prix : le pouvoir et l'influence. Cependant, le Dr Jenkinson note : « Il n'avait pas été malhonnête dans ses recherches – cela aurait été contraire à l'éthique et l'aurait discrédité. Techniquement, ce qu'il avait présenté était la vérité. Mais il savait très bien que ce n’était pas toute la vérité. Au fur et à mesure que j'ai étudié les résultats de la recherche de DORA et les travaux ultérieurs plus en détail, les parallèles entre cette description et la rigueur de la recherche dans le rapport sur l'état du DevOps de DORA et le cadre SPACE et DevEx ultérieur sont devenus évidents. Où sont les données ? Premièrement, la recherche DORA est menée en échantillonnant plusieurs milliers de développeurs grâce à l'utilisation d'enquêtes subjectives. Cette recherche est menée en interne par l’équipe DORA. Habituellement, ceux qui mènent de telles recherches pour gagner leur vie ont rejoint des organisations telles que la Market Research Society (MRS) et le British Polling Council (BPC) pour garantir que le public puisse avoir confiance dans les recherches effectuées par les organisations qui en sont membres. Par exemple; Les règles du BPC imposent à leurs membres des règles de divulgation strictes exigeant qu'ils divulguent des tableaux de données complets avec les questions posées dans les 2 jours ouvrables suivant la publication de la recherche. Ici réside notre premier problème ; l'équipe DORA ne publie pas ses données brutes, publiant uniquement son rapport sur l'état du DevOps. Méthodologie défectueuse La recherche DORA de Google et les cadres SPACE et DevEx utilisés au sein des équipes utilisent des enquêtes subjectives pour créer des mesures. Lorsque vous utilisez des enquêtes subjectives, il est important de prendre des mesures pour garantir qu'aucun biais n'entre en jeu. Cependant, DORA utilise quatre indicateurs clés pour mesurer les résultats : le délai de modification, la fréquence de déploiement, le taux d'échec des modifications et le temps de récupération (anciennement délai moyen de récupération). Il s’agit essentiellement de mesures de la rapidité de déploiement des nouvelles fonctionnalités et de la rapidité de résolution des problèmes. Imaginez que vous demandiez à certaines personnes : « Vos collègues mangent-ils beaucoup de légumes verts ? » » et « Vos collègues s'entraînent-ils beaucoup ? Ceux qui se sentent mieux dans leur travail seraient probablement plus susceptibles de répondre « oui » aux deux questions. Cela ne signifie pas que manger plus de légumes verts entraînera toujours une plus grande fréquentation des salles de sport. Bien qu’il puisse y avoir une corrélation, nous n’avons pas créé de relation de cause à effet. Les recherches de DORA soutiennent que la vitesse et la fiabilité vont de pair, mais qu'elles le font sur la base de mesures de résultats entièrement basées sur la vitesse. De plus, le recours à des enquêtes subjectives peut inciter les bénéficiaires qui se sentent mieux dans leur travail à répondre « oui » aux deux questions. Et même si les entreprises les plus compétentes peuvent inévitablement l’être dans ces deux domaines, cela ne crée pas de relation causale. Par exemple; considérez à quel point la fiabilité des logiciels d’aviation est hautement appréciée, par rapport au déploiement peu fréquent de logiciels sur les avions. Ou considérez comment Toyota, le pionnier des méthodologies agiles, dans l'affaire de fiabilité logicielle « Bookout contre Toyota » sur un bug d'accélération involontaire qui a entraîné des décès, a concédé dans la communication interne que « En vérité, une technologie telle que la sécurité intégrée ne fait pas partie du système Toyota. L'ADN du pôle Ingénierie". Ou pensez à la façon dont, lors du scandale Horizon IT - imputé à de multiples suicides et à ce qui a été décrit comme « l'erreur judiciaire la plus répandue de l'histoire du Royaume-Uni », avec des personnes emprisonnées à tort, dont une femme enceinte - le développeur de logiciels Fujitsu a été le pionnier de l'utilisation d'un méthodologie agile pour développer des logiciels, à savoir . Rapid Application Development Résultats de mesure erronés Comme indiqué, la recherche DORA a été mesurée par rapport à quatre indicateurs clés qui évaluent la vitesse de déploiement de nouveaux travaux et de correction des bogues pour évaluer les performances. Cependant, ces mesures n’ont d’importance que dans la mesure où elles constituent des résultats utiles à mesurer. J'ai mené (avec la société de recherche Survation) et j'ai constaté que tous deux conviennent que la vitesse est le facteur le moins important. Au lieu de cela, le public se soucie avant tout de la sécurité des données, de leur exactitude et de la prévention des bogues graves. Il est difficile de trouver une hypothèse qui relierait les quatre indicateurs clés à ces résultats que les développeurs de logiciels et le public considèrent comme les plus importants - d'autant plus que la prévention des bogues graves est carrément une moindre priorité que la correction rapide des bogues ou la mise en œuvre rapide du travail. Même pour d’autres facteurs comme la sécurité des données, il est difficile de voir comment ceux-ci sont liés à l’un des quatre indicateurs clés. des recherches auprès d'ingénieurs logiciels et d'un échantillon représentatif du grand public Même parmi les décideurs commerciaux, il semble que la livraison à temps prime sur la livraison rapide. Selon une étude que j'ai menée avec JL Partners, 98 % de ces décideurs commerciaux au Royaume-Uni et 96 % aux États-Unis sont d'accord avec l'affirmation « L'objectif d'une équipe d'ingénierie logicielle est de fournir des logiciels de haute qualité à temps », avec 65 % au Royaume-Uni et 62 % aux États-Unis sont tout à fait d'accord. Enfin; la recherche que j'ai menée avec Survation a révélé que la confiance dans les ingénieurs logiciels et les attentes du public en matière de fiabilité peuvent varier considérablement d'un secteur à l'autre, ce qui signifie qu'une approche universelle devrait être découragée en faveur de ce que suggère l'Engineering Council UK dans son rapport. : « adopter une approche décisionnelle proportionnée au risque et cohérente avec l'appétit pour le risque défini par leur organisation ». Guidance on Risk Suivez l'argent Tout comme le Dr Keys a reçu un financement de l'industrie sucrière pour ses recherches, dans de nombreuses enquêtes, il est important de suivre l'argent pour comprendre où se trouvent les incitations. L'équipe DORA a initialement commencé à rédiger des rapports sur l'état du DevOps pour Puppet, une entreprise axée sur l'automatisation de l'infrastructure informatique, et elle effectue désormais ce travail pour Google Cloud. Tous deux ont tout intérêt à ce que les développeurs puissent déployer leur travail le plus rapidement possible. Cela ne veut pas pour autant dire que c’est la solution à tous nos problèmes. DORA a apporté une contribution au monde du génie logiciel en ajoutant un degré d'évaluation empirique au processus. Cependant, nous devons éviter de confondre les documents marketing avec toute la vérité et reconnaître les défauts de telles recherches.
