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

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

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

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

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

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

Спасибо.

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Книги Майка Кон, в частности Agile Estimating and Planning, помогут вам на этом этапе и помогут вам найти полезные инструменты для работы с.

Удачи!

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

Итак, вообще говоря:

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

  • Держите итерации между 2-4 неделями

  • Владельцы и проект менеджеры добавляют рассказы в релиз отставание

  • Оценки команды разработчиков истории, основанные на размерах TShirt, пункты и т.д.
  • В Spring планировании meetwings команда разработчиков выбирает работа для итерации с релиз.

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

Помните акронимы Invest и Smart для оценки пользовательских историй, хорошая история должна быть: Я - независимый N - Договорная V - Ценный E - Оценочный S - Маленький T - Testable

Smart:

S - Конкретный M - Измеримый A - Достижимый R - Релевантно T - Time-boxed

Ответ 5

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

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

Ответ 7

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

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

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

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

Для крупных организаций, если вы используете SCRUM, используйте каскадный механизм stand-up. Руководители Scrum встречаются с их командами. Затем Scrum Masters встречаются в стойках 6-9, с Super-Scrum-MAster, ответственным за сообщение предметов из схватки Scum-Master на следующий уровень... и т.д.

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