Участвуя в различных дискуссиях, посвященных процессам разработки ПО можно заметить, что Scrum постоянно находится в центре внимания, вызывая множество споров и обсуждений.
Интересно, что поле для дискуссии все еще огромно, несмотря на уже весьма солидный возраст процесса Scrum. Для меня это значит, что Scrum растет, развивается и совершенствуется, что бы помогать нам решать новые проблемы и находить более эффективные решения к старым.
Вместе с процессом развивается трактовка ролей и инструментов Scrum, мы по новому смотрим на взаимодействие членов команды, появляются новые практики для успешного разрешения возникающих вопросов.
Один из наиболее интересных вопросов, обсуждающийся IT-сообществом - кем становится сегодня самая одиозная личность в Scrum – Scrum-Мастер! Должен ли он обладать выраженными техническими скилами или, напротив, они ему не нужны, в то время как без коуч-скилов ему никак не обойтись? Какие метаморфозы претерпевает эта роль, когда мы используем наиболее успешный «тендем» - Scrum+XP?
Давайте обратимся к каноническому определению Scrum-Мастера. Итак, вот его обязанности:
- Устранять любые (внешние и внутренние) препятствия на пути команды к достижению цели спринта и релиза
- Контролировать следование процессу
- Проводить фасалитацию (ну и слово...) митингов
- Поддерживать командный дух и фокус на общих целях
И при этом, что важно, Scrum-Мастер должен быть "свиньей" а не "цыпленком", то есть, проще говоря, членом команды! И естественно, принимать деятельное участие в разработке. Поэтому им обычно является один изразработчиков. Вот тут то и начинается самое интересное. Давайте взглянем на зоны ответственности SM и попытаемся определить, какими чертами должен обладать человек для того, что бы успешно с этим справлятсья:
- Целеустремленность
- Организованность и, в некоторой степени, педантичность
- Коммуникативность
- Неконфликтность
- Незаинтересованность в предмете - для проведения митингов
- Желание помогать
Сразу становится ясной некоторая уязвимость такого определения SM - ведь далеко не все программисты обладают хорошими коммуникативными навыками (чаще наоборот). Незаинтересованность в предмете обсуждения тоже представляет собой проблему, так как SM-программист тоже иногда участвует в митингах как активный участник и тогда нужно передавать фасилитацию кому-нибудь другому "на время". Ну и неконфликтных людей, к сожалению, не так много в этом мире, как этого бы хотелось. А уж "поддержание командного духа и фокус на общей цели", то бишь team-building - это вообще довольно сложный предмет, которым обычно занимаются менеджеры и лиды...
В общем, идея SM от первоисточников имеет право на существование, но при этом может быть применена в весьма ограниченном количестве случаев - обычно когда команда уже сложившаяся, все в ней такие конструктивные и процесс устаканился. А вот так, что бы создать команду из сложных талантливых индивидуальностей в условиях кризиса на проекте - тут уж увольте! Я знаю множество классных программистов и очень их ценю, но выполнить миссию SM в таких условиях для программиста почти нереально!
Насколько я понимаю, к подобной же мысли пришел не один я. Поэтому, чем дальше в лес, тем более сложной становится роль скрам-мастера. Тем больше ему надо знать и уметь вещей, которые не имеют отношения к программированию. А раз навыки и способности SM все дальше уходят от технических к административное-социальным, значит и требования к SM меняются. До сих пор некоторые продолжают обсуждать варианты совмещения роли технического лидера (которая явно или неявно обычно проявляется в любой команде), но эта дискуссия осмысленна только когда SM особо ничего не надо делать по своим главным обязанностям (когда команда хорошо работает, PO не бузит и унитаз в туалете не засорился, работа SM становится простой и приятной, да и занимает не менее 20% времени). В реальном мире, где исключительные ситуации, требующие вмешательства SM происходят каждый день, а рискам (особенно, невыявленным) свойственно сбываться, трудозатраты SM на Scrum и команду становятся очень существенными и ему все труднее становится выполнять при этом еще и программистские задачи.
Еще одна проблема - это саморазвитие. Когда я был программистом, я старался тусоваться на технических конфах, читал Кнута, Страуструпа и Банду Четырех. Когда я стал заниматься управлением проектами, я переключил свой фокус на Project Management, Коучинг, командообразование, Requirements Engeneering и планирование. Развиваться одновременно по нескольким векторам и делать это эффективно способны единицы! Именно поэтому так тяжело совместить в одном человеке хорошего программиста и хорошего скрам-мастера. Вот классный программист и средненький SM-вполне реально. Или плохонькой програмер и божественный SM - тоже можно.
Но тогда внимание, вопрос - зачем хорошей команде плохонький программист? Его "выход" все равно ничтожен по сравнению с общим "выходом" остальной команды. Он не развивается как порграммист и не знает новые технологии. Он не умеет делать Dependency Injection и пишет кривые Unit-тесты. Как вы думаете, это будет способствовать установлению дружесткой и конструктивной обстановки в команде?
Выходит, что за исключеним нескольких гуру, реализовать каноническое определение SM в реальности почти никто не способен. И именно поэтому некоторые команды пришли к идее выделенного Scrum-Мастера. Человека, который не занимается программированием и по-сути, уже не является "свиньей". Человека, который как раз и занимается все время только тем, что помогает команде, защищая ее права перед PO и кастомером, проводя для нее митинги, выявляя конфликты и помогая их решать с использованием таких практик как, например, коучинг. Человека, который даже занимаясь контролем следования процессу будет максимально деликатен и не будет "строить" команду за опоздание на Daily Standup. Никого вам не напоминает?
Это же XP-шный коуч! Вот они - плоды многолетнего совмещения XP и Scrum - правильные и полезные вещи начинают проникать из одного процесса в другой, принося каждому из них новые ценности!
продолжение следует...
П.С. Кстати, навеяно вот этим обсуждением: http://www.infoq.com/news/2010/06/technical-scrummaster
Итак, в первой части статьи мы смогли выявить обозначившуюся тенденцию к выделению Scrum-Мастера из команды, переводу его из отряда "свиней" в отряд "цыплят" и снятию с него обязанностей по разработке.
