Видимо, скрам-мастеры работают с каким-то особенным типом личностей, возможно, это какие-то забитые снулые немощи, возможно, еще что. То есть цель вроде бы очевидна — научить людей искать улучшения и дать им время на эти поиски. Важнейшая роль по ведению команды и её совершенствованию. Команда в свою очередь решает как ей себя улучшить, а Scrum Master это исполняет и создает все условия для выявления проблем. Scrum Master играет важнейшую роль в мероприятии Sprint Retrospective Meeting.

Если подытожить, скрамгайд предлагает проводить ограниченную во времени встречу, на которой скраммастер как-то побуждает участников привносить идеи по улучшению качества продукта, технологии или процесса работы. Опять же, варианты исполнения здесь могут быть разными. На самом деле для ведения более эффективных встреч и нужен Scrum Master, который, к примеру, может попросить команду выкрикнуть идеи во время схватки. Scrum Master может так и не делать, а вообще пойти по кругу и попросить каждого участника назвать одну любую вещь на выбор, которую команда должна начать делать, или прекратить, или продолжить. Независимо от того, насколько хорошо работает Scrum Team, всегда есть возможность улучшить показатели. Итак, я утверждаю, что если в команде скрам-ретроспектива проходит больше Х раз, вы ухудшаете работу команды, инфантилизируете работу людей и размываете их веру в то, что что-то осмысленно может и будет исправляться.

Sprint Retrospective Meeting, наравне со Sprint Reviews Meeting, проводится в последний день спринта. Задачи, в отличие от Sprint Reviews Meeting, ставятся совершенно иные. Если обзорная встреча имеет цель посмотреть на результат продукта, то ретроспектива призвана посмотреть на результат команды. Повторю свой тезис — скрам-ретроспектива — плохое место для разруливания как рабочих, так и межличностных конфликтов в команде. Разруливайте их минимальным числом участников, и эффективнее, и время других сэкономите. Щас я попрошу показать мне 26 значимых исправленных проблем, приведших к улучшению процесса / качества, к более эффективному производству.

Пример Sprint Retrospective Meeting в разработке интернет-магазина

Как видно, высказывать идеи по улучшению можно совершенно разрознено, ведь этих точек соприкосновения с рабочим процессом может быть огромное множество. Команде однозначно следует продолжить использовать текущую систему контроля версий и облачных сохранений, с ней мы менее беспокоимся о потерях и более концентрируемся на работе. После завершения Sprint и проведения Sprint Reviews Meeting, команда Scrum собралась для обсуждения эффективности её работы, которая была оценена каждым самостоятельно.

Если требовать целевым артефактом гарантированный список улучшений, то вероятность значительных улучшений заранее неивестна. Такая работа по определению не может иметь целевым артефактом гарантированный список улучшений. Живой программист, как мне кажется, рад будет процесс, инструментарий или код улучшить. Я постулирую, что необходимый для осмысленной инспекции объём работы варьируется и не может быть дискретен типа “1 итерация”. Под значимых я имею в виду влияющих значительно на производственный процесс. Скрамгайд упоминает неоднократно, что нужна фасилитация, нужно как-то побуждать к рефлексии и к тому, чтобы люди высказывались, чтобы та самая инспекция проходила.

retrospective meeting это

Давайте еще посмотрим в описание ретроспективы в скрам-гайде, дабы собрать основные мысли. Создание Product Backlog – главная задача Product Owner. Эффективность работы команды напрямую зависит от правильного составления бэклога.

Scrum retrospective meeting — плохо, дорого, избыточно

Каждый божий раз в скрам-ретроспективе одними и теми же инструментами мы вытягиваем и вытягиваем из людей даже не улучшения, а “что болит”. Например, онбординг нового сотрудника ментором заканчивается тогда, когда сотрудник стал достаточно производительным. Поиск багов в релизе заканчивается тогда, когда определённая планка качества взята. Обучение команды скраму на курсах заканчивается https://deveducation.com/ тогда, когда (ха-ха) сотрудники достаточно поняли скрам. Но у каждого бизнес-процесса (поиск дефектов, рефакторинг, обучение, да что угодно) есть достаточный результат, после которого теми же средствами почти не достигается улучшение. В прошлой проблеме (побуждение к инспекции) я спрашивал, помните ли вы, какие 26 значимых проблем вы нашли после побуждений к инспекции.

  • То есть цель вроде бы очевидна — научить людей искать улучшения и дать им время на эти поиски.
  • Решения выносимые на Sprint Retrospective Meeting исходят именно от команды и она решает как лучше устроить работу в будущем.
  • После завершения Sprint и проведения Sprint Reviews Meeting, команда Scrum собралась для обсуждения эффективности её работы, которая была оценена каждым самостоятельно.
  • Scrum Master может так и не делать, а вообще пойти по кругу и попросить каждого участника назвать одну любую вещь на выбор, которую команда должна начать делать, или прекратить, или продолжить.
  • На самом деле для ведения более эффективных встреч и нужен Scrum Master, который, к примеру, может попросить команду выкрикнуть идеи во время схватки.
  • Но я стараюсь находить причины формирования избытка давления, а не надеяться, что мой “спуск пара” сработает вдолгую.

Логическим завершением Sprint является готовый продукт, который и демонстрируется на Sprint Retrospective Meeting. Я считаю, что команда должна продолжить использовать текущий https://deveducation.com/ вид Product Backlog, он оптимально подходит. Я постулирую, что если постоянно формируется избыток давления в коллективе, то причиной тому лишь неумелый менеджмент.

проблема №8: “психологический выдох, спуск пара”

Да, это идет немного вразрез с первым тезисом доклада, но я надеюсь, что таким набросом я заставил вас задуматься. Необходимость инвестиций в обучение по определению должна иметь обоснование в недостатке знаний/умений. Таким образом, с гарантированно бОльшей эффективностью можно потратить это время на реализацию уже запланированных улучшений с хорошей прозрачной эффективностью.

Команда разработки одна из самых основных модернизирующихся элементов Scrum Team. Решения выносимые на Sprint Retrospective Meeting исходят именно от команды и она решает как лучше устроить работу в будущем. Scrum Master составляет список всех пожеланий и затем устраивает голосование. Во время голосования команда решает, что из предложенного надо первым делом внести в очередь улучшений и исправить в следующем спринте, а что оставить на потом. Мне кажется, команде надо прекратить использовать текущую IDE, её «неповоротливость» замедляет работу.

retrospective meeting это

Но я стараюсь находить причины формирования избытка давления, а не надеяться, что мой “спуск пара” сработает вдолгую. В рамках инструментария скрама — если конфликт мешает достижению цели спринта, то он должен был быть вынесен на daily scrum и пофикшен прямо сразу. Дальше мы, видимо, голосуем, все вместе, shared picture же, чья вытянутая на свет божий боль была больнее.

проблема №4: синхронность встречи

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

Sprint Retrospective Meeting – Ретроспектива в Scrum

Целевой артефакт ретроспективы — план улучшений, берущийся в работу. Весь процесс разработки делится на специальные итерации – спринты. Во время спринта и происходит вся жизнь команды и весь смысл методологии.

Во время Sprint

Серьезно, скрам-гайд пишет, что скрам-мастер побуждает к изменению процессов в ответ на обнаружение проблем или неэффективностей. Ну то есть если у человека где-то болит, то его надо побуждать убирать боль. Вот мой первый плевок в сторону скрам-ретроспективы — мы не даем людям учиться. Мы каждый раз как из детей вытягиваем и вытягиваем “а где же вавочка где же бобо”.

Роли в Scrum

И скрам-мастер раз от раза к этому команду понуждает. Я говорю лишь о ретроспективе скрамоподобной, завершающей какую-то ограниченную во времени командную итерацию разработки. Вся Scrum Team – как объединение Scrum Master, Product Owner и Development Team улучшает себя постоянно. Sprint Retrospective Meeting является одним из важных мероприятий по улучшению.

Ясность задач и их правильное расположение приводят к лучшим показателям команды, которые рассматриваются на Sprint Retrospective retrospective meeting Meeting. Самым распространенным и простым способом (что не отменяет его эффективности), является способ Start-Stop-Continue.

Автор: Александр Петров