Доброго времени, хабравчане.

Хочу поделиться наблюдениями возникшими в процессе проведения трека «Usability Engineering & Ubiquitous Computing on mobile devices» который проводился в рамках совместной российско-немецкой студенческой школы JASS-2012 о которой уже писали на хабре. Однако, в отличие от предыдущего поста я буду описывать школу глазами организатора.

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

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

Инициация проектов

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

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

Выглядело это очень весело. Участникам было дано несколько пачек стикеров и 10 минут на генерацию самых фантастических идей проектов. Каждая идея записывалась на стикере и клеилась на маркерную доску. За 10 минут было сгенерировано несколько десятков идей. Выбрали модератора, который стал зачитывать по одной идее с доски, вызывая автора пояснить свою мысль и заинтересовать присутсвующих. Автор каждой идеи имел примерно 15-30 секунд на объяснение. После представления, идеи ранжировались на той же доске по количеству полученных голосов (каждый имел право, как зритель гладиаторского поединка, проголосовать за отправку идеи в корзину или за ее реализацию).

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

Последняя фаза — распределение участников по командам. Каждый мог заявиться для участия в любом из выбранных проектов, но было выдвинуто несколько ограничений — команды должны содержать как минимум по одному представителю из России и Германии, и в проекте не может быть больше 5 и меньше 3 человек. Таким образом мы создали весьма мотивированные и рвущиеся в бой команды.

Требования

Ни для кого не секрет, что требования, это краеугольный камень в разработке программного обеспечения. Их так сложно сформулировать, донести до каждого члена команды и следить-следить-следить за изменениями и меняющимися условиями… Масса книг, которые must read каждый разработчик (Брукс, Де Марко, Спольски, Купер,… ) снова и снова делающих попытки объяснить природу понимания командой требований, управления ими, взаимоотношений между разработчиками так и не вносят окончательного просветления в умы проектных менеджеров и программистов.

Мы применили следующую, на мой взгляд, очень эффективную методику управления требованиями — рассмотрели сбор и разработку требований как создание фильма. Да, да — небольшого ролика длительностью от 45 до 60 секунд. Этот ролик сразу позиционировался как рекламный ролик для продажи продукта. В создании такого ролика участвовал каждый член команды, и его появление это с одной стороны результат командной переработки требований и, самое главное, фиксация того самого единственного и главного юзкейса, ради которого создается проект. Почему это работает лучше, чем любой другой механизм управления требованиями в небольшой команде? Да хотя бы потому, что кинематографический образ не только проще, но и психологически приятнее удерживать в голове, чем текст, набор задач в трекере или иной формальный или полу-формальный документ. Фактически, это визуализированная User Story, и разработчикам не требуется прилагать усилий чтобы понять ее смысл, поскольку каждый принял участие в создании. Я бы назвал подготовку такого фильма эмоциональным усилителем восприятия требований.

Процесс

Поскольку мы имели очень ограниченное время для разработки и обучения, было решено опробовать на студентах несколько видов scrum-митингов (митинг — от англ. meeting, совещание).

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

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

Третий вид митинга, примененного в рамках школы — попытка реализации scrum of scrum, когда каждая команда самостоятельно определяет свой статус и выделенный участник рассказывает о статусе команды на своего рода мета- митинге. Это упражнение дает ощущение того как процесс может быть отмасштабирован в больших проектах.

Chaordic teaching

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

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

Такой подход к обучению мы назвали Chaordic teaching, позаимствовав идею у Dee Ward Hock который являясь CEO VISA применил такое слово, образованное из Chaos и Order (с англ. хаос и порядок), обозначив границу между ними, считая что именно на этой границе возможны различные инновации и открытия. И мы убедились в рамках нашей школы, что это действительно работает, как в сфере обучения, так и в сфере разработки.

Выводы

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

Идея chaordic teaching так понравилась, что мы запланировали сделать небольшой совместный доклад на эту тему на ближайшей конференции SECR.

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

Chaordic teaching или что общего между Agile и обучением в IT