Конкретные примеры документации Agile?

В ответе на вопрос Документы для проекта?, Крис Балланс ответил, что "Истории пользователей" и "графика выгорания" являются двумя наиболее полезными типами проектной документации для разработчика.

Мой вопрос: знаете ли вы о каком-либо хорошем примере [s], который я могу видеть (например, в Интернете или в книге) о таких документах?

Если возможно, я был бы рад увидеть много примеров, в том числе:

  • Малые/короткие/простые примеры
  • Большие/длинные/сложные примеры
  • Известные примеры
  • Высококачественные примеры

Я не считаю эту тему легкой для Google: я нахожу много написанных об этом, но меньше демонстраций, показывающих ее.

Ответы

Ответ 1

Очень хорошее место для начала, если речь идет о книгах, "Использованы пользовательские истории" и Agile Оценка и планирование как Майк Кон. Это отличные примеры и хорошие отправные точки для тех, кто первым приходит к гибким методологиям.

Что касается ресурсов веб-сайта, то их мало и далеко. Вероятно, хорошим местом для начала было бы поиск этих ключевых слов в Google Images, так как многие люди фотографируют свои графики выгорания и пользовательские истории. Это очень помогло мне при старте. Вот несколько примеров: Burndown Chart и Истории пользователей

Обратите внимание, что, хотя диаграмма сжигания - это простой отчет, который вы запускаете на своих текущих сюжетных точках, оставшихся на итерации, истории пользователей более сложны, чем это, и требуют немного чтения, чтобы обернуть голову. Начните с пользовательских историй. Прикладная книга для этого.

Надеюсь, что это поможет!

Ответ 2

Я думаю, что для обоих этих вопросов вы можете сделать намного хуже, чем сканировать веб-сайт Алистера Кокберна. В частности, у него есть отличная статья о графиках сжигания и некоторые другие способы их генерации:

http://alistair.cockburn.us/Earned-value+and+burn+charts

(Ты э-э-э-э-э-э-э-э-э-э-э-э-э-э-э-э-э-э...)

Один из трюков - это решение, какая документация подходит для ВАШЕГО проекта. У вас много разработчиков, которые распространяются во времени и пространстве? Вам понадобятся более крупные, более тяжелые, более подробные истории. У вас есть один или два разработчика, работающих в одном и том же месте? Вы можете уйти с более легкими. Работала ли команда в системе (если она устарела) в течение длительного времени? Легкие истории, вероятно, сделают. Является ли команда новой для системы или ее бизнес-требования сложными? Это подталкивает вас к более подробному направлению.

Если вы находитесь в "маленьком" проекте по любому из десяти определений малых, вы можете быть в порядке с очень легкими историями. Вот пример, снова с сайта Cockburn:

http://alistair.cockburn.us/Examples+of+ultra-light+use+cases

Ответ 4

Несколько месяцев назад мы начали писать документацию пользователя одновременно с разработкой функций. Каждому команде Scrum присваивается технический писатель.

Наличие письменной документации пользователя при разработке помогает проверить дизайн. Технический автор также участвует в разработке приложения.

Это, кроме того, выключение сжигания и сжигание спринта.

Дополнительная документация создается командой, когда они считают, что полезно общаться с владельцем продукта. Это стало менее важным, поскольку мы учимся писать лучшие истории пользователей.

Ответ 5

Рассмотрим чтение Ambler "Agile Modeling". Он делает очень сильный аргумент в пользу того, почему просто создание тонны полных UML - довольно плохая идея и дает несколько хороших примеров.