Retour sur le livre “Fact & Fallacies about Software Engineering”

La forme

Rapidement sur la forme, l’auteur nous liste les 55 faits et 10 fictions avec les éléments suivants :

• Le fait ou la fiction
• Une description : l’analyse du fait et les éléments qui portent l’auteur à croire ce qu’il mentionne (expérience personnelle principalement)
• Les controverses : les opinions contraires au fait,
• Les sources et références : des pointeurs vers des livres ou articles témoignant en faveur des faits mentionnés

C’est un peu une liste à la Prévert mais chaque sujet est bien traité, ça reste donc facilement lisible.

Le fond

Sur le contenu, on peut ne pas être d’accord avec tout ce qu’il mentionne (d’où les parties “controverses”), mais globalement, le bonhomme est plein de bon sens et on sent qu’il a du vécu. Le plus incroyable reste à mon sens les références vers des ouvrages qui ont parfois plus de 30 ans mais qui sont pourtant toujours d’actualité : gestion de projet/d’équipe, cycle de vie du logiciel, qualité du logiciel… À croire qu’on n’a pas appris de nos erreurs après toutes ces années !

Je ne vais pas vous recopier le livre, simplement énoncer/refactorer quelques faits intéressants qui à eux seuls méritent que tous les chefs/directeurs/managers de projets lisent le livre :

Les hommes

Le premier concerne les développeurs et la gestion des ressources. Les managers ont tendance à croire qu’un développeur est une ressource, au même titre qu’un serveur. Lorsque le serveur tombe en panne, on le change. Lorsque le serveur est trop lent, on en ajoute un autre. Pourquoi ne pas faire pareil avec les développeurs ? Ils sont trop lent, on en ajoute ! Un d’entre eux s’en va, on l’échange !

Et bien malheureusement, ça ne marche pas comme ça… eh oui ! Une équipe trop lente ne sera que plus ralentie si on ajoute d’autres personnes (temps de formation, communication plus difficile, répartition des tâches…). De même, lorsqu’un développeur s’en va, on ne se contente pas d’en mettre un autre lorsque le premier est parti, il y a un minimum de passage de connaissances à faire !

Enfin, si on devait tout de même faire l’analogie au serveur, si on veut une application rapide, il faut un serveur rapide (plus puissant). Donc si on veut une application développée rapidement et efficacement (de meilleure qualité j’entends), on prend des développeurs meilleurs. Selon R. Glass et ses sources, un bon développeur peut être jusqu’à 28 fois meilleur qu’un mauvais ! Tout ça pour dire que vous n’aurez pas forcément votre logiciel plus rapidement avec deux prestataires débutants à 400€/j plutôt qu’un développeur plus expérimenté facturé 800, bien au contraire !

Estimation des charges et délais

Je vais simplement reprendre une anecdote du bouquin vécue par l’auteur : chez un de ses clients, il a demandé aux développeurs comment s’était déroulé le projet. Ceux-là lui ont répondu que le projet fonctionnait bien et respectait les besoins du client. Il a ensuite posé la même question au chef de projet qui a déclaré que c’était un échec, que les délais prévus avaient été dépassés de moitié…

J’aime beaucoup cette petite anecdote et le fait qui lui est associé : une des principales causes des dépassements de délais (et donc pour certains managers d’échec du projet) est la mauvaise estimation du projet.

Les raisons qu’il cite sont multiples :

• On fait l’estimation au mauvais moment : à quoi bon estimer un projet avant d’avoir les spécifications ? On ne sait pas encore ce que va faire le logiciel et il faudrait déjà planifier sa durée ?
• L’estimation est faite par les mauvaises personnes. Bien souvent, ce sont les managers qui déterminent la date butoire de livraison. Mais savent-ils vraiment ce qu’il faut faire ? Et quand bien même, savent-ils combien de temps il faut à leurs développeurs pour le faire ? Les développeurs seraient plus à même d’estimer leur charge en fonction des besoins et le manager, lui, se contenterait d’agréger ces infos, prendre la marge nécessaire et ainsi avoir une estimation plus proche du terrain…
• L’estimation est faite à partir de mauvaises bases : nombre de lignes de code (comment on peut savoir à l’avance le nombre de lignes de code qui vont constituer le logiciel ?!), rapprochement avec les expériences passées (”mon dernier projet avait mis 6 mois, là ça devrait prendre un peu plus, allez on va dire 8 !”)

