Пользовательские истории для интеграции в Scrum
Я работаю над проектом, который имеет очень сложные потребности в интеграции, в частности, с получением и отправкой данных EDI и всего "забавного", что происходит между ними. Я могу определенно сосредоточить усилия на обработке данных (проверка, обязательные поля, трансформация), но проблема, с которой я сталкиваюсь, заключается в том, как создавать истории и эпопеи в отставании, чтобы планировать и отслеживать работу.
Очень легко сказать: "Как менеджер, я могу отклонить запрос на отпуск, чтобы убедиться, что у меня достаточно сотрудников в штате, чтобы выполнить свои обязательства". На самом деле, я очень и очень хорош в этом, но я очень новичок в такого рода интеграционных усилиях.
Для большого интеграционного проекта сложнее указать, кем является пользователь и какова его ценность. Интеграция с EDI - это просто интерфейсные (нефункциональные) требования, но реализация требует больших усилий.
Может ли кто-нибудь дать несколько советов о том, как структурировать / структурировать такие требования в списке продуктов, который я создаю?
3 ответа
Майк Кон есть, что сказать по этому поводу, я думаю, что последний абзац очень актуален
Но вы должны быть осторожны, чтобы не зацикливаться на этом шаблоне. Это только инструмент мышления. Попытка вставить ограничение в этот шаблон - хорошее упражнение, поскольку оно помогает вам понять, кто чего хочет и почему. Если в результате вы получите запутанное утверждение, отбросьте шаблон. Если вы не можете найти способ обозначить ограничение, просто напишите ограничение любым естественным способом
Scrum не указывает, что требования должны быть написаны в виде пользовательских историй, и вы должны использовать любую технику, которая лучше всего подходит для вас. Если вы боретесь с историями типа "КАК А", попробуйте "В ПОРЯДКЕ, КАК ХОЧУ". Если это не использует, используйте моделирование вариантов использования.
Требования не контракты, а заполнители для связи. Ключевым моментом здесь является наличие достаточного количества информации для целей планирования, что дает команде ощущение того, что нужно сделать. Подробности можно обсудить в спринте.
Что я делаю в таких ситуациях:
1) Попробуйте и предложите простейшую часть сквозной функциональности, которую мы можем реализовать для интеграции.
2) Попробуйте придумать вариант использования для этой интеграции
3) Переведите это в истории (необязательный шаг: истории не являются законом физики. Используйте их, если они полезны.)
Например:
1) Хорошо - похоже, аутентификация - самая тривиальная вещь для реализации, которая затрагивает все.
2) Привет - аутентификация сама по себе полезна. Мы можем использовать его, чтобы узнать, может ли эта группа пользователей получить доступ к данным.
3) "Как администратор сайта, я хочу убедиться, что только авторизованные сотрудники имеют доступ к Foo, чтобы ценная информация не была общедоступной".
Таким образом, у вас всегда будет работающая система EDI - она просто покрывает подмножество функций. Подмножество, которое вы можете увеличивать со временем - надеюсь, в зависимости от важности функциональности для вашего бизнеса.
Однако я предпочел бы немного глубже понять, почему проводится EDI. Обычно этого не происходит, потому что "EDI" - это функция, которую хотят люди. Это будет потому, что EDI необходим для некоторых других функций системы.
В этом случае, вместо того, чтобы иметь отдельный проект EDI, я бы предпочел использовать все, что нужно EDI, для развития уровня EDI. Истории в (3) выше будут исходить из живого проекта - и у вас будет гораздо больше шансов построить то, что вам нужно, и избежать потерь.