Comment convaincre mon équipe qu'une spécification des exigences n'est pas nécessaire si nous adoptons des user stories?

9

Nous prévoyons d'adopter des user-stories pour capturer «l'intention» des parties prenantes de manière légère plutôt qu'un SRS lourd (spécifications des exigences logicielles). Cependant, il semble que bien qu'ils comprennent la valeur des histoires, il y a toujours un désir de `` convertir '' les histoires en un langage de type SRS avec tous les attributs, priorités, entrées, sorties, source, destination, etc.

Les histoires d'utilisateurs «éliminent» le besoin d'un SRS formel comme un artefact pour commencer, alors quel est l'intérêt d'avoir un SRS? Comment devrais-je convaincre mon équipe (qui sont tous des gens CS très qualifiés d'ailleurs - à la fois par l'éducation et la pratique) que le SRS serait `` éliminé '' si nous adoptions des user-stories pour capturer les exigences fonctionnelles du système? (Les NFR, etc. peuvent également être capturés, mais ce n'est pas le but de la question).

Voici donc mon argument `` workflow '': capturez les exigences initiales sous forme d'histoires utilisateur et élaborez-les ensuite dans des cas d'utilisation (qui doivent être documentés à un faible niveau, c'est-à-dire décrire les interactions avec les prototypes / maquettes de l'interface utilisateur et sont un article livrable déploiement). Ainsi, passer des user-stories aux cas d'utilisation plutôt que des user-stories au SRS aux use-cases.

Comment saisissez-vous actuellement toutes les user-stories sur votre lieu de travail (le cas échéant) et comment proposez-vous que je «plaide» en faveur de l'absence de SRS en présence de user-stories?

— Doctorat
source

cela n'arrivera pas en une journée,

— adoptez

Si vous travaillez pour un fournisseur de services logiciels, le SRS peut ne pas être nécessaire pour faire l'implémentation mais pour faire le "jeu de blâme" lorsque le client veut réduire le coût ou les arguments du fournisseur de services selon lesquels plus d'argent est nécessaire ou les deux vont devant les tribunaux.

— k3b

14

Pas de bébé. Continuez à écrire le SRS pendant un certain temps. Ensuite, convoquez une réunion et discutez de leur utilité. Quelqu'un les lit-il encore? Le temps passé sur eux est-il justifié? Existe-t-il une autre étape intermédiaire qui serait plus légère?

Vous ne savez jamais, vous pourriez trouver que vous vous trompez. Souvenez-vous du manifeste Agile, nous trouvons plus de valeur dans "Logiciel de travail sur une documentation complète", mais il y a toujours de la valeur dans ce dernier.

Je suppose cependant que vous découvrirez rapidement que le désir de continuer à écrire des documents volumineux disparaît quand ils voient à quel point les cas d'utilisation et les histoires d'utilisateurs sont étroitement liés.

— pdr
source

2

@PhD: Vous avez raison. C'est presque primal. Et c'est pourquoi vous ne gagnerez pas cette bataille avec une logique quelconque, uniquement avec des preuves. Pas de bébé.

— pdr

2

J'ai travaillé pour des managers qui ont confronté le changement à de petits pas, c'était leur mot de code pour "ne faire qu'assez pour échouer donc je peux dire que j'avais raison" ce n'est pas un chemin vers le succès car cela montre un manque fondamental de compréhension de la nouvelle méthodologie et un manque d'adhésion complète de la part de la direction, ce qui est crucial pour réussir le changement. Cela semble bien en théorie, mais dans la pratique, c'est une excuse pour ne pas changer et revendiquer la victoire que la nouvelle façon ne fonctionne pas et l'ancienne. Ainsi, le SRS a été renforcé et les histoires seront étiquetées comme du travail supplémentaire et vous serez de retour là où vous étiez.

2

Mon expérience n'est pas singulière, c'est au cours de mes 22 ans et plus dans l'industrie, dont la plupart était consultant. J'ai donc travaillé avec beaucoup plus de gestionnaires et de décideurs que la plupart des gens dans le même temps. Mon point est que cette approche par étapes est une approche d'échec, seul l'engagement de la haute direction envers le changement et la philosophie derrière le changement vont conduire à une mise en œuvre réussie. Si ses collègues ne sont pas convaincus, les laisser continuer à faire ce qu'ils veulent ne les convaincre, il se nourrit tout le nous avons encore besoin l'ancienne et la nouvelle façon est une perte de temps argument.

1

@JarrodRoberson Je veux juste ajouter que mes expériences reflètent plus fidèlement la vôtre. Il existe deux types de personnes, et donc deux types de managers, les conservateurs et les preneurs de risques. Les conservateurs sont naturellement opposés au changement et au risque. Quand ils trouvent un modèle qui fonctionne, même mal, ils s'y tiennent. Lorsque le changement leur est imposé ou forcé, ils le sabotent inconsciemment en essayant de faire des pas de bébé . C'est pourquoi la seule fois où j'ai jamais vu un véritable travail d'adoption Agile est lorsqu'il est dirigé par des preneurs de risques.

— maple_shaft

2

@maple_shaft: L'astuce consiste à continuer d'avancer. Si un changement incrémentiel ne fonctionne pas, ne faites pas nécessairement le même pas en arrière, réfléchissez pourquoi il n'a pas fonctionné ... comme peut-être que vous passez encore trop de temps à écrire un document désormais inutile. Maintenant, je concède qu'il faut un bon manager pour penser de cette façon, et que la plupart retourneront dans leur zone de confort. Mais, par exactement la même logique, cela ne signifie pas que la seule autre option est un changement radical. Un mauvais manager va tout gâcher.

— pdr

6

Les épopées sont des espaces réservés

Dans à peu près n'importe quelle méthodologie Agile, le concept d'Epics serait autant que nécessaire pour une spécification d'exigences, les espaces réservés sont ce dont vous avez besoin à ce niveau. Ces entrées seront hiérarchisées en permanence, tout détail supplémentaire est un effort inutile si l'exigence devient peu prioritaire pendant longtemps, ou n'est même jamais mise en œuvre. Le documenter et gérer la documentation qui l'entoure serait une perte de temps totale. YAGNI s'étend aux activités d'exigences ainsi qu'aux activités de codage.

Les outils sont votre ami!

Si vous utilisez un outil approprié pour collecter et gérer les user stories, vous pouvez alors générer la spécification des exigences. Une spécification d'exigences est de toute façon un document d' artefact temporel , ce n'est pas un document vivant, c'est un instantané des exigences dans le temps. Et n'est jamais en phase avec la réalité.

Générer automatiquement des artefacts

Les user stories qui peuvent être exportées à partir d'un outil approprié sont bien plus précieuses que n'importe quel document d'artefact statique à tout moment. Personnellement, je préfère Pivotal Tracker pour suivre les User Stories, j'ai même écrit une suite de plugins MoinMoin en Python pour publier toutes les différentes Stories et leurs états dans le Wiki (qui contenait des notes de développeur détaillées et autres sur les histoires), les données en direct sont toujours mieux que les données statiques.

Le Wiki est devenu un document en direct de tous les magasins / exigences et de leur état d'achèvement et de priorité avec des détails et des commentaires et d'autres métadonnées.

Bien mieux qu'un énorme document Word dans Sharepoint qui est simplement envoyé par e-mail constamment et jamais mis à jour, garantissant que tout le monde a une version différente et n'est pas synchronisé avec tout le monde!

Les user stories sont plus riches que les cas d'utilisation

L'histoire d'utilisation est beaucoup plus valable qu'un cas d'utilisation, car ils disent POURQUOI .

Le format User Story: As a [ROLE] I [ACTIVITY] so that [WHY]est beaucoup plus expressif que les cas d'utilisation similaires The System [shall/shall not/may/must] perform [action](où l'action est un organigramme).

