Les dépassements, parlons en !

Les dépassements de coûts en développement logiciel en choquent plus d'un. Des projets dont l'estimé initial tourne autour de 17M$ se révèlent coûter plus de 100M$ à l'état. Pourquoi ?

Lors d'une récente publication, j'ai parlé de l'agilité, de son historique et un peu des valeurs qui y sont véhiculées. Quoiqu'il en soit, certaines personnes ne comprennent toujours pas les dépassements de coûts en développement logiciel, et du coup se révèlent plutôt hésitant, voir méfiant vis-à-vis les méthodologies agiles. Or je vais tenter d'éclaircir le tout selon mon point de vue personnel et mes expériences au sein du gouvernement du Québec en développement logiciel. Je parlerai d'abord des demandes de services, ensuite de la méthodologie Waterfall en V, et je parlerai aussi de quelques concepts clés de l'agilité, pour finir en faisant certains parallèles avec les deux méthodologies et la façon de négocier un contrat en TI.

La méthodologie Waterfall en V

Cette approche vient de la gestion de projets en construction. Le développement logiciel étant une jeune industrie encore aujourd'hui, on ne savait pas encore comment gérer un projet de développement logiciel de grande envergure. Ce qu'on avait de plus similaire ce sont les travaux d'importants chantiers de construction où, bien entendu, toutes les étapes jusqu'à la réalisation sont réalisées en séquence.

