问题
In an answer to the question Documents for a project?, Chris Ballance replied that "User Stories" and a "burndown chart" are the two most useful types of project documentation for a developer.
My question is, do you know of any good example[s], which I can see (for example on the internet, or in a book), of these kinds of documentation?
If possible I'd be happy to see many examples, including:
- Small/short/simple examples
- Big/long/complicated examples
- Famous examples
- High-quality examples
I don't find this an easy topic to Google for: I find lots written about it, but fewer demonstrations showing it.
回答1:
A very good place to start as far as books are concerned is User Stories Applied and Agile Estimation and Planning both by Mike Cohn. This have excellent examples and good starting points for anyone first coming to agile methodologies.
As far as website resources they are few and far between. Probably a good place to actually start would be searching for those keywords on Google Images as many people take photos of their burndown charts and User Stories. This helped me a lot when starting. Here are some samples: Burndown Chart, and User Stories
Please note however while a burndown chart is a simple report that you run on your current story points left in an iteration, User stories are more complex than that and do require a bit of reading to wrap your head around. Start with User Stories Applied book for that.
Hope that helps!
回答2:
I think for both of these questions, you can do a lot worse than scan over Alistair Cockburn's web site. In particular, he has a great article about burndown charts and some different ways to generate them:
http://alistair.cockburn.us/Earned-value+and+burn+charts
(thoug I echo the earlier poster's recommendation of Mike Cohn's work).
One of the tricks is deciding what kind of documentation is good for YOUR project. Do you have many developers, spread over time and space? You will need bigger, heavier, more detailed stories. Do you have one or two devs working in the same place? You can get away with lighter ones. Has the team worked in the system (if it's legacy) for a long time? Light stories will probably do. Is the team new to the system, or are its business requirements complex? This pushes you in the more-detail direction.
If you're on a "small" project by any of the dozen definitions of small, you may be fine with very light stories. Here's an example, again from Cockburn's site:
http://alistair.cockburn.us/Examples+of+ultra-light+use+cases
回答3:
This article shows a couple of actual task boards. http://www.mountaingoatsoftware.com/task-boards
回答4:
A few months ago, we started writing the user documentation at the same time as we are developing features. A technical writer is assigned to each Scrum teams.
Having to write the user documentation while developing helps validating the design. The technical writer also participate in the design of the application.
This is in addition of release burndown and sprint burndown.
Additional documentation is created by the team when they feel it is useful to communicate with the product owner. This became less important as we are learning to write better user stories.
回答5:
Consider reading Ambler's "Agile Modeling". He makes a very strong case as to why just creating tons of full UMLs is a fairly bad idea, and gives some good examples.
来源：https://stackoverflow.com/questions/534019/specific-examples-of-agile-documentation