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

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

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

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

Именно поэтому в первом семестре на ФИИТ появляется курс «Основы проектной деятельности».

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

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

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

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

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

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

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

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

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

Проект

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

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

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

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

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

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

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

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

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

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

Итог

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

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

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

Возможно, среди читателей найдутся те, кто либо делает подобное, либо просто имеют своё мнение :) Расскажите мне, что можно улучшить или сделать по-другому?

А подать документы на поступление можно в личном кабинете УрФУ.