(de l'analyse des besoins au codage, et du codage à la recette)

On doit avoir complété à 100% chaque étape avant de passer à la suivante. Par exemple, si la Conception détaillée révèle une anomalie, l'étape de la Conception architecturale doit être reprise au complet! Et lorsqu'on passe la phase du codage et qu'on est rendu aux tests unitaires, et que les tests révèlent une anomalie, on doit reprendre la Conception détaillée, puis le codage, et ensuite recommencer la phase des tests unitaires. On définit ici une anomalie par un bogue du système ou encore un changement prescrit par le client, par exemple. C'est pourquoi ce modèle est très coûteux et très lourd dans le développement logiciel. On utilise un modèle de gestion de projets qui est bien adapté et mature pour l'industrie de la construction. Ce modèle est malheureusement inadéquat pour le développement logiciel, une industrie qui bouge très vite et qui doit s'adapter aux changements.

De plus, les équipes de développement typiques sont formées de plusieurs membres qui ont chacun leurs responsabilités et leur rôle à jouer. Ce qui signifie qu'on ne peut demander, par exemple, à un architecte de développer une fonctionnalité si les programmeurs sont dans le jus.

Les méthodologies agiles

Les méthodologies agiles proviennent de l'expérience de 17 professionnels internationaux qui oeuvrent en technologies de l'information (voir Qu'est-ce qu'Agile?) qui se sont réunis pour définir certaines règles tirées de leur expérience. De leur rencontre ressort entre autre Scrum, une méthodologie agile de gestion de projets. Le cycle de développement diffère en plusieurs points de l'approche Waterfall en V.

Cycle de développement selon Scrum

Ce qui signifie qu'au bout de 30 jours, une équipe peut livrer un incrément fonctionnel potentiellement livrable du logiciel. C'est lors de la revue d'itération que l'équipe de réalisation présente le logiciel à date au responsable de produit et aux parties prenantes.

Pour une raison ou une autre, si les fonctionnalités développées ne correspondent pas à la volonté du client, on s'adapte et on reprend les travaux pour les 30 prochains jours, après avoir eu un ou des entretiens avec le client (ou responsable de produit) afin d'apporter les changements nécessaires. C'est lors de la rétrospective d'itération que l'équipe Scrum se rencontre pour faire le point sur l'itération et suggérer des pistes d'amélioration quant au déroulement de l'itération qui se termine. Ces suggestions devront être mises en application immédiatement à la prochaine itération, i.e. celle qui débute de suite.

Durant chaque itération, l'équipe de réalisation se concentre uniquement sur les fonctionnalités pour lesquelles elle s'est engagée, et les réalise en ordre de priorité établi par le responsable de produit pour qui la responsabilité la plus importante constitue le retour sur investissement du développement du produit. Une itération comprend les activités suivantes:

1. Analyse des besoins
2. Développement des fonctionnalités
3. Préparation de la démonstration au responsable de produit (et aux parties prenantes, s'il y a lieu)

Le développement des fonctionnalités

Durant la phase de développement, des tests d'acceptation et unitaires sont élaborés dans le but d'assurer la qualité du logiciel développé et renforcir une meilleure architecture. Or, c'est en faisant usage du développement piloté que l'architecture se conçoit d'elle-même en même temps que le développement évolue. Les équipes sont multidisciplinaires et interfonctionnelles.

Les dépassements

L'industrie du logiciel a subi une mauvaise presse en utilisant un modèle de gestion de projets qui n'était pas du tout adapté pour le développement logiciel. Néanmoins, en présence d'une nouvelle industrie émergente, on devait trouver une façon de gérer les projets et l'essayer. Ce fut alors l'adoption de la méthodologie Waterfall. L'industrie s'ajuste maintenant vers une nouvelle approche! Et ça a commencé à changer dans certains organismes paragouvernementaux qui ont adopté l'agilité.

Est-ce que tous les dépassements sont liés à cette méthodologie ?

Sûrement pas ! Ces dépassements sont aussi dû à certains choix technologiques ou des politiques d'utilisation de certains outils qui freinent le développement. La complexité de certaines entreprises privés ou de certains ministères ou organismes gouvernementaux viennent accroître ces dépassements de coûts et d'échéancier. Et il est possible que des dépassements de coûts surviennent dans le futur même avec l'adoption de l'agilité. Une méthodologie n'a aucun effet si l'administration d'un organisme, d'un ministère ou d'une entreprise n'adopte pas les valeurs de ces méthodologies. L'agilité représente bien plus qu'un simple ensemble de méthodologies appliqué au développement logiciel, et peut s'appliquer à la gestion d'une entreprise également.

Les contrats en TI

En développement logiciel, il est difficile d'établir une règle de trois pour déterminer combien de ressources on aura besoin.

Par exemple, dans le cas de la construction d'une niche à chien, à partir du moment où on connaît la grandeur du chien qui va habiter la niche, on peut déterminer la superficie du plancher, la hauteur des murs et du toit de la construction. On peut aussi calculer combien de clous on aura besoin, combien de feuilles de contreplaqués, etc. On a une excellente idée du coût de la construction.

En développement logiciel, il n'en est pas aussi simple. Et pourtant, combien de fois on me demande "Combien cela peut me coûter" ? On veut toujours savoir combien va nous coûter un projet avant même qu'il soit construit. Et c'est normal, compte tenu des budgets alloués par département ou par par projets. Par ailleurs, à moins d'un projet très simple, mais très très simple, il est quasi impossible de prévoir combien peut coûter un projet de développement logiciel, à mon humble avis. Pensez-y, un logiciel optimise en général vos processus d'affaires, chose qu'on ne savait faire sans le logiciel ! Un logiciel vous permet aussi de faire plus en moins de temps, ça a un coût - et ce coût devient un investissement lorsque bien géré et les risques bien contrôlés. Bien entendu, je ne parle pas d'un simple site Internet de quelques pages, mais bien d'un système de gestion intégrés complexes qui peut comprendre plusieurs sphères de vos activités.

Or, les projets gouvernementaux représentent souvent des projets de très grandes envergures. Il est certain qu'aucune personne peut évaluer avec exactitude combien il en coûtera. Néanmoins, les firmes de services conseils sont appelées à établir un montant, montant à partir duquel une idée du projet est faite et une stratégie de développement est développée. En bout de ligne, les prérequis changent, les besoins ont évolués ou on ne pouvait prévoir un élément de complexité caché, et c'est là que le coût du projet explose.

Conclusion

J'espère que cet article vous éclaire sur le dépassement des coûts et des échéanciers des projets de développement logiciel. Par l'expérimentation de la méthodologie Waterfall en V, on s'est aperçu que ce n'était pas adapté à l'industrie du logiciel. Cette industrie maintenant plus mature a trouvé un ensemble de méthodologie qui lui est plus adapté et qui, par la même occasion, devrait améliorer la réputation des services conseils en développement logiciel. Je suis curieux de voir ce qu'il en sera dans une trentaine d'années !