Ознакомительная версия. Доступно 1 страниц из 4
Sprint Retrospective
Цель Sprint Retrospective – запланировать повышение качества и эффективности.
Зачем нужна ретроспектива?
Это не праздный вопрос, его часто задают начальники, когда им предлагают провести ретроспективу. Они спрашивают: «Зачем? Мы можем сами все решить». Почему же нельзя сделать так, чтобы какой-то начальник или эксперт пришел, посмотрел и сказал, что команде надо делать, а что в рабочем процессе стоит изменить?
Основных причин две. Во-первых, если мы приходим к команде с готовыми решениями, возникает феномен, который называется «not invented here». Даже если члены команды понимают, что это правильное решение и его нужно выполнять, у них нет чувства собственности по отношению к нему. Такие решения, не «выстраданные» самим коллективом, а «навязанные» или предложенные сверху, имеют меньше шансов на реализацию.
Во-вторых, сейчас разработка ПО настолько сложная и запутанная вещь, что вряд ли найдется специалист, который сможет, не зная контекста, расписать, как на самом деле должны работать процессы в конкретной команде при решении определенной задачи. Чтобы это выяснить, надо что-то пробовать, проводить эксперименты, смотреть, к чему приводят те или иные решения. Только попробовав, можно понять, хороша или не очень та или иная практика в контексте данной команды.
В основе ретроспективы лежит концепция цикла Деминга, PDCA (англ. Plan-Do-Check-Act). Цель ретроспективы – к ее окончанию получить план изменений. Но важно понимать, что это не план окончательных изменений в процессе – это план эксперимента на ближайший период. Мы что-то пробуем, а потом смотрим, что из этого вышло, и на основании этого принимаем решение.
Цикл Деминга: Plan – запланируй, Do – выполни, Check – посмотри, что получилось, Act – прими какие-то дальнейшие решения, реши, что дальше делать. Ретроспектива должна проходить именно по этому циклу. Собственно, сама ретроспектива – это стадия Plan.
Короткий план:
• Плюсы. Что шло хорошо в прошлой итерации?
• Минусы. Какие проблемы были в прошлой итерации?
• Идеи. Какие идеи появились по ходу ретроспективы?
• План. Какие улучшения мы запланируем на следующую итерацию?
Эффективность
Анализ эффективности является важным процессом повышения производительности команды.
Цель
Команда должны понять, для чего они реализуют данный проект/продукт. Цель должна быть простой и понятной всем членам команды. Цель должны быть зафиксирована и доведена до всех членов команды. Цельпо мере развития продукта может меняться, но при любых изменениях в цели они должны быть снова объяснены и доведены до команды.
Оценка задач
Первый шаг к пониманию эффективности команды является оценка задач. Задачи рекомендуется оценивать в относительных величинах, сравнивая их друг с другом. Проще и легче всего внедрить оценку в Story points, когда задачи измеряются в абстрактных величинах. Команде нужно начать замерять, сколько Story points она «съедает» в конце спринта (если разработка идет без спринтов, то за неделю, две недели, месяц) и, на основе этих данных, может прогнозировать свою эффективность в следующем отрезке (спринте) разработки.
Метрики
Метрики являются следующим этапом развития анализа эффективности и прогнозирования времени достижения целей. Они помогают более точно планировать сроки и бюджеты работ, а также информировать пользователей о поставке им готового функционала.
Команды могут использовать различные метрики, но наиболее простые и эффективные на начальном этапе являются:
Velocity
Скорость работы команды. Средняя величина выполнения задач. Может измеряться, как в количестве задач, так и в Story points. Рассчитывается из среднего значения выполненных задач / Story points за последние 4–6 спринтов. Рекомендуется определять данную метрику, как по команде в целом, так и по каждому разработчику (тут имеется ввиду именно разработчик = программист). Постоянно обновляя данную метрику, можно более точно провести анализ достижения различных целей.
Code destiny
Чистота кода. Измеряется в процентном соотношении количества багов к количеству задач во всем бэклоге продукта. Индикатор отслеживается на регулярной основе, помогая определить на сколько чистый код пишет команда и не является ли количество багов в продукте критичной проблемой. Рекомендуется держать данный показатель не выше 30 %.
Дополнительные метрики
• Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки (команда должна установить, что является точкой старта и окончания работы над задачей).
• Lead Time – время от появления задачи до ее конечной поставки. Включает Cycle Time и время ожидания в очереди на реализацию (команда должна установить, что является точкой старта и окончания работы над задачей).
• WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
• Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
• Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
Команды могут внедрять много разных метрик, главное помнить, что метрики внедряются не ради самих метрик, а для того, чтобы понимать, где в процессе возникают проблемы. Если метрика не дает этого понять, то ее следует исключить и не тратить на нее время.
Метрики должны служить главной цели – повышение точности прогнозирования. За метрики, обычно, отвечает менеджер проекта (РМ).
Оценка + чек лист
В рамках разработки S-Light мы постарались устранить основную проблему Scrum – точно понять, работает ли команда в рамках фреймворка или нет.
Дальше команда может оценить, как глубоко внедрен S-Light и на сколько близко команда подошла к переходу на полноценный Scrum.
Но надо помнить, что целью внедрения S-Light не является переход в Scrum или повышения глубины внедрения самого S-Light.
С помощью данного чек листа команда может легко и быстро понять, как глубоко она внедрила S-Light. Также команда может определить, какие еще действия она можете сделать, чтобы внедрить больше элементов S-Light. Но перед планированием внедрения дополнительных элементов, команда должна для себя ответить на вопрос: а надо ли их внедрить? /
Чек-лист внедрения S-Light
Используя данный чек-лист вы легко можете оценить, на сколько глубоко вы внедрили наш метод.
При его использовании есть два простых правила:
1) Основные пункты из зеленой зоны должны быть внедрены обязательно. Без них начинать работу нельзя.
2) Зачитывать балл за внедрение пункта можно, если все пункты из предыдущего этапа
Ознакомительная версия. Доступно 1 страниц из 4
