четверг, 11 ноября 2010 г.

Rugby, Agile, и командная работа

Почему Такеути и Нонака, в своей статье The New New Product Development Game сравнили процессы в проектной деятельности с процессами в игре Регби и конкретно с игровой ситуацией Scrum (схватка)?

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

Давайте попробуем взглянуть на эту игру глазами основателей Scrum.
И так постарайтесь представить себя японцами, учащимися в Англии и наблюдающими за игрой регби:

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

На самом деле Scrum и регби очень просты и подчиняются четким правилам.

Регби: командная игра

Цель – приземлить мяч за линию ворот соперника.
Основное правило – руками мяч можно передавать только назад.

Приведенное выше правило может показаться простым, но здесь есть подвох.

Это правило создают потребность в четкой командной работе, дисциплине и взаимопомощи.
А это уже человеческий фактор, который увы не прост.

Для более глубокого понимания Scrum, рассмотрим базовые заповеди Регби.

Слайд: Основные базовые заповеди

«Передавать мяч можно только назад». Вследствие чего возникает необходимость преодолевать каждым членом команды непосредственное, физическое сопротивление соперника. Применительно к проектной деятельности это означает: «Работа с требованием переходит от одного специалиста к другому и каждый должен преодолеть определенный вид сложностей, причем получающий требование игрок немного отстает от передающего из-за разницы начала работы с требованием». Это заповедь порождает следующую.
«Отдал мяч - сбавь скорость, чувствуй ритм, не забегай вперед мяча». Команда разнородна, кто-то очень быстрый, кто-то ловкий, кто-то более сильный. В результате появляется средняя скорость перемещения команды, выдерживая которую команда получает наивысшую мобильность и способность преодолевать сопротивление соперника. Если все таки игрок оказывается в положении “Вне игры”, то получается что он напрасно потратил силы для продвижения вперед, при этом никто ему не может легально передать пас, а если он получит пас, то команда заработает нарушение и потеряет контроль над мячом. В разработке ПО это означает: «Не прорабатывай лишние требования, т.к. “они протухнут”». Если Вы нашли свою командную скорость, то открывается новая заповедь.
«Поддержка». Если Вы не впереди мяча, а Ваш партнер с мячом захвачен и упал на землю то Вы, должны моментально прийти ему на помощь, чтобы соперник не овладел лежащим на земле мячом. В идеале на помощь должны приходить 2-3 игрока, чтобы сдержать яростный натиск соперника. В разработке ПО это один из ключевых моментов. Если человек плохо знает какую-то технологию, ему нужно помочь. Если разработчик запутался в диаграммах аналитика, то нужно помочь. Если разработчик не успевает написать java-скриптовый код, то ему нужно помочь. Если тестировщик перегружен задачами по тестированию, то ему нужно помочь. Если у члена команды личностные проблемы, то его надо поддержать.

Trust Me, I’m …

И так, самое интересное – игра и перемещение игроков по полю.
В регбийной команде 15 игроков.

Если разделить игроков на группы, то основные из них:
Нападающие
Полузащитники
Защитники

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

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

В разработке ПО ролей и компетенций еще больше, основные из них показаны на поле.


Т.е. и регбийная и проектная команда кроссфункциональна.

Должен ли игрок быть кроссфункциональным?

Давайте посмотрим, что по этому поводу говорит Регби.
При этом обратите внимание на итерационность/фазовость атак.

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

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

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

Теперь поговорим о проблемах.

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

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

Если вы работаете по скраму с большим проектом, размер которого составляет десятки тысяч человеко/часов то помните, что необходимо регулярно раз в 1-3 месяца выпускать релиз. Это позволяет членам команды осознавать, что результатами их труда пользуются конечные пользователи, при этом желательно, чтобы те возвращали и положительный фидбэк. Если же вы выпускаете релиз раз в год, то утомленность игроков после 20й фазы атаки настолько велика, что они в лучшем случае готовы на реализацию заработанного штрафного, а в худшем совершают грубое нарушение и их удаляют с поля. После этого команде требуется некоторое время на восстановление моральных и физических кондиций. Как следствие, команда перестает работать эффективно.

«Звездность» одного игрока ведет к разбалансированности игрового ритма и скорее всего межличностным конфликтам. В такой ситуации должен помочь авторитет капитана или тренера. Звездного игрока можно, например, привлечь к коучингу более слабых сотрудников.

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

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

Теперь упомяну старый добрый союз регби (IRB).
В данной организации принято за правило, что если мнения, относительно принятия нововведения делятся в пропорции примерно 50/50, то принимается решение о введении экспериментальных правил. Правила вводятся на ограниченный период времени, по окончании которого и принимается решение о целесообразности включения нововведений в общий свод законов.
Данная практика отлично вписалась в рабочий процесс. Теперь подобным образом у нас принимаются решения относительно изменения бизнес-процессов, внедрения инструментов управления проектами или выбора платформ реализации. Например, переход с TrackStudio на Redmine.

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

Используйте Scrum и играйте в регби!

p.s. Эта статья резюмирует мой доклад на spb.agiledays'11.

Комментариев нет:

Отправить комментарий