[DUMD 6/24] Soyez "agile"

Auteur du billet de blog : Nicolas Hilaire - Neotech Solutions

Nicolas Hilaire

Consultant .NET
  Publié le mercredi 2 novembre 2016

Artisan logiciel particulièrement intéressé par les technologies .NET. Polyvalent et curieux, je suis néanmoins à l'écoute des autres technologies du marché. MVP (Microsoft Most Valuable Professional) de 2007 à 2014, je suis également auteur d'un ouvrage pour apprendre le C#, à destination des débutants et de plusieurs MOOCs sur le C#, Windows Phone ou ASP.NET MVC...

Sixième billet sur comment devenir un meilleur développeur. Pour retrouver le sommaire ainsi que tous les liens, rendez-vous sur le premier billet.

 

Force est de constater qu'aujourd'hui de plus en plus d'entreprises doivent répondre à des contraintes et à des problématiques de plus en plus rapidement. L'évolution rapide du marché, la forte concurrence, font que les logiciels ne peuvent plus suivre un cycle de développement de plusieurs mois, voire plusieurs années.

Le développement logiciel doit s'adapter à ces besoins ; on l'a vu et on le subit régulièrement, le client change d'avis tout le temps. Nous devons donc disposer d'outils et de pratiques pour faire en sorte que nos projets s'adaptent à ce fonctionnement.

Nous allons parler ici brièvement des pratiques agiles et notamment de celles qui vont nous aider à devenir des meilleurs développeurs.

 

Le manifeste Agile

Ce texte est né en 2001, sous la tutelle de dix-sept experts, et fait émerger les principes unificateurs des méthodes agiles. Je ne souhaite pas présenter dans ce billet l'exhaustivité des méthodes agiles, mais simplement les valeurs et outils dont nous devons nous inspirer. Voici les quatre valeurs de ce manifeste :

  1. Les individus et leurs interactions plus que les processus et les outils.
  2. Du logiciel qui fonctionne plus qu’une documentation exhaustive.
  3. La collaboration avec les clients plus que la négociation contractuelle.
  4. L’adaptation au changement plus que le suivi d’un plan.


Ainsi que les 12 principes :

  • Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
  • Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client.
  • Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
  • Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
  • Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
  • La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
  • Un logiciel opérationnel est la principale mesure d’avancement.
  • Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
  • Une attention continue conduit à l'excellence technique et à une bonne conception renforce l’agilité.
  • La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
  • Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
  • À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

 

Tous les principes sont importants, mais ceux qui nous parlent le plus sont ceux liés au changement. Le changement va arriver, il faut donc s'y préparer. Simplicité, excellence, efficacité, oui oui, on y va :).

Pour tout ce qui est de la livraison rapide, cela implique un processus d'intégration continue bien sûr, mais cela sous-entend également que l'on va faire des cycles de développement très courts (en général de 2 à 3 semaines). C'est une bonne chose, cela nous forcera à faire des choses simples et à ne pas partir dans des architectures trop complexes, sous peine de ne pas être capable de livrer l'incrément du logiciel à temps.

Suivre une méthodologie agile implique de faire du développement agile. Vous découvrirez ces pratiques tout au long des futurs billets.

 

Les pratiques de l'extreme programming (XP)

L'extreme programming est une méthode agile fortement centrée sur des pratiques concrètes pour les développeurs. Nous allons parler un peu de certaines de ces pratiques et voir comment elles font de nous des meilleurs développeurs.

- La simplicité :

XP nous dit que la façon la plus simple d'arriver au résultat est la meilleure. Anticiper les extensions futures est une perte de temps. Une application simple sera plus facile à faire évoluer.

- Le pair programming (ou la programmation en binôme) :

il s'agit d'un concept très intéressant où les développeurs travaillent à deux sur le même poste. Il y en a un qui développe pendant que l'autre décèle les imperfections, vérifie le design, les règles de code, etc. Et régulièrement, on échange les rôles. Même si on peut penser qu'avec une telle méthode de travail, on va augmenter le temps de développement pour une tâche, des études ont montrées que le code est plus robuste et contient moins de bugs que s'il avait été réalisé par une unique personne. Donc, au final on va plus vite car on perd moins de temps en maintenance. De plus, le pair-programming encourage la discussion et le partage de connaissances. Il est ainsi plus facile pour une personne arrivant sur un projet de se former auprès des autres développeurs. Cela permet également de réduire les parties d'une application où il n'y a qu'une seule personne qui connait (on fait quoi si cette personne se casse une jambe ?) et ainsi augmenter la responsabilité collective du code.

- Le refactoring (remaniement de code) :

Il permet l'amélioration régulière du code sans en modifier le comportement. Ainsi, on évite les syndromes de dégradation du code comme on peut les rencontrer régulièrement. Cette phase n'apporte pas de nouvelles fonctionnalités mais elle permet au développeur de faire baisser la dette technique. Un refactoring est garanti sûr grâce à l'utilisation de tests automatisés.

- TDD (Test Driven Development ou Développement piloté par les tests) :

TDD est une méthode de développement de logiciel qui préconise d'écrire les tests unitaires avant d'écrire le code source d'un logiciel. TDD permet de faire émerger le design d'un code grâce à l'écriture successives des tests et du code permettant de faire passer les tests.

 

Je m'arrête là pour les pratiques XP, il y en a d'autres. N'hésitez pas à aller creuser le sujet.

 

Le software craftmanship

Le software craftmanship, que l'on peut traduire en artisanat du logiciel, est une approche de développement de logiciels qui met l'accent sur les compétences de codage des développeurs. Ce mouvement a également un manifeste, un peu à la manière du manifeste agile :

  1. Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus.
  2. Pas seulement l'adaptation aux changements, mais aussi l'ajout constant de la valeur.
  3. Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels.
  4. Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.


On retrouve dans ces valeurs beaucoup de principes empruntés à l'extreme programming.

Pour résumer, si le code n'est pas de qualité, alors le logiciel sera non-fonctionnel ou pire, difficile à maintenir et à faire évoluer. L'idée est donc de remettre au centre de la réalisation de logiciels les bonnes pratiques de développement.

Et c'est tout l'idée de ces billets :).

 

Conclusion

Ce qu'il faut retenir de ce billet, c'est que nous allons construire notre code par petites itérations et que celui-ci va inévitablement changer au fur et à mesure du développement de l'application. En tant que développeur compétent, nous devons faire en sorte que notre code soit le meilleur possible, le plus évolutif et le plus maintenable possible, tout en le réalisant petits bouts par petits bouts.

Notre rôle en tant que professionnels est de faire en sorte que le logiciel fonctionne mais également qu'il soit bien écrit et maintenable. Et si en plus on peut partager l'excellence professionnelle au sein de l'équipe, c'est encore mieux :).

 

Prochain billet sur le pourquoi des design patterns.