Три способа использовать Scrum в образовании. Часть 2

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

Впервые мы попробовали этот подход в следующих условиях.

• платный курс по подготовке бизнес-аналитиков для ИТ - не повышение квалификации, не переподготовка (т.е. никаких "корочек" государственного образца на выходе);
• две группы, два преподавателя;
• первая группа учится 3 раза в неделю очно, по вечерам; 
• вторая группа учится 2 раза в неделю на вебинарах и 1 раз в неделю очно, по субботам;
• отбор на курсы - по результатам тестов компетенций;
• ключевая мотивация (и слушателей, и наша) - трудоустройство;
• курс состоит из 2 частей - 6 недель теоретической части и 6 недель проектного практикума.

Именно для проектного практикума решили использовать методологию Scrum.

ПРИМЕЧАНИЕ.

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

На практикум выбирали сложный проект, который можно было разбить на 4 функциональных модуля. Это был либо проект стороннего заказчика, либо мы придумывали сложный проект, у которого аналогов нет, либо они очень примитивные, либо очень косвенные. Обе группы объединяли в одну и формировали 6 команд:

• команду владельцев продукта - 3 человека: двое Product Owners (PO), каждый из которых отвечает за 2 функциональных модуля, плюс Lead Product Owner (LPO); их задача была - коммуникация с Заказчиком по своим модулям, составление резерва продукта;
• команду Scrum Masters (SM) - ими были мы с +Tory Piliptsevich, и каждая тоже курировала по 2 модуля; наша задача - помогать выстроить процесс и снимать блоки, если таковые возникнут;
• 4 команды аналитиков - по 4-5 Business Analysts и 1 Lead Business Analyst в каждой; они участвовали в формировании резерва продукта по своим блокам, разработке требований, прототипов. 

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

ПРИМЕЧАНИЕ. Мы использовали Scrum-подход и на малых группах, где была только одна команда. Опыт таких групп показал, что команда меньше 4 человек не работает. Ну, и проект должен быть попроще, не 4-модульный. Вполне подойдет мобильное приложение, например.

Существует подход, при котором преподаватели становятся на роль PO, а на роль SM выбирают кого-то из обучаемых, но мне этот подход кажется критически неверным. Во-первых, SM должен быть тот, кто хорошо понимает процесс и может помочь адаптироваться к нему другим. Во-вторых, SM при правильном подходе на каждом следующем спринте все реже нужен - иной раз и хочешь влезть с помощью, но команды отодвигают: "Не надо, мы сами!", и действительно сами способны и отрефлексировать, и скорректировать процесс, и разобраться с задачами. В-третьих, я убеждена, что в создании резерва продукта должны участвовать сами обучаемые, а не преподаватель - тогда это будет ИХ продукт. Единственное, когда я или Виктория становились PO - это случаи с маленькими группами, где не нужно 2 scrum-мастера, а сами слушатели отказывались от роли, и предпочитали роль BA/LBA.

Практикум длится 6 спринтов (по 1 неделе на спринт):

• 1-й спринт вводный - для освоения инструментов и адаптации к методологии;
• 2-5 спринты рабочие - на них шла основная работа по проекту;
• 6-й спринт на "чистку блох" и подготовку к защите.

Вводный спринт начинаем с установочного вебинара, на котором:

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

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

Планирование происходит с учетом того, сколько кто может потратить времени на спринт. Нет смысла уравнивать, к примеру, маму двоих детей, которая может сесть за задачи не раньше 21:00, и безработную молодую женщину, которая готова сидеть с утра до вечера. Слушатели должны получить опыт за эти 6 недель, и все всегда понимали: чем больше времени уделишь, тем больше опыта получишь. По сути, те, кто тратил по 6-8 часов в день на проект получали опыт работы на полноценном рабочем дне. Конфликтов на тему "Я тут по 8 часов работаю, а ты часик посидел и все" не было совсем. В обратную сторону "Оставьте мне задачи, не забирайте все" - были :)

