|
Editorial : des spécifications qui évoluent
Jeudi, 28 Mars 2002, par Ian Stokes
Sujet : Editorial
Résumé :
Laisser évoluer les spécifications dans un projet est pénalisant et coûteux. Figer les spécifications n’est pas réaliste non plus, dans un monde qui évolue de manière imprévisible. Les développeurs crient pour une meilleure définition des objectifs, les clients demandent plus de réactivité. Heureusement, une alternative existe.
Corps de l'article :
Le débat tourne souvent en rond. Laisser évoluer les spécifications dans un projet est pénalisant et coûteux. Figer les spécifications n’est pas réaliste non plus, dans un monde qui évolue de manière imprévisible. Les développeurs crient pour une meilleure définition des objectifs, les clients demandent plus de réactivité. Chacun voit midi à sa porte.
Logiquement, cette réflexion pourrait amener à arrêter plus souvent des projets, ou même à refuser des projets pour cause de manque de définition.
Heureusement, une alternative existe :
- concevoir des architectures qui sont plus tolérantes des changements,
- identifier et isoler les composants qui vont évoluer,
- améliorer la gestion de la configuration technique,
- mieux comprendre l’opération, l’utilisation et l’exploitation,
- relativiser les besoins en termes de priorités et de valeur ajoutée,
- écouter les points de vues des différents acteurs métiers plus en amont,
- mieux intégrer les métiers de la conception et du marketing,
- construire des plans technologiques qui prennent en compte les tendances,
- s’appuyer sur la réutilisation et maîtriser des transitions,
- planifier le lancement et anticiper des changements d’échelle.
Bref, la solution consiste en une intégration organisationnelle et une agilité technique. C’est un travail qui nécessite surtout une meilleure écoute des autres. Donc, c’est dur. Il faut appliquer une méthode adaptative. Mais, c’est peut-être préférable aux meilleurs alternatives : arrêter ou ne pas commencer du tout des projets.
0KB (0 bytes)
Publiez vos commentaires sur cet article
|