Какие истории пользователей должны быть написаны на начальных этапах проекта?

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

Это не вписывается в мою концепцию «задач»: мне бы хотелось иметь что-то вроде следующих «задач»:

• Показывать фиктивные данные для пользовательского кода в HTML, полученные из объектов JavaScript.
• Настройте слой логики представления и подключите к нему объекты JavaScript.
• Настройте уровень логики домена и подключите к нему уровень логики представления.
• Настройте уровень доступа к данным и подключите к нему уровень логики домена.

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

Это хороший вопрос, и, возможно, на него есть несколько хороших ответов. Мое мнение таково:

История - это история пользователя поэтому она должна быть определена в терминах, описывающих, как она приносит пользу пользователю.

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

На начальных этапах проекта, когда у вас нет соответствующих структур для быстрого и легкого развития CRUD ( C reate, R ead, U pdate, D elete), ваши истории должны быть гораздо меньшими, инкрементальными частей.

Вместо «Пользователь должен иметь возможность просматривать свои foo» , что-то вроде этого:

1. Пользователь должен видеть страницу с образцами данных.
2. Пользователь должен иметь возможность видеть страницу с примерами интерактивных данных.
3. Пользователь должен видеть страницу с интерактивными примерами данных

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

История / особенность не обязательно должна быть товарной, она должна быть значимой для владельца продукта. В приведенном выше случае вы могли бы вставить несколько быстрых демонстрационных примеров, чтобы показать, что изменилось и как эта история теперь делается - например, для № 3, вы можете показать страницу для двух разных пользователей с данными, предварительно заполненными в базе данных. , На этапе № 2 все пользователи увидят одинаковые данные.

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

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

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

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

Вы должны представить это обратно и получить согласие.

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

Некоторые расскажут историю, а затем представят и объяснят.

Некоторые напишут строгие и тщательно проанализированные документы.

Каждая техника имеет свои преимущества и недостатки.

О единственном совете, который я бы дал, это то, что слишком рано начинать кодировать решение - плохой шаг. Понимание того, что делать для ВОЗ и ПОЧЕМУ, прежде чем делать это, как правило, приводит к меньшему количеству переделок и ускорению развития.

Когда вы говорите о «задачах», это кажется мне каким-то упадком в работе, когда я понял, что, кто и почему выше. Вы не можете понять задачи ХОРОШО, пока не поймете историю пользователя в документе, утвержденном заказчиком как объем работы, которую вы собираетесь выполнить. Знание того, чего вы должны достичь (выход), позволяет вам определить задачи (шаги, необходимые для их достижения).

Не экономьте на анализе и документации переднего плана.

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

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