AGILE пользовательские истории для сбора требований?
Хотелось бы спросить, как бы вы писали пользовательские истории, где ваш первоначальный набор задач состоит в анализе или сборе требований.
Немного предыстории, скажем, у клиента есть устаревшее приложение, где он хотел бы преобразовать его в онлайн-приложение. Устаревшее приложение использует исключительно листы Excel + макросы. Теперь, когда вы пишете истории пользователей, как бы вы написали следующее?
- Сбор существующих образцов данных, основанных на этом, существующих физических файлов Excel с соответствующей документацией
- Анализ файлов Excel и документации для получения бизнес-правил и логики (каковы возможные значения этого поля Excel? И т. Д., И т. Д.)
- анализ взаимосвязи данных, форм нормзалиций и т. д.
Могу ли я сделать что-то вроде - Как бизнес-аналитик, я бы хотел Ядди-Ядда?
это звучит неправильно...
Ребята, можете ли вы помочь мне, приведя несколько примеров гибких пользовательских историй для сбора требований? Спасибо.
3 ответа
Вы не должны писать истории, чтобы писать истории. Нет никакого смысла в создании невыполненных заданий, потому что это никогда не является целью пользовательских историй.
Итак, начните с очень быстрого, очень высокого уровня описания цели продукта / системы, которое должно дать вам достаточно для начала работы, теперь уточните каждое из описаний высокого уровня в наборы историй.
Для отслеживания этой работы не нужно создавать истории, само состояние отставания должно быть достаточным указанием.
Поскольку, с пользовательскими историями, вы начнете работу, когда не все ясно (пока), частью работы по фактическому построению будет извлечение точных бизнес-правил или анализ файлов Excel, чтобы гарантировать, что будут построены правильные контрольные примеры., Это не требуется для создания отставания, так как уровень детализации будет очень глубоким.
Нет необходимости писать пользовательские истории для такого рода задач, но я предлагаю вам создать задачи для каждой группы работ. Могут быть задачи анализа для модуля / функциональности существующей системы.
Как только задачи анализа завершены, вы можете продолжить и начать писать истории пользователей на основе выявленной работы.
"Немного предыстории, скажем, у клиента есть унаследованное приложение, в котором он хотел бы преобразовать его в онлайн-приложение. Устаревшее приложение использует исключительно таблицы Excel + макросы".
Итак, почему клиент хочет, чтобы устаревшее приложение было онлайн-приложением? Например:
"Как пользователь, я хочу иметь доступ к приложению ABC онлайн, а не устанавливать его локально, потому что это позволяет мне работать более продуктивно"
Теперь это звучит как могущественная большая история (или даже эпопея). Так что, возможно, следующий этап - сломать его. Возможно, всплеск времени, чтобы исследовать существующее приложение и получить некоторые ключевые функции. Затем они могут быть преобразованы в истории, например:
"Как пользователь, я хочу иметь возможность загружать свой набор данных, чтобы он мог быть обработан"
"Как пользователь, я хочу иметь возможность выполнять анализ XYZ на наборе данных, чтобы я мог определить значение коэффициента X"
На этом этапе команда может начать работу и начать работу над первым поставляемым продуктом. Взаимодействие с заказчиком, чтобы убедиться, что то, что строится, отвечает его требованиям (а не просто копирует предыдущее приложение).
Намерение будет состоять в том, чтобы сначала произвести самые ценные функции и превратить их в работоспособный продукт при первой же возможности. Это предпочтительнее, чем тратить много времени на извлечение требований из унаследованного приложения и, таким образом, иметь много времени, прежде чем клиент увидит что-либо.