Большинство пользовательских историй можно разделить. Может быть трудно найти хороший способ разделить некоторые истории, но большинство из них можно разделить. Они известны как составные истории — истории, состоящие из нескольких более мелких историй.
Есть еще один тип истории: сложная история. Сложные истории — это те, которые нельзя разделить. Они по своей природе большие и/или сложные, и в них нет частей, которые можно было бы разделить на отдельные истории. Но даже со сложной историей вы не захотите, чтобы история задерживалась на три, четыре или более спринтов.
Если вы делаете одну историю более одного спринта, то столкнетесь со следующими не очень хорошими последствиями:
Делаете скорость команды менее предсказуемой от спринта к спринту.
Увеличиваете риск того, что разработчик отклонится от ожиданий пользователей.
Позволяете команде развить плохую привычку: оставлять работу незавершенной в конце спринта.
Используйте точки прогресса
Итак, что же должна делать хорошая Agile-команда?
Когда невозможно найти хорошее, естественное разделение пользовательской истории, вы можете найти точки прогресса.
Точка прогресса — это любой момент во время разработки, когда разработчик чувствует, что что-то было достигнуто.
Ни один разработчик не хочет провести два месяца без удовлетворения от работы, когда единственное, что он может сказать товарищам по команде на всех встречах: «Я продолжаю делать историю 505». Это печально и демотивирует.
Чтобы определить точки прогресса, спросите разработчика, который занимается сложной историей: «Какие важные небольшие достижения ты видишь во время работы над этой историей, когда ты захочешь сказать технически подкованному товарищу по команде: «Чувак, зацени это! У меня есть то-то и то-то для работы!»
Примеры точек прогресса
В качестве примера предположим, что разработчик работает над сложным кодом для взаимодействия с удаленной системой. Разработчик предполагает, что потребуется два или три спринта.
Первая точка прогресса указывает на то, что первая транзакция отправлена (или получена) из другой системы. Никакой проверки или обработки ошибок не выполняется, но первый обмен данными с другой системой будет моментом, когда разработчик может поделиться достижением со вторым технически подкованным товарищем по команде, который понимает важность достижения.
Второй точкой прогресса может быть обмен другими типами транзакций, обнаружение ошибок или повторная проверка ошибок.
После определения точек прогресса, они могут быть легко выражены в виде пользовательских историй. Таким образом, размышление о точках прогресса помогает разработчикам определить естественные вехи, которых они достигнут во время реализации большой и сложной истории.
Использование точек прогресса
Определив одну или несколько точек прогресса в сложной истории, используйте их в качестве вех. Попросите разработчика определить, сколько точек прогресса может быть выполнено в течение предстоящего спринта, а затем используйте это для отслеживания прогресса, как если бы вы использовали обычную пользовательскую историю.
varenich
С большими сценариями помогает их разбитие на "пользовательские истории" (в моей интерпретации). Это когда под историей понимается один конкретный альтернативный путь из большого сценария.
Пример из нашей практики.
Большой сценарий: выдача груза Водителем на точке доставки
Основной путь (пользовательская история): Получатель груза на месте и он принимает груз оптом (просто пересчитывая грузовые места)
Альтернативный путь (пользовательская история): Получатель решает принять груз по-коробочно (сверяя номер на этикетке каждой коробки)
Альтернативный путь (пользовательская история): Получателя нет на месте, Водитель отменяет доставку
Альтернативный путь (пользовательская история): Получателя нет на месте, но вместе него получает другой человек.
и т.п.
В таком варианте "истории" получаются не очень большими и вполне помещаются в спринт. И их даже можно выводить по-отдельности в прод.