Réalité: le client sait rarement exactement ce qu'il veut, a du mal à l'exprimer et celui qui réalise a du mal à le comprendre.
Oui, donc, il faut des réponses précises à des questions précises, c'est un peu ce qui est dit dans le journal.
Réalité: voir ci-dessus. Un cahier des charges n'est jamais exhaustif et les besoins évoluent dans le temps. De plus le client se focalise sir les livrables et ne perçoit pas certains aspects annexes mais nécessaires) à la réalisation.
Donc, tu livres le plus souvent possible, pour avoir un retour le plus souvent possible, ce qui pousse aux prototypages.
Merci Monsieur de la Palisse. Moins on en fait moins ça prend de temps.
Le client veut toujours papa/maman. Sauf quand il s'agit de payer. Classer les fonctionnalités permets de choisir l'ordre de priorité.
Réalité: les interfaces sont rarement définies a priori, elles emergent d'elles même lors de l'écriture du code et évoluent encore ensuite. Il est donc impossible d'écrire des tests avant.
C'est dangereux ça. Cela veut dire que tu n'as pas de stabilité. Ce qui implique beaucoup de code spaghetti et des grosses dépendances que tu veux justement cassées.
[^] # Re: Malheuresement...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 5.
Oui, donc, il faut des réponses précises à des questions précises, c'est un peu ce qui est dit dans le journal.
Donc, tu livres le plus souvent possible, pour avoir un retour le plus souvent possible, ce qui pousse aux prototypages.
Le client veut toujours papa/maman. Sauf quand il s'agit de payer. Classer les fonctionnalités permets de choisir l'ordre de priorité.
C'est dangereux ça. Cela veut dire que tu n'as pas de stabilité. Ce qui implique beaucoup de code spaghetti et des grosses dépendances que tu veux justement cassées.
"La première sécurité est la liberté"