Как стать автором
Обновить
1
0

Пользователь

Отправить сообщение
Спринт из 20-30 задач задерживался и ждал решения одной задачи. В результате — один человек фиксит проблему, остальные «придумывают» себе работу.
Т.к. продукт работает 24/7, а code-freeze делаем только в случае выкатки критического функционала — чем дольше спринт ждет — тем больше риск конфликтов и необходимости повторной прогонки регрессии(а то и не одной).
+ бизнес нервничает, куа нервничают, все нервничают, а нервные клетки не восстанавливаются :)
Сотрудники относятся с пониманием :) Часто инициативы для изменений приходят с ретро либо с one-2-one. Не все, что хочется можно внедрить и не все приживается, но сотрудников точно слушают и слышат.
Очень нравятся термины :) И термины кстати ровно из повседневной жизни, Вы же наверняка их тоже используете?

Дело не в 10 минутах, если бы захотели экономить — вообще отменили бы стендапы. Это больше вопрос синхронизации команды и озвучивания проблем. Иногда проблемы вскрываются там, где их вроде-бы не было (Пр: по разному поняли задачу; ждут кого-то, но не сказали об этом, либо сказали, но их не услышали).
У нас чаще всего «спринт» === «большая фича». А как его называть «задача» либо «спринт» либо «итерация», как по мне — дело десятое.

Беклоги мы тоже поделили. У каждого модуля системы свой беклог. Т.к. задач очень много — так намного удобней формировать задачи для спринта.

Пленинг покер используем, но носит он больше информативный характер. Для синхронизации команды в понимании задачи.
Может Вы можете подсказать, какой agile является правильным? :)

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность