Гибкость в Скраме - это не про то, что мы настолько гибкие, что можем менять скоуп спринта когда заблагорассудится, как некоторые думают. А это про то, что команда может доставлять ценность в течение двух недель и менять направление работы каждые две недели.
Несколько дней назад я допустил ошибку позволив добавить в уже запущенный спринт задачи, которые не были настолько критичными, чтобы делать их asap.
По-хорошему я должен был остановить спринт, поменять цель, запустить новый спринт с новой целью. Останавливать спринт - тоже так себе решение, но как минимум в критических ситуациях это поможет команде сохранять фокус на чем-то одном.
Но так как я сам новичок в компании и не очень хорошо знаю продукт, я поддался на три манипуляции от менеджмента:
1. Это небольшие задачи, может быть на день, не больше, они не займут много времени;
2. У вас же запланировано 20% в спринте на срочные ад-хоки?
3. Я - СЕО и я так сказал, делайте.
По-хорошему, я должен был парировать эти манипуляции.
Это небольшие задачи, может быть на день
Менеджмент и СЕО, как правило, не знают технических деталей реализации. Ну или знают, но не так глубоко, как разработчики. И, как правило, те решения, которые они предлагают, в 80% случае костыли, а не целевое решение. А когда у тебя одна команда в компании, то меньше всего хочется копить тех.долг, потому что нормально его никто не будет исправлять, до появления дополнительных ресурсов. А их поди найми. Даже если будет “добро” и бюджет - цикл поиска 2 месяца, плюс, в среднем, 1 месяц до фактического выхода на работу. А потом еще несколько месяцев, чтобы разработчик вообще понял, что за продукт и как в него программировать.
И что вообще оценивает менеджмент в этот момент?
Допустим, менеджмент окажется прав по поводу того, что задача на 1 день. Но, как правило, никто не учитывает то, что должно быть перед и после этого одного дня разработки:
- прояснить требования;
- обсудить бизнес логику со стейкхолдерами;
- учесть краевые сценарии;
- сформировать и выбрать наилучшее решение;
- запланировать в спринт, поменять задачи местами, передоговориться с командой о разных вещах;
- разработать (ну тут как бы 1 день, ок);
- протестировать;
- потестировать самому и показать стейкхолдерам, чтобы скорректировать ожидания;
- подготовить к релизу.
И сколько по времени и ментальным ресурсам занимает всё кроме разработки? Очень много. А если делать это очень много и очень быстро - это просто разрушает на некоторое время процессы в нескольких отделах.
Так что я должен был объяснить всё это менеджменту. Взять время на обсуждение этой задачи. И ни в коем случае не должен был просто брать и делать. Урок выучен.
У вас же запланировано 20% в спринте на срочные ад-хоки?
Какие нафиг 20% на ад-хоки? Нам бы цель спринта выполнить и релизнуть это всё до ретроспективы, в чем молодая команда вряд ли и так преуспеет.
Может, у тебя, дорогой стейкхорлдер, проблемы с тайм-менеджментом, что ты не можешь заранее подумать о важных для тебя проблемах и задачах, приоритизировать их с ПМ и спокойно работать? 20% чего? Времени? Как сделать так, чтобы 20% времени действительно оставалось в спринте?
Для молодой команды - никак.
Только сработавшиеся команды могут позволить себе резервировать время, потому что они уже хорошо знают продукт, среду и точность их оценок достаточно высока.
А молодые команды - дай бог если цель спринта выполнят согласно Definition of Done и релиз выпустят.
В большинстве случаев на стабилизацию новой команды может уйти 4-6 спринтов, и то без постоянного вмешательства менеджмента с его пожарами.
Ну и в целом, разработка софта связана с большой долей неопределенности.
В молодых командах нет и не должно быть никаких 20% в спринте на ад-хоки, тех.долг и прочее. В большинстве случаев только что сформировавшаяся команда не знает, что такое Story Points, как оценивать комплексность задач, как действительно эффективно участвовать в ритуалах, чтобы они по-настоящему имели ценность для команды и помогали достичь цель спринта.
А тут еще “давайте закладывать 20%”.
Единственное, что могу предложить, дорогой стейкхолдер, это положить твою задачу в спринт без оценки, а дальше - молись всем богам, чтобы команда успела закончить цель спринта пораньше и смогла переключиться на твой “важный ад-хок”.
Я - СЕО и я так сказал, делайте
Извините, господин СЕО, мы продукт для вас делаем или для пользователей?
В чем основная задача СЕО - быть лидером или микро-менеджером?
Для тебя, господин СЕО, затраты ресурсов на постановку задачи - 5 секунд твоего времени, а для команды - это уйма времени (смотри выше, что я имею в виду).
Да и вообще, все эти ад-хоки и “важные запросы от стейкхолдеров” отнимают ментальную энергию и заставляют суетиться, что часто ни к чему хорошему не ведет.
И не поймите меня неправильно, я понимаю, что, например, в случае изменения регуляторных требований, от которых зависит судьба компании, действительно есть смысл поднапрячься.
Только чаще всего, приходят с ад-хоками другого типа - такого, без которого можно пожить недельку-полторы до следующего спринта и ничего плохого не случится.
Так вот, еще раз:
Гибкость в Скраме - это не про то, что мы настолько гибкие, что можем менять скоуп спринта когда заблагорассудится, как некоторые думают. А это про то, что команда может деливерить ценность в течение двух недель и менять направление работы каждые две недели.