Comments 9
Заголовок статьи взяли из опыта другой компании или просто из башки? Откуда цифры в 50 багов и 2 недели, если в итоге закрыли 26 за 2 дня
> «Научились не копить»
> «нуу у нас висит еще 20 неприоритетных багов, мы их не фиксим, но про них помним. А так мы прошли через большие изменения, и даже новый митинг создали
Проблема всех таких статей в том, что они ни о чем. Это болтология как минимум потому, что невозможно описать универсальный порядок действий при таких ситуациях. Каждая команда и ее ситуация- уникальны, различны процессы и внутренние подходы. Единственный универсальный метод - обсуждать с командой на локальном уровне. А проводить багатон со всеми разрабами чтобы закрыть четверть бэклога за 2 дня - как минимум изнурительно, как максимум - идиотизм.
Здесь как минимум две управленческие трудности: 1. отсутствие ресурсов для решения низко приоритетные задачи, у которых количество переходит в качество. 2. мотивация инженеров их решать, тем более перед новым годом.
Единственный универсальный метод - обсуждать с командой на локальном уровне.
Ну вот автор поделился своим решением, какое получилось. Значит не единственный. Можно ещё ввести SLA для решения задач, в зависимости от приоритета, и мотивировать команды укладываться в сроки. Можно организовать "bug retirement" и просто закрывать, если ни у кого так и не дошли руки. Можно конечно сказать, что все есть в ITIL, но не все организации к этому готовы.
Все верно, наша задача была — справиться с конкретной накопившейся проблемой в ситуации ограниченных ресурсов. Как я писала в статье, багатон стал разовым решением, а не традицией. Часть багов мы закрыли еще во время подготовки к нему, поэтому цифра в заголовке - 50
Вам нужна "система основанная на правилах"
Для каждой задачи назначается срок решения.
Срок можно переносить дважды, но после проговаривания проблемы, общим решением.
Если лимит переносов исчерпан, то задача либо берётся в работу, либо удаляется. Инициатор задачи ставится в известность, восстановить задачу в том же виде/контексте он уже не может.
С таким подходом беклог не растёт
Основным аргументом была мотивация команды
Ну то есть заказчикам было ок? Если так - что-то сомнительно, что просто фикс багов так уж мотивирует команды, особенно если это именно просто фикс, и он не совмещён хотя бы с рефакторингом...
Некоторые задачи сразу удалили, поскольку они потеряли актуальность, другие были не воспроизводимы, и так далее.
Получается до багатона всем было плевать, что именно попадает в бэклог и никто его никогда не пересматривал?
Мы договорились, что на багатон у нас есть два дня: в понедельник и вторник фиксим баги, в среду утром подводим итоги и награждаем победителей.
Двухдневный спринт - 26 багов... Возникает вопрос, если они настолько мелкие - почему они не фиксились раньше... Либо недостаток тестирования по итогу, либо завышенные оценки на груминге...
За статью спасибо - интересно посмотреть, где как выстроены процессы.
Ламоде явно нужно задуматься о проф. пригодности их менеджера)
Полностью поддерживаю предыдущих ораторов, вплоть до профпригодности.
После прочтения заголовка
"Шаг 1. Посмотреть бэклог и выбрать подходящие для мероприятия баги по определенным требованиям"
хочется спросить - народ в этой ваше Ламоде, а что вам раньше мешало сделать то же самое, но в нормальном рабочем процессе? И вы вообще понимаете, что такое "...отон"? Что этот ваш сотрудник, написавший статью и не затруднивший себя даже представить, хладнокровно решил свои проблемы вашим ловким манипулированием?
Когда там работал, так и делал. Перекапывал бэклог своей команды и вычищал старые баги и тех долг, подбрасывая актуальное в существующие спринты. В итоге за 3 месяца, у нас не осталось багов, большую часть задач вынесли как неактуальные, часть поделилась по приоритету и была выполнена.
Ревизию и актуальность проверял с бизнес заказчиком и техлидом.
Т.к. на скрине не вырезали названия команд, то вижу что разгребали бэклог ребят из соседней команды, моего же направления. Там до бэклога и его вычистки, видимо не доходили руки, он больше (системы существуют 5 и более лет) и менеджеры менялись стабильно раз в год/полтора. Последнее самое хорошее, т.к. преемственность не идеальная.
p.s. Никакой е****й магии баготонов. И привет ягуарам и леопардам ))
Колодец с неприоритетными багами. Как мы закрыли 50 задач за две недели и научились не копить их