Cette news a le mérite de poser le problème et j'en remercie son auteur.
Premièrement, la problématique est différente selon qu'on développe un logiciel ou un progiciel car les contraintes sont bien différentes.
Or, la carte de visite du logiciel libre et/ou de Linux, ce sont des projets logiciels (Apache, mySql (!), Mozilla, etc...). La pire des erreurs serait de les comparer le cycle de développement des logiciels avec celui des progiciels. On ne développe pas une appli bancaire spécifique comme on développe un navigateur. Le progiciel est développé avec des ressources déterminées selon le budget, il est à usage unique, spécifique, pas forcément évolutif, et le déploiement se fait en lien direct avec l'équipe de réalisation. Pour le logiciel c'est tout l'inverse.
Deuxièmement, parlant de logiciel, le milieu du libre fait peut-etre les frais d'une liberté, celle de ne pas avoir de contrainte subie. Si Mozilla répond à IE en terme de fiabilité, respect des standards, rapidité, ouverture, etc., c'est par la seule motivation de leurs auteurs et non pas parce qu'un objectif commercial a été défini. Du coup, un cycle de développement n'est mis en place que si les développeurs le veulent bien. C'est une erreur.
Personne ne doit faire l'économie du choix d'un cycle de développement, quel qu'il soit (XP, RAD, V, W, cascade, étoile, spirale (ça c'était le passage "j'en connais des choses")).
La question n'est pas de savoir s'il faut en choisir un, mais lequel choisir. Et il est vrai que le seul choix d'un bug tracker n'est pas suffisant.
Au passage, l'XP (qui ne s'applique qu'aux progiciels) est un remâchage marketing de méthodes éprouvées. Son seul mérite est de faire oublier le RAD (Rapid Application Développement) qui foutaient dans la mouise les développeurs dont les CdP pensaient que c'était le moyen de développer des applications plus rapidement (alors que ça incite seulement à se donner les moyen de définir rapidement les spécifications en lien avec le client et donc de perdre un minimum de temps, nuance)
# Choisir un cycle de dev
Posté par Franck Hanot . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 5.
Cette news a le mérite de poser le problème et j'en remercie son auteur.
Premièrement, la problématique est différente selon qu'on développe un logiciel ou un progiciel car les contraintes sont bien différentes.
Or, la carte de visite du logiciel libre et/ou de Linux, ce sont des projets logiciels (Apache, mySql (!), Mozilla, etc...). La pire des erreurs serait de les comparer le cycle de développement des logiciels avec celui des progiciels. On ne développe pas une appli bancaire spécifique comme on développe un navigateur. Le progiciel est développé avec des ressources déterminées selon le budget, il est à usage unique, spécifique, pas forcément évolutif, et le déploiement se fait en lien direct avec l'équipe de réalisation. Pour le logiciel c'est tout l'inverse.
Deuxièmement, parlant de logiciel, le milieu du libre fait peut-etre les frais d'une liberté, celle de ne pas avoir de contrainte subie. Si Mozilla répond à IE en terme de fiabilité, respect des standards, rapidité, ouverture, etc., c'est par la seule motivation de leurs auteurs et non pas parce qu'un objectif commercial a été défini. Du coup, un cycle de développement n'est mis en place que si les développeurs le veulent bien. C'est une erreur.
Personne ne doit faire l'économie du choix d'un cycle de développement, quel qu'il soit (XP, RAD, V, W, cascade, étoile, spirale (ça c'était le passage "j'en connais des choses")).
La question n'est pas de savoir s'il faut en choisir un, mais lequel choisir. Et il est vrai que le seul choix d'un bug tracker n'est pas suffisant.
Au passage, l'XP (qui ne s'applique qu'aux progiciels) est un remâchage marketing de méthodes éprouvées. Son seul mérite est de faire oublier le RAD (Rapid Application Développement) qui foutaient dans la mouise les développeurs dont les CdP pensaient que c'était le moyen de développer des applications plus rapidement (alors que ça incite seulement à se donner les moyen de définir rapidement les spécifications en lien avec le client et donc de perdre un minimum de temps, nuance)