Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Системный и бизнес-анализ доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 13
У меня следующий подход - мы договариваемся об обьеме работы который важен и может быть выполненен при самом худшем сценарии, но ПО будет доволен, а остальное это то, что мы постараемся выполнить, но не обещаем закрыть на 100 процентов. Вот эти задачи становятся кандидатами на выбывание в случае критической задачи, которая пришла после планирования. При этом не замарачиваемся над сравнением их размера, тут обычно два подхода - 1) одна задача пришла, другая ушла по менее значимости 2) все оставляем, но сдвигаем прироритеты. В любом случае у команды остается чувство выполненности поставленной задачи, а для ПО не является сюрпризом, что что-то не сделали, так как команда обязывалась закончить оставшееся. Другой момент если слишком часто такие прилёты. В этом случае надо разбираться с процессом и пересматривать договоренности или формат работы. В противном случае это превратиться в привычку и размер "обещанного" или в терминологии нашей команды "confident scope" будет уменьшаться и утратить свою ценность.
Ну это идеальный план, да. Особенно когда команда сама готова быть вот настолько адаптивной. Потому что у меня несколько раз был опыт когда тимлиды разработки, а иногда даже проджекты, до последнего бились за то чтобы все спринты были заранее распланированными и статическимию. А то, что проект только запустился – это проблемы продактов и бизнеса, что они не могут за месяц до начала спринта спланировать какие критические задачи появятся у проекта у которого в данный момент два юзера с оборотом в сотню баксов. Особенно когда за спиной такой команды стоит целый департамент без опыта запуска совсем новых продуктов, но с многолетним опытом поддержки существующих – вот это изменение рабочего подхода становится достаточно весомой задачей, как по эффекту в результате, так и по сложности в процессе.
Скорее изменилась одна величина — горизонт планирования. Насколько далеко вперед можно планировать, прежде чем реальность обнулит план. До прода он измерялся месяцами. А после запуска парой задач.
Надо смотреть статистику. Но обычно на внеплановые просто фиксированный резерв при котором по статистике плановые задачи редко вытесняются. Задача оптимизации на основе статистики.
Так и есть, тут только особенность в том, что на этапе когда проект запускается, слишком много критов возникает и выходит, что плановые задачи постоянно вытесняются. Сейчас подумал, что вот этот этап стабилизации после запуска я бы назвал "этапом накопления техдолга" :-). Что в этот момент спасает - то, что не смотря на костыльность срочных решений для критов, получается все эти решения как-то документировать и сохранять. В итоге склады с костылями не теряются, остаются видимыми и после стабилизации команда видит, что нужно причесать.
Обычно на внеплановую деятельность закладыаается бюджет внутри спринта.
Полезно также на тушение пожаров выделять отдельного человека с ротацией каждые неделю или спринт. Он будет защищать команду от постоянного дергания и он же будет выступать бюджетом на внеплановую деятельность.
Далее стоит понять, откуда берутся внеплановые таски. Если это критические баги, то нет ли в них паттерна. Не являются ли они следствием нарушения какого-то процесса в проектировании/разработке/тестировании? Возможно, удастся устранить первопричину вместо постоянной борьбы со следствием. Либо выявить новые проблемы превентивно, а не посфактум - тогда их можно будет вписать в спринты.
Если это критические фичи, то разобраться, кто именно и по каким критериям определяет критичность. По моему опыту, в большинстве случаев критичные фичи на самом деле не критичные. Просто стейкхолдеры умышленно перекручивают важность, т.к. видят в этом эффективный способ решения своей задачи.
да на этапе запуска проекта "первопричина" – это чаще всего пропущенные какие-то корнер кейсы на этапе проектирования архитектуры. ну т.е. когда проект живет уже несколько лет то да, там могут быть какие-то нарушенные принципы в проектировании, а именно на старте обычно просто не учтенные моменты какие-то
В статье не нашел ни слова про цель спринта. А это ключевой элемент. Спринт, как и скрам в целом, предназначен для оптимизации business value. Если спринт не является продуктовым экспериментом, то это бесполезный контейнер, он ничего не оптимизирует. Канбан метод, вы правы, напротив очень помогает, потому что в 99% случаев команде надо оптимизировать delivery, а не business value. Потому что человек, который отвечает за окупаемость разработки в команде как правило не присутствует - он слишком высоко сидит, чтобы спускаться на уровень команды (а делегировать ответственность за стратегические цели по продуктовым/бизнес метрикам он не готов). В таких условиях команда вообще никак не может повлиять на business value, и единственное, что она может - улучшать delivery, и тогда спринт, обзор спринта, планирование спринта - это бесполезные ритуалы.
ага, пост в принципе как раз про это – что неоднократно встречались ситуации когда спринт являлся лишь контейнером и вся работа по скраму вокруг него была скорее симуляцией(и самообманом) оптимизации business value, а не ей самой. потому что на этапе запуска продукта об оптимизации еще слишком рано говорить
На этапе маркетингового запуска продукта (официального выхода продукта на рынок), не происходит ничего такого, что бы принципиально отличалось от других этапов (до запуска, после запуска).
Любые действия бизнеса с участием каких-то серьезных изменений в кастомной IT-инфраструктуре бизнеса (тот самый production, который почему-то постоянно называют продуктом или проектом, и из-за чего упускают возможность понять реальный проект и реальный продукт) являются экспериментами. Эти эксперименты не всегда связаны с изменениями в кастомной IT-инфраструктуре, но серьезные изменения в кастомной IT-инфраструктуре по инициативе бизнеса всегда связаны с экспериментами. И существование этих экспериментов абсолютно не зависит от того, применяют разработчики скрам или они перешли на канбан-метод.
Реальный продакт (который отвечает за ROI/P&L, а не тот, у которого в профиле под аватаркой написано Product Owner) всегда работает над тем, чтобы растить бизнес-метрики. Помимо GTM, это всегда рискованные гипотезы запуска разных инициатив, рискованность которых снижается с помощью тех самых экспериментов. И некоторые риски связаны с long term operational costs или customer satisfaction (то самое business value в разработке). Для снижения таких рисков ему (продакту) приходится идти в разработку. Больше ему разработка по большому счету ни для чего не нужна (ему нужна эксплуатация / поддержка).
И тут всплывает реальная проблема, из-за которой попытки крутить и оптимизировать эти эксперименты (которые в скрам-гайде называются спринтами) чаще всего являются симуляцией. Продакт не хочет напрямую общаться с разработчиками про реальные цели фичей, которые он просит запилить. Он не хочет общаться с технарями про product goal и business value. Цитирую: "О чем с ними вообще можно говорить? Они на своём птичьем языке говорят, я их не понимаю". И/или происходит назначение переводчика с русского на русский: "У меня нет на это времени. Пусть проджект/продакт/аналитик займутся."
И в этих словах много истины, потому что разработчики как правило действительно не хотят (подчеркиваю - не "не могут", а "не хотят") разбираться в том, как устроен продукт заказчика и бизнес-модель вокруг него. Из-за этого в кастомной IT-инфраструктуре процветает архитектурная космонавтика и неустраняемый техдолг: вечная непредсказуемость хотелок бизнеса и их такое же вечное несоответствие архитектуре "продукта" (слово не случайно взято в кавычки именно тут, а не ранее).
Надо сказать, что когда технари хотят разобраться в продукте и бизнес-модели, то в большинстве случаев они натыкаются на непонимание со стороны продакта "Вам это зачем?". Ему даже в голову не может прийти, что запредельная совокупная стоимость владения продуктом связана именно с тем, что бизнес и его кастомная IT-инфраструктура написаны на разных языках и на любой чих нужен переводчик. Сильная разница между бизнес-моделью и архитектурой = много legacy, слабая разница = мало legacy.
Но (по разным причинам) скрам-то всё равно хочется применить, мы же хотим business agility. И вместо того, чтобы пойти в бизнес и найти там реальные спринты (эксперименты по снижению соответствующих рисков), менеджмент (а я встречал, когда технари сами) начинают крутить свои фейковые никому нафиг не нужные спринты. По этой причине очень распространено заблуждение, что спринт нужен для фиксации обязательств по поставке на период времени. И вроде бы всё по scrum guide, кроме "сущей мелочи" - sprint goal и product goal либо отсутствует, либо не имеют ничего общего с реальными ограничениями роста бизнеса заказчика.
И когда этот цирк с конями надоедает, от безысходности идем в kanban-метод. Хотя kanban-метод и scrum-фреймворк нельзя сравнивать и тем более противопоставлять. Потому что они, как уже наверное стало понятно, применяются на совершенно разных уровнях: kanban-метод для управления delivery, а scrum-фреймворк для управления business value. И поэтому они отлично сочетаются вместе, если бы не всё вышесказанное.
Спринт хорош на поддержке изменений готового продукта (сопровождение с небольшими доработками), когда от заказчика идут потоком хотелки на доработку. Вот тут да, мы говорим в какой спринт мы это готовы сделать, сколько это стоит в трудоёмкости, и заказчик понимает что в какой спринт будет сделано и когда ждать свои пожелания. И до спринта должно быть планирование, может прям с заказчиком).
А когда мы разрабатываем новый продукт или его новую версию, делаем доработки по контракту - там спринты выглядят странновато... Там уместенее водопадный гант + разделение на PI или релизы (мажорные, минорные и т.д.) - так понятнее. Но спринты все равно живы))). Хотя задачи просто перелазят из одного в другое тут они служат для самого разработчика или аналитика - вот мой фронт работ на 2 недели. Неделя - мало, можно не успеть получить информацию, 3 - много, сложно накидывать работы на большие сроки. Хотя можно и на месяц планировать, если люди привыкнут.
все так. я пришел к мысли, что важно в первую очередь себе самому, а во вторую очередь команде смириться с тем, что "спринты" на этом этапе – это лишь контейнеры для хоть какого-то упорядочивания хаоса, а не реальный инструмент планирования. в этот момент жить все становится легче.
ну и, понятное дело, в момент устаканивания проекта, важно обратно вернуться к нормальному планированию, а не застрять в жонглировании асапами :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я перестал верить в спринты