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

Question

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

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

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

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

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

спасибо.

Answer 1

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

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

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

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

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

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

Удачи вам!

Answer 2

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

My Agile Wall (Plus A Few Tricks)

Answer 3

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

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

1. Организация по высвобождению

2. Держите итераций от 2-4 недель

3. владельцев продукта и проект менеджеров добавить истории в выпуске накопившихся

4. Оценки команды разработчиков истории, основанные на размерах тенниски, точек и т.д ...
5. Весна планирования meeetings команда разработчиков выбирает работы для итерации с отставанием выпуска.

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

Помните Invest и смарт-аббревиатуру для оценки пользовательских историй, хорошая история должна быть: I - Independent N - договорная V - полезный E - почтенный S - Small T - Тестируемые

Смарт :

S - Конкретные М - Измеримый А - достижимые R - Соответствующий Т - Время-коробки

Answer 4

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

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

Answer 5

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

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

Answer 6

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

Help a BA! Managing User Stories ...

Answer 7

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

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

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

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

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

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