Каждый день были Daily Scrum Meetings - 15-минутные совещания команд. Мы стараемся, чтобы хотя бы один SM был на "дейлике" каждой команды. Проводили по Skype, реже - в вебинарной комнате или в Hangout (с командой решаем, чем удобнее, но Skype всегда побеждал в итоге). Эти совещания - отличный мотиватор: ты можешь прийти на одно и сказать, что ничего не сделал... на второе... но на третье становится стыдно перед командой :)

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

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

Основные рабочие инструменты:

• Skype - для обсуждений голосом и текстом; создавали 7 чатов: по 1 чату на каждую команду, чат для LBA, чат для PO и чат для PO+LBA; нас добавляли во все чаты; бывало, что появлялись чаты и без нашего участия - это нормально; но основные обсуждения надо отслеживать, и лучше эти коммуникации сразу прописать в правилах, чтобы не упустить что-то важное;
• Google Disk - для работы с документами, таблицами, диаграммами; подключали к нему (по ситуации) сервисы draw.io, Realtimeboard, Cacoo;
• DevProm - для управления проектом, резервом продукта и требованиями;
• вебинарная комната - для проведения вебинаров по запросу команд;
• scrumblr.ca - доска для проведения ретроспектив и планирования.

Ключевые сложности, с которыми столкнулись.

1. Вход в процесс. Основа Scrum - самоорганизующаяся команда, которая сама принимает решения, и не ждет, что ей скажут, что делать. Но именно самоорганизация была самым сложным препятствием на входе в процесс. Люди привыкли, что на курсах им дают задания. Как самим решать, какие должны быть задания, и какие из них взять - поначалу непонятно. Этап самый болезненный для многих. Включая нас с Викторией: это ужасный соблазн, когда знаешь, что делать - побежать и научить другого :) Но пройти его необходимо, чтобы снять страх перед проектом, научиться планировать свою работу, принимать самостоятельные решения, оформиться как команда. 
2. Конфликты. Конечно, они возникали. Кто-то предлагал решение, с которым не соглашались, и это было обидно. Кому-то был стрессовый вход, и во всем виноваты оказывались мы с Викой - что не учим, как надо, а только смотрим (позже, правда, понимали, что неправы, и что вот эта "непомощь" - самая сложная работа). Кому-то не нравилось, как с ним обращается Lead. И много чего еще. Мы старались не влезать до последнего, чтобы слушатели научились объясняться, говорить, что им не нравится, что беспокоит (Scrum ведь очень прозрачный процесс), выявлять и устранять корни конфликта. Извиняться, в конце концов, а не спихивать вину на других. Но иногда приходилось вмешиваться и снимать напряжение.
3. Право на ошибку. Самое сложное - видеть, что команда пошла по неверному пути, потому что не учла каких-то важных факторов (о которых много раз говорили), не запросила информацию у команд, с которыми есть пересекающиеся функции... В общем, видеть все это и... позволить ей этот путь пройти. Да, мы понимали, что через спринт-два это вылезет большой проблемой, и кому-то придется все переделать. Но позволяли им до этой проблемы дожить, осознать, разобрать и найти пути решения. И после этого мы точно знали: вот таких проблем у них больше не возникнет - перепроверят все лишний раз, достанут душу кому надо, соберут все данные. А если и накосячат, то смогут отрефлексировать и найти решение. Опыт - сын ошибок трудных, как говорил Александр Сергеевич.
4. Соскоки. Бывало, кто-то соскакивал. Один только случай был, когда человек заленился. Остальные - объективные: заболел кто-то из родных, отправили в командировку, нагрузили на работе. Было даже, что взяли уже на работу, и человеку стали актуальнее боевые проекты на новом месте, а не наш проект. А один раз соскочил Заказчик - поменялись планы, и проект перестал быть актуален. Ну, на то и Scrum, чтобы гибко подстраиваться под проектные обстоятельства. Я всегда говорю: что бы ни случилось на учебном проекте - это просто проектная ситуация, которая даст новый проектный опыт.
5. Ловушки компетентности. Возникали, если на проекте оказывались действующие ИТ-шники - как аналитики, так и тестировщики, программисты, менеджеры проектов. У них был такой же соблазн, как и у нас: мы ж опытные, мы ж и так много знаем. И опыт этот иногда подсказывал, что надо делать не так - "У нас так никто не делает". Но если выдержать этот прессинг и уговорить попробовать сделать "не так", то начинались инсайты и сюрпризы, и люди понимали: опыт тоже надо уметь применить, а то можно проглядеть много важного и интересного.

