AgileDays-2011: Отчет Гребнева Н.Ю./Командный старт

Сергей Дмитриев

Фотографии флит-чартов с мастер-класса: http://www.dropbox.com/gallery/3490871/4/Documentation/Conferences/AgileDays%20Msk%202011/Team%20startup?h=06ae92

Какие бывают игры…

Это был мастер-класс посвященный такому процессу как «командный старт». Сергей под командным стартом понимает специально выделенное время, когда собирается вся команда вместе, а также люди имеющие отношение к проекту (типа Product Owner `a и руководства заинтересованного в результате), с целью познакомиться друг с другом и проектом в целом, а также определить общие ценности и видение проекта.

Сергей рекомендует для командного старта отвести один день. Командный старт необходимо проводить когда:

Собирается новая команда для проекта
В команду приходят новые члены
Команда начинает новый проект
При внедрении agile.

Проведение командного старта позволяет:

Найти общую отправную точку
Обозначить общие ценности команды
Определить общее видение проекта
Увеличить шансы на успех

Во время командного старта необходимо сделать:

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

Первый и пятый шаги должны занимать большую часть времени командного старта. Сергей придерживается концепции Брюса Такмана по развитию команды (Forming-Storming-Norming-Performing) и считает, что при изменении состава команда вновь оказывается в стадии Forming и из-за этого некоторые команды никогда не выходят на performing. Командный старт направлен именно на то, чтобы сократить стадии forming, storming, norming и выйти на performing. Это необходимо потому, что производительность хорошо сработанной команды может быть выше в несколько раз, чем просто у группы людей собравшихся для выполнения одной работы (по некоторым исследованиям прирост производительности составляет до 400 %).

В качестве инструмента для проведения командного старта докладчик рекомендует использовать игры (в выступлении были приведены в качестве примера, игры «35», «Мне интересно…», «спагетти» и т. д.). Игровая форма расслабляет людей и позволяет быть более открытыми и ускоряет процесс решения задач. Например, для знакомства членов команд друг с другом просить каждого рассказать о себе достаточно бесполезно, так как из рассказа вряд ли удаться понять какими навыками человек обладает и чем он увлекается. А при использовании игры типа «рынок навыков» это получиться сделать легко и непринужденно. Сергей также рекомендует в качестве пособия по играм обратиться к книге Innovation Games.

После мастер-класса была серия вопросов и ответов не всегда по теме, но достаточно интересных. Мне больше всего понравился вопрос про то, как команда должна принимать технические решения. Сергей считает, что команда должна принимать решения только единогласно и пока среди всех членов команды не будет достигнуто взаимопонимание, то должно продолжаться обсуждение. При этом уровень решений, которые принимает команда, должен быть ограничен итерацией. Решения, которые влияют на проект в целом, должны приниматься product owner`ор, причем возможно без учета мнения команды или вопреки ему. Более того команда для product owner`а не является единственным инструментов для выполнения проекта, у него также могут быть люди не входящие в команду, но при этом работающие на проекте. Например, таким человеком может быть системный архитектор, который также в своей работе может не принимать во внимание мнение команды, но при этом должен убедить product owner`а в правильности своего решения. Фактически PO и его люди отвечают на вопросы, что делать, а команда — как делать, причем именно в рамках итерации.

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