Effectivement, si l’on prévoit 1 an pour un projet et qu’on en met 2, on peut se dire qu’on a échoué. On peut aussi se dire que 1 an était peut-être sous-estimé et que même si on a dépassé, on a un projet qui répond au besoin (si c’est effectivement le cas, sinon oui c’est probablement un échec).

La réutilisation

Bien souvent, on nous demande de développer des logiciels dont le code puisse être réutilisable (modules, frameworks). Ça part d’un bon sentiment, limiter le nombre de fois où l’on va développer la même chose. Mais est-on bien sûr qu’il s’agisse effectivement de la même chose. D’après lui et certaines études qu’il mentionne, pour être sûr que du code est vraiment réutilisable, il faut qu’il soit réutilisé avec succès dans 3 applications différentes.

Cycle de vie du logiciel

Concernant le cycle de vie, quelques faits bien connus, mais pourtant toujours aussi mal appréhendés:

Spécification

Notamment, il rappelle que la principale cause des projets en retard est l’instabilité des spécifications et que les erreurs de spécifications (les “features” comme dirait un certain Tom ) sont les plus chères et compliquées à corriger.
Ça me paraît évident mais on perpétue la tradition des dossiers de spécification (de plusieurs centaines de pages, voire de plusieurs tomes), rédigés en année/homme avant de commencer à concevoir et développer…
Je doute que cela change si on n’ajoute pas une pointe d’agilité dans notre manière de recueillir et retranscrire le besoin.

Revues de code et rétrospectives

Je vous passe le design, le code… pour vous parler de revue de code. C’est une pratique assez rare et pourtant selon l’auteur, elle permettrait de supprimer jusqu’à 90 % des erreurs avant même les tests. Les tests restent donc essentiels.

Il mentionne également les rétrospectives comme étant importante pour le bon fonctionnement de l’équipe, mais elles aussi sont trop rarement pratiquées. Les rétrospectives permettent de faire le point à l’issu d’un projet (ou d’une phase) sur ce qui a marché, ce qui a moins marché et comment s’améliorer. Cela permet à l’équipe d’apprendre de ses erreurs pour éviter de les refaire.

Qualité

J’aime beaucoup ce qu’il dit sur le sujet : “La qualité, ce n’est pas la satisfaction de l’utilisateur, ce n’est pas non plus la concordance avec les besoins, ni même le respect des délais et du budget”. Ce sont peut-être des critères de réussite d’un projet, mais en aucun cas des critères de sa qualité.

Et il mentionne les 7 critères suivants:

• La portabilité (fonctionne sur des environnements différents)
• La fiabilité du logiciel (pas de plantage)
• L’efficacité (les performances)
• L’usabilité (ergonomie, productivité des utilisateurs…)
• La testabilité (avoir une application qui soit testable, automatiquement si possible)
• La compréhensibilité (compréhension du code à sa relecture)
• La modifiabilité (le code est facilement modifiable)

Effectivement, ça me va mieux comme “définition” de la qualité.

Autres sujets

Il aborde de nombreux autres sujets tout aussi intéressants : la maintenance, les tests, la formation des développeurs, les outils… mais je vous laisse le soin de vous faire votre avis en lisant ce livre.

Conclusion

Je vais passer pour un contestataire mais je ne saurai que trop conseiller à tous les chefs de projets et managers de lire ce livre : l’auteur retrace toutes les croyances, les erreurs… qu’il a rencontrées au long de sa carrière (40 ans) dans l’ingénierie logicielle. Il n’apporte pas de réelle solution mais le simple fait de prendre conscience de ses erreurs peut parfois aider à s’améliorer.

Bien entendu, les développeurs et tous les acteurs du développement logiciel sont invités à le lire aussi, la lecture ne pourra qu’être bénéfique.

Arrêtons de reproduire encore et toujours les mêmes erreurs !