Впечатления от тренингов Certified Scrum Master и Certified Scrum Product Owner24.09.2015 13:48

Сегодня мы хотим поделиться впечатлениями от участия в тренингах Certified Scrum Master и Certified Scrum Product Owner от Innovel и ProCognita, которые проходили в Варшаве 29-30 июня и 1-2 июля соответственно. Здесь мы рассмотрим наиболее интересные с нашей точки зрения инструменты и техники, представленные на обоих тренингах, которые будут полезны как тем, кто делает свои первые шаги в SCRUM, так и уже имеющим некоторый опыт в применении гибких SCRUM в своих проектах. Мы оставили оригинальные названия упражнений, чтобы упростить поиск тем, кто впоследствии пожелает найти больше информации; кроме того, статья дополнена ссылками на англоязычные статьи, поясняющие суть некоторых упражнений.

Certified Scrum Master

Курс начался с упражнения под названием Silent sorting. Вначале участникам тренинга предложили выписать свои ожидания от курса на стикеры и поместить их на «доску ожиданий». Затем всех участников разделили на две группы. Первая группа должна была выполнить сортировку стикеров по категориям. Правило было только одно — сортировку необходимо выполнять без обсуждений, в полной тишине. Первая группа справилась достаточно быстро, хотя некоторые стикеры были перемещены в различные категории по несколько раз. После этого вторая группа должна была дать имена полученным категориям. В отличие от первой группы, второй было позволено обсуждать свои действия.

В ходе аналитической части упражнения выяснилось, что вторая группа потратила намного больше времени на то, чтобы дать названия семи категориям, в отличие от первой группы, которая потратила значительно меньше времени на сортировку более чем 30 стикеров. Вывод заключается в том, что зачастую при обсуждении значительная часть времени тратится на разговоры, а не на непосредственное выполнение задачи. Однако мы не акцентируемся на полном исключении обсуждения из любых видов работы; напротив, в некоторых активностях, таких как «мозговой штурм», обсуждение является одной из важнейших составляющих для достижения нужного результата. Тем не менее, когда все участники задачи находятся в одном «контексте», можно опустить предварительное обсуждение. По опыту применения данной техники можем отметить, что ее использование при оценке задачи из бэклога на 10-15% уменьшает затраты времени на планирование по сравнению с использованием планировочного покера. Кстати, важность нахождения в одном контексте продемонстрирована второй группой: львиная доля времени, затраченного на придумывание наименований категорий, ушла на попытки понять логику, согласно которой первая группа выполняла сортировку стикеров.

Следующее упражнение с первого взгляда показалось участникам тренинга весьма тривиальным, однако впоследствии оказалось очень полезным в работе. Упражнение заключалось в разработке т.н. Working aggreements для тренинговой группы. Любая группа людей, работающих вместе, должна разработать для себя набор правил «общежития», которых эта группа будет придерживаться. В обязанности группы входит также обновление правил по мере необходимости и контроль за их выполнением всеми членами группы.

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

Следующее упражнение, с которым мы познакомились, называлось Ball Point Game. Суть его заключается в том, чтобы передать максимальное количество мячей от первого участника к последнему. Правила хорошо описаны в статье по ссылке, потому не будем здесь на них останавливаться. В течение 30 минут тренинговая группа провести 7 итераций, включающих в себя планирование, выполнение работы и ретроспективу. После каждой итерации группа старалась модифицировать процесс таким образом, чтобы увеличить свою продуктивность. Благодаря этим изменениям группа в результате смогла увеличить продуктивность в 6 (!) раз — с 20 до 120 мячей. Безусловно, на практике результаты могут оказаться не столь радужными, потому что игровая симуляция не учитывает такие факторы, как внутренние процессы компании, готовность команды к изменениям, бизнес-домен проекта и т.д. Тем не менее, данное упражнение достаточно наглядно показывает выгоду от использования итеративных методологий управления проектами.

Внимание заслуживает еще одно упражнение, разработанное для обучения SCRUM-команд работе с относительными оценками. Это модифицированная версия техники Zoo Points Майка Коха. Однако данный вариант имеет значительное преимущество благодаря иному составу группы объектов для оценивания и поставленной задаче. В Zoo Points предлагается выполнить оценку размеров животных, что имеет мало общего с реальной оценкой сложности работы. В то же время, упражнение Томаша изначально подразумевает взаимодействие хоть и с одной задачей, но с разными условиями ее выполнения. Участникам задается вопрос: насколько сложно будет сделать что-либо. Например, бросить камень, лист бумаги, перо или живой объект на расстояние в один метр. Поскольку в разработке ПО мы чаще встречаемся с разнородными задачами, это упражнение представляет больший интерес по сравнению с Zoo Points.

Есть еще кое-что, о чем участники тренинга узнали в ходе выполнения упражнения. Во-первых, процесс планирования нацелен не на факт получения оценки, а на синхронизацию знаний о задаче между участниками команды. Это то состояние, которого нам пришлось достичь, выполняя упражнение на тренинге, потому что каждый из участников упражнения изначально имел свое видение, как нужно выполнять задачу. Во-вторых, оценивать гораздо легче, когда у вас есть «эталон»: единица работы, которая отчетливо ясна всем участникам команды и имеет некую величину, на основании которой можно оценивать последующие работы. Мы уже попробовали эту технику на одной из наших SCRUM-команд и получили отличный результат: если ранее точность оценок команды составляла около 70-75%, то после применения техники и определения «эталона» точность выросла до 90% в течение всего нескольких спринтов, и имеет тенденцию к росту. Конечно это не единственный инструмент, который мы использовали для повышения качества оценок. Но именно это упражнение дало наибольший результат.

