Un autre classique, un thème du développement logiciel qui devient de plus en plus important, la gestion du développement logiciel moderne n’est pas un processus simple…
Users Can’t Know Their Requirements Early
IWBNI (It Would Be Nice If) users could know their requirements early. For small projects (a couple of people, maybe a couple of months) it might even be possible to fully know and define the requirements at the beginning of the project. But I contend it’s not possible for users to fully know their requirements early for any substantive effort.
The nature of software — ephemeral and malleable and not well understood by users until the users see the artifacts — guarantees that as soon as a user sees the system, the user will see the next step in the evolution of the requirements.
C’est un excellent article, parce que c’est quelque chose avec lequel je me bat depuis plusieurs années… à date, ma méthodologie est de définir les grandes lignes, suggérer des pistes possibles, documenter on the go (wiki ou notes libres) et de développer par phase, par itération.
Ça fonctionne assez bien, mais pour les systèmes complexes, ça prend beaucoup d’investissement auprès des clients, ça monte la charge de projet/analyse à près de 40% du projet. Mais ça fait des clients très heureux des résultats… n’est-ce pas là l’objectif? Il faut que le développement s’ajuste à l’utilisateur et pas l’inverse, c’est là une des quêtes du Graal de cette industrie.
J’ajouterais que c’est pourquoi le choix d’un framework (comme Ruby on Rails) qui est développé sur cette philosophie devient alors un avantage énorme comparativement à des plate-formes plus lourdes en processus, comme .NET ou J2EE…
