Maximisez les chances de réussir votre projet informatique

Vous êtes un·e développeur·se ou CTO à la recherche de méthodes pour maximiser les chances de réussite de votre projet informatique ? Dans cette série d’articles, je vais aborder différentes tactiques pour commencer sur de bonnes bases, issues et consolidées via de mes diverses expériences et de veille technologique.

💡 L’article est écrit dans un contexte d’un écosystème Java mais peut tout à fait être adapté pour tout autre langage de programmation !

Voici les thèmes qui seront détaillés dans la série :

• Les bonnes pratiques
• L’agilité
• l’open source
• L’architecture
• Les tests
• La responsabilisation des équipes

Dans un prochain article, j’aborderai l’aspect DevOps.

De nombreux liens sont à disposition dans l’article pour en savoir plus.

Cet article sera enrichi à diverses reprises pour rester un point d’entrée à jour, vous pouvez me suivre sur Twitter ou LinkedIn pour vous tenir informé des mises à jour.

La base : les bonnes pratiques

Je traite tous ces aspects dans un article dédié, La base de toute réussite : les bonnes pratiques, qui fait partie de la série nommée “Maximisez les chances de réussir votre projet informatique”.

Voici les différents sous-thèmes abordés :

• Style de code
• Commentaires et documentation
• Workflow Git
• Outils d’analyse de code en continu
• Principes de conception
• Programmation en binôme
• Revue de code
  👉 La revue de code est encore plus détaillée dans mon article Travailler efficacement en équipe avec la revue de code
• Katas
• La plateforme d’intégration continue, indispensable
  👉 La plateforme d’intégration continue est elle aussi encore plus détaillée dans mon autre article, Livrer de la qualité tout en restant productif

Soyez agile !

L’agilité, à défaut d’être souvent dévié du concept original via la gestion de projet, les certifications…, c’est principalement un état d’esprit !

Soyez positif, ayez la soif de connaissance. N’ayez crainte des échecs et tirez en des enseignements. Intégrez les retours le plus souvent possible, que ce soit d’utilisateurs, du métier, ou même de la plateforme d’intégration continue. Travaillez de façon incrémentale, en privilégiant l’ajout de valeur. Visez la réussite de l’équipe et non pas d’un individu.

👉 Les pratiques techniques ont toujours fait partie de l’agilité. Scrum ne l’a pas repris, non pas parce qu’elles ne sont pas utiles, mais parce que Scrum se veut générique et car les équipes doivent suivrent les pratiques qui font sens dans un context donné.
Plus d’infos sur Agility implies Craftsmanship

📺 J’ai parlé de cette imbrication de la technique avec l’agilité dans un talk aux côtés de Constantin Guay, Faire grandir une application

La suprématie de l’Open Source

Optez pour des frameworks, outils et solutions issues du monde open source. Ceux-ci seront plus maintenables.

Pour ce qui est du choix des solutions open source, je ne peux qu’approuver l’une des philosophies d’Unix : “Do one thing, and do it well”.

👉 Sur l’un des projets où j’ai travaillé, l’application devait être refaite car elle était basée sur des solutions Oracle. Ces solutions, en plus d’avoir un coût non négligeable, ont une durée de vie limitée avec le support. L’enjeu était alors de refondre une application qui a évolué pendant 8 ans, en quelques années seulement, pour éviter les coûts exorbitants de l’extension du support

Une architecture pertinente et pérenne

Je traite tous ces aspects dans un article dédié, Une architecture pertinente et pérenne, qui fait partie de la série nommée “Maximisez les chances de réussir votre projet informatique”.

Voici les différents sous-thèmes abordés dans l’article :

• Le CQRS
• L’Event Sourcing
• Le DDD
• Les Microservices

Tests

Je traite tous ces aspects dans un article dédié, Les tests, oui, mais pas n’importe comment !, qui fait partie de la série nommée “Maximisez les chances de réussir votre projet informatique”.

Voici les différents sous-thèmes abordés dans l’article :

• TDD ou BDD ?!
• Rappels concernant l’écriture de tests unitaires
• Les tests fonctionnels automatisés
• Des raisons pour lesquelles des tests mal mis en place pourraient être à l’origine d’échecs

Responsabilisation des équipes

Un des intérêts d’avoir une équipe responsable est d’avoir une équipe plus pro-active, impliquée.

La responsabilité ne doit en aucun cas n’impliquer qu’une culpabilité en cas d’échec. Donner de la responsabilité, c’est aussi faire confiance, donner une marge de manœuvre, écouter et accompagner.

L’idéal se produit lorsque c’est l’équipe elle-même qui demande à être autonome, mais pour ça, il faut que le management leur en donne les moyens.

Exit le reporting à la hiérarchie, les ordres unilatéraux sans consultation de l’équipe au préalable, la mise sous pression stressante.

Optez pour une organisation plus transparente, collaborative.

📔 Dans l’une de mes missions, j’ai eu l’occasion de participer à un PI planning (SAFe… 😢) où une équipe avait indiqué ne pas avoir la capacité d’intégrer une nouvelle feature dans leur planning. Le chef de projet a ensuite estimé et décidé que l’équipe pouvait prendre un sujet supplémentaire, et donc les a forcé à le prendre.
C’est contraire à toutes les bonnes pratiques !

L’adoption des microservices peut aider à mieux visualiser les responsabilités de chacun.

💡 Selon moi, responsabiliser chacun sur un trop gros projet où une dizaine d’équipes interviennent, alors qu’aucune différence n’est faite dans le code, est une mauvaise idée. “Si tout le monde est responsable, personne ne l’est”

En dehors du cadre des microservices, il est pertinent d’adapter l’architecture aux équipes ou à l’organisation.

Ainsi, la loi de Conway indique que “Les organisations qui définissent des systèmes … sont contraintes de les produire sous des designs qui sont des copies de la structure de communication de leur organisation.” (Wikipedia)

📔 Dans l’une de mes missions, nous étions plus de 15 équipes, découpés en trois domaines ambigus, à intervenir sur la même application, composée d’une dizaines de composants, chacun isolé sur un projet Git. Si les tests fonctionnels automatisés cassaient, l’équipe pour qui c’était sa semaine de les prendre en charge se devait de mener l’investigation et corriger. Il était fréquent qu’une équipe d’un autre domaine casse une série de tests affectés à notre domaine et nous perdions alors un temps précieux à mener l’enquête.
Une organisation mieux définie et des composants affectés à une équipe nous auraient permis d’être beaucoup plus efficaces

Et vous ?

Qu’avez vous mis en place pour maximiser vos chances de réussir ? Suivez-vous déjà certains points abordés dans cette série d’articles ?

Je serais heureux d’avoir vos retours d’expérience, vos avis, …