Миграция Scrum-Мастера

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

Вместе с процессом развивается трактовка ролей и инструментов Scrum, мы по новому смотрим на взаимодействие членов команды, появляются новые практики для успешного разрешения возникающих вопросов.
Один из наиболее интересных вопросов, обсуждающийся IT-сообществом - кем становится сегодня самая одиозная личность в Scrum – Scrum-Мастер! Должен ли он обладать выраженными техническими скилами или, напротив, они ему не нужны, в то время как без коуч-скилов ему никак не обойтись? Какие метаморфозы претерпевает эта роль, когда мы используем наиболее успешный «тендем» - Scrum+XP?

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

1. Устранять любые (внешние и внутренние) препятствия на пути команды к достижению цели спринта и релиза
2. Контролировать следование процессу
3. Проводить фасалитацию (ну и слово...) митингов
4. Поддерживать командный дух и фокус на общих целях

И при этом, что важно, Scrum-Мастер должен быть "свиньей" а не "цыпленком", то есть, проще говоря, членом команды! И естественно, принимать деятельное участие в разработке. Поэтому им обычно является один изразработчиков. Вот тут то и начинается самое интересное. Давайте взглянем на зоны ответственности SM и попытаемся определить, какими чертами должен обладать человек для того, что бы успешно с этим справлятсья:

1. Целеустремленность
2. Организованность и, в некоторой степени, педантичность
3. Коммуникативность
4. Неконфликтность
5. Незаинтересованность в предмете - для проведения митингов
6. Желание помогать

Сразу становится ясной некоторая уязвимость такого определения 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

AgileDays'10 в Питере

Ураааа! AgileDays'10 в этом году будет целых две! Сначала - в сентябре в Питере (интересно, как это будет? все-таки это серьезный challenge для организаторов), затем в конце года в Москве. После AD'09 я решил, что не хочу пропустить следующие подобные события - слишком интересные люди, да и организация AD'09 в Москве была просто великолепна.
Инфа о AD'10 пока нормально не опубликована, но какие-то крупицы уже стали появляться, например на сайте ScrumTrek: http://scrumtrek.ru/trainings-timetable/register/75

Я планирую не ударить в грязь лицом и выдать на AD'10 что-нибудь не хуже своего доклада на AD'09. Столько идей, столько идей..... :)

Вот и отпуск закончился

Вот и закончился отпуск! За эти две недели на даче мне удалось не только полностью отключиться от работы(ура!), но и пришло несколько интересных идей для лекций по гибкой разработке. Удалосб закончить лекцию "Эффективное Использование Scrum" и подготовить основу для лекций про XP и совмещение практик XP и Scrum. На ближайшие две недели уже запланированы две лекции по Scrum - аудитория уже собралась(ура еще раз!). Думаю, что в конце августа проведу повторную лекцию "Введение в Гибкую Разработку" - там есть много интересного про Kanban и FDD и, думаю, что многим новичкам это будет интересно.

И, кстати, я немного поработал над огугливанием нашей компании - на двух этажах установил баскетбольные кольца и положил плюшевые мячи (сначала купил обычные баскетбольные, но оценив их вес, понял, что после первого же часа игры мы останемся без зеркал, окон, ламп и камеры наблюдения в коридоре :) ). Немного рекламы - и вот уже народ с удовольствием пуляет мячики в свободное время! Так что еще одно УРА! Огугливание компании идет успешно!

Работа над образом компании. Очередной шаг

Всем привет!

Мы все знаем Google, Microsoft, Sun и другие компании в которых люди будут просто счастливы работать, если их туда просто позовут, а некоторые (которых не зовут, и таких большинство) проходят для этого сложные интервью и всем силами стараются доказать работодателю, что именно они - то что нужно для этой компании. В таких "неравных браках" компания находится в заранее выгодном положении, но не надо считать, что это неправильно или несправедливо. Совсем нет! Для того, что бы такая ситуация сложилась, компания долгие годы работала не только над созданием классных продуктов, но и над собственным имиджем. Причем, не только имиджем для своих заказчиков (тут-то все из кожи вон лезут, ибо это закон рынка), но и имиджем для своих сотрудников - реальных и потенциальных.

Можно уверенно утверждать, что дальше всех в этом направлении продвинулся, конечно, Google. Кто из нас хоть раз не разглядывал с благоговением "те-самые фотографии офиса Google"? :) А сколько ходит разговоров про их "инженерные дни", про их потрясающий командный дух и все такое прочее. Воистину, Google - это земля обетованная для разработчиков, где текут пивные реки и гордо возвышаются берега из удобных бин-бигов, а в небе парит птица с тремя мониторами...

Не стану скрывать, и я какое-то время назад тайком мечтал о работе в этой компании...грешен :) Но вот какое дело - то, чем я сейчас занимаюсь в AVIcode (и с кем я это делаю) мне настолько нравится, что я не хочу идти в Google.

Черт! Значит не будет у меня 3-х мониторов, значит не будут говорить знакомые: "Аааа. Так ты в AVIcode! Ну ни фига себе, как тебе повезло! Я слышал, что та му вас...." и не будет бин бегов и дизайнерских столиков для чаепитий?.....

