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

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

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

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

До старта проекта

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

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

Следующий этап работы — планирование и распределение задач.

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

Как раз такой подход формализует Scrum. Мы выбрали его как самый легкий для входа и подходящий для студенческих проектов. С его принципами мы знакомили ребят на примере... строительства города (на фото) или туристического острова из Lego! :)

Lego это же так просто, да? Сложности начинаются, когда у вас есть заказчик с какими-то не всегда явными желаниями и ожиданиями. «Погодите, вы построили детский сад рядом с вулканом? Нет-нет-нет, безопасность детей — наш первый приоритет! Переделывайте!» Ребятам предлагается строить из Lego с помощью гибкой методологии, с итерациями, командным планированием, демонстрацией промежуточных этапов заказчику. «Вот, теперь отличный вулкан! А как все-таки туристы будут подходить к его жерлу? В смысле, «никак»? Кому нужен такой вулкан?!» Отличный и весёлый способ быстро и интенсивно прочувствовать смысл итеративной разработки. «Ого, это что, большая статуя пирата на пляже? Прекрасно! Очень нравится!».

Проект

Итак, собрали команду и научились планировать, пора работать! Самое время рассказать про задачу, которая стояла перед командами. Это был не совсем программный проект в обычном понимании этого слова. Это было соревнование.

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

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

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

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

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

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

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

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

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

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

Итог

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

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

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

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

А если вы выбираете себе ВУЗ прямо сейчас, то обратите внимание на нашу программу ФИИТ УрФУ. Подать документы на поступление можно в личном кабинете УрФУ.