Ретроспектива предназначена для обсуждения ошибок

Ретроспектива спринта в Scrum (или просто «ретро») — это важное мероприятие, от реализации которого зависит развитие команды и эффективность процессов в команде.

Что такое ретроспектива в Скраме

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

Миша Ряженка

Founder, Executive Partner

Зачем нужна ретроспектива

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

Миша Ряженка

Founder, Executive Partner

Как проходит ретроспектива

За процесс ретроспективы отвечает Скрам–мастер. Ключевой принцип ретроспективы заключается в том, что мы по–человечески относимся к любым косякам и ошибкам, при этом обращаем на них внимание.

Миша Ряженка

Founder, Executive Partner

Что такое ретроспектива в Скраме (v2)

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

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

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

Зачем нужна ретроспектива (v2)

Согласно Scrum Guide, ретроспектива — это «возможность для Скрам–команды провести инспекцию, направленную на себя, и создать план улучшений командной работы в следующем Спринте».

Напомню, что прозрачность, инспекция, адаптация — это «три кита» Скрама. Это основы, на которых базируется этот фреймворк. Это основа ценностей Скрама.

Это значит, что если вы не делаете ретроспективу, или делаете ее недостаточно качественно — вы рискуете разрушить основу Скрама — инспекцию. В результате вы можете начать получать плохие результаты от командной работы.

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

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

Именно поэтому нужна ретроспектива.

Вместе запустим вам B2B–продажи в Европе

Программа по выводу консультантов, экспертов, тренеров, трекеров и коучей на англоязычный европейский рынок

Как проходит ретроспектива (v2)

За процесс ретроспективы отвечает Скрам–мастер. Именно он следит за качеством процесса работы («как» делается работа, насколько процесс работы эффективен).

Для Agile–подхода к работе характерна фокусировка на человеческие отношения. В связи с этим ключевой принцип ретроспективы заключается в том, что мы по–человечески относимся к любым косякам и ошибкам, при этом обращаем на них внимание.

Для более «классических» форм менеджмента привычными являются такие мероприятия, как оценка, осуждение, порицание, санкции, и даже угрозы. Это все неприемлемо, если мы реализуем agile: ведь «Люди и взаимодействие важнее процессов и инструментов».

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

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

• Что нужно начать делать? (Start)
• Что нужно продолжить делать? (Keep)
• Что нужно прекратить делать? (Stop)

В этим вопросам можно добавить «вариации»:

• Что нужно делать больше? (More)
• Что нужно делать меньше? (Less)

Фиксировать итоговые решения можно либо просто вербально (на уровне словесной договоренности), либо можно сделать на отдельной доске / флипчарте. Последний вариант обычно более предпочтителен, так как вы делаете ваши договоренности (commitment) визуализированными и прозрачными.

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

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

Вопрос «Что нужно начать делать?» имеет своей целью внедрение новых полезных особенностей командной работы.

Ситуация постоянно изменяется, как и тип работы, который выполняется в конкретный момент. Возможно, для новой работы или для работы в новых условиях вам нужны совершенно новые способы взаимодействия — между командой, с клиентами, стейкхолдерами и т.д.

Вопрос «Что нужно продолжить делать?» направлен на выявление хорошо работающих моделей. Это повод для команды зафиксировать, что уже работает хорошо, и каких стандартов работы следует придерживаться.

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

Вопрос «Что нужно прекратить делать?» — очень важный. Он направлен на выявление всего того, что не ведет к ценности и к командному результату.

Это очень важно, потому что — как это ни странно — команды и люди в целом всегда склонны делать не только то, что полезно, но и то, что не является полезным. С точки зрения Lean мышления такие действия являются потерями — они не ведут к достижению ценности, а значит, они совершаются «впустую» и даже в минус (потому что та же самая энергия и время могли быть инвестированы в полезные действия).

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

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

Скрам–команда должна быть единой и целостной системой. Ретроспектива должна развивать и укреплять эту целостность.

Миша Ряженка

Founder, Executive Partner

Сколько длится ретроспектива?

Как правило, длительность ретроспективы напрямую зависит от длительности спринта. Рекомендуется 45 минут на каждую неделю спринта (например, спринт одна неделя — 45 минут, спринт четыре недели — 180 минут).

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

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

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

Это в принципе касается и других событий / церемоний Скрама. Вам нужны рамки и структура — просто эти рамки можно определять и планировать. Именно так проявляется гибкость (Agile).

Миша Ряженка

Founder, Executive Partner

Когда проводить ретроспективу?

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

