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

Ретроспектива: как и зачем ее проводить?

Проведение ретроспектив – это активность, которую каждая agile-команда проводит для того, чтобы решать свои проблемы. Что такое ретроспектива? Это регулярная встреча, на которой команда обсуждает свой рабочий процесс и что-то в нем меняет.

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

Это не праздный вопрос, его часто задают начальники, когда им предлагают провести ретроспективу. Они спрашивают: «Зачем? Мы можем сами все решить». Почему же нельзя сделать так, чтобы какой-то начальник или эксперт пришел, посмотрел и сказал, что команде надо делать, а что в рабочем процессе стоит изменить?

Основных причин две. Во-первых, если мы приходим к команде с готовыми решениями, возникает феномен, который называется «not invented here». Даже если члены команды понимают, что это правильное решение и его нужно выполнять, у них нет чувства собственности по отношению к нему. Такие решения, не «выстраданные» самим коллективом, а «навязанные» или предложенные сверху, имеют меньше шансов на реализацию.

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

Тем не менее, существуют такие вещи как good practice или best practice. Это практики, которые многие используют и которые многим помогают. Возьмем, например, code review: хорошая это практика или плохая? Одним командам она помогает. Другие пытаются ее использовать, и ничего хорошего из этого не выходит. Так происходит потому, что эта конкретная практика, не хороша и не плоха как таковая: ее можно оценить только в контексте конкретной команды и ситуации.

Хотя бы поэтому невозможно сказать заранее, даст она какое-то преимущество или нет. Сode review – это один пример. На самом деле этот эффект характерен для любой практики – никогда нельзя знать заранее, насколько она будет эффективна в той или иной ситуации.

Цели и результаты

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

Цикл Деминга: Plan – запланируй, Do – выполни, Check – посмотри, что получилось, Act – прими какие-то дальнейшие решения, реши, что дальше делать. Ретроспектива должна проходить именно по этому циклу. Собственно, сама ретроспектива – это стадия Plan.

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

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

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

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

Какие бывают ретроспективы?

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

• ретроспектива в самом общем смысле слова;
• ретроспектива по качеству;
• ретроспектива по проблемам;
• ретроспектива по какому-либо отдельно взятому вопросу.

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

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

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

В чем проблема?

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

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

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

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

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

Формат ретроспективы: наши предложения

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

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

• Плюсы. Что шло хорошо в прошлой итерации?
• Минусы. Какие проблемы были в прошлой итерации?
• Идеи. Какие идеи появились по ходу ретроспективы?
• План. Какие улучшения мы запланируем на следующую итерацию?

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

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

После обсуждения плюсов, минусов и идей команда переходит к составлению плана, куда попадают не просто результаты обсуждения, а (как уже было отмечено) конкретные действия («Выполнить…», «Обсудить…», «Сформировать…») или правила («Задачу Х выполнять с использованием подхода Y»). Не стоит при этом пытаться выработать пути решения всех возможных проблем команды – для эффективной работы на следующей итерации достаточно плана из 3-6 пунктов. Слишком объемный план может в итоге оказаться невыполним и только демотивирует команду.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему не успели сделать все запланированные задачи?
Стоит ли перенести время Daily Scrum Meeting (ежедневное собрание — “летучка”, на которой обязательно должны присутствовать все члены команды) на более раннее (более позднее) время?

А не сменить ли систему контроля версий?
Может быть, стоит заказывать пиццу, если работаем после 20.00?
 

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

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

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

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

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

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

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

Сделай сам

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

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

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

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

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

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

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

***

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

Василий Кудрявцев (vkudriavtsev@custis.ru) — ведущий программист, компания CUSTIS (Москва).

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

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

• спринт в 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 году выпускниками МФТИ, которые стремились решать сложные нестандартные задачи в области разработки прикладного программного обеспечения. В результате появилась компания, которая выполняет разработку больших корпоративных систем на заказ. Компания никогда не изменяла исходным принципам и научилась непрерывно расти и развиваться в этом непростом секторе ИТ-рынка.

Наш бизнес

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

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

Наш подход

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

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

В сложившихся условиях неопределённости и паники важно уметь сосредоточиться на повышении эффективности своих команд.

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

• «Как мне успешно вести проект и непрерывно улучшать свои показатели?»
• «Как оперативно отслеживать и гибко реагировать на изменения внешних и внутренних условий: бизнес-целей клиента, ситуации на рынке, атмосферы внутри команды?»
• «Есть ли на проекте скрытые проблемы, которых я не вижу, но которые могут принести существенный вред?»

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

ИНСТРУМЕНТ ДЛЯ РЕШЕНИЯ ТИПИЧНЫХ ПРОБЛЕМ НА ПРОЕКТЕ

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

В зависимости от целей выделяют три вида ретроспективы:

• Общая ретроспектива.

В ней участвует и принимает решения вся проектная команда без исключения (тестировщики, разработчики, бизнес-аналитики, дизайнеры и т. д.).

• Проектная ретроспектива.

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

• Внутренняя ретроспектива.

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

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

Кроме того, ретроспектива может проводиться:

• в конце определённой фазы проекта;
• после каждой итерации (для Agile-программ);
• при завершении проекта;
• в любой момент при возникновении проблем.

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

ПРОЦЕСС ПРОВЕДЕНИЯ РЕТРОСПЕКТИВЫ

Стандартно ретроспектива начинается с этапа «открытия», который помогает настроить команду на рабочий лад, чтобы каждый участник мог спокойно и конструктивно высказывать своё мнение и вместе с остальными членами команды работать над поиском оптимальных решений.

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

• С какими задачами команда справилась удачно?
• Выполнение каких задач не было успешным?
• Какие ошибки можно исправить?

Это наиболее распространённый вариант, но существуют и другие. Например, подход Starfish предлагает основываться на следующих пунктах:

• Start doing: что нужно начать делать.
• Stop doing: что нужно прекратить.
• Continue doing: это хорошо работает, нужно продолжать делать.
• More: этим активностям нужно уделять больше внимания.
• Less: на эти активности нужно тратить меньше времени.

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

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

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

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

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

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

ПОВЫШАЕМ ЭФФЕКТИВНОСТЬ РЕТРОСПЕКТИВЫ

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

Важно сделать ретроспективы интересными, чтобы они не стали очередной рутинной задачей, а команда была мотивирована на конструктивное обсуждение и совместный поиск лучших решений. Например, можно использовать такие виды практик, как голосование для выбора Captain Sprint – человека, который лучше всего проявил себя во время спринта; обсуждение по методу «Шести Шляп»; геймификация с помощью Лего и другие.

Читайте продолжение статьи по ссылке: https://www.a1qa.ru/blog/retrospektiva-v-qa-effektivno-reshaem-problemy-na-proekte/