principes architecturaux comme des histoires d'utilisateurs « non fonctionnels » [fermé]

Question

Je suis sur le point de lancer un projet pilote dans notre entreprise à introduire des pratiques agiles, y compris l'utilisation de témoignages d'utilisateurs. Après avoir lu deux livres par Mike Cohn, Agile Estimating et de la planification en particulier et Histoires d'utilisateurs appliquée, j'ai maintenant une idée plus claire de la façon de procéder. J'ai confiance en affiner nos techniques ainsi que la pratique.

Cependant, il y a une chose qui ne me convainc pas. Dans ce blog Mike Cohn définit un type spécifique d'histoires d'utilisateur , qu'il appelait des contraintes qui peuvent être utilisées pour définir les soi-disant exigences non fonctionnelles. Personnellement, je ne aime pas le mot contrainte et même l'utilisation du modèle classique « En tant que ..., je veux ..., de sorte que ... ».

Au contraire, je vais essayer de faire au client d'écrire, toujours sur les cartes, peut-être avec le modèle ci-dessus, ceux que Nick Rozanski et Eoin Woods ont appelé, dans leur livre fantastique Systèmes logiciels d'architecture , principes architecturaux :

  

« Un principe architectural est une déclaration de la croyance, l'approche ou l'intention qui guide la définition d'une architecture ».

(ils divisent également ces principes dans principes commerciaux et principes technologiques , une différenciation Je pense que nous ne devrions pas en charge.)

Ce que je voudrais faire avec ces principes cartes est de les mettre à côté de nos cartes de backlog bord afin de les avoir toujours présent lors de la définition des histoires d'utilisateurs et les activités de planification. Je voudrais aussi encourager les clients et les développeurs à les ramasser et de les mettre à côté du plateau d'itération chaque fois qu'ils pensent qu'une carte pourrait être utile comme rappel pour l'équipe.

Avez-vous déjà essayé une approche similaire? Avez-vous découragez pour une raison quelconque? Avez-vous des suggestions à ce sujet?

Answer 1

Avez-vous déjà essayé une approche similaire? Je ne l'ai pas essayé quelque chose exactement similaire, mais quand j'étais Scrum Master de mon équipe, nous avons eu un projet de grande ligne directrice architecturale et la vision (qui toutes les équipes faisaient partie de), que nous nous rappelle, au cours des différentes inspectent et à s'y adapter des points d'un sprint et aussi le projet Scrum, comme lors Rétrospectives, réunions Sprint planification et même des réunions quotidiennes Scrum. Voici quelques façons que nous avons utilisé pour nous rappeler étaient en ajoutant des tâches Critères qui Done inclus un principe de suivre les directives architecturales, et il pourrait également être ajouté comme une petite note dans Retards. Dans ma suggestion ci-dessous je l'ai mentionné comment cela a été examiné d'un niveau très élevé.

Avez-vous découragez pour une raison quelconque? Non pas du tout. Je dis votre suggestion est bonne et vous devriez l'essayer pour une réunion de planification. Et comme suggéré par Ken Schwaber et Jeff Sutherland dans leur Guide Scrum, vous devriez inspecter et adapter pendant les 3 points dans un sprint - « Il y a trois points pour l'inspection et l'adaptation à Scrum La réunion quotidienne Scrum est utilisé pour inspecter les progrès vers la. Sprint but, et de faire des adaptations qui permettent d'optimiser la valeur du jour de travail suivant. en outre, les réunions d'examen Sprint et la planification sont utilisés pour inspecter les progrès vers l'objectif de sortie et de faire des adaptations qui permettent d'optimiser la valeur de la prochaine Sprint. Enfin, Sprint rétrospectif permet de passer en revue le passé Sprint et déterminer quelles adaptations feront le prochain Sprint plus productif, la réalisation et agréable. "