Иногда бывает полезным делать ретроспективу конкретных мероприятий и событий — также сразу после них.

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

Миша Ряженка

Founder, Executive Partner

Ошибки в проведении ретроспективы

• Ретроспектива — это не время для решения проблем. Проблемы нужно решать сразу.

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

Если вы будете решать содержание на ретроспективе — вы упустите что–то очень важное в работе. Все важные вещи будут откладываться на ретроспективу. И это неприемлемо.

• Фасилитация без навыков фасилитации.

Проведение ретроспективы в Скраме очень тонкий процесс. Здесь можно совершить много ошибок. Самое опасное — что вы можете подтолкнуть команду к решениям, относительно которых у них нет внутреннего согласия.

Тогда они будут воспринимать такие решения как навязанные, подорвется их доверие и мотивация к работе.

Решения должны быть сгенерированы именно всей командой. Поэтому важно учитывать мнения каждого, каждый должен быть выслушан.

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

Миша Ряженка

Founder, Executive Partner

Кратко про ретроспективу в Скраме

• Ретроспектива — это мероприятие / церемония Скрама, которое проходит в конце спринта.
• Ретроспектива позволяет принимать новые решения о том, как команда может работать лучше.
• Проводит ретроспективу Скрам Мастер. У него должны быть навыки фасилитации мероприятий.
• Результатами («артефактами») ретроспективы должны быть новые решения о том, как команда будет работать дальше — что начнет делать, что перестанет, что продолжит и т.д.

Модель этапов ретроспективы

Представленная в книге авторская модель этапов ретроспективы основана на оригинальной модели этапов Эстер Дерби и Дианы Ларсен (Дерби Э., Ларсен Д. «Agile ретроспектива: как превратить хорошую команду в великую»).

Что такое ретроспектива и ее значение

Что такое ретроспектива и ее значение

Согласно Scrum Guide ретроспектива завершает спринт.

Её смысл заключается в том, чтобы остановиться и «заточить пилу», не застревать на текущей неоптимальной методике работы.

Постоянный анализ и внесение, как правило, небольших корректировок позволяет рассматривать ретроспективу как инструмент более быстрого выявления рисков и более эффективного управления ими.

Будучи ориентированными на непрерывное развитие, ретроспективы способствуют формированию обучающихся организаций и являются отличным инструментом для инициирования изменений в организациях вообще.

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

Agile–ретроспективы полезны и в личной жизни.

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

Чем ретроспектива отличается от обсуждения с целью извлечения уроков из произошедшего? Главное – команда не ждет окончания проекта, чтобы провести ретроспективу и сформулировать гипотезы для проведения изменений.

Ретроспектива (или просто ретро) — это специальная встреча, которая проводится по итогам одного или нескольких спринтов. На ней команда подводит итоги проделанной работы и рефлексирует о проведенном времени.

Ретроспектива — важный атрибут работы по гибким методологиям. Она помогает команде:

• взглянуть на себя со стороны, оценить свою работу;

• на ранней стадии выявить проблемы в коммуникации и сложности в рабочих процессах;

• найти способы и составить план решения этих проблем;

• сгенерировать идеи по улучшению рабочего процесса.

В общих чертах ретроспективу можно свести к обсуждению ответов на следующие вопросы:

• Что было хорошего в прошедшем спринте? Что помогало работать?

• Что мешало сотруднику в работе?

• Что или кто может помочь ему работать лучше?

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

Этапы ретроспективы

Существует множество возможных сценариев встречи. «Классической» считается структура ретроспективы из пяти этапов.

1. Создание атмосферы. Ведущий ставит цели ретроспективы, обозначает тайминг и делится ожиданиями от встречи. Еще одна цель этого этапа — настроить участников встречи, «растопить лед» между ними и фасилитатором. Для этого можно проводить активности, не связанные с работой.

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

3. Формирование понимания. Рефлексия. Участники либо напрямую делятся проблемами, либо выявляют их в процессе обсуждения. Далее можно переходить к генерации идей по их решению. Можно обращаться к разным методикам мозгового штурма.

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

5. Завершение. Закрытие встречи: команда фиксирует все, к чему пришла в процессе. Команда выбирает, что будет применяться в работе со следующей итерации. Далее фасилитатор подводит итоги встречи, а участники благодарят его и друг друга за проведенное время.

Как проводить ретроспективу?

Решите, как часто проводить ее

Частота проведения ретро зависит от вашего стиля работы.

