Комментарии 14
Первая ошибка: скрам не внедряется, а принимается.
Вы вообще-то с живыми людьми работаете.
Вторая ошибка: скрам не решает проблем других команд. Все равно договариваться придется. И не всегда в результате договора получится так, что все желания смежной команды будут удовлетворены скрам-командой.
И третья ошибка: скрам вообще не про доску и про автоматизацию. Как раз поменьше автоматизировать — в интересах скрам-команды. Совсем уж положиться на память не получится, поэтому задачи нужно где-то записывать. Но они служат лишь поводом поговорить, а не целью.
Ну и про то, что в скраме нет тимлида я не буду даже говорить. Ну, кто-то есть, понятно, с чем-то подобным, но только если это действительно надо и это не отдельная должность.
Идем в раздел автоматизации в джире и настраиваем автоматическое перемещение в статус todo всех задач из статуса ready.
А это просто брилиант!
Спасибо за статью. Очень напомнило мои собственные первые шаги в сторону Agile. Не всё гладко пока, но вектор правильный.
Особенно понравилось жизненное описание проблем, фиксация достигнутых результатов (ценностей).
Реальные шороховатости лучше видны изнутри. Я могу судить только по косвенным факторам.
Все последующие спринты сделаем двухнедельными, так мы сможем экономить время на планированиях.
Выигрыш сомнительный: если спринт больше, то и планирование его займет дольше.
Спринт – это цикл получения обратной связи (разумеется, вы должны уметь этой обратной связью пользоваться). Чем он короче, тем лучше, особенно в условиях неопределенности. Но на практике не всегда удается уменьшить его до желаемого размера.
Обычно размер спринта – это срок, в течение которого команда способна выполнить минимальный законченный объем работ, который, как минимум, можно показать заказчику, а в идеале еще и вывести в продакшн. Этот срок может зависеть от проекта, размера задач в нем, технологического процесса CI/CD, слаженности работы команды, накладных издержек.
Если команда не может закончить взятые задачи внутри спринта, можно попробовать удлинить спринт. Но лучше разобраться и устранить причины этого.
Оценки не совпадают, дискуссия, обсуждение, вновь оценка… Было одно планирование, на которое мы потратили целый рабочий день, с 10 до 19 и так и не пришли к консенсусу.
Консенсус не обязателен. Важно, чтобы все участники высказались и поняли опасения друг друга. Потом обычно берут максимальную оценку.
Вообще, если группа людей ходит по кругу и не может придти к консенсусу, это означает, что они обсуждают не то, что на самом деле их тревожит. Если человек снова и снова повторяет одно и то же, значит он не чувствует, что другие поняли его точку зрения. Вместо того, чтобы спорить с ним, надо подтвердить, что вы его услышали (пересказать своими словами то, что он говорит, чего опасается, и попросить подтвердить, правильно ли вы его поняли).
Планирование вслепую
Как вариант, попробуйте покер планирования.
Вообще, мне кажется, у вас многовато параметров, таблиц и прочего учета. Попробуйте упросить процесс. Вы правильно написали, что оценка должна учитывать и сложность, и неопределенность, и объем, но после небольшой практики участники обычно могут оценить всё это интегрально одним числом в стори-поинтах.
следим за велосити каждого из команды
В Agile команда – это единое целое. Поощряется совместная работа нескольких (или даже всех) участников команды над одной задачей. Раздельный учет чего-либо разобщает команду, что наносит больший ущерб, чем может быть получена выгода (есть ли вообще она?) от индивидуального учета.
Организация статусов задач
Я не вижу у вас в процессе тестирования. У вас этим занимается отдельная команда? Такое разделение практикуют во многих организациях. И это первое, что надо устранять при переходе на Agile – включать тестировщиков в команды разработки. Здесь вы получите существенный выигрыш в производительности, а главное, в оперативности обратной связи.
Прокомментирую некоторые моменты. Так как заказчиков и проектов очень много, то двухнедельный спринт — 10 рабочих дней позволяет в течение дня заниматься одной задачей без переключений на другие. Если количество заказчиков упадет до 3-4, то спринт спокойно сократится до недели. CI/CD и автотест настроены на все проекты, так что тут время не тратится
попробуйте покер планирования.
Пробовали, не зашло, заменили на таблицы. Это такой покер план, но в удобное для каждого время.
Параметров много, но пока не готовы оценивать только в сторипоинтах. Но идем к этому.
В Agile команда – это единое целое.
Да, но в команде есть джуны, мидлы и сеньоры, и у каждого свой темп и производительность. Важно не замотать, а работать эффективно и без просрочек для заказчиков. За время работы примерно понятно, кто сколько в SP может закрыть от общего количества и планирование идет с учетом этого.
Я не вижу у вас в процессе тестирования.
Тестировщик в команде есть. На скриншоте воркфлоу этапа тестирования нет, так как у нас, к сожалению, один воркфлоу на всю компанию и пока нам не могут сделать собственный. Проблему решили так: сделали на доске свои статусы. На скриншоте доски видно, что после in Progress идет in testing, а затем review
Спасибо, за подробный отзыв, думал, что намного больше граблей собрал
покер план, но в удобное для каждого время
В Agile оценку задач рекомендуют делать на общем собрании команды. Так есть возможность обсудить, подсветить риски, задать уточняющие вопросы, ответы на которые сразу услышат все. Если делать оценку off-line, то теряеются преимущества живого общения (быстрая обратная связь, подтверждение правильности понимания и т.п.). Кроме того, совместная деятельность сплочает команду.
примерно понятно, кто сколько в SP может закрыть от общего количества и планирование идет с учетом этого
Для планирования используется velocity всей команды. Она учитывает всё разнообразие темпов участников команды. Индивидуальные velocity будут менее стабильными, чем velocity всей команды (сеньор ведь тоже может промахиваться с оценками отдельных задач).
Или у вас состав команды нестабилен? Если так, очень рекомендую стабилизировать его, как можно скорее. Команда, состав которой не меняется, со временем начинает работать намного эффективнее.
Итерации введения скрам в компании