L"objet des methodologies de developpement est d'encadrer un projet, de pouvoir mieux le planifier, de deceler des problemes, de bien preparer toutes les etapes du developpement et de la vie des produits et aussi d'avoir la certif ISO 9001 (tracabilite des specs, des plans de tests, des resultats, evaluation du risque, ...)
Toutes ces choses sont necessaires en entreprise, mais beaucoup moins importantes pour un projet open source.
Une toute petite equipe de dev n'a pas besoin de conception formelle pour faire du logiciel. Si mplayer prend un mois de plus a sortir, c'est pas grave. Et si au dernier moment, l'auteur decide de ne pas mettre la fonctionnalite X ou Y, c'est pas grave. Et il peut prendre la decision en 1 minute, il n'a pas besoin de se justifier, planning a l'appui. Comme c'est lui qui fait a la fois la conception, le codage, les tests et le planning, il n'a pas besoin de specs ecrites formelles.
Sinon, d'un point de vue perso, je trouve UML et tous les autres machins completement inutil, tout au moins dans mon travail. Ca fait 5 ans que je suis dans le logiciel et je n'ai jamais eu besoin d'UML. J'arrive encore a faire ma conception sur un bout de papier et comme mes logiciels font un peu moins de 50 000 lignes, il n'y a pas besoin de passer du temps a formaliser la conception. En plus, je reste persuade que le code reste quand meme un important facteur de pilotage d'un projet de dev et que cet aspect est occulte dans des methodlogies UML.
Je prefere netteemnt les methodes agiles comme XP et je regrette que le monde de l'open source n'en utilise pas plus, notamment en ce qui conerne les tests unitaires.
[^] # Re: Méthodes de conception, processus de développement et Open Source
Posté par Philippe F (site web personnel) . En réponse au journal Conception et OpenSource. Évalué à 2.
L"objet des methodologies de developpement est d'encadrer un projet, de pouvoir mieux le planifier, de deceler des problemes, de bien preparer toutes les etapes du developpement et de la vie des produits et aussi d'avoir la certif ISO 9001 (tracabilite des specs, des plans de tests, des resultats, evaluation du risque, ...)
Toutes ces choses sont necessaires en entreprise, mais beaucoup moins importantes pour un projet open source.
Une toute petite equipe de dev n'a pas besoin de conception formelle pour faire du logiciel. Si mplayer prend un mois de plus a sortir, c'est pas grave. Et si au dernier moment, l'auteur decide de ne pas mettre la fonctionnalite X ou Y, c'est pas grave. Et il peut prendre la decision en 1 minute, il n'a pas besoin de se justifier, planning a l'appui. Comme c'est lui qui fait a la fois la conception, le codage, les tests et le planning, il n'a pas besoin de specs ecrites formelles.
Sinon, d'un point de vue perso, je trouve UML et tous les autres machins completement inutil, tout au moins dans mon travail. Ca fait 5 ans que je suis dans le logiciel et je n'ai jamais eu besoin d'UML. J'arrive encore a faire ma conception sur un bout de papier et comme mes logiciels font un peu moins de 50 000 lignes, il n'y a pas besoin de passer du temps a formaliser la conception. En plus, je reste persuade que le code reste quand meme un important facteur de pilotage d'un projet de dev et que cet aspect est occulte dans des methodlogies UML.
Je prefere netteemnt les methodes agiles comme XP et je regrette que le monde de l'open source n'en utilise pas plus, notamment en ce qui conerne les tests unitaires.