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

Комментарии 14

Вам следует озаглавить статью «как не следует „внедрять“ скрам».

Первая ошибка: скрам не внедряется, а принимается.
Вы вообще-то с живыми людьми работаете.

Вторая ошибка: скрам не решает проблем других команд. Все равно договариваться придется. И не всегда в результате договора получится так, что все желания смежной команды будут удовлетворены скрам-командой.

И третья ошибка: скрам вообще не про доску и про автоматизацию. Как раз поменьше автоматизировать — в интересах скрам-команды. Совсем уж положиться на память не получится, поэтому задачи нужно где-то записывать. Но они служат лишь поводом поговорить, а не целью.

Ну и про то, что в скраме нет тимлида я не буду даже говорить. Ну, кто-то есть, понятно, с чем-то подобным, но только если это действительно надо и это не отдельная должность.
+100500!

Идем в раздел автоматизации в джире и настраиваем автоматическое перемещение в статус todo всех задач из статуса ready.


А это просто брилиант!
Хм. Меня тоже как-то удивило. В скрам есть (по одному документу от 2017 года). Продукт Овнер, Скрам Мастре и Разработчик. А тут про тимлидов да IT директоров написано.
У нас на работе гордо обозначалось, что мы работаем по скраму, при этом в команде не было скрам мастера, и спринты превращались из однонедельных в трехмесячные…
А выбрать самого уравновешенного и попросить его быть мастером что помешало?
эх, не моя команда была, так, что предлагать что-то было бесполезно…
А вы пробовали?

Спасибо за статью. Очень напомнило мои собственные первые шаги в сторону Agile. Не всё гладко пока, но вектор правильный.


Особенно понравилось жизненное описание проблем, фиксация достигнутых результатов (ценностей).

Можете рассказать о шероховатостях?

Реальные шороховатости лучше видны изнутри. Я могу судить только по косвенным факторам.


Все последующие спринты сделаем двухнедельными, так мы сможем экономить время на планированиях.

Выигрыш сомнительный: если спринт больше, то и планирование его займет дольше.


Спринт – это цикл получения обратной связи (разумеется, вы должны уметь этой обратной связью пользоваться). Чем он короче, тем лучше, особенно в условиях неопределенности. Но на практике не всегда удается уменьшить его до желаемого размера.


Обычно размер спринта – это срок, в течение которого команда способна выполнить минимальный законченный объем работ, который, как минимум, можно показать заказчику, а в идеале еще и вывести в продакшн. Этот срок может зависеть от проекта, размера задач в нем, технологического процесса CI/CD, слаженности работы команды, накладных издержек.


Если команда не может закончить взятые задачи внутри спринта, можно попробовать удлинить спринт. Но лучше разобраться и устранить причины этого.


Оценки не совпадают, дискуссия, обсуждение, вновь оценка… Было одно планирование, на которое мы потратили целый рабочий день, с 10 до 19 и так и не пришли к консенсусу.

Консенсус не обязателен. Важно, чтобы все участники высказались и поняли опасения друг друга. Потом обычно берут максимальную оценку.


Вообще, если группа людей ходит по кругу и не может придти к консенсусу, это означает, что они обсуждают не то, что на самом деле их тревожит. Если человек снова и снова повторяет одно и то же, значит он не чувствует, что другие поняли его точку зрения. Вместо того, чтобы спорить с ним, надо подтвердить, что вы его услышали (пересказать своими словами то, что он говорит, чего опасается, и попросить подтвердить, правильно ли вы его поняли).


Планирование вслепую

Как вариант, попробуйте покер планирования.


Вообще, мне кажется, у вас многовато параметров, таблиц и прочего учета. Попробуйте упросить процесс. Вы правильно написали, что оценка должна учитывать и сложность, и неопределенность, и объем, но после небольшой практики участники обычно могут оценить всё это интегрально одним числом в стори-поинтах.


следим за велосити каждого из команды

В Agile команда – это единое целое. Поощряется совместная работа нескольких (или даже всех) участников команды над одной задачей. Раздельный учет чего-либо разобщает команду, что наносит больший ущерб, чем может быть получена выгода (есть ли вообще она?) от индивидуального учета.


Организация статусов задач

Я не вижу у вас в процессе тестирования. У вас этим занимается отдельная команда? Такое разделение практикуют во многих организациях. И это первое, что надо устранять при переходе на Agile – включать тестировщиков в команды разработки. Здесь вы получите существенный выигрыш в производительности, а главное, в оперативности обратной связи.

Бывают задачи которые в принцыпе в 1 недельный спринт не влезают и так себе делятся на части. Особенно когда сначало бекенд должен сделать свою часть а потом фронтенд. Ну естественно до того как фронт закончит все равно нечего показывать бизнесу. Демо оно для бизнеса и ему показывать — Вот тут мы можем через Постман вот такой json отправить и такой вот получить смысла хрен целых и ноль сотых.
По моему опыту оптимальный 2 недели. Да и по опыту других людей также.
Понял.
Прокомментирую некоторые моменты. Так как заказчиков и проектов очень много, то двухнедельный спринт — 10 рабочих дней позволяет в течение дня заниматься одной задачей без переключений на другие. Если количество заказчиков упадет до 3-4, то спринт спокойно сократится до недели. CI/CD и автотест настроены на все проекты, так что тут время не тратится

попробуйте покер планирования.

Пробовали, не зашло, заменили на таблицы. Это такой покер план, но в удобное для каждого время.

Параметров много, но пока не готовы оценивать только в сторипоинтах. Но идем к этому.

В Agile команда – это единое целое.

Да, но в команде есть джуны, мидлы и сеньоры, и у каждого свой темп и производительность. Важно не замотать, а работать эффективно и без просрочек для заказчиков. За время работы примерно понятно, кто сколько в SP может закрыть от общего количества и планирование идет с учетом этого.

Я не вижу у вас в процессе тестирования.

Тестировщик в команде есть. На скриншоте воркфлоу этапа тестирования нет, так как у нас, к сожалению, один воркфлоу на всю компанию и пока нам не могут сделать собственный. Проблему решили так: сделали на доске свои статусы. На скриншоте доски видно, что после in Progress идет in testing, а затем review

Спасибо, за подробный отзыв, думал, что намного больше граблей собрал
покер план, но в удобное для каждого время

В Agile оценку задач рекомендуют делать на общем собрании команды. Так есть возможность обсудить, подсветить риски, задать уточняющие вопросы, ответы на которые сразу услышат все. Если делать оценку off-line, то теряеются преимущества живого общения (быстрая обратная связь, подтверждение правильности понимания и т.п.). Кроме того, совместная деятельность сплочает команду.


примерно понятно, кто сколько в SP может закрыть от общего количества и планирование идет с учетом этого

Для планирования используется velocity всей команды. Она учитывает всё разнообразие темпов участников команды. Индивидуальные velocity будут менее стабильными, чем velocity всей команды (сеньор ведь тоже может промахиваться с оценками отдельных задач).


Или у вас состав команды нестабилен? Если так, очень рекомендую стабилизировать его, как можно скорее. Команда, состав которой не меняется, со временем начинает работать намного эффективнее.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории