Des exemples spécifiques de la documentation Agile? [fermé]

Question

Dans une réponse à la question documents pour un projet? , Chris Ballance a répondu que « Histoires de l'utilisateur » et un « tableau burndown » sont les deux plus types utiles de la documentation du projet pour un développeur.

Ma question est, est-ce que vous connaissez des bon exemple [s], que je peux voir (par exemple sur Internet ou dans un livre), de ce genre de documents?

Si possible, je serais heureux de voir de nombreux exemples, y compris:

• Exemples petits / courts / simples
• Exemples Big / long / complexe
• Des exemples célèbres
• Exemples de haute qualité

Je ne trouve pas un sujet facile à Google pour: Je trouve beaucoup écrit à ce sujet, mais moins de démonstrations montrant qu'il

.

Answer 1

Un très bon endroit pour commencer dans la mesure où les livres sont concernés est User Stories Applied et Agile Estimation et planification à la fois par Mike Cohn. Cela a d'excellents exemples et de bons points de départ pour toute personne première venue aux méthodologies agiles.

En ce qui concerne les ressources du site ils sont peu nombreux. Probablement un bon endroit pour commencer serait effectivement la recherche de ces mots-clés sur Google images que beaucoup de gens prennent des photos de leurs cartes et Burndown Histoires de l'utilisateur. Cela m'a beaucoup aidé lors du démarrage. Voici quelques exemples: Burndown graphique et Histoires de l'utilisateur

S'il vous plaît noter cependant alors qu'un tableau burndown est un simple rapport que vous exécutez sur vos points d'histoire actuels laissés dans une itération, des histoires d'utilisateurs sont plus complexes que cela et exigent un peu de lecture pour envelopper autour de votre tête. Commencez avec User Stories livre appliquées pour cela.

L'espoir qui aide!

Answer 2

Je pense que pour ces deux questions, vous pouvez faire bien pire que numériser sur Alistair le site Web de Cockburn. En particulier, il a un grand article sur les graphiques burndown et des différentes façons de les générer:

http://alistair.cockburn.us/Earned-value+and + + graver des graphiques

(thoug je fais écho à la recommandation de l'affiche plus tôt du travail de Mike Cohn).

L'une des astuces est de décider quel genre de documents est bon pour votre projet. Avez-vous des nombreux développeurs, étalé dans le temps et dans l'espace? Vous aurez besoin plus gros, plus lourds, des histoires plus détaillées. Avez-vous un ou deux développeurs qui travaillent au même endroit? Vous pouvez vous en sortir avec les plus légers. L'équipe a travaillé dans le système (si elle est l'héritage) depuis longtemps? histoires légères feront probablement. L'équipe est nouvelle au système, ou sont ses besoins d'affaires complexes? Cela vous pousse dans la direction plus-détail.

Si vous êtes sur un projet « petit » par l'une des définitions douzaine de petits, vous pouvez être très bien avec des histoires très légères. Voici un exemple, encore une fois sur le site de Cockburn:

http://alistair.cockburn.us/Examples+of + ultra-léger + utilisation + cas

Answer 3

Cet article montre quelques conseils de tâche. http://www.mountaingoatsoftware.com/task-boards

Answer 4

Il y a quelques mois, nous avons commencé à écrire la documentation utilisateur en même temps que nous développons des fonctionnalités. Un rédacteur technique est attribué à chaque équipe Scrum.

Le fait de devoir écrire la documentation utilisateur tout en développant la validation de la conception aide. Le rédacteur technique participe également à la conception de l'application.

Ceci est en plus de la libération et burndown burndown sprint.

Documentation supplémentaire est créée par l'équipe quand ils se sentent il est utile de communiquer avec le propriétaire du produit. Cela est devenu moins important que nous apprenons à écrire de meilleures histoires utilisateur.

Answer 5

Vous pouvez lire "Agile Modeling" de Ambler. Il fait un cas très fort pour expliquer pourquoi seulement la création de tonnes de plein est une UML idée assez mauvaise, et donne quelques bons exemples.