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?
Réponses:
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.
la source
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 similairesThe 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.
la source
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.
la source
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.
la source