Architecture logicielle & Développement

Encore YAGNI ?

Par Emmanuel Deloget, dimanche 30 juillet 2006 à 23:34 :: Expériences :: permalien #4

Tags:

Un précédent billet expliquait YAGNI et ses raisons d'être, en précisant la nécessité d'être rigoureux et discipliné. Voici venu le temps pour moi d'avouer quelque chose : je ne suis pas encore assez rigoureux et discipliné.

Il y a quelques jours, j'ai supprimé 38 des 1050 fichiers du projet sur lequel je travaille actuellement. 38 fichiers, donc 19 classes qui ont été développées "en avance de phase" et qui, un an après, ont prouvé leur flagrante inutilité.

38 fichiers regroupant près de 3000 de lignes de code - donc plusieurs jours de travail, une perte de temps conséquente même si l'incidence sur le temps de developpement global est assez difficile a estimer (quelques jours / homme sur 30 mois / hommes ne vont pas planter un projet, même si la pillule reste quand même difficile à avaler).

Ceci dit, ces quelques jours auraient pu être passé à corriger des problèmes connus avant la présentation faite début juin au client, et ça n'aurait pas été du luxe.

Trackbacks

Aucun trackback.

Les trackbacks pour ce billet sont fermés.

Commentaires

1. Le mercredi 26 juillet 2006 à 21:37, par Christophe Moustier

Gravatar

Le manque d'objectifs

C'est souvent par manque d'objectifs à court terme que l'on se perd dans des conjectures et des hypothèses qui font que le développeur aura tendance à vouloir anticiper sur les besoins : lorsque l'on se trouve à devoir effectuer une livraison d'un contenu convenu avec le client, cela laisse peu de temps au luxe : c'est la base du travail itératif.
Par cette technique, on place tout le monde dans une dynamique de la survie du besoin le plus fort, du travail piloté par les risques ou de la plus forte valeur ajoutée, selon l'étape du projet.
Quant aux besoins anticipés et obligatoires, ils doivent être négociés avec le client...

2. Le jeudi 17 août 2006 à 15:18, par Emmanuel Deloget

Gravatar

Il y a effectivement des techniques de conduite de projet qui peuvent fortement réduire les risques liés à une anticipation par trop aléatoire des besoins. Le problème est que bien souvent, ces techniques ne sont pas utilisés : les spécifications du client sont minces voire quasi-inexistantes, le client ne suit le projet que de très loin (lorsqu'il suit le développement), etc. Quand aux négociations, on sait pour l'avoir vécu que le volet financier l'emporte bien souvent face aux considérations purement techniques - et encore, quand elle ne sont pas menées uniquement par des personnes étrangères à cette problématique.

Au final, c'est souvent au développeur ou á l'équipe de developpement que revient la responsabilité de faire attention à ne pas se laisser entraîner par le tourbillon de sa folie créatrice.

Ceci dit, je ne peux qu'approuver ton point de vue ;-)

:: Fil rss des commentaires de ce billet ::

Ajouter un commentaire

Si votre navigateur est compatible, vous pouvez vous aider de la barre d'outils placée au-dessus de la zone de saisie pour enrichir vos commentaires.