Des exemples spécifiques de la documentation Agile?
En réponse à une question Documents pour un projet?, Chris Ballance a répondu que "Histoires d'utilisateur" et un "burndown chart" sont les deux plus utiles les types de documents de projet pour un développeur.
Ma question est, connaissez-vous un bon exemple[s], je peux voir (par exemple sur internet ou dans un livre), de ces sortes de documentation?
Si possible, je serais heureux de voir de nombreux exemples, y compris:
- Petit/court/exemples simples
- Gros/long/compliqué exemples
- Exemples célèbres
- De haute qualité, des exemples
Je ne trouve pas cette un sujet facile à Google pour: - je trouver de nombreux écrits sur le sujet, mais de moins en moins de manifestations montrer.
OriginalL'auteur ChrisW | 2009-02-10
Vous devez vous connecter pour publier un commentaire.
Un très bon point de départ pour que les livres sont concernées est Les User Stories Appliquée et Agile de l'Estimation et de Planification à la fois par Mike Cohn. Cela a d'excellents exemples et de bons points de départ pour quiconque de venir d'abord pour les méthodologies agiles.
Comme autant que ressources sur le web ils sont peu et loin entre. Probablement un bon endroit pour commencer serait à la recherche de ces mots clés sur Google Images, comme beaucoup de gens prennent des photos de leurs burndown charts et les articles de l'Utilisateur. Cela m'a beaucoup aidé lors du démarrage. Voici quelques échantillons: Burndown Charts, et Les User Stories
Veuillez noter, cependant, tandis qu'un burndown chart est un simple rapport que vous exécutez sur votre histoire de points dans une itération, les User stories sont plus complexes que cela et ne nécessitent un peu de lecture pour envelopper votre tête autour de. Démarrer avec les User Stories Appliquée livre.
Espère que ça aide!
En fait je travail sur une équipe agile et bien sûr, nous utilisons des outils de contrôle à distance, je pensais que vous parliez d'un aspect de l'apprentissage agile. Pour les outils virtuels, vous avez des options telles que Acunote, TargetProcess, Unfuddle. Ces outils sont utiles pour des équipes à distance, mais ne devrait pas remplacer un tableau de liège lorsque cela est possible.
Je pense donc que vous êtes en train de dire que les user stories etc. utilisé par des équipes virtuelles; mais, ils ont tendance à ne pas être sur les sites web, car au lieu de cela, ils sont créés à l'aide des outils [comme ceux que vous avez cités] autres que le web?
Ou, est-il plus à voir avec la différence entre fermée/propriétaires et open/public des projets de développement: c'est à dire qu'ils sont sur des sites web, mais pas sur public sites web?
Je dirais que dans notre équipe, nous avons des histoires d'Utilisateurs cependant, il est facile de les faire trop gros et manquer le point. Partie de la raison de l'avoir à l'utilisateur d'histoires sur les cartes d'index est de sorte que vous ne pouvez pas faire de l'utilisateur des histoires trop grand.
OriginalL'auteur Sean Chambers
Je pense que pour ces deux questions, vous pouvez faire beaucoup plus que de balayage sur Alistair Cockburn site web. En particulier, il a un excellent article sur les burndown charts et différentes façons de les générer:
http://alistair.cockburn.us/Earned-value+et+burn+cartes
(thoug je fais écho à la précédente affiche la recommandation de Mike Cohn de travail).
L'une des astuces est de décider quel type de documentation est bonne pour VOTRE projet. Avez-vous beaucoup de développeurs, étalé dans le temps et dans l'espace? Vous aurez besoin d'un plus grand, plus lourd, plus détaillée des histoires. Avez-vous un ou deux développeurs travaillant dans le même lieu? Vous pouvez vous en sortir avec plus légères. L'équipe a travaillé dans le système (si c'est l'héritage) pour une longue période de temps? La lumière histoires vont probablement le faire. L'équipe est nouvelle pour le système, ou sont ses exigences métier complexe? Cela vous pousse dans le détail de la direction.
Si vous êtes sur un "petit" projet par une de la douzaine de définitions de petit, vous pouvez être fine avec de très légers histoires. Voici un exemple, à nouveau à partir de Cockburn du site:
http://alistair.cockburn.us/Examples+de+ultra-léger+utiliser+cas
OriginalL'auteur Steve Lane
Cet article montre un couple de réels tableaux de tâches.
http://www.mountaingoatsoftware.com/task-boards
OriginalL'auteur Murmelschlurmel
Il y A quelques mois, nous avons commencé à écrire la documentation de l'utilisateur en même temps que nous sommes des caractéristiques de développement. Un rédacteur technique est attribué à chaque Mêlée équipes.
Avoir à écrire la documentation de l'utilisateur tout en développant aide à la validation de la conception. Le rédacteur technique aussi participer à la conception de l'application.
C'est en plus de la libération traitement non sélectif et la sprint burndown.
De la documentation supplémentaire est créé par l'équipe lorsqu'ils sentent qu'il est utile de communiquer avec le propriétaire du produit. C'est devenu moins important que nous apprenons à mieux écrire des articles de l'utilisateur.
En fait, la documentation de l'utilisateur peut être suffisant pour les développeurs ("quelles fonctionnalités pour les utilisateurs finaux sommes-nous construire?") mais peut-être pas enoug pour les gestionnaires de projet ("ce que font les dans ce sprint, et à l'inverse de ce que de faible priorité, la fonctionnalité est l'objet d'un tri et d'être ignoré au moins jusqu'à la prochaine fois?").
OriginalL'auteur David S.
Envisager la lecture de Ambler "Modélisation Agile". Il a fait une très forte pourquoi juste de créer des tonnes de plein Uml est une assez mauvaise idée, et donne de bons exemples.
Désolé, je n'ai pas eu le temps d'écrire quelque chose de plus complet, voulais surtout vous référer à l'ouvrage. Il n'discuter de ses solutions de rechange à des cas d'utilisation et ce serait important de le capturer.
OriginalL'auteur Uri