J'ai terminé la lecture de ce classique de la gestion de projets informatiques. Il est étonnant de constater jusqu'à quel point les problèmes essentiels du développement logiciel sont restés, à peu de choses près, les mêmes, depuis les tous débuts. Ce qu'il faut retenir : en développement logiciel, on n'augmente pas la productivité selon un ratio 1:1 en ajoutant un programmeur au projet. En particulier pour les gros projets. La manière la plus optimale de développer est une petite équipe. La petite équipe la plus efficace est la paire. Malheureusement, la plupart des gros projets logiciels sont trop grand et prendraient trop de temps à être réalisés par une si petite équipe. C'est pourquoi, pour bien planifier les plus gros projets informatiques, il faut tenir compte du facteur de la communication. L'auteur mentionne également que pour un maximum de cohérence et d'uniformité, (celui-ci appelle ça l'intégrité conceptuelle), il faut qu'une personne, un architecte ait une vision globale du projet, et possiblement plusieurs sous-architectes, coordonnés par un architecte-chef pour les plus gros projets. Un dernier point intéressant amené par l'auteur : la maintenance. Selon lui, toute réparation tend a détruire la structure et de ce fait, augmente l'entropie et le désordre du systeme. Meme les réparations les plus habiles ne font que retarder l'inévitable chute du logiciel dans un chaos irréparable, a partir duquel, il faut reconcevoir depuis le début. (traduction adlib).
En conclusion, ce livre est une sorte d'essai, réfléchissant et faisant le point sur la profession. Il m'a éclairé et montré une perspective très intéressante qui est, je crois, incontournable lorsqu'on s'intéresse au génie logiciel en 2011.
Aucun commentaire:
Publier un commentaire