Comment prouver aux collègues que les cas d'utilisation sont importants ?

Question

... et comment prouver à la direction que les cas d'utilisation peuvent être informels et rester utiles ?

Salut les amis,

Je suis arrivé au milieu d'un projet et j'ai découvert qu'il n'y avait pas de cas d'utilisation, d'histoires d'utilisateurs, d'exigences, ni rien de semblable à une spécification. Comme les délais sont courts, l'équipe de développement actuelle ne veut pas passer de temps sur de telles choses. J'ai voulu me joindre à ce projet, mais en creusant davantage, j'ai découvert que le développement actuel ajoute des fonctionnalités en considérant uniquement leur "effet waouh" et choisit ce qu'il faut ajouter en utilisant simplement la facilité que la technologie sous-jacente fournit. J'ai été surpris de voir comment ils ont réussi à aller aussi loin (plus de 4 mois) sans exigences, mais c'est ce que nous avons maintenant. Je pense que la voie qu'ils ont choisie est la plus sûre pour tuer le produit qui a une bonne valeur marketing.

Ai-je raison, et que feriez-vous dans des circonstances similaires pour prouver à l'équipe de développement/à la direction de faire des cas d'utilisation/exigences avant d'aller de l'avant ? Merci d'avance, kh.

P.S. Deux exemplaires du livre de Cockburn sont sur l'étagère...

Answer 1

Montrez l'exemple en vous concentrant sur les extensions et les exceptions. En d'autres termes, mettez l'accent sur les scénarios d'échec, car tout le monde sait comment le système peut être utilisé. devrait travail. La véritable valeur des cas d'utilisation écrits est d'identifier ce qui devrait se passer lorsque quelque chose se passe mauvais .

Cela dit, vous devrez peut-être vous passer de cas d'utilisation écrits. Et, pour l'environnement que vous décrivez, un gain important est tout une sorte de documentation des exigences. Les compilations d'écran et/ou le prototypage sont souvent plus faciles à introduire.