Опубликован: 24.02.2017 | Доступ: свободный | Студентов: 1315 / 245 | Длительность: 10:06:00
Лекция 7:

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

< Лекция 6 || Лекция 7: 1234 || Лекция 8 >

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

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

Что такое ретроспектива? Это регулярная встреча, на которой команда обсуждает свой рабочий процесс и что-то в нем меняет.

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

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

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

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

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

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

Ретроспектива - это мероприятие, на котором команда решает свои проблемы.

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

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

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

Существует такое понятие, как "best practice". Это тип практик, которые подтвердили свою эффективность на ряде примеров при решении конкретных задач. Несмотря на кажущийся универсализм, каждая подобная практика поможет не в любом случае. Это происходит потому, что рассматриваемую практику можно оценить только в контексте определенной ситуации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

< Лекция 6 || Лекция 7: 1234 || Лекция 8 >
Александр Борисенко
Александр Борисенко

Мне кажется, или курс сыроват. При прочтении обнаруживается ощущения размытости, неточностей и прочего в том же роде. Например - "ЦФО - центр финансовых затрат" в пункте 2.4. Это как понимать? "О" - это расшифровывается как "затрат"? Как-то довольно много воды. Кстати, почему нет ссылок на глоссарий? Только сейчас обратил внимание, что он есть. Поначалу очень удивился почему столько английских терминов без расшифровки

Андрей Дубинин
Андрей Дубинин
Россия, Калининград, МГУТУ, 2001
Berkut Molodoy
Berkut Molodoy
Россия