• Если команда работает по SCRUM или просто делит проект на итерации, ретроспективу стоит проводить после одного или нескольких спринтов — в зависимости от их продолжительности.

• Если же стиль работы команды ближе к Kanban и предполагает непрерывность рабочего процесса, ретро следует проводить, например, ежемесячно или ежеквартально.

Найдите фасилитатора

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

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

• руководитель проектной команды;

• начальник отдела или структурного подразделения;

• SCRUM-мастер или Agile-коуч;

• человек со стороны — начальник другого отдела или специально нанятый человек.

Кроме того, на плечи фасилитатора ложится выбор формата и сценария встречи.

Выберите формат и соберите сценарий

Если вы решили провести ретроспективу по «классической» пятиступенчатой структуре, выберите формат для каждого из этапов. Поможет в этом конструктор ретроспективы в Аспро.Agile.

Однако не стоит использовать один и тот же сценарий для каждого ретро — такие встречи быстро наскучат команде и будут восприниматься как часть рабочего процесса. Сочетайте разные форматы активностей и генерируйте уникальные сценарии для каждой ретроспективы.

Подберите удобный тайминг

Будьте готовы к длительной дискуссии. Стандартная продолжительность ретроспективы — 1-3 часа. В зависимости от продолжительности итерации, по итогам которой проводится встреча.

От уставших коллег в самом конце рабочего дня вы узнаете мало полезного. Поэтому выделите несколько часов и подберите оптимальное для команды время встречи.

Ретроспективу можно провести:

• во второй половине последнего дня спринта,

• утром в день планирования следующего спринта.

Найдите подходящее место

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

Учтите, что для многих форматов ретро вам может потребоваться физическая доска или флипчарт для пометок.

Из-за искажений в понимании agile-философии, а точнее из-за сужения этого понятия до методик и практик разработки ПО, также сузилось и тем самым обесценилось понятие ретроспективы до простого ритуала с опросом команды о том, «хорошо ли мы разрабатывали наш продукт и что мы можем делать, чтобы разрабатывать продукт лучше». Между тем командная ретроспектива – отличный инструмент управления непрерывными изменениями в компании, в подразделении, в команде.

Ретроспектива – это рефлексия о прошлом с целью улучшить картину будущего

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

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

Мы же поговорим о ретроспективе в контексте продуктовых команд. С какими последствиями встречаются продуктовые команды, которые не используют этот инструмент или используют его номинально, поверхностно:

Низкий eNPS. Другими словами, команда несчастна (выгорела) и не удовлетворена процессами, инструментами, коммуникациями

Невысокая производительность команды

Недостигнутые продуктовые метрики

Повторяющиеся проблемы в продукте.

Низкое качество продукта, и, как следствие, – недовольный клиент/потребитель продукта

Частые разрывы в коммуникациях в команде

Сложный поиск и обмен информацией

Высокая текучесть персонала

Любой из этих признаков говорит о том, что необходимы качественные изменения

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

Рефлексия в рамках сессии может охватывать разные уровни взаимодействия:

Внутренние коммуникации в команде

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

Продукт, его характеристики и план развития

Технологии, производственные процессы

Инструменты, которые использует команда для решения задач на разных уровнях

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

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

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

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

Таким образом, ретроспектива – это не только способ вовлечения сотрудников в рабочие процессы и задачи, но еще и мощный инструмент развития инициативы: каждый сотрудник имеет возможность высказывать предложения, участвовать в изменениях, непосредственно своим вкладом влиять на то, как будет выглядеть рабочий процесс, какими инструментами будет пользоваться команда, какие позитивные изменения будут внедряться в области коммуникаций и общего взаимодействия.

Системное использование ретроспективы как инструмента управления изменениями дает уверенность в том, что будут внедряться только релевантные, действительно ценные для роста компании и развития продукта изменения, так как инициатива исходит от команды – от тех людей, которые пользуются предоставленными им инструментами и процессами.

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

Как подготовиться

Готовиться необходимо заранее. Это аксиома. И время подготовки стоит рассчитать исходя из того, что оно будет не меньшее, чем время, которое планируется на само проведение.

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

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

Продумайте заранее, какой состав участников ретроспективы необходим. Кто еще, кроме членов команды, может быть полезен на ретро.

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

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

Использовать онлайн-инструменты для опросов. К примеру, такой Happiness Radar, который позволяет быстро понять настроение команды 

Делать включения в виде экспертных выступлений, заранее договариваясь об этом с коллегами (например, ресерч и небольшой доклад на 10 минут на какую-то актуальную для команды тему)

