Этапы и мероприятия Scrum

7.6. Ретроспектива

Ретроспектива - мероприятие, направленное на систематическое инспектирование и адаптацию Scrum к условиям функционирования конкретной команды. На ретроспективе должна собираться вся команда и обсуждать, каким образом сделать следующий спринт более продуктивным по сравнению с прошедшим.

В основе ретроспективы лежит концепция цикла деминга, PDCA (англ. Plan-Do-Check-Act). Цель ретроспективы - к ее окончанию получить практический план эффективных изменений, но это не план окончательных изменений в процессе - это эскиз эксперимента на ближайший период. Цикл деминга состоит из следующих этапов:

• Plan - запланируй.
• Do - выполни.
• Check - проверь.
• Act - прими какие-то дальнейшие решения, реши, что дальше делать.

Собственно, сама ретроспектива - это Plan.

Целями проведения ретроспективы являются:

• инспекция того, насколько успешно прошел спринт в отношении людей, отношений между ними, процессов и инструментов;
• определение и упорядочение того, что прошло успешно, и того, что нуждается в улучшении;
• разработка плана по внедрению улучшений в Scrum.

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

Решение проблем в Scrum - это не праздный вопрос. Невозможно сделать так, чтобы организационный руководитель или эксперт пришел, посмотрел и сказал, что команде надо делать, а что в рабочем процессе стоит изменить.

Во-первых, приходить к команде с готовыми решениями чревато отторжением предлагаемых решений. Этот феномен принято называть "not invented here" (не изобретено здесь). Тут срабатывает природная гордость и упертость человеческой натуры. Даже если разработчики понимают, что предлагаемое решение верное, у них нет уверенности в его работоспособности для их команды, плюс отсутствует "собственническое" отношение к нему. Подобные, не "выстраданные" командой решения имеют низкие шансы на реализацию. Члены команды должны набить собственные шишки проблем и определиться с решением, которое будет оптимальным для всех.

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

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

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

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

• написать …;
• принять …;
• Задачу Х выполнять с использованием подхода N.

Однако не стоит пытаться на конкретной встрече решить все проблемы сразу - для эффективной работы в следующем спринте достаточно плана из 3-6 пунктов. Слишком объемный план может в итоге оказаться невыполнимым, демотивирует команду и точно изменится через короткий интервал времени. В процессе проведения ретроспективы могут возникнуть проблемы, связанные как с Scrum, так и с его участниками:

• Команда полагает, что у нее нет проблем, Scrum-процесс хорош, и она не видит смысла в его улучшении. Ошибка. Но команде этого так просто не объяснить. Чтобы сдвинуть ее с мертвой точки, полезно пригласить на ретроспективу кого-то из менеджеров компании - заказчика или пользователей, которые имеют конкретные претензии к команде или продукту. Пользователи очень редко полностью удовлетворены. Они могут быть удовлетворены до определенной степени, но у них все равно есть какие-то мысли на тему того, что можно сделать лучше. Если такой заказчик приходит на ретроспективу и рассказывает это команде, то она вынуждена обсуждать направления для дальнейшего развития.
• На ретроспективе говорит в основном один или 2-3 человека. Ошибка. Людям всегда есть что сказать. Если внимание забирает негласный лидер, то своим доминированием он подавляет остальных членов команды. Если каждый будет высказывать свое мнение, то вероятность найти лучшие решения намного возрастет.

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

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

7.7. Краткие выводы

В этой главе мы обсудили понятие спринта, которое является центральным для методологии Scrum.

Спринт - это временной интервал, в рамках которого перед командой стоит задача реализовать согласованное количество требований, объединенных общей целью. Спринт, в отличие от обычного рабочего графика, подчинен особым принципам и в своем составе имеет ряд мероприятий, каждое из которых направлено на то, чтобы эффективным образом скоординировать процесс работы над разрабатываемыми командой задачами. Состав работ, длительность спринта фиксированы. Он повторяется до тех пор, пока есть необходимость в разработке программного обеспечения для конкретной организации.

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

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

В "Атрибуты Scrum" мы приступим к рассмотрению ключевых артефактов, используемых при работе в Scrum.