Ta remarque sur les changements rapides des besoins est juste lorsqu'on développe un produit sur un marché ouvert. Les besoins des cibles commerciales peuvent changer du jour au lendemain pour diverses raisons (secteur du client très changeant, un compétiteur qui renverse le marché avec une nouvelle offre, que sais-je encore). Le besoin peut être d'autant plus changeant lorsqu'on travaille sur quelque chose de novateur. Dans ces cas, ça peut être bon et même nécessaire de se laisser de la flexibilité pour ne pas s'enfermer dans une solution qui sera déjà obsolète une fois arrivé à la fin du développement.
Dans le cas des SSII (mais je m'écarte du sujet du journal), on est dans un schéma plus classique. On a un client qui passe un appel d'offre. Le client est censé avoir un besoin concret et identifié (en partie au moins). Si on est choisi pour le projet, on est alors lié par un contrat qui devrait définir un cahier des charges précis. Toute modification du cahier des charges devrait faire l'objet d'un avenant au contrat. Si la modification demandée remet en cause l'architecture qui a été décidée et validée avec le client, c'est à lui de payer les pots cassés, d'où l'intérêt de définir correctement son besoin dès le début. Dans ces cas, il me semble qu'un processus de développement plus classiques et rigides devrait s'appliquer.
[^] # Re: Méthodes de conception
Posté par FreeFax . En réponse au journal L'homme orchestre, partie 1 : les casquettes. Évalué à 1.
Ta remarque sur les changements rapides des besoins est juste lorsqu'on développe un produit sur un marché ouvert. Les besoins des cibles commerciales peuvent changer du jour au lendemain pour diverses raisons (secteur du client très changeant, un compétiteur qui renverse le marché avec une nouvelle offre, que sais-je encore). Le besoin peut être d'autant plus changeant lorsqu'on travaille sur quelque chose de novateur. Dans ces cas, ça peut être bon et même nécessaire de se laisser de la flexibilité pour ne pas s'enfermer dans une solution qui sera déjà obsolète une fois arrivé à la fin du développement.
Dans le cas des SSII (mais je m'écarte du sujet du journal), on est dans un schéma plus classique. On a un client qui passe un appel d'offre. Le client est censé avoir un besoin concret et identifié (en partie au moins). Si on est choisi pour le projet, on est alors lié par un contrat qui devrait définir un cahier des charges précis. Toute modification du cahier des charges devrait faire l'objet d'un avenant au contrat. Si la modification demandée remet en cause l'architecture qui a été décidée et validée avec le client, c'est à lui de payer les pots cassés, d'où l'intérêt de définir correctement son besoin dès le début. Dans ces cas, il me semble qu'un processus de développement plus classiques et rigides devrait s'appliquer.