Готовить графики или чарты по производственным метрикам для обсуждения динамики

Какие правила будут полезны при проведении ретроспективы

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

Таймлайн и его соблюдение

Заранее обозначенная повестка

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

Беззвучный режим для гаджетов

Тем не менее в силу специфики встречи есть необходимость более тщательно проработать отдельные аспекты взаимодействия.

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

Договоритесь с кем-то из коллег о помощи в ходе ретро – время от времени смотреть на видео и убеждаться в вовлеченности коллег. Если участие спадает – скучные лица, отсутствующий взгляд, много выключенных видео – на этот случай стоит запасти любого рода «энерджайзеры»: физические упражнения, аплодисменты, короткие перерывы на кофе или телефонные звонки.

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

При этом нужно создать поддерживающую и безопасную атмосферу. На время проведения ретроспективы следует забыть об иерархии. Каждое мнение и вклад каждого имеют равную ценность. Задача участников ретроспективы – вносить позитивные изменения, а не искать виноватых и укорять за ошибки.

Не забывайте о юморе. Чувство юмора помогает легче преодолевать трудности! Например, вот так одна из команд обсудила совместную внерабочую активность:

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

Какие инструменты полезны для групповых обсуждений

Используйте онлайн-инструменты для общения. Например ZOOM или доски в Miro. Это прекрасный инструмент не только для фиксации договоренностей или планирования изменений, но и для такой важной части ретроспективы, как сбор мнений или генерация идей.

В качестве инструментов визуализации и фиксации мнений можно использовать ментальные карты (mind maps) https://www.mindmup.com/, https://milanote.com/.

Неплохо сокращает время ретроспективы, но при этом дает возможность каждому участнику высказаться работа в мини-группах. К примеру, ZOOM позволяет создавать команды в рамках одного звонка, и для каждой команды можно заранее подготовить доски в Miro или другом инструменте онлайн-коллаборации. Формируйте группы по 4–5 человек, причем старайтесь делать их кросс-функциональными, например, если в обсуждении участвуют разработчик, тестировщик, дизайнер и аналитик – пользы и инсайтов от такой коллаборации будет больше, чем если группа будет состоять только из разработчиков или только из дизайнеров.

Хорошая практика в рамках ретроспективы – ранжировать идеи изменений и отбирать те, которые необходимо внедрить в первую очередь. Во-первых, для начала идеи важно кластеризовать (объединять в группы по теме). Это можно сделать в диалоге с командой, попутно объединяя дубли. И уже кластеризованные идеи можно включить в механизм голосования – с помощью того же ZOOM, или в командном чате в Telegram, или с помощью веб-форм. А можно ранжировать идеи с помощью меток прямо на доске в Miro.

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

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

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

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

Если вы начнёте гуглить, берегитесь: на вас вывалится пачка статей с личным опытом скрам-мастеров о том, как разнообразить процесс ретро с помощью самых разных методик. Подчас — похожих на сектантство. Но мы всё отфильтровали, не переживайте.

Время на проведение ретроспективы
Есть общие временные рамки, зависящие от длины спринта:

• спринт в 4 недели: до 2х часов на ретро,
• спринт в 2 недели: 1−1,5 часа на ретро,
• спринт в 1 неделю: 45 минут на ретро.

В Сибирикс стандартные спринты длятся 2−4 недели, и 1 часа на ретроспективу вполне достаточно, чтобы обсудить плюсы и минусы, предложить направления для улучшений и сформировать задачи (дальше поймёте, почему).

Участники и роли
На ретроспективу зовется вся команда. Вот прям ВСЯ — в идеале, никто не должен быть в отпуске, на звонке, на другом проекте (с которого нельзя переключиться). От полноты состава зависит успех ретро. Помимо команды присутствует Владелец продукта (кто такой — смотри здесь) и Скрам-мастер.

У нас в роли владельца продукта выступает руководитель проектов: он присутствует на всём ходе проекта, знает все клиентские пожелания и имеет влияние на команду разработки.

Этапы ретроспективы
Классически их пять:

1. открытие,
2. сбор данных,
3. генерация идей,
4. составление плана действий,
5. закрытие.

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

Василий Кудрявцев

ведущий программист и Scrum-Master, компания CUSTIS

Журнал «Открытые системы», январь 2011.http://www.osp.ru/os/index.html

Статья в рубрике «МАСТЕР-КЛАСС ОС».

Agile-методологии проникли в российскую индустрию разработки программного обеспечения уже несколько лет назад и имеется немало отчётов и статей о том, как приступать к внедрению методологии Scrum или других разновидностей agile-методологий и практик. Однако, что делать дальше, когда проблемы начального этапа остались в прошлом, а работа по принципам Scrum стала для команды нормой?

Ретроспектива в Agile

Чем дольше команда работает по принципам Agile, тем интереснее становятся проблемы, которые ей приходится решать. С одной стороны, выясняется, что вещи, которые на этапе внедрения казались очевидными и не вызывали вопросов, видятся разными людьми по-разному. С другой стороны, некоторые практики, например, полная кроссфункциональность (взаимозаменяемость членов команды), оказываются неприменимы и приходится изменять процесс. Опыт команд, внедрявших Scrum, показывает, что полная кроссфункциональность встречается нечасто и в нашей практике, например, вместо «универсальных разработчиков» команду составляют разработчики и аналитики-тестировщики — такая конструкция для нас оказалась оптимальной.

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

• Почему не успели сделать все запланированные задачи?
• Стоит ли перенести время Daily Scrum Meeting (ежедневное собрание — «летучка», на котором обязательно должны присутствовать все члены команды) на более раннее (более позднее время)?
• А не сменить ли систему контроля версий?
• Может быть, стоит заказывать пиццу, если работаем после 20.00?

На первых этапах внедрения Scrum ретроспективы проходят бодро. Команда получает «законную» возможность зафиксировать и даже решить проблемы, о которых все знают, но до которых обычно не доходят руки. Но после того, как проходит первый эффект, ретроспектива часто вырождается в формальность или вообще не проводится. Почему так происходит? По нашему опыту, причин может быть несколько:

• на ретроспективе по разным причинам не затрагиваются системные проблемы;
• решения, принятые на ретроспективе, не выполняются.

Об этом не говорят

В каких случаях команда не говорит о реальных проблемах? Часто это может быть связано с взаимными претензиями членов команды друг к другу — всегда тяжело говорить человеку в лицо о том, что он ведёт себя неправильно не только с профессиональной, но и с человеческой точки зрения. Рассмотрим несколько примеров.

Программисты vs. тестировщики

Программисты — люди увлекающиеся и часто в порыве вдохновения могут реализовать полезную, но не запланированную на данной итерации функцию, или провести масштабный рефакторинг, который можно было отложить. В результате программист получает удовольствие, а тестировщики — дополнительную работу. Проблема усугубляется тем, что канонический Scrum ограничивает сроки итерации, подразумевая полную кроссфункциональность команды, поскольку в такой команде тот, кто не занимается в данной момент разработкой, проводит тестирование. В команде, которая кроссфункциональна не полностью, тестированием и разработкой занимаются разные люди, поэтому ограничение сроков сдачи продукта рамками одной итерации оборачивается тем, что программист сдает код в предпоследний момент и чувствует себя свободным, в то время как тестировщики «зашиваются», чтобы успеть к дате релиза или демонстрации. Такие ситуации для тестировщиков выглядят как пренебрежение к ним со стороны программистов, отчего напряженность в команде может сильно возрасти. Надо сказать, что подобные проблемы могут подолгу тлеть внутри коллектива и проявятся только после запуска системы в промышленную эксплуатацию, когда к срокам доработок предъявляются особенно жёсткие требования, но при этом требуется сохранять высокий уровень качества.

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

Сделай сам

Приведем еще один пример типичного конфликта внутри команды, который без вмешательства извне помогает вскрыть ретроспектива. Новый разработчик приходит в устоявшуюся команду, которая уже несколько лет развивает продукт, запущенный в промышленную эксплуатацию, причем разработка идёт на мощном стеке собственных технологий. Через некоторое время между новичком и некоторыми членам коллектива начинает расти напряжение — новичку кажется, что его просьба помочь, объяснить или показать что-то в продукте негативно воспринимается другими членами команды. С его точки зрения, они или не настроены помогать другим, или не готовы пожертвовать минутами своего времени, для того чтобы показать то, с чем в противном случае ему пришлось бы разбираться несколько часов. С другой стороны, у более опытных сотрудников нарастает недоумение: просьбы о помощи они рассматривают как проявление лени и некомпетентности. Ведь у новичка есть отладчик, система контроля версий, система учета ошибок (bug-tracker) и даже документация!

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

Правила виноделов

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

• команда договорилась никогда не ломать сборку проекта на сервере непрерывной интеграции;
• решили делать рефакторинг не в ущерб наращиванию нового функционала;
• приняли решение не допускать передачи заказчику кода, не прошедшего Code Review (инспекцию другим разработчиком).

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

