Управление историями пользователей для большого проекта [закрыто]

Question

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

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

Интересно, какие методы люди используют, чтобы разбить проекты на части для включения в список невыполненных работ, и как только список невыполненных работ создан, как его поддерживать и упорядочивать.также, как поддерживаются отношения между элементами (т. Е. это должно быть сделано до того, как станет возможным это сделать, или это была одна история, теперь их пять)

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

Что-то еще, что могло бы получить от меня + 1, - это примеры реальных историй пользователей из реальных проектов (история "пользователь может войти в систему" не помогает мне представить себе ситуацию в моем проекте.

Спасибо.

Answer 1

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

Сейчас я запустил несколько agile-проектов, и нам никогда не требовался более сложный инструмент, чем электронная таблица, да еще для проекта с бюджетом более миллиона фунтов.В основном мы считаем, что белой доски и карточек (по одной на историю пользователя) более чем достаточно.

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

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

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

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

Удачи вам!

Answer 2

Как и DanielHonig, мы также используем RallyDev (в небольшом масштабе), и, похоже, вам было бы полезно хотя бы изучить эту систему.

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

Answer 3

Я не уверен, что это то, что вы ищете, но это все еще может быть полезно.У Макса Пула из codesqueeze есть видео, объясняющее его "гибкую стену".Здорово видеть его процесс, даже если он не обязательно имеет отношение к вашему вопросу:

Моя Гибкая стена (плюс несколько трюков)

Answer 4

Итак, вот несколько советов:Мы используем RallyDev.
Мы создали представление пакетов, в которых соответствуют нашим требованиям.Большие истории помечаются как epics и помещаются в список невыполненных работ того выпуска, для которого они предназначены.К эпосам добавляются детские истории.Мы пришли к выводу, что лучше всего делать истории очень подробными.Крупнозернистые истории затрудняют реалистичную оценку и исполнение сюжета.

Так что в целом:

1. Организуйте выпуск

2. Продолжайте повторения в течение 2-4 недель

3. Владельцы продукта и проекта Менеджеры добавляют истории в выпуск невыполненная работа

4. Команда разработчиков оценивает истории на основе размеров футболок, баллов и т.д...
5. Во время весеннего планирования собраний команда разработчиков выбирает работу для итерации из невыполненной работы по выпуску.

Это то, чем мы занимались последние 4 месяца, и обнаружили, что это хорошо работает.Очень важно сохранять размер историй небольшим и детализированным.

Помните аббревиатуры Invest и Smart для оценки историй пользователей, хорошая история должна быть:I - Независимый N - Подлежащий обсуждению V - Ценный E - Оцениваемый S - Небольшой T - Проверяемый

Умный:

S - Специфичный M - Измеримый A - достижимый R - Релевантный T - Ограниченный по времени

Answer 5

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

Я прочитал несколько хороших вещей о Общайтесь с Thoughtworks.

Answer 6

вот мой ответ на аналогичный вопрос, который может натолкнуть вас на некоторые идеи

Помогите бакалавру!Управление историями пользователей ...

Answer 7

Многие из этих ответов содержали предложения по использованию инструментов.Однако реальность такова, что ваш процесс будет гораздо важнее инструментов, которые вы используете для его реализации.Держитесь подальше от инструментов, которые пытаются запихнуть вам в глотку методологию.Но также будьте осторожны с простым внедрением старого негибкого процесса с использованием нового инструмента.Вот несколько убедительных фактов, которые следует учитывать при определении инструментов для процессов:

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

Учитывая все вышесказанное, вот несколько рекомендаций, которые помогут вам:

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

Для более крупных организаций, если вы используете SCRUM, используйте каскадный механизм stand-up.Скрам-мастера встречаются со своими командами.Затем скрам-мастера встречаются в составе 6-9 человек, причем Супер-Скрам-мастер отвечает за передачу элементов из scrum Scum-Мастера на следующий уровень...и так далее..

Возможно, вы обнаружите, что на самом высоком уровне вашей иерархии будет достаточно еженедельных суперскрам-собраний.