А теперь про приятное.

1. Вовлеченность. Среднее количество часов в день, которое тратил один слушатель на такой проект - 4 часа. С понедельника по субботу. Меньше 2-3 часов не тратил никто. Это к вопросу о том, что дистанционное только для мотивированных. В общем-то, да. Вопрос только в том, какой процент не растеряет эту мотивацию. У нас демотивировался 1-2 из 25-30 человек. Потому что человеку крайне важно знать, что его действия имеют смысл, и именно в Scrum-проектах это видно хорошо, ведь задачи себе ты поставил сам! Когда выполняешь задания сам для себя, расслабиться гораздо проще, чем выполняя задания, которые могут заблокировать всю команду.
2. Развитие компетенций. Самый приятный вопрос, который я слышала много раз и от нанимателей, и от выпускников: "Лена, получается, реально человеку с нуля за 2-3 месяца ТАК поменять мышление?!" Да, реально! Менялось мышление, менялось поведение. Подавляющее большинство из сотен наших выпускников признается, что только на таком вот обучении поняли, что такое настоящая командная работа, и что такое ответственность. Что твоя идея может быть прекрасна, но не своевременна. Что ты можешь накреативить кучу интересных функций для будущего продукта, но далеко не все они останутся, т.к. не все они соответствуют бизнес-целям Заказчика, и это нормально. Что информации может быть очень много, и мало ее найти - надо тщательнейшим образом ее проанализировать, прежде, чем принимать решения. А это значит, что нам, преподавателям, пора забыть о том, чтобы собрать весь необходимый контент, а отдать эту задачу слушателям.
3. Трудоустройство. Не все, конечно, нашли работу. Но за сотню трудоустроенных мы перевалили точно. К сожалению, мы сталкивались и продолжаем сталкиваться с нехваткой рабочих мест по данному направлению. Не потому, что аналитики не нужны, а потому что мало кто понимает, что нужно вводить такую позицию. Причем, нужны они не только в ИТ-компаниях, но и в других отраслях, т.к. сейчас невозможно представить бизнес, который не использует ИТ-решений. Кто-то должен эти решения подбирать и внедрять. Благодаря нашим встречам с нанимателями и Заказчиками появлялись рабочие места, на которые брали наших выпускников. Но здесь еще не паханное поле для работы, которой еще предстоит заняться системно. 

Основной вывод, который я сделала - Scrum-подход в проектном обучении заставляет очень сильно поменять взгляды на обучение и преподавателей, и обучаемых. По сути, надо все делать наоборот:

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

Процесс в этом случае должен строиться исключительно на вере в слушателей. Все наше поведение должно быть демонстрацией того, что мы уверены в ИХ результате БЕЗ нашего активного участия. Понять самим и объяснить им, что принимаемые ими проектные решения прекрасны все без исключения - ибо благодаря им и происходит обучение, формируется необходимое поведение. Главное - помнить, что это не произойдет сразу (у нас уходит 2-3 первых спринта на вкатку в процесс). И даже если это не произошло на одном проекте, то не стоит сразу опускать руки и отказываться от подхода, а стоит проанализировать, почему так вышло, и снова пробовать. 

Удачи во внедрении. Ну и, пишите, если что! :)