cela part du principe qu'on sait exactement ce qu'il faut faire dès le début et qu'on a le temps pour le faire
Pas du tout: c'est justement quand on ne sait pas exactement ce qu'il faut faire qu'il faut réfléchir.
On sait ce qu'on veut à court terme, mais on est en général incapable de savoir ce qu'il faudra avoir dans 1 an ou dans 2 ans. Et dans ces conditions on n'anticipe pas sur la flexibilité à implémenter pour d'hypothétiques fonctionnalités qui pourraient arrivent dans quelques années.
Plus tu réfléchis en début de projet à toutes les problématiques, plus tu retardes la sortie et en particulier la sortie de la v1. Donc plutôt que retarder ta v1 pour "mieux prévoir ta v2, v3 et autre", tu sorts ta v1 au plus vite, et tu capitalise sur l'expérience de ta v1 pour définir ta v2. Et tu vas de proche en proche.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Pas évident
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 2.
On sait ce qu'on veut à court terme, mais on est en général incapable de savoir ce qu'il faudra avoir dans 1 an ou dans 2 ans. Et dans ces conditions on n'anticipe pas sur la flexibilité à implémenter pour d'hypothétiques fonctionnalités qui pourraient arrivent dans quelques années.
Plus tu réfléchis en début de projet à toutes les problématiques, plus tu retardes la sortie et en particulier la sortie de la v1. Donc plutôt que retarder ta v1 pour "mieux prévoir ta v2, v3 et autre", tu sorts ta v1 au plus vite, et tu capitalise sur l'expérience de ta v1 pour définir ta v2. Et tu vas de proche en proche.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo