Конкретные примеры гибкой документации?[закрыто]

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

(хотя я повторяю рекомендацию предыдущего постера о работе Майка Кона).

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

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

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

Answer 3

В этой статье показана пара реальных досок задач.http://www.mountaingoatsoftware.com/task-boards

Answer 4

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

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

Это в дополнение к выгоранию релиза и выгоранию спринта.

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

Answer 5

Подумайте о прочтении книги Эмблера "Гибкое моделирование".Он приводит очень веские доводы в пользу того, почему просто создавать тонны полных UMLS - это довольно плохая идея, и приводит несколько хороших примеров.