Комментарии 11
Мы с командой приходили к тому, что можно коммитится не на полный объем работы, а на его часть. А оставшуюся часть, оставить на запас "если все пойдет хорошо". Ретроспективно высчитали оптимальный обьем задач, коммитимся на него с запасом (всеравно есть какая то дельта неопределенности + сразу маркировать задачи, которые не рутинные и рискуют затянутся), и также оставлять задачи, которые можем взять в работу, если у нас освободится время после приоритетных задач. Условно сделать работу на 5 без них, и на 5 со звездочкой с ними). Планирование спринта это всегда прогноз, и вряд ли он будет точным. А так у нас есть место для маневра
И продакт сыт, и разработчики целы
Забавно. Никогда не встречал менеджеров, которым было бы не всё равно на эти "цифирки".
Хотят чтобы было сделано то что запланировано, если не сделано - разбираемся почему не сделано и как сделать чтобы было сделано. И всё...
— Так получается потому, что ваши процессы - это Waterfall обернутый в спринты. - резко отрезал менеджер. — Все, что нам нужно сделать, это попросить разработчиков тестировать свои задачи.
Еще вариант, примерно той же степени бредовости, - вынести тестировщиков в отдельный проект джиры.
Плюс много, очень знакомая ситуация.
Как по мне, корень проблемы здесь лежит в разделении на фазу разработки и фазу тестирования. Если у вас не trunk-based, а один из вариантов gitflow, то в релизе всегда будет какой-то момент, когда ваш код из dev отправляется в релизную ветку. И тут получается так, что либо ваши две недели разработки, совсем не 10 дней, 10 дней минус 3,4,5 дней до отливки релиза. Либо вы заранее делите спринт на две части: неделю разработки и неделю тестирования и планируете спринт из сорока рабочих часов. Но неделя разработки в двухнедельном спринте - это очень мало для реализации требуемых фич, поэтому оценки всё равно даются нереалистичные, а разработка фич по факту переезжает в релизную ветку. Это в свою очередь приводит к ненормальному объёму миграции кода между ветками rel и dev, к ещё большему числу багов и к ещё большим затратам времени на разработку.
Проблема, вообще говоря, в самом использовании sp для оценки трудозатрат (они для этого не пригодны), в попытках забить задачами спринт (это противоречит скрамгайду), да и вообще в очевидно неверном использовании скрама и полной некомпетентности менеджеров, которые все это предлагают.
Убирается Scrum, ставится пайплайн Kanban, ПМ первращается в SDM и вы делаете такие же регулярные поставки заказчику, не выгораете и будут видны затыки, WIP и прочая шляпа.
В Scrum постоянно пытаются запихать и тестировщиков, и аналитиков и т.д., это не работает. Над этим фреймворком как только не издеваются.
Расскажу ноу-хау со старого места работы. Разносим кодеров и тестеров по временнЫм зонам, т.е. например кодеры в Японии тестеры в Англии (пример сугубо условный). Т.е. каждый день кодеры готовят к вечеру релиз кандидат, который тестеры сразу после этого тестируют. Получается что все работают 8/5 в нормальное для своей локации время, а на скорость разработки не влияет время тестирования. Если нет возможности разнести географически, тогда придется использовать ночные смены...
Хорошая статья, спасибо! Не кажется, что проблема много глубже? Просто рациональную систему оценок пытаются натянуть на нерациональный мир. Пример:
Есть турбо-разраб AAA уровня. Все сам и пишет и тестит и релизит (и требования собирает). Предположим, он выдает за спринт 100sp. Можем ли мы в нашем мысленном эксперименте гарантировать, что он будет выдавать из спринта в спринт 100sp? Нет, не можем.
Т.е за этими цифрами ничего не стоит. Эти оценки просто не могут отражать действительной картины мира, а значит мы не можем отследить их мутаций.
Пикантности добавляет то, что продуктовые команды еще комитятся на эти цифры. Т.е цифры, которы не отражают истинной картины, начинают напрямую влиять на оценки эффективности команды.
Я сам проджект, но текущую ситуацию могу описать так "Менеджменту нужно мерить и они мерят"
Складывается впечатление, что есть команда, которая ничего не хочет менять и меняться, а приходит злой менеджер и начинает мешать закрывать джирки, ещё и вопросы разные задаёт, потому что сам закрывать их не может )
По моему мнению, подобные ситуации вызваны как непониманием самого фреймворка (вполне вероятно, как менеджером, так и командой разработки) и простым нежеланием брать на себя ответственность. В скраме нет менеджера, есть dev team. И как раз задача команды каждый спринт - думать и меняться ради того, что бы сделать процесс разработки а. более предсказуемым, б. более оптимальным и в. качественным (и тут не про закрытие задач в трекере). Никто лучше самой команды этого сделать не сможет.
Факт того, что именно менеджер и есть скрам мастер, уже говорит о многом - отсутствии доверия и инициативы. Либо же компания (менеджер) не готова (не доверяет) больше делегировать команде, либо команда не готова брать на себя ответственность, а часто и то и другое.
Касательно тестирования результатов своего труда - один из ярких примеров нежелания и перекладывания ответственности, ее разделения в команде. Я как разработчик, не могу представить, что бы мог отдать работу на тестирование, не убедившись, что все в порядке. И это не дев тестирование успешных сценариев и не только вручную. Считаю, что так будет меньше сюрпризов именно в конце, уменьшает количество переключения контекста и делает меня счастливые ) Но QA действительно нужен.
Committed vs. completed, в скрам так же никто не вспоминает. Но это одна из метрик, которая косвенно может характеризовать процесс разработки, его предсказуемость. Разбиение на небольшие задачи, атомарные и частые деплои, кросс функциональные команды, написание интеграционных и функциональных тестов разработчиком, быстрая передача на тестирование, заведение spike задач, что бы лучше подготовиться к следующей итерации и т.д. - то, что обычно помогает. Но конечно, не везде и не всегда это панацея.
Для начала нужно узнать, что нужно вашему конкретному менеджеру, ну а также понять хотите ли вы из раза в раз слышать от него одни и те же вопросы. Если не хотите, а он хочет знать какую ценность даст этот спринт, нужно ему объяснить, что задачи в спринте не обязательно будут выполнены, но вы готовы сообщить ему, какие будут и какую ценность получит пользователь. И по окончанию планирования передавать эту информацию любым удобным способом. А если хочется еще и красивый график, то можно прибегнуть к спорному, но работающему подходу. Просто вынести тестирование в отдельные задачи, это может быть не привычно и не удобно поначалу, но привыкаешь быстро, а потом может даже понравится)
Committed vs Completed или как мы годами повторяем одну и ту же «ошибку»