Нужно (можно) ли разносить по разным спринтам зависимые задачи из одной юзерстори?
Вводная часть:
есть некая юзерстори от заказчика, чтобы выполнить её целиком должны поработать три команды: дизайн, бэкенд (api) и фронтенд. На деле получается так, что в начале спринта дизайн и бэкенд работают параллельно, а фронтенд вынужден их ждать, а в конце спринта фронтенд должен торопиться, чтобы уложиться в рамки спринта, поскольку к нему задача приходит в последнюю очередь. При этом дизайн и бэкенд тоже торопятся, чтобы не задерживать фронт. Появляются риски снижения качества работы.
Нужно (можно) ли в такой ситуации разносить задачи из одной юзерстори по разным спринтам? Или нужно бить юзерстори по другому? Или что мы делаем ни так?
Начнем с нулевого варинта. Это самая плохая идея, которая тут может быть - увеличить размер спринта. Не стоит этого делать, поскольку это принесет больше проблем, чем решит. Вплоть до того, что через некоторое время окажется, что задачи не влезают и в расширенный спринт.
Вариант первый, самый простой, осознанно смотрим проблеме в лицо - явно говорим на планировании, что да, история большая, кросфункциональная, мы ее оцениваем как Х, а практика показывает, что истории больше У не продят в спринт, значит эта история займет этот спринт, часть следующего и будет готова только через два спринта. Если заказчику/ПО это ок и такие штуки не особо часты, можно не делать из этого трагедию. Если такое часто происходит - лучше посмотреть другие варианты.
Вариант второй, использующий инженерные практики - явно говорим команде, мол вы профессионалы или кто? Зачем вам друг друга ждать? Используйте контрактное программирование, парное программирование, экстремальное программирование ну или просто договоритесь как это все будет работать и приступайте к работе одновременно, итеративно внутри истории добавляя весь функционал и графику сразу же как только оно будет готово. Звучит как магия, но на практике вполне достижимо и работает в соответствии с духом agile/scrum. Чтобы попробовать такой вариант, достаточно просто не брать в спринт ничего кроме этой задачи и дать понять разработчикам, что от них ожидается еще до начала спринта, чтобы было время свыкнуться с мыслью. С третьего раза даже начнет получаться.
Вариант третий, призываем силу декомпозиции - лучшее из того, что может сделать менеджер в подобной (да и вообще в любой) ситуации - декомпозировать. В случае с пользовательскими историями должны помочь шаблоны декомпозиции пользовательских историй - ниже перевод статей про модель INVEST с красивой схемой, которую можно держать как шпаргалку на столе:
- https://scrumtrek.ru/blog/right-sizing-features-sa...
- www.agileukraine.org/2014/05/patterns-for-splittin...
Простой
