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

В ответ на вопрос Documents for a project?, Крис балланс ответил, что "User Stories" and a "burndown chart" are the two most useful types of project documentation for a developer.Конкретные примеры гибкой документации?

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

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

малых/короткие/простые примеры
большой/длинный/сложные примеры
Известные примеры
высокого качества примеры

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

источник

2009-02-10 ChrisW

Очень хорошее место для начала, поскольку книги касаются User Stories Applied и Agile Estimation and Planning и Майком Кон. Это отличные примеры и хорошие отправные точки для тех, кто первым приходит к гибким методологиям.

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

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

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

источник

2009-02-10 20:27:39

Я удивлен, услышав, что «ресурсы веб-сайта немногочисленны и далеки друг от друга»: эти типы документации не используются на практике, а затем «виртуальными командами» (то есть географически распределенными разработчиками), разрабатывающими open source (т.е. общедоступных) проектов? Если нет, можете ли вы рассуждать о том, почему нет? – ChrisW

Я на самом деле работаю в удаленной гибкой команде, и, конечно же, мы используем удаленные инструменты, я думал, вы имели в виду аспект обучения. Для виртуальных инструментов у вас есть такие опции, как Acunote, TargetProcess, Unfuddle. Эти инструменты полезны для удаленных команд, но не должны заменять пробку, когда это возможно. –

Итак, я думаю, вы говорите, что истории пользователей и т. Д. * * Используются виртуальными командами; но, как правило, они не размещаются на веб-сайтах, потому что вместо этого они создаются с помощью инструментов [таких, как вы цитировали], кроме Интернета? – ChrisW

Рассмотрите возможность изучения «гибкого моделирования» Амблера. Он делает очень сильный аргумент в пользу того, почему просто создание тонны полных UML - довольно плохая идея и дает несколько хороших примеров.

источник

2009-02-10 20:28:46 Uri

Простое объяснение, почему не создавать тонны UML, не было бы ответом на мой вопрос. – ChrisW

Извините, у меня не было времени написать что-нибудь более полное, в основном хотели отсылать вас к книге. Он обсуждает свои альтернативы для использования дел и что было бы важно для захвата. – Uri

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

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

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

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

источник

2009-02-10 22:38:25

Я всегда думал, что функциональная спецификация - самая полезная документация. Документация пользователя является подклассом функциональной спецификации IMO. Итак, если вы говорите, что документация пользователя достаточна и что ее хорошо разрабатывать до и/или с программным обеспечением, я считаю это правдоподобным. – ChrisW

На самом деле документации для пользователей может быть достаточно для разработчиков («какие функции конечного пользователя мы создаем?»), Но может не быть enug для менеджеров проектов («что делают * в этом спринте» и, наоборот, что более низкая приоритетность функций триггеров и игнорируется, по крайней мере, до следующего раза? »). – ChrisW

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

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

(thoug Я присоединяюсь рекомендацию более раннего автора работы Майка Кона).

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

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

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

источник

2009-02-11 04:48:40