Gestion des user stories pour un grand projet [fermé]

StackOverflow https://stackoverflow.com/questions/118064

Question

Nous commençons à peine un très gros projet comportant de nombreux sous-projets. nous n'utilisons actuellement aucun type de processus nommé, mais j'espère obtenir un processus agile / scrumlike par la porte arrière.

Le domaine sur lequel je me concentrerai le plus sera un bon arriéré pour l’ensemble du projet et, du moins dans ma tête, l’idée d’une itération où certaines choses sont extraites de l’arriéré, examinées plus en détail et développées un délai raisonnable.

Je me demande quelles techniques les gens utilisent pour décomposer les projets en éléments à ranger dans l'arriéré, et une fois que l'arriéré est créé, comment il est maintenu et ordonné. ainsi que la façon dont les relations entre les éléments sont maintenues (c’est-à-dire que cela doit être fait avant de pouvoir le faire, ou c’était une histoire maintenant il y en a cinq)

Je ne suis pas sûr de ce à quoi je m'attends de la réponse à cette question. Je pense que ce qui peut être le plus utile, c’est qu’il existe un projet open source qui conserve son arriéré en ligne d’une manière ou d’une autre afin que je puisse voir comment les autres le font.

Un autre élément qui pourrait me rapporter +1 est des exemples d'histoires d'utilisateurs réels issues de projets réels (l'histoire "un utilisateur peut se connecter") ne m'aide pas à visualiser les éléments de mon projet.

Merci.

Était-ce utile?

La solution

Je vous conseillerais de bien réfléchir avant d’adopter un outil, d’autant plus qu’il semble que votre processus risque d’être fluide au début, lorsque vous trouvez vos pieds. Mon sentiment est qu’un outil peut être plus susceptible de vous contraindre que de vous le permettre à ce stade, et vous ne verrez aucun substitut à un bon mur de cartes dans l'espace physique . Je vous conseillerais plutôt de concentrer vos efforts sur la tâche à accomplir et de saisir un outil lorsque vous sentez que vous en avez vraiment besoin. À ce stade, vous aurez probablement une idée claire de vos besoins.

J'ai dirigé plusieurs projets agiles à présent et nous n'avons jamais eu besoin d'un outil plus complexe qu'un tableur, et cela sur un projet dont le budget dépasse 1 million de livres. Nous constatons généralement qu’un tableau blanc et des fiches (une par histoire d’utilisateur) sont plus que suffisants.

Lorsque vous identifiez vos histoires, veillez à les exprimer toujours dans des termes qui ont du sens pour vos utilisateurs - certaines fonctionnalités (peut-être même minuscules). Ne vous laissez jamais glisser dans des histoires sur des détails techniques que vous ne pourriez pas montrer à un utilisateur.

La compétence lors de la planification des histoires est d’essayer de donner la priorité à ce que vous savez le moins en premier (planifiez ce que vous voulez apprendre plutôt que ce que vous voulez faire) tout en commençant par les histoires qui vous permettront de vous développer. les fonctionnalités principales de votre application, en utilisant des récits ultérieurs pour envelopper la fonctionnalité (et la complexité technique) autour d'eux.

Si vous êtes certain de pouvoir laisser quelque chose du casse-tête à plus tard, ne perdez pas autant de temps pour en entrer dans les détails - écrivez simplement une carte récit qui représente la grande conversation que vous devrez avoir plus tard. et passer à autre chose. Si vous souhaitez avoir une idée de ce qui vous attend, consultez une technique d’estimation à large bande de delphi appelée la planification du poker .

Les livres de Mike Cohn, en particulier les estimations et planification agiles , vous aideront à beaucoup à ce stade, et vous donner quelques techniques utiles pour travailler avec.

Bonne chance!

Autres conseils

Alors, voici quelques conseils: Nous utilisons RallyDev.
Nous avons créé une vue des packages dans lesquels nos exigences résident. Les histoires de grande taille sont qualifiées d’épopées et sont placées dans le carnet de commandes de la publication à laquelle elles sont destinées. Des histoires pour enfants sont ajoutées aux épopées. Nous avons jugé préférable de garder les récits très détaillés. Les histoires à grain grossier rendent difficile l’évaluation et l’exécution réalistes de l’histoire.

Donc en général:

  1. Organiser par la publication

  2. Garder itérations entre 2-4 semaines

  3. Propriétaires du produit et projet les gestionnaires ajoutent des histoires à la publication arriéré

  4. Les estimations de l'équipe de développement les histoires basées sur les tailles de T-shirt, points, etc ...
  5. Planification printanière réunions l'équipe de développement sélectionne le travailler pour l'itération de la libérer l'arriéré.

C’est ce que nous faisons depuis 4 mois et nous avons constaté que cela fonctionnait bien. Très important de garder la taille des histoires petites et granulaires.

N'oubliez pas les acronymes Invest et Smart pour évaluer les histoires d'utilisateurs. Une bonne histoire devrait être: I - Indépendant N - négociable V - Précieux E - Estimable S - Petit T - Testable

Intelligent:

S - Spécifique M - Mesurable A - réalisable R - Pertinent T - Boîte horaire

Je commencerais par dire Keep it Simple .. utilisez une feuille de calcul partagée avec suivi (et sauvegarde). Si vous rencontrez des problèmes de mise à l'échelle ou de synchronisation tels que le maintien de l'arriéré dans un état cohérent prend de plus en plus de temps, échangez. Cela validera et justifiera automatiquement les dépenses / coûts de reconversion.

J'ai lu des articles positifs sur Mingle de Thoughtworks .

voici ma réponse à une question similaire qui peut vous donner quelques idées

Aidez un BA! Gestion des user stories ...

Beaucoup de ces réponses ont été faites avec des suggestions sur les outils à utiliser. Cependant, la réalité est que votre processus sera bien plus important que les outils que vous utiliserez pour le mettre en œuvre. Éloignez-vous des outils qui tentent d’enfoncer une méthodologie dans votre gorge. Mais aussi, méfiez-vous de la simple mise en œuvre d'un ancien processus non agile à l'aide d'un nouvel outil. Voici quelques faits importants à prendre en compte lors de la détermination des outils de processus:

  1. Un processus incorrect instrumenté avec un outil logiciel entraînera une mauvaise implémentation d'outils logiciels.
  2. Les processus changeront en fonction du groupe que vous gérez. le Ce qui compte, c’est le peuple, pas le processus. Mettre en œuvre quelque chose ils peuvent travailler avec succès et votre projet sera couronné de succès.

Cela étant dit, voici quelques directives pour vous aider:

  • Commencez par une implémentation pure d'un processus documenté,
  • Faites de petites itérations,
  • Après chaque itération, discutez avec vos équipes et demandez-leur ce qu'elles changerait, implémenterait les changements qui font sens.

Pour les grandes organisations, si vous utilisez SCRUM, utilisez un mécanisme de stand-up en cascade. Les Scrum Master rencontrent leurs équipes. Ensuite, les Scrum Masters se rencontrent en stand-up du 6 au 9, avec un Super-Scrum-MAster chargé de rapporter les éléments de la mêlée Scum-Master au niveau supérieur ... et ainsi de suite.

Vous constaterez peut-être que des réunions hebdomadaires de super-scrum suffiront au plus haut niveau de votre hiérarchie.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top