Как я eduScrum училась

8-9 февраля я ездила в Москву на тренинг по eduScrum, преследуя сразу пять целей.

1. Убедиться, что мой подход к использованию Scrum отличается от eduScrum, и разобраться в тонкостях eduScrum, чтобы расширить свой арсенал.
2. Найти единомышленников, увлеченных проектным обучением вообще и Scrum в обучении в частности, чтобы не чувствовать себя так одиноко.
3. Найти творческих преподавателей, которым будет интересно попробовать SkillTerra.
4. По возвращению провести обучение для белорусских учителей - про Scrum в обучении вообще, и про eduScrum в частности.
5. Получить международный сертификат (некоторым почему-то важнее мои бумажки, я не N-летний опыт).

Что из этого получилось, а что не очень?

Про то, как я использую Scrum в проектном обучении, я уже подробно писала. И это действительно очень отличается от eduScrum.

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

Во-вторых, роль учителя. В eduScrum учитель является владельцем продукта (Product Owner, PO). Иными словами, именно он диктует требования к ученику как к продукту. При этом от роли scrum-мастера (SM) ему тоже никуда не деться: кто-то же должен помогать перейти на Agile-ценности, помогать команде самоорганизоваться и выстроить эффективный процесс, снимать блоки команды и все вот это. По сути, в eduScrum учителю приходится действовать в интересах двух разных ролей: диктующей требования к продукту и реализующей эти требования. Это не очень хорошо.

На учебных проектах, которые организую я, роль учителя - SM, а в роли PO будет либо кто-то из учеников, либо реальный PO на стороне реального Заказчика. Учитель в роли РО может оказаться, когда над проектом работает сразу два учителя, а сам продукт не имеет реального Заказчика (например, мобильное приложение дополненной реальности для определения расы инопланетянина). В этом случае один из учителей становится РО и генерирует требования к продукту и историю продукта (которая в eduScrum называется легендой). Второй же становится на позицию SM и помогает команде выстроить процесс, который позволит нужный продукт создать. 

В-третьих, итерации (спринты). В eduScrum одна итерация - это один урок. Мне сложно оценить эффективность, т.к. на моих проектах 1 итерация = 1 неделя. С одной стороны, ученики остаются в тонусе, а также обратная связь и рефлексия происходят в нужном темпе. С другой - они учатся очень важным вещам: планировать свое время, оценивать трудозатраты, обсуждать и согласовывать свои действия, контролировать работу друг друга, помогать при необходимости и т.п. Я думаю, ни одна взрослая опытная scrum-команда не способна на такие изменения и рефлексию по ним за урок. Что же говорить о школьниках? 

В-четвертых, время на проект. По большому счету, eduScrum пляшет от того, что есть некая тема, на изучение которой выделено N часов. Часы эти распределены по урокам, и каждый ученик должен эти N часов на изучение темы потратить, т.е. изучить все во время уроков. Мы же при организации проектов ориентируемся на то, что у разных учеников разный резерв времени на проект. Кто-то может тратить на него только N часов, кто-то - N+M часов. Почему же не дать возможность кому-то получить на M часов больше проектного опыта, делая что-то дополнительно вне занятий? 

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

В-пятых, истории. Собственно, отличия к тому, как они формулируются, пляшут от всех предыдущих отличий моего подхода и eduScrum. 

• Отличие 1. Истории в scrum формулируются от лица пользователей продукта. Причем, если у продукта несколько пользовательских ролей, то будут целые блоки историй - по каждой роли. На своих проектах мы так и делаем: ученики выделяют роли пользователей и описывают продукт от их лица. Получается, что в команде у всех примерно одинаковая работа, но артефакты разные, друг друга дополняющие.
  А вот в eduScrum получилась, на мой взгляд, каша. Если отталкиваться от концепции продукт=ученик, то истории должны быть от лица пользователя этого продукта (родителя, нанимателя и т.п.). Но - та-дамм! - в eduScrum истории формулируются от лица... самого продукта! "Мы, как команда, хотим знать таблицу умножения, чтобы...". Вполне даже и неплохо можно так проработать содержание курса, но тогда это истории использования курса, т.е. продуктом должен быть курс, а не сам ученик! И это отличная была бы ситуация: когда ученики из полного набора таких историй могли бы собрать свой собственный резерв продукта, читай - свой собственный курс исходя из своей собственной подготовки (привет, индивидуальные планы обучения!) Но нет...
• Отличие 2. В eduScrum обязательно появляется история "Теория". В моем подходе изучение теории происходит до того, как мы приходим в проект. Т.е. предполагается, что команда уже имеет теоретическую подготовку, чтобы творить некий продукт. При этом, безусловно, возникают то у одного, то у другого ученика ситуации, когда теории не хватило, и нужно что-то изучить дополнительно - тогда ученики сами инициируют обучение, и я, как SM, обеспечиваю им это обучение. Причем, я тщательно изучаю запрос и выбираю форму: статью написать, вебинар провести, видеоурок записать, самой или кого-то пригласить и т.п. Как правило, запросы приходят настолько продуманные и глубокие, что одно удовольствие с ними работать. Ну, и само такое обучение, конечно, оформляется не как целая история, а как самая обычная задача.

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

На тренинге нас было несколько человек, кто использует "чистый" scrum. Если честно, мы два дня недоумевали, зачем было придумывать какую-то адаптацию, если "чистый" scrum прекрасно подходит для учебных проектов. Ответ на этот вопрос мы так и не нашли. А ведь eduScrum позиционируется подходящим для любого обучения. Представьте, как себя должен чувствовать студент вуза или слушатель курса повышения квалификации, если он прямо сейчас где-то работает по "чистому" scrum, а тут вдруг слова все знакомые, а процесс совсем другой? У него будет такая же каша, какая была у нас два дня. 

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

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

А мои цели 1, 2 и 5 достигнуты полностью, цель 3 - частично, достижение цели 4 в планах на весну. 

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

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

• Понравилась идея сделать демо-проект, в котором уже расписаны все истории, критерии и задачи, и на нем показывать, как что из чего проистекает. Даже уже придумала, куда ее приложить.  
• Впечатлило количество учителей и преподавателей вузов, которые за свои кровные (а то и вовсе взяв отпуска за свой счет), приехали учиться в Москву. Отдельная большая радость - что из Беларуси нас было аж четверо (см. фото)! 
• Я очень благодарна ведущим, которые несколько раз озвучили: учебный проект и построение команды - это длинная история. Не на один урок, и даже не на пару дней. По крайней мере, если речь идет не только об изучении темы, но и о развитии компетенций (тех же 4К). В том же eduScrum мини-проект - это примерно 7 уроков, т.е. может идти несколько недель! И группа - это еще не команда! 

Благодарна всем коллегам, с кем довелось поработать в командах, а также нашим искренним ведущим. Как бы мы все ни использовали Scrum, пусть это будет в интересах наших учеников, релевантно поставленным образовательным задачам, а не ради модных словечек. И пусть приводит к самым высоким образовательным результатам!