Истории пользователей для интеграции в Scrum

Question

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

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

Для большого интеграционного проекта более жестко указать, кто является пользователем, и каково значение. Интеграция EDI - это просто интерфейсные (нефункциональные) требования, но реализация - это большие усилия.

Может ли кто-нибудь дать некоторые рекомендации о том, как структурировать/сфотографировать эти требования в выпуске продукта, который я создаю?

Answer 1

Mike Cohn есть что сказать об этом, я думаю, что это последний пункт очень актуален

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

Answer 2

Scrum не указывает, что требования должны быть написаны как рассказы пользователей, и вы должны использовать то, что когда-либо лучше всего подходит для работы вы. Если вы сражаетесь с историями типа «AS A», попробуйте «ЗАКАЗАТЬ КАК Я ХОЧУ». Если это не используется, используйте модель использования.

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

Answer 3

Что делать в таких ситуациях, как это:

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

2) Постарайтесь придумать прецеденте для такой интеграции

3) Перевести, что в рассказах (необязательный шаг:. Истории не закон физики используется им, если они полезны.)

Например:

1) Хорошо - выглядит как аутентификация является наиболее тривиальная вещь, чтобы осуществить это касается всего.

2) Привет, аутентификация сама по себе полезна. Мы можем использовать его, чтобы узнать, может ли эта группа пользователей получить доступ к данным.

3) «Как администратор сайта я хочу, чтобы убедиться, что только авторизованные вещи имеют доступ к Foo, чтобы предотвратить ценную информацию является общедоступной»

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

Мой реальный предпочтение однако было бы копать немного дальше в почему ИДЭ делается. Как правило, это не потому, что «EDI» - это функция, которую люди хотят. Это связано с тем, что EDI необходимо для некоторых других функций в системе.

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