К счастью, я не впал в депрессию, а традиционно настроился на конструктивный лад и сказал себе: "Ну раз мы не идем в Google, пускай Google идет к нам!" Точнее нам нужен не Google с его проектами и работникам. Нам нужен такой же или лучший имидж и дух компании! Мы можем сами стать гуглом, майкрософтом или лабораторией касперского - все в наших силах!

Звучит, конечно, пафосно и (возможно) нелепо, так как на сегодняшний день между нашими компаниями в этом плане - пропасть шириной с Grand Canyon. Однако, даже если мы долетим хоть до четвертинки (эге-гей, какие планы!) этой дистанции, это будет колоссальный прыжок вперед для компании. Уже в этой ситуации люди будут АПРИОРИ хотеть работать в нашей компании, и именно им придется доказывать, что нам необходимо их нанять, а не иначе.

Вот такие вот у меня наполеоновские планы :) Догнать и перегнать Google - не больше и не меньше!

Запуск программы "AVIcode - Школа Профессионалов"

Всем привет!

Ура! Сегодня состоялась первая лекция в рамках программы по внутреннему обучению, которую мы запустили в нашей компании. Для меня это приятно вдвойне, так как, во-первых, я являюсь одним из организваторов этой программы, а во-вторых, это была моя лекция "Введение в Agile Development". Мне кажется, что в жесткий формат одно-часовой лекции удалось вложить действительно много материала и при этом не "высушить" лекцию, доведя ее до состояния справочника.
Вся лекция прошла на отличном драйве и хорошем контакте с аудиторией (хотя уровень знаний как об IT так и об agile у всех был достаточно разный). Но я столкнулся с интересным эффектом. Если выступление на AgileDays перед аудиторией в 100 человек зарядило меня энергией на 10000 вольт, то эта лекция для 8 человек наоборот выжала меня до полуобморочного состояния...потом 3 часа каматозил и отпаивался сладким чаем с лимоном...
Интересно, чем объясняется подобная разница в энергетике? Является ли подобное поглощение энергии свойством маленькой группы, или это особенность данной конкретной группы? Ну, или наконец, может я просто не выспался, репетируя лекцию вчера до 3-х часов ночи? :) Думаю, что ситуация прояснится чуточку позже: 17-го июня будет повторная лекция для второй группы - вот там и посмотрим...

Лучший Task-Board

Всем привет!

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

1. Whiteboard - есть почти у всех, но по-факту, самый неудобный вариант, т.к. прикреплять к нему задачи неудобно (post-it листочки все время отлепляются, а магнитиков не хватает), да и доска для записей тоже иногда нужна. Так что этот способ уже почти не используется.


2. Пробковая доска - недорого и довольно удобно. Разделяется на зоны ленточками(да хоть изолентой), задачи крепятся кнопками. Основной минус - это именно кнопки: все время падают, теряются и т.д. Но в целом, вариант весьма неплохой.


3. Askhat-style Taskboard- знаменитые taskboard-ы от Асхата Уразбаева из всего, что под руку подвернется: пенопластовые потолочные модули, листы ватмана и прочее. Основной их плюс - это уникальное авторское исполнение, а так же исключительна дешевизна и простота в изготовлении.

Для своих проектов я использовал решение, которе до этого не встречал ни у кого - это доски с клейкой поверхностью 3M. Стоит такая доска 40х60 см около 600 рублей, так что я не могу назвать этот способ дешевым (для одного таксборда нужно от 3-х такиз досок), зато удобство исключительное! Задачи, burndown chart, заголовки секций и все остальное прекрасно прилипает к поверхности доски, а когда нужно снять или передвинуть что-то, то это делается элементарно!

Купить такие доски можно много где (e-shops, канцелярские сети или, например, гипермаркет METRO Cash&Carry)

Удачи!

Второе правилу коуча

Во время очередного сеанса коучинга с нашим HR мы заговорили о проблемах, которые возникают у самого коуча. Ведь если он не независимый конультант, а сотрудник компании, то у него скорее всего есть руководитель, с которым тоже нужно общаться, решать проблемы, предлагать новые идеи. И вот тут-то я услышал очень странную для себя вещь: "Коуч не должен коучить своего начальника! Никогда!" Причина? Очень просто: дело в том, что в процессе сеанса "пациент" может прийти к какой-то неожиданной мысли о самом себе, вскрыть и высказать вслух то, что обычно руководитель никогда не говорит своим подчиненным (например, о каком-то своем недостатке). И это, в свою очередь его весьма не порадует и, очевидно, неявно спровоцирует негатив в отношение человека, который "развел" его на это признание - то есть в отношение коуча.

Надо сказать, что меня эта мысль очень удивила. Фактически, принимая это правило, коуч себя значительно ограничивает, сознательно отказываясь от прекрасной практики там, где она может помочь не только ему лично, но и всей компании! Ведь не надо забывать, что коуч не навязывает (явно или неявно) свои идеи "пациенту", а помогает ему прийти к правильному решению его проблем! Мое мнение - начальника коучить можно и нужно,...но осторожно :) Желательно заранее понимать те темы и проблемы (обычно личные), которых стоит избегать и аккуратно уводить разговор в сторону от них. А со временеми, возможно, отношение я руководителем станут более доверительными и таких тем будет становиться все меньше. Так что коучинг начальника вполне допустимая практика, правда требующая высокого мастерства и начинающему коучу лучше практиковаться на других :)