Avec une User Story, vous avez QUI veut faire quelque chose, vous avez CE QU'ils veulent faire (ce qui peut pointer vers un diagramme / document plus détaillé pour des tâches complexes) et vous avez la partie la plus importante POURQUOI ils veulent faire cette activité.

Si vous avez le premier, le second est complètement redondant, et juste du bruit au mieux. Une spécification d'exigences formelle traditionnelle issue d'une méthodologie Waterfall n'a pas sa place dans un environnement Agile.

À la fin

Si votre direction n'est pas engagée à changer, vous n'allez pas réussir avec une nouvelle méthodologie. J'ai travaillé pour une entreprise de plus de 100 milliards de dollars par an, ils n'ont pas fait de petits pas pour passer à Agile / SCRUM, ils ont juste dit, toute l'entreprise se dirige vers cela, voici la nouvelle façon de faire les choses, voici lorsque votre formation sur la nouvelle façon va commencer, voici les nouveaux outils que nous allons utiliser, voici la date à laquelle nous commençons à faire les choses de cette façon. Cela a fonctionné pour eux en moins d'un an. J'ai travaillé sur sa mise en œuvre dans les petites entreprises avec le même succès.

Engagement

Les implémentations de baby steps , quel que soit le changement, sont une recette pour l'échec. C'est un mot de code pour la direction qu'ils ne sont pas d'accord et qui vous mettent passivement en place pour l'échec. Ils disent que je n'y crois pas assez pour m'y engager, donc je vous laisse faire juste assez pour échouer / ne pas réussir , de cette façon, ils peuvent dire qu'ils ont essayé et que cela n'a pas fonctionné et qu'ils ont géré le travail très bien tout au long. Un engagement partiel conduit finalement à l'échec.

