Introduction
Dans le chapitre précédent, nous nous sommes intéressés au modèle de recherche des performances présentées par le rapport DORA qui permet principalement de contribuer à l'amélioration du modèle DevOps au sein d’une organisation. Dans cet article nous allons aborder l'autre modèle qui concerne productivité.
Le modèle de la productivité
Comme évoqué dans l'introduction, leur second modèle de recherche est sur la productivité. La recherche démontre que les organisations peuvent améliorer la productivité des ingénieurs en investissant dans des outils faciles à utiliser, une recherche d'informations plus accessible, une culture de la sécurité plus accrue et la réduction de la dette technique.
Cette amélioration de la productivité contribue également à améliorer l'équilibre travaille et vie personnelle des employés et par conséquent à réduire le Burnout (l'épuisement professionnel).
Qu’est-ce que la productivité et comment la mesurer ?
Les ingénieurs productifs sont plus à même à réaliser leurs tâches efficacement, ce qui leur libère plus de temps à réinvestir dans d'autres travaux, tels que le développement de fonctionnalités supplémentaires, l’amélioration de l’architecture du code, la création de la documentation, la formation sur des nouvelles technologies ou le développement de l’infrastructure existante.
La productivité ne peut pas être mesurée avec des métriques simples telle que le nombre de lignes de code ou de bogues résolus. Les chercheurs ont longuement discuté sur ce sujet et la plupart s’accordent sur la même définition : « la productivité est la capacité à réaliser des tâches complexes et chronophages avec un minimum de distractions et d'interruptions ».
Le rapport recommande de localiser d’abord l’objectif que l’on souhaite améliorer, puis d’identifier les capacités qui l'ont impacté. Par exemple, si l’objectif est de réduire la dette technique, les capacités seront la maintenabilité du code, l’implémentation d’une architecture faiblement couplée et la mise en place d’un système de supervision.
Schéma du rapport DORA sur l'impacte de la productivité
Des outils utiles et faciles à utiliser
Le rapport mentionne que les outils utiles et faciles à utiliser sont désormais considérés comme un incontournable pour les technologies grand public. Cependant ces caractéristiques évidentes sont souvent négligées parmi les professionnels de la technologie qui supposent qu'ils sont des experts et peuvent faire fonctionner n'importe quel outil ou technologie. Le contraire est vrai, car lors de la construction de systèmes complexes, les outils à choisir sont encore plus importants car ils seront utilisés longtemps et par d’autres individus.
Le rapport s’est principalement concentré sur les outils utilisés dans le déploiement de logiciels via les pratiques CI/CD car ils sont au cœur même d’un pipeline DevOps. Ils ont constaté que les deux attributs suivants de la chaîne d’outils CI/CD stimulent la productivité :
- La facilité d'utilisation de la chaîne d'outils (y compris les interactions et le fonctionnement simple et facile)
- L'utilité de la chaîne d'outils pour atteindre les objectifs liés au travail
À quoi ressemblent ces outils ? Ils ont creusé les données par profil de performance et ont remarqué des modèles intéressants catégorisés dans le tableau ci-dessous :
| Faible | Moyen | Élevé | Élite | |
|---|---|---|---|---|
| Un mélange d'outils propriétaires, open source et COTS* | 30% | 34% | 32% | 33% |
| Principalement open source et COTS, fortement personnalisés | 17% | 8% | 7% | 10% |
| Principalement open source et COTS, avec peu de personnalisation | 14% | 21% | 18% | 20% |
| Logiciel principalement packagé COTS | 8% | 12% | 8% | 4% |
| Développé principalement en interne et propriétaire de mon organisation | 20% | 6% | 5% | 6% |
| Principalement open source, fortement personnalisé | 6% | 7% | 5% | 12% |
| Principalement open source, avec peu de personnalisation | 5% | 12% | 24% | 15% |
Définition
*COTS : désigne tout produit informatique fabriqué en série et non pour un projet en particulier.
Ce tableau nous montre que la concentration la plus élevée de logiciels entièrement propriétaires est observée chez les acteurs peu performants, tandis que la concentration la plus faible de ce type de logiciels est observée chez les acteurs performants et d'élite. Les logiciels propriétaires peuvent être utiles, mais leur maintenance et leur support sont très coûteux.
Voici un autre tableau qui liste également l’automatisation et l’intégration par profil de performance :
| Faible | Moyen | Élevé | Élite | |
|---|---|---|---|---|
| Build automatisé | 64% | 81% | 91% | 92% |
| Tests unitaires automatisés | 57% | 66% | 84% | 87% |
| Tests d'acceptation automatisés | 28% | 38% | 48% | 58% |
| Tests de performances automatisés | 18% | 23% | 18% | 28% |
| Tests de sécurité automatisés | 15% | 28% | 25% | 31% |
| Provisionnement et déploiement automatisés dans des environnements de test | 39% | 54% | 68% | 72% |
| Déploiement automatisé en production | 17% | 38% | 60% | 69% |
| Intégration avec des outils de monitoring de la production | 13% | 23% | 41% | 57% |
| Aucune de ces réponses | 9% | 14% | 5% | 4% |
Ce tableau nous montre que les groupes d'élites automatisent et intègrent les outils plus fréquemment dans leurs chaînes d'outils dans presque toutes les dimensions.
Même, si l’automatisation peut être considérée comme laborieuse à mettre en place au départ, elle reste tout de même un réel bon investissement sur le long terme, détachant ainsi les ingénieurs des travaux manuels, leur permettant ainsi de consacrer plus de temps à d'autres activités importantes.
Cela met également plus en confiance les ingénieurs lors de la mise en œuvre des changements car ils ont préalablement établi des tests sur toutes les étapes de l’automatisation.
Recherche interne et externe
Trouver les bonnes informations au bon moment pour résoudre des problèmes est un facteur à ne pas négliger dans le cycle de vie application, de son développement à sa livraison.
Cela est particulièrement vrai dans la complexité technologique d'aujourd'hui. Dans ces temps, l'accès aux sources d'information au moment attendu permet d’effectuer avec rigueur un travail efficace, de maintenir un bon flux de travail, de moins stresser les intervenants et par conséquent de favoriser la productivité.
Enfin, ces sources d'information se divisent en deux sous catégories :
- La recherche interne
- La recherche externe
La recherche interne
La recherche interne correspond aux investissements qui prennent en charge la création de documentations locales au sein d’une organisation ainsi qu’une recherche efficace assistée par une base de connaissances généreusement alimentée et un système de tickets facile à utiliser.
Le rapport confirme ainsi que les entreprises utilisant des sources de connaissances internes sont 1,73 fois plus susceptibles d'être productifs. Cela a même tendance à encourager les équipes à partager avec les autres leurs informations et connaissances supplémentaires.
La recherche externe
Il s'agit de sources externes telles que les moteurs de recherche comme Google ou des sites de questions/réponses tel que Stack Overflow. Le rapport révèle alors que ceux qui utilisaient la recherche externe dans leur travail étaient 1,67 fois plus susceptibles de déclarer se sentir productifs dans leur travail.
En effet, de nos jours la recherche externe est devenue très importante car les technologies open source actuelles sont d'autant plus consommées et fournissent une communauté d’utilisateurs solide qui facilite l’adoption et l'utilisation de ces technologies et garantissent un support permettant aux équipes de résoudre leurs problèmes plus rapidement.
De plus, les recherches du rapport 2018 ont démontré que les acteurs d'élite tirent parti et ont prévu d'étendre leur utilisation de l'open source. Dans les recherches de l’année 2019, ils constatent que les artistes d’élite utilisent davantage d’outils open source alors que les moins performants utilisent davantage de d’outils propriétaires. Ces choix technologiques ont inévitablement un impact sur la productivité.
La dette Technique
La dette technique a été introduite en 1992 par Ward Cunningham pour décrire ce qui se passe lorsqu’une personne ne parvient pas à maintenir correctement un code immature.
Bien qu'un code immature puisse fonctionner correctement et être complètement acceptable pour le client, des quantités excessives de ce type de code rendront un programme impossible à maîtriser, conduisant finalement à un produit rigide.
Une brève dette peut précipiter le développement d’une application tant qu'elle est remboursée rapidement avec une réécriture du code. Mais, le danger survient lorsque la dette n'est pas remboursée et chaque temps passé sur un code pas tout à fait maintenable compte comme intérêt sur cette dette.
De nos jours, avec des systèmes de plus en plus complexes, la dette technique peut se produire depuis différentes sources de code telle que l’architecture du code applicative, les fichiers de configuration, le code de l’infrastructure. D’une autre façon, on peut définir la dette technique comme un code ou un système avec :
- Des bugs connus qui ne sont pas corrigés au profit de nouvelles fonctionnalités
- Une couverture de tests insuffisante
- Des problèmes liés à une faible qualité de code ou à une mauvaise conception
- Un code ou artefacts qui ne sont pas nettoyés lorsqu'ils ne sont plus utilisés
- Des implémentations dans lesquelles l’équipe actuelle n’a pas d’expertise et ne peut donc pas déboguer ou maintenir efficacement
- Une migration incomplète
- Une technologie obsolète
- Une documentation incomplète ou obsolète ou commentaires manquants
Le rapport DORA constate que la dette technique a un impact négatif sur la productivité, les répondants ayant une dette technique élevée étaient 1,6 fois moins productifs et que les plus performants étaient 1,4 fois plus susceptibles d'avoir une dette technique faible.
La culture de la sécurité psychologique
Le rapport cite que pour une organisation quelconque qui décide de valoriser et favoriser la culture du confort et de la sécurité psychologique de ses salariés, en mettant de mise la confiance et le respect, contribuent à la productivité en permettant à ses employés de se concentrer sur la résolution de problèmes et de réaliser leurs tâches efficacement plutôt que de gérer des problèmes annexes hors de leurs domaines de compétence.
Cela fait écho aux travaux d'autres chercheurs, comme l’étude de Google dans l'article précédent, qui révèle que ce même type de culture conduit à des équipes plus efficaces.
Avantages supplémentaires d'une amélioration de la productivité
Les avantages de la productivité accrue d’une équipe pour une organisation sont généralement clairs. En effet, plus les salariés sont productifs, plus ils offrent plus de valeur à leur entreprise. Mais qu'en est-il des avantages pour les salariés ? Le rapport commence par définir ce qu’est la récupération de travail, car c’est un facteur clé quand il s’agit de bien-être d’un salarié.
Ils décrivent la récupération au travail comme la capacité de se détacher du travail lorsque nous ne travaillons pas. Ainsi, ils démontrent que les personnes arrivant véritablement à se détacher de leur travail, arrivent à mieux gérer le stress lié à ce dernier.
L'inverse est également vrai, un surmenage entraîne un épuisement professionnel (burnout) qui a été reconnu par l' OMS (Organisation Mondiale de la Santé) comme une condition qui résulte d'un stress chronique non géré au travail.
Pour finir, dans leurs recherches de cette année, ils ont constaté tout d’abord qu’une mauvaise récupération au travail cause le burnout et qu’une application des bonnes pratiques techniques, d’une collaboration attentive, d’une amélioration continue des processus imparfaits et d’une gestion du changement claire et transparente peuvent réduire l'épuisement professionnel. Ainsi ils déclarent que les acteurs peu performants sont 2 fois plus susceptibles de se sentir épuisés.
Conclusion
Après avoir examiné les aptitudes et stratégies clés qui améliorent la livraison de logiciels pendant six années consécutives, le rapport State of DevOps 2019 a su prouver statistiquement que le DevOps apporte véritablement une valeur significative, améliorant à la fois leur cycle de développement et de livraison de logiciels à l'aide de diverses méthodes et bonnes pratiques DevOps.
Enfin, ils finissent par conclure que le DevOps n'est pas une tendance, et sera à terme le moyen standard de développement et d'exploitation des logiciels, offrant à chacun une meilleure qualité de vie.