Наконец, стоит отметить упражнение, которое очень хорошо показывает, как продуктивно и слаженно могут работать самоорганизованные команды по сравнению с теми, где всё управление осуществляет менеджер. Данное упражнение — вариация «человеческого узла», часто применяемого на тимбилдингах. В этом упражнении участников просят взяться за руки в хаотическом порядке. Затем, когда все взялись за руки, необходимо распутать получившийся узел. Представленный на тренинге вариант этого упражнения состоял из двух этапов. В первом один из участников стал менеджером и указывал команде, как распутываться. Во втором этапе команда действовала без менеджера. Результаты выполнения упражнения оказались потрясающими: первый этап занял около 4-х минут, второй — всего 17 секунд, в 14 (!) раз меньше. Таким образом, даже с поправкой на то, что это симуляция, а не реальный случай, можно утверждать, что при определенных условиях команда профессионалов способна выполнять работу без четкого руководства менеджера.

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

Certified Scrum Product Owner

Если предыдущий тренинг был нацелен на работу с командой, то тренинг Certified Scrum Product Owner предназначен для работы с продуктом в таких аспектах, как приоритезирование функций, планирование версий, управление ожиданиями заказчиков и пользователей и т.д.

Как и на предыдущем тренинге, группа начала работу с выявления ожиданий участников тренинга и разработке рабочих соглашений. Далее перешли к упражнению Scrum Penny Game. В ходе этого упражнения четыре участника играли роль сотрудников, которым предстояло выполнять достаточно простую работу: переворачивать 20 однокопеечных монет и передавать их следующему сотруднику. Каждая монетка, которая достигла последнего сотрудника и была перевернута, считалась выполненной единицей работы; все 20 монет считались объемом проектных работ. Еще четыре участника тренинга играли роль менеджеров. Им требовалось находиться рядом со своим сотрудником и фиксировать количество времени, за которое сотрудник выполнит свою часть работы, т.е. перевернет все 20 монет. Наконец, один из участников тренинга фиксировал два момента: когда первая и двадцатая монеты были перевернуты последним сотрудником. В течение пяти итераций правила изменялись несколько раз: вначале каждый сотрудник должен был перевернуть все 20 монет и только потом передать их второму сотруднику. Затем необходимо было передавать по 10, 5, 2 и 1 монете. В результате стало ясно, что чем меньше размер партии, передаваемой следующему сотруднику, тем хуже становилась продуктивность каждого отдельного сотрудника, зато общая продуктивность росла. Если вначале команда поставила заказчику первую завершенную единицу работы только через 76 секунд, то уже в пятой итерации — всего за 6 (!) секунд. Общее время выполнения проекта также снизилось и составило 25 секунд на пятой итерации против 86 на первой, то есть в 3 раза быстрее при том же уровне качества. Конечно, этот результат далек от реальности, т.к. не учитывает возможные увеличения объемов работ, исправления дефектов, переработки функциональности, проблемы с приемкой и т.д. Тем не менее, данное упражнение отлично продемонстрировало всем участникам тренинга возможную выгоду от применения итеративного подхода к разработке продукта и скорость, с которой такой подход принесет выгоду заказчику.

Далее приступили к работе с бизнес-кейсом, который стал центром внимания в оставшуюся часть тренинга. Сперва потребовалось придумать некий продукт. Одна из команд решила создать систему, которая помогала бы путешественникам подбирать наилучшие варианты туров по заданным критериям: стоимость, продолжительность путешествия, количество пересадок в пути и т.д. Затем участникам команды потребовалось определить т.н. business drivers — нечто сродни «миссии». В ходе обсуждения были определены следующие driver’ы:

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

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

Получив список пользовательских историй, команда перешла к технике Story Mapping:

Сначала создали каркас приложения, расположив ключевые функции в том порядке, в котором пользователь должен был бы столкнуться с ними в приложении;
Затем расположили пользовательские истории под соответствующими ключевыми функциями. На этом этапе участники добавили некоторые существенные истории, которые были упущены при изначальном декомпозировании функций;
Следующим шагом была произведена приоритезация пользовательских историй для каждой из функций: наиболее приоритетные истории были расположены выше, а наименее важные — ниже;
Наконец, все пользовательские истории разделили на версии продукта таким образом, чтобы каждая из версий могла быть логически оконченной и готова к выходу. При этом первая версия должна была обладать минимальным набором функциональности, т.е. быть тем, что в иностранной литературе называется “The walking skeleton”.

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

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

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

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

Purpose Alignement Model. Используется для разделения функций на четыре группы по степени важности для потенциальных пользователей. Функции, попадающие в квадрант «дифференцирующие», должны быть разработаны как можно скорее; в то же время функции, до которых «никому нет дела», возможно, не понадобятся пользователям никогда, поэтому должны получить более низкий приоритет.
Kano model. Данная техника разделяет все функции на базовые, требуемые и восхищающие. В первую версии продукта нужно включить все базовые функции, несколько требуемых и 1-2 восхищающие. Если потребуется чем-то жертвовать, то вначале стоит отказаться от восхищающих, а затем от требуемых, но ни в коем случае не от базовых.

Вывод

Оба тренинга оказались крайне полезными. За четыре дня мы успели:

Устранить белые пятна в теоретических знаниях о SCRUM;
Изучить множество полезных инструментов для работы с заказчиками и командой;
Получить ответы на актуальные вопросы из нашей практики от опытных SCRUM-специалистов.

Некоторые из вас могут подумать, что большинство приведенной информации можно найти в интернете. И вы будете правы, но лишь отчасти, потому что на курсах можно получить то, чего не найти в интернете — живое общение с действительно крутыми специалистами и обсуждение животрепещущих вопросов здесь и сейчас. И как приятный бонус — возможность стать Sertified Scrum Product Owner или Certified ScrumMaster.