Dans votre cas, ils ne croient probablement pas discrètement aux User Stories, et après un certain temps, ils commenceront à affirmer que ce sont les User Stories qui sont inutiles et non le SRS, et pousseront à arrêter d'écrire les User Stories , qui vous mènera simplement en arrière et non en avant.

— kmote
source

vous serez assez surpris, les user stories SONT gérées par un outil qui peut (et le fait) l'exporter en tant qu'exigences. Cependant, le souci semble être de «traduire» les user-stories dans le langage SRS de «le système doit…» etc. et de ne PAS le laisser comme user stories.

— PhD

1

Eh bien, si le raccrochage est la terminologie «doit / doit / peut», vous crachez probablement dans le vent avec ces gens. Les User Stories indiquent QUI / QUOI et surtout POURQUOI quelque chose doit être fait, beaucoup plus utile que ces cas d'utilisation statiques, qui sont plus faux que corrects dans la plupart des cas.

2

-1: Je ne suis pas du tout en désaccord avec la plupart des réponses, mais en déclarant que et SRS est "Une spécification des exigences est un document temporel artefact de toute façon, ce n'est pas un document vivant", est si erronée qu'elle montre un manque inquiétant de compréhension de ce que un SRS est destiné à, ou comment il est utilisé lorsqu'il est fait correctement - généralement uniquement dans les éditeurs de modèles de cascade existants aujourd'hui.

— mattnz

5

Un SRS est un document mort dès sa publication. Je les écris depuis 1990. Ils sont comme un plan de guerre, ils ne survivent jamais au premier contact. Et ils ne suivent jamais l'implémentation réelle, à moins que vous n'ayez une équipe dédiée d'écrivains qui édite constamment la chose et même alors, c'est faux en raison de la déconnexion du changement constant et des développeurs qui sont toujours en avance sur le document, et ne le font pas toujours dire au propriétaire du document ce qui se passe. Les entreprises passent des milliers d'heures à écrire des trucs comme ça, et les documents sont mis sur une étagère et pourrissent pendant le développement.

3

@JarrodRoberson +1 pour vous. En effet, mattnz a également raison de dire que le SRS est censé être un document évolutif, mais vous prenez ensuite quelques problèmes de production critiques que les demandes des clients soient modifiées, tout en travaillant sur une ou plusieurs versions ramifiées de la base de code, des exigences mal interprétées par les analystes commerciaux, les développeurs et le contrôle qualité ... ce qui vous reste est un document qui n'est pas un véritable reflet du système en ce moment, mais pas non plus un véritable reflet des besoins des utilisateurs. Les user stories sont vraiment adoptées par des entreprises plus soucieuses du client que du système.

— maple_shaft

0

J'essaierais d'utiliser l'humour.

Commencez par le http://www.halfarsedagilemanifesto.org/

Parlez-en pendant un certain temps ( détournement )
et parlez de ce que signifient réellement les conflits ( discussion ouverte ),
puis après un certain temps, tournez-vous vers votre organisation ( pivot )
et examinez le SRS et si cela a du sens avec la nouvelle configuration du projet .

Je conclurais ensuite (ou peut-être lors d'une autre réunion) par une discussion sur le changement d'approche concernant le SRS et je verrais si vous avez plus de consensus.

À la fin de la journée, vous êtes également limité par le budget et le service aux gens d'affaires, il peut donc y avoir un moment où vous êtes un peu plus ferme dans ce qui est utilisé, mais cela dépend vraiment de l'industrie, de la taille de l'entreprise, des facteurs organisationnels et de nombreux autres d'autres facteurs.

— Michael Durrant
source

5

Soyez très prudent. Ne fonctionnera que si vos collègues sont très en sécurité et que vous entretenez de bonnes relations avec eux. Beaucoup de gens s'énervent si vous utilisez l'humour pour leur dire qu'ils ont tort et sont liés.

— MarkJ

-1

Convaincre mgmt de s'éloigner du SRS et de commencer à utiliser les user stories est essentiellement la même chose que convaincre mgmt d'adopter Agile. Il existe des statistiques convaincantes sur les avantages en termes de productivité d'Agile. Un exemple est la présentation que VersionOne a faite lors d'une conférence en 2013. Montrez ces données de l'industrie et si elles sont du type à l'écoute, vous avez une chance.

— Joe
source

1

Désolé, ce n'est pas vraiment une réponse. Vous dites «afficher les statistiques» et ne fournissez même pas de liens.

— Jan Doggen

et écrivez des mots et des phrases complètes ...

— jwenting