В компании, над которой я сейчас работаю, мы заметили, что иногда некоторые истории связаны друг с другом (как в случае слишком связанных). Это может быть связано с тем, что они принадлежат к одной и той же общей функции, или что это разные функции, но есть некоторые из них, которые необходимо завершить в первую очередь, чтобы перейти к следующим, и т. Д.
Как вы справляетесь с этими случаями, не останавливая рабочий процесс итерации? Мы делаем что-то не так?
Это большой вопрос. Теория говорит, что пользовательские истории должны быть независимыми, но я так и не смог этого достичь.
На мой взгляд, наиболее важным является информирование о зависимости, чтобы команда и владелец продукта знали об этом. Это заставит владельца продукта либо переопределить пользовательские истории, чтобы удалить зависимость (например, путем объединения пользовательских историй), либо соответственно определить бизнес-приоритет, чтобы основная пользовательская история была реализована первой.
Исходя из приоритета и решения PO, вы либо реализуете их оба в одном и том же спринте, либо зависимый будет реализован позже без каких-либо проблем, потому что принципал уже будет выполнен.
В худшем случае, если A зависит от B, а B зависит от A. В этом случае пользовательские истории, скорее всего, определены неправильно и, вероятно, должны быть переписаны в A и B (в основном независимые или только с односторонней зависимостью), а C зависит от А и Б.
Планируйте их соответственно.
Поместите их в один и тот же спринт, и, поскольку пользовательские истории также имеют приоритет в зачете спринта, проблем не возникнет.
Поскольку ваша команда участвует в этом, они знают о зависимостях, поэтому вам нечего бояться. Они взрослые, и если вы объясните им их зависимость (обычно они вам это объяснят), все пойдет гладко.
В Agile, как и в Waterfall, вы можете делать только одну вещь за раз. И вы обычно делаете A перед B, если B нужно A. Это здравый смысл.
Зависимости могут быть запахом, что вы рассекаете свои истории горизонтально, а не вертикально через систему. Разработка для конкретной функции должна включать в себя все, от изменения дизайна базы данных вплоть до пользовательского интерфейса. Если вы обнаружите, что вы тратите все свои усилия на создание пользовательской истории на каком-то более низком уровне структуры системы, например, на написание подпрограмм обработчиков для поиска в базе данных, то вы, скорее всего, будете создавать зависимости между историями. И вы, вероятно, пишете свои пользовательские истории неправильно.
Лучше всего разбить ваши независимые пользовательские истории на более мелкие фрагменты, которые могут стать как можно более независимыми. Это те истории, от которых вы в первую очередь зависите (как вы сказали: те, которые нужно закончить первыми, чтобы продолжить другие). Создайте что-то вроде индекса зависимости: если в истории 3 больше зависимых от дел, чем в истории 1, сначала вы должны взять историю 3.
Если ваши зависимости вызывают слишком много остановок, возможно, будет хорошей идеей полностью прекратить работу (да, прямо в середине текущего спринта) и пересмотреть ваши приоритетные пользовательские истории и сначала заняться ими.
источник