Другой пример. В определённый момент выясняется, что правило об ограничении времени на рефакторинг в общем объёме задач не работает потому, что часть разработчиков занимается в основном инспекцией кода и рефакторингом, но не берет задачи собственно по разработке нового функционала. С формальной точки зрения правило соблюдается на уровне команды, но общий темп разработки снижается. Регулярная ретроспектива помогает прояснить ситуацию и найти удачный выход: временно запретить (с их добровольного согласия, что важно) этим разработчикам брать задачи по Code Review вообще. В течение двух спринтов нормальная пропорция видов деятельности восстановилась, и запрет был снят.

Бывает так, что работающая в нормальных условиях договорённость в экстремальных ситуациях перестаёт соблюдаться. Часто достаточно лишь отследить этот момент и волевым решением команды вернуть течение вещей в нормальное русло. Например, после старта большой, распределенной системы, работающей в режиме 24×7 и имеющей сотни пользователей, доработки и баги посыпались как из рога изобилия. Изменения вносились впопыхах без детальной проработки. На ретроспективе было замечено, что очень часто Code Review не выполнялся, отчего страдало как качество проектных решений, так и их реализация. Было принято решение вернуть Code Review, которое жестко контролировалось в течение спринта. Со временем отпала сама необходимость контроля, поскольку процесс вошёл в норму.

Все в ваших руках

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

Дополнения

Методология Scrum

Слово Scrum было заимствовано из регби и может быть переведено как «схватка вокруг мяча». Это итеративный процесс разработки программного обеспечения, при котором каждая итерация ограничена во времени (канон предписывает ограничение не больше 4 недель), и, что важно, в конце каждой итерации появляется работающее программное обеспечение.

Результат каждой итерации показывают и обсуждают с заказчиком на собрании, которое называется «Демонстрация». Таким образом, заказчик видит работающее ПО, начиная с самой ранней стадии проекта, и может оперативно указывать на необходимые изменения.

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

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

Инструментарий

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

Проекты

Заказчику — крупному ретейлеру — требовалась информационная система для обеспечения поставок товара со складов во множество розничных магазинов, расположенных от Калининграда до Красноярска. Система должна была функционировать в режиме 24/7, обеспечивая работу нескольких сотен пользователей. Важной особенностью проекта было то, что в нем впервые применялся новый стек технологий собственной разработки.

Разработка системы продолжалась 16 месяцев, после чего комплекс был сдан в промышленную эксплуатацию, которая продолжается и по сей день. За это время функциональность системы была расширена, добавлены новые модули, возросла нагрузка (в несколько раз увеличилось количество документов, обрабатываемых в течение дня), расширилась география пользователей. Также значительно менялась команда: несколько разработчиков перешли в другие команды передавать опыт работы с новыми технологиями, приходили новые люди, которые обучались новым технологиям непосредственно в проекте.

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

Размер команды составлял в среднем шесть человек (2 инженера и 4-5 программистов). Трудозатраты: 14 человеко-лет (3500 человеко-дней). Объем кода: 150 тыс. строк. Использованные технологии: Net 3.5, C#, Web Services, собственный стек технологий, включающий ORM и «тонкий» клиент. База данных: Oracle 10g. Среда разработки: сначала Visual Studio 2008,затем Visual Studio 2010, PL/SQL Developer.

Компания CUSTIS

Компания CUSTIS (www.custis.ru) основана в 1996 году выпускниками МФТИ, которые стремились решать сложные нестандартные задачи в области разработки прикладного программного обеспечения. В результате появилась компания, которая выполняет разработку больших корпоративных систем на заказ. Компания никогда не изменяла исходным принципам и научилась непрерывно расти и развиваться в этом непростом секторе ИТ-рынка.

Наш бизнес

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

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

Наш подход

Каждая крупная компания сама по себе является сложной системой, ее бизнес-процессы автоматизированы в нескольких разнородных информационных системах. Добавить или изменить ключевые процессы, не имея перед глазами цельной картины происходящего, сложно. А поскольку это касается жизненно важных участков, все изменения нужно проводить «на полном ходу». Поэтому нами применяется технология бережного внедрения, которая позволяет контролировать процесс замены информационной системы и в итоге получить гарантированный результат.

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

---

Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.

Если вы интересуетесь менеджментом, то наверняка не раз слышали про Agile и Scrum — популярные инструменты управления проектами. Эти методики управления внедряют тысячи компаний по всему миру, так чем же они так хороши?