Les 4 mythes de la productivité

Photo de Sohrab Salimi
Sohrab Salimi
4 min. Temps de lecture
Ce contenu a été traduit par IA. Voir l'original

Vous souhaitez améliorer la productivité du développement logiciel pour vous-même, votre équipe ou votre organisation ? Alors poursuivez votre lecture et nous allons ensemble démystifier quelques idées reçues.

Rapidité versus Qualité

Mythe : Chaque projet de développement logiciel est un compromis entre rapidité et qualité.

Réalité : En matière de productivité dans le développement logiciel, il n'y a pas de conflit entre rapidité et qualité.

« Quand la qualité est bonne, le développement est plus facile. »
Greger Wikstrand

Une qualité élevée permet une vitesse élevée. C'est l'enseignement tiré de nombreuses méthodes agiles populaires, comme le développement piloté par les tests (TDD), l'intégration continue et DevOps. Quand on ne se concentre plus suffisamment sur la qualité, la dette technique s'accumule de plus en plus. Assez vite, tout le budget passe dans la maintenance et il ne reste plus rien pour les investissements. Tu dois maintenir ton système (ou l'environnement système) dans un état où tu peux réellement changer ou améliorer quelque chose.

Si tu veux en savoir plus sur la qualité et comment l'atteindre, je te recommande le World Quality Report.

Compétences versus Quantité

Mythe : Les développeurs logiciels ne sont que des ressources et peuvent être remplacés selon les besoins.

Vérité : En ce qui concerne la productivité dans le développement logiciel, il existe d'énormes différences entre les développeurs !

Il y a des différences individuelles entre les développeurs. Supposons simplement qu'un développeur moyen a une productivité de 1. Un mauvais programmeur a peut-être une productivité de 0 ou même de -1. Cela signifie que la performance d'un mauvais développeur et celle d'un développeur médiocre peuvent en fait s'annuler mutuellement. Un programmeur vraiment excellent peut en revanche avoir une productivité de 10 ou même de 30. Un tel développeur peut remplacer des équipes entières de développeurs. Donc oui, il s'agit d'avoir les bonnes personnes.

Il faut du temps pour construire une équipe performante en développement logiciel. À moins de te concentrer explicitement sur la création d'une mémoire transactive au sein de l'équipe, il faudra jusqu'à un an avant que cette amélioration ne se produise d'elle-même. Les gens ne sont pas des plantes en pot qu'on peut déplacer d'un endroit à un autre sur ordre du jardinier. Ce sont des arbres aux racines profondes. Leurs racines sont blessées et laissent un grand trou quand on les déplace.

Agile versus Cascade

Mythe : Dans d'autres secteurs, on travaille avec succès selon la méthode en cascade, donc nous devrions faire de même.

Réalité : Beaucoup de choses ont changé depuis les années 1950, et même dans le secteur du bâtiment, on ne travaille plus en cascade.

Il existe une différence fondamentale entre la production de masse (reproduction) et les secteurs comportant beaucoup plus d'incertitude et de travail de conception, comme le développement logiciel ou même le secteur du bâtiment. Mais attendez, le bâtiment n'est-il pas l'exemple phare de la méthode en cascade ? Tout commence avec l'architecte, puis viennent les ingénieurs, la construction du bâtiment et enfin son utilisation. Oui, c'était la situation dans les années 1950, quand on construisait des bâtiments sur terrain vierge. Mais les choses ont changé. Aujourd'hui, dans le bâtiment, il s'agit de rénover, restaurer et transformer des bâtiments existants – et personne ne sait ce qui se cache dans un mur ou sous un plancher. Le secteur du bâtiment évolue lui aussi vers une approche plus agile.

Bien sûr, en Agile, certaines conditions doivent être réunies pour que tout fonctionne bien, mais on ne peut pas s'en débarrasser en les ignorant. Si tu ne travailles pas encore de manière agile, devenir agile est extrêmement important pour améliorer la productivité et résoudre les problèmes.

Cloud versus On-Premise

Mythe : Le cloud n'est rien d'autre que des serveurs dans le cloud – il ne peut pas améliorer ta productivité.

Réalité : Le cloud est l'un des moteurs les plus puissants de la productivité dans le développement logiciel.

… et ce, même si tu considères le cloud uniquement comme un moyen de louer des serveurs (Infrastructure-as-a-Service), ce qui présente déjà en soi des avantages considérables pour la productivité dans le développement logiciel. La capacité d'obtenir un tout nouvel environnement en quelques secondes permet par exemple l'intégration et le déploiement continus, et même le DevOps, ce qui peut considérablement augmenter la productivité. Mais le cloud, c'est bien plus qu'une simple infrastructure. Aujourd'hui, il ne faut plus que quelques heures après la finalisation du design pour commencer à vendre ses premiers produits dans sa boutique en ligne. Et tout cela grâce au Manufacturing-as-a-Service, au Logistics-as-a-Service et même à l'eCommerce-as-a-Service. Cela ne s'applique pas seulement aux produits physiques, mais aussi au développement logiciel.

Ce texte est tiré du blog de Greger Wikstrand et a été traduit en français par nos soins.

Parle à notre assistant Parle à notre assistant