Еще более важной целью было убедить в этом бизнес-заказчика. Много сил и времени ушло, чтобы объяснить, почему нельзя переполнять спринт новыми функциями. Убеждали на срезах, совещаниях, созвонах. По их итогам готовили митинг-репорты — ключевой элемент коммуникации. После каждого совещания все участники получали письмо с подробным описанием принятых решений. Если в дальнейшем возникали вопросы или конфликты, нам было на что сослаться. Задачи на планировании мы выбирали вместе с бизнес-заказчиком. При планировании спринта внедрили систему эпиков. Вывели ее на отдельную Канбан-доску с приоритезацией по положению в колонке. Это помогало нам не тормозить важные бизнес-процессы, при этом следить и за качеством продукта, и за процессом. Перед этим мы определили, что в каждый спринт берем не более 20% задач, связанных с техническим долгом и дефектами. Остальное — бизнес-задачи.
Команда выгорала, вы им обязательные ретроспективы сделали, а в отпуск вы команду не хотели бы отпустить??
Отпуск не изменит ужасные бизнес процессы, а автор молодчина
а после отпуска возвращаться в те же условия, такое себе
Комментарий недоступен
От Идеи до реализации, спасибо за комментарий.
Описанное увеличение команды является следствием выстроенных процессов, хорошей и доверительной коммуникации с клиентом.
Мы выявили оптимальную релизную схему — 2, 5 недели. Это позволило нам:
— Устранить давление от клиента «Ну когда вы уже выпустите релиз?»
— Планировать с учетом возможностей команды;
— Прогнозировать развитие продукта.
Конечно, объем выпускаемых фич изменился в большую сторону, а техдолг и количество дефектов уменьшились.
А количество инкремента может быть разное
Спасибо за статью