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

Vous devriez donner à vos collègues le discours sur les cas d'utilisation :D Dites-leur que les cas d'utilisation sont utiles en tant que tels :

• Une façon de capturer les processus d'affaires d'une manière qui est raisonnablement compréhensible par toutes les parties prenantes. Cela permet de combler le fossé entre les programmeurs, les clients et les utilisateurs.
• Unités de fonctionnalité traçables. Les cas d'utilisation sont formés (idéalement) dans la phase d'analyse, référencés dans la phase de conception et peuvent être utilisés comme sources de cas de test par la suite.
• Rapide et facile à rédiger et utile, même si informel.

Si vous avez besoin de plus de munitions, vous pourriez lire Cas d'utilisation - Hier, aujourd'hui et demain par nul autre qu'Ivar Jacobson.

Si vos collègues ne voient toujours pas l'utilité potentielle des cas d'utilisation en tant qu'outil d'analyse commerciale, ils ne peuvent probablement pas vous aider :P Vous devriez leur rappeler qu'ils développent des logiciels pour répondre aux besoins d'autres personnes. besoins et de résoudre leurs problèmes à long terme, et non pour les impressionner ostensiblement à court terme avec des gadgets mesquins. Un peu d'orientation et de spécification sont donc utiles. Même si les cas d'utilisation eux-mêmes ne s'avèrent pas très utiles, le simple fait de les proposer obligera vos collègues à réfléchir à l'objectif sous-jacent réel du logiciel.

Answer 2

Posez des questions, des deux côtés. Du côté du développement, demandez-leur s'ils sont certains que toutes les façons dont ils ont envisagé d'utiliser l'application sont toutes les façons dont les utilisateurs finaux voudront l'utiliser ; s'ils disent que oui, demandez des preuves. S'ils affirment que c'est le cas, demandez-leur des preuves. Demandez-leur également s'ils ont déjà utilisé un logiciel qui fait tout ce qu'ils veulent, mais qui finit quand même par être difficile à utiliser (ils l'auront fait). Ces questions feront germer l'idée que ce qui sera livré pourrait ne pas être ce que l'on souhaite, de part et d'autre ; utilisez cette graine d'idée, ensuite, pour ouvrir des discussions (pas de documents, pas au début) sur la façon dont le logiciel sera utilisé, et de quelle manière les différences éventuelles peuvent être résolues. Les documents de cas d'utilisation finiront bien par arriver.

Answer 3

Je suis chef de produit de profession, et ma première réaction à votre post est que les idées peuvent venir de n'importe où, et que si l'équipe de développement a de bonnes idées, elles doivent être intégrées au produit.

Cela dit, un produit ne peut pas développer une âme (un message simple) à travers une série d'idées déconnectées qui ne servent pas le but ultime : résoudre les besoins d'un utilisateur cible. Et, en fin de compte, cela revient à dire qu'il est préférable de consacrer du temps aux exigences et aux cas d'utilisation qui ont un sens pour le produit, tandis que le coût d'opportunité lié à l'absence d'une stratégie et d'un objectif final clairs entraînera un trop grand nombre de chefs et un message produit désuet.

Le meilleur moyen de faire passer ce message est d'impliquer d'autres parties prenantes et de faire en sorte que le développement fasse la démonstration de son travail. Au final, il y aura des désaccords et une approche plus formelle (moins cow-boy) aboutira à un produit plus raffiné et plus simple.

Answer 4

L'un des problèmes que vous mentionnez est le calendrier serré et les dérapages induits par les développeurs eux-mêmes. Expliquez-leur qu'en utilisant les cas d'utilisation, vous pouvez gagner du temps en abandonnant des fonctionnalités, qui finiront potentiellement sur la pile des "jamais utilisées". Avec les cas d'utilisation, vous pouvez découvrir quelles sont les fonctionnalités dont les clients ont besoin et pour lesquelles ils sont prêts à payer, et en supprimant les fonctionnalités sans importance de la portée, vous aurez le temps de les mettre en œuvre. Les cas d'utilisation, en plus de définir le champ d'application, permettent également d'identifier toutes les parties prenantes, ce qui peut vous aider à mieux vous concentrer lors de la définition du champ d'application et à éviter d'oublier des choses insignifiantes, qui ne sont pas si évidentes, mais qui sont indispensables pour que le produit soit utilisable. La troisième chose la plus importante à propos des cas d'utilisation est qu'ils vous permettent de commencer à réfléchir aux cas particuliers qui pourraient être importants pour le client avant le développement et vous pouvez donc découvrir avec le client quelle serait la solution idéale au lieu de laisser le codeur décider seul sous la pression du délai.

Answer 5

Montre-leur.

L'exemple n'est pas le meilleur moyen d'éduquer les gens, c'est le seul.