Avez-vous des suggestions à ce sujet? Est-il sûr pour moi de penser que ce projet « agile » dans votre entreprise est juste de commencer et vous n'avez pas un ensemble de vision de projet solide encore? Si oui, je vous suggère organiser un atelier de planification de projet de diffusion à grande échelle de 2 semaines. Le but de cet atelier serait obtenir toutes les parties prenantes, OREN, chefs de projet et SMs dans un endroit unique et développer un Super histoire utilisateur et Vision, et le reste des Retards décomposées du super-utilisateur Story.The super User Story serait la vision de haut niveau de l'objectif du projet. Si vous avez déjà fait cela, alors s'il vous plaît ne pas tenir compte de cette suggestion, mais mon point de avoir soulevé cette question est que la vision de haut niveau ou une histoire super-utilisateur pourraient / devraient avoir une partie qui mentionne suivant l'ensemble principe architectural dans votre entreprise.

Les avantages de ce? Il obtient l'acteur impliqué dans l'aspect architectural et technique du droit produit de la Super User Story qui aide à créer une bonne compréhension de la vision entre l'entreprise et le plan technique, et on ne peut pas vivre sans l'autre.

Je peut avoir volontairement tenté d'étendre la réponse au-delà de la portée des questions afin que je puisse obtenir des commentaires sur mes idées.

Merci, Sid.

Answer 2

Je le fais dans la façon dont vous avez décrit. J'ai des contraintes définies sur les cartes (autre couleur). Les contraintes ne sont pas écrites sous forme de récit de l'utilisateur, mais comme une phrase simple comme:

• système soutiendra l'utilisation maximale de 30 utilisateurs.
• Les importations doivent exécuter tous les jours.
• Tous les filtres et les résultats de la recherche doit être sur la même page.

Si le client a des exigences particulières qui ne sont pas directement histoire unique de l'utilisateur, mais a un effet plus large que je les écris comme des contraintes. Ces contraintes ne sont pas estimées et ne font pas partie du carnet de produit. Nous les utilisons pour rappeler certaines exigences de mise en œuvre des histoires d'utilisateur réel.

Answer 3

Ce a fait l'objet d'une scie parler I en Janvier de cette année à l'usine d'architecte. Je dépisté vers le bas. Il était de Lee Ingram « Business Driven Architecture: Un exemple à partir d'un démarrage en cours ». Je ne peux pas trouver des diapositives, mais il a parlé de l'idée de principes généraux qui guident la façon dont les exigences doivent être respectées.

Il avait des choses comme multi-location et marquage blanc. Avec un service Web multi-locataire, vous devez planifier dès le début de la ségrégation / isolement des utilisateurs. De même, si vous voulez être en mesure de marque blanche de votre service, alors beaucoup plus de choses doivent être configurable (style, étiquettes, etc.). Les deux effets presque chaque histoire.

Answer 4

Je recommande fortement Jeff présentation de Patton sur la cartographie de l'histoire de l'utilisateur .

Il ne clarifie que la composition de exactement ce que les histoires de but servent (ou tout ce que vous souhaitez les appeler), ainsi que la façon d'établir des relations ou dépendances entre les histoires et la façon de traiter avec eux.

Answer 5

Cette idée générale des « principes » (ou contraintes) semble être un bon. Je l'ai vu ce qui se passe quand les choses qui devraient vraiment être dans cette classe - par exemple « système doit atteindre une certaine spécifique, le niveau de performance quantifiés » - juste est jeté dans l'arriéré et perdu parmi toutes les autres histoires « feature »: les inquiétudes de Noone sur la performance (parce que «c'est OK ... il y a une histoire pour que quelque part ») et puis quand quelqu'un ne finit par ramasser (curieusement, ces choses se laissaient toujours à la dernière, en dépit de la forte valeur au client) ils se trouvent avec un tâche impossible pour les quelques jours une histoire est censée prendre, et avec un peu rearchitecting sérieux probablement que vraiment réalisable du système qui aurait dû être fait beaucoup plus tôt et a maintenant un coût de rééquipement massif.