Эффект Приближения к Цели

Когда свои мысли еще не оформились для изложения в блоге не грех и написать об интересностях, прочитанных на других ресурсах. Так в начале декабря на Software People появилась интересная статья об "Эффекте Приближения к Цели". Фабула этой статьи в следующем: не только реальный прогресс, но и даже его иллюзия повышают мотивацию. С точки зрения people management, а так же в контексте построения отношений с заказчиком это дает интересную пищу для размышлений. Правда, как и любой фокус, этим инструментом необходимо пользоваться осторожно и не злоупотреблять, иначе это превратится в профанацию. Так что кладем на полочку в нашей голове с пометкой "интересно, попробую как-нибудь" :)

Моя Шизофрения

Всем привет!

Сегодня пора рассказать миру о том, что твориться в моей голове...равно как и в голове тысяч других менеджеров по всему миру. Да! Сегодня, друзья, речь пойдет о наиболее распространенном заболевании PM-ов, а именно - шизофрении. Надеюсь, что коллеги не станут меня ругать за то, что я решил открыть эту нашу маленькую тайну...

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

1. Собственно, Менеджер проекта (планирование, отчетность)
2. Бизнес Аналитик
3. Системный Аналитик
4. Лидер (визионер)
5. Владелец проекта (если у нас scrum-scrum)
6. People Manager (карьера членов команды, развитие, обучение, зарплаты...)
   

Довольно много разных ролей, не правда-ли? И, что характерно, активности, а самое главное интересы в этих ролях далеко не идеально совмещаются. Одно из наиболее явных противоречий, которое сильнее всего проявляется - это совмещение двух следующих зон ответственности:
1. Отстаивание интересов заказчика
2. Отстаивание интересов команды

Если у вас еще есть сомнения, что эти интересы надо отстаивать, то просто приведу "на-гора" несколько тривиальных примеров:
- "...заказчику нужно успеть сделать продукт за 2 месяца, а команда утверждает, что только на дизайн необходимо 7 недель..."
- "...заказчик хочет иметь полный доступ к исходникам проекта, а так же сам вносить изменения в них в любой момент..."
- "...заказчик регулярно устраивает неожиданные визиты в ваш офис и каждый раз требует от каждого программиста отчета о том, чем он занимается..."
- "...программистам ужасно интересно использовать .Net 4.0 и они бы не прочь изучить его за счет заказчика, раздувая сроки....а заказчику вполне достаточно и тех технологий, которыми уже владеет команда..."
- ну и так далее...

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

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

Вот и получается, что менеджерам проектов постоянно приходится вести незримый бой по отстаиванию интересов всех участников проекта прямо в своей голове. Да на таком уровне, что мистер Фикс из старого мультфильма "За 80 дней вокруг света", ведущий диалоги сам с собой выглядит абсолютно здоровым человеком.

Что с этим делать? Хмм...думаю, что об этом будет рассказ во второй части этой статьи. И я лучше это обдумаю и интрига будет напряженнее :)

Думай о хорошем

Пока летал в белоруссию на тренинг Славы Панкратова "Тренинг в ИТ" почитал последние сообщения блога студии детской анимации "Да". Потрясающие люди! Позитивные, открытые, делающие то, на что у обывателей нет или времени или смелости. Спасибо им еще и за то, как они способны поддержать любого, кто читает их блог. Вот вам цитата, дающая +100 позитива и надежды:

«Муха, как и пчела, очень любит мед. Но она не может удержаться и пролететь мимо какашек. Пожалуйста, думайте о хорошем...»

Анонс следующей встречи Agile-Питер!

Итак, определена дата проведения следующей встречи Agile-сообщества Санкт-Петербурга.
Тема новой встречи — «Работа с заказчиком и управление требованиями».
Обсудим, как быть с изменениями и жёсткими ТЗ, как строить отношения с заказчиком, что делать, а также попробуем вместе найти ответы на ваши вопросы.
Модерирует дискуссию консультант ScrumTrek — Алексей Корсун.

Участие бесплатное; количество мест ограничено.

Более подробный анонс и регистрация на Хабре: http://habrahabr.ru/blogs/agile/109210/

Где живут менеджеры

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

"Менеджеры живут на информационных потоках..."

Офигенно емко, выпукло, красиво и на 1000000% верно... здесь мы и живем, и все есть иллюзия, пока ты не поймешь этого... с пониманием этой простой и ясной мысли становятся не нужны Стивен Кови и другие консультанты, да и сам Александр Орлов уже не так необходим :) Просто с пониманием и принятием этого тезиса меняется система ценностей, меняется мотивация и поведение во всем...

Встречи AgileRussia.SPB

Свершилось историческое событие - в наших северных болотах "возобновились" (а учитывая, что перерыв был столь долог, что о них мало кто помнит) встречи сообщества AgileRussia! Наконец-то, наконец-то в нашу гавань зашли корабли гибкости и встали на якорь рядом с bootиком Piter the First!
Итак, в четверг, 18го ноября, в 19.00 по Ленинградскому времени Алексей Корсун, Михаил Карпов и Татьяна Васильева (пардон, лично знаком только с Алексеем :( ) собрали довольно значительную компанию людей (около 15 человек), которым интересен Agile. На повестке дня стояло два вопроса:
- "Распределенный Agile"
- "Автоматизация сборки и тестирования!"
Встреча проходила в формате свободной дискуссии, которую стимулировал и поддерживал Арексей Корсун. Сразу накидали достаточно много вопросов как на одну так и на другую тему - причем весьма разнообразных и интересных. Все это оставило у меня массу положительных эмоций, ведь это просто суперски, когда ты обсуждаешь интересную тебе тему в компании интересных, конструктивно настроенных людей. Приятным сюрпризом было встретить знакомого, которого не видел много (по-настоящему много) лет и законнектиться с ним через мойкруг. Увы, дела призвали меня и я вынужден был свалить по-английски не дождавшись даже пиццы, так что часть информации пришлось затем доставать из организаторов :)
Так вот! Засекреченный источник из узкого круга посвященных сообщил, что следующая встреча состоится через месяц (ориентировочно 18-го декабря) и на ней мы будем говорить о работе с требованиями! И это не может не радовать меня, как человека, 50% времени занимающегося именно этим!

Надеюсь, что со следующей встречи у нас будет полноценный репортаж со всякими интересностями! Всем удачи!

Оценки в Fixed-Price контрактах

Привет!

В последнее время мне все чаще приходится выполнять SWAGи для множества проектов, находящихся на различных стадиях (чаще всего на pre-sale). И основная проблема в том, что каким бы ни был контракт: Time-Material или Fixed-Price заказчик обычно требует определить бюджет проекта. Это, в принципе, разумно, так как без предварительных данных о бюджете менеджер на стороне заказчика обычно просто не в состоянии продвинуть проект (даже если он сам распоряжается деньгами).

В дебрях рунета наткнулся на небольшую статью об оценках затрат в Fixed-Price проектах:

http://www.enter-agile.com/2010/10/fixed-price.html?spref=fb. Статья несет в себе одну единственную полезную вещь, о которой стоит помнить планируя ЛЮБОЙ проект независимо от типа контракта. Мысль простая и разумная:

Оценивайте не модули (реализацию) а функциональность (требования).

Это действительно важно и крайне полезно, так как позволяет "играть" с содержанием(scope) проекта а так же очевиднее позволяет показать заказчику "тяжесть" каждой фичи. Хотя, надо сказать, бывают и другие ситуации:

1. Бывает необходимость разделять виды деятельности (например, разработка и тестирование) так как они будут выполняться различными субподрядчиками или финансироваться из различных бюджетов.

2. Зачастую бывает проще напрячь фантазию и разработать план, состоящий из "модульных" блоков, в составе которых делать глубокую декомпозицию до задач типа "разработать класс A" весом не более 8-16 часов, потому что только так можно показать ожидаемую продолжительность проекта заказчику, который не готов работать по Agile. Главное - даже не пытаться использовать этот план в дальнейшем! :)

Всем удачи! Точных вам оценок!

Суперцитата от Александра Орлова

Александр Орлов, как всегда, радует грамотными цитатами великих умов :) На этот раз в очередной раз попал в яблочко с моими текущими проблемами со своей цитатой Генри Форда:

"Я лучше нанял бы человека с энтузиазмом, чем человека, который все знает."

Человеки с энтузиазмом - приходите к мне на собеседование. Вы мне сейчас так нужны!

Коммуникации с заказчиком. О сборе требований.

Урааа! Наконец-то после месяца молчания я смог найти время для короткого (увыыы) и, пожалуй не слишком искрометного (позоооор!) поста о процессе сбора требований. Это скорее заметка на полях - некоторое время назад я просматривал слайдкаст доклада Александра Новичкова и Галины Карабановой "Коммуникации с заказчиком и проектной командой при сборе требований". В целом доклад несколько занудный (что, впрочем, типично для нашей отрасли :)), но несколько ключевых моментнов я для себя зафиксировал. Итак...

1. Правила хорошего слушания

• Перестаньте говорить
• Помогите говорящему раскрепоститься
• Покажите, что вы готовы слушать
• Устраните раздражающие моменты
• Сопереживайте говорящему
• Будьте терпеливы
• Сдерживайте свой характер
• Не допускайте споров и критики
• Задавайте вопросы
• Улыбайтесь
• Проявляйте искренний интерес

2. Восприятие информации

• На слух - 15%
• На глаз - 25%
• Аудио + Видео + Кинестетика - до 65%

По большому счету пункт 1 - это весьма вольное изложение идей активного слушания, о котором столько спето песен :) Активное слушание я люблю, стараюсь его активно использовать, так что авторы доклада молодцы, что затронули этот аспект. А вот пункт 2 будет вам гарантированно полезен если придется доказывать необходимость on-site визита к заказчику для уточнения требований или, напротив, для on-site визита к удаленной команде где-нибудь в Белоруссии для популярного выноса в массы идей проекта.

К слову сказать, мой последний проект показал на практике, что on-site визит - это просто волшебная штука и фактически must have во всех ситуациях, где вы делаете что-то хоть немного нетривиальное. Ну и не надо говорить, что особенно здорово, когда заказчик располагается в Вегасе, на Гавайах или хотя бы в Риме :)

Удачных вам проектов и непротиворечивых требований!

AD закончился...AD впереди

Отшумел, отговорил и отвыступал ADский сентябрь в Питере! По правде сказать, для меня это была весьма противоречивая конференция - с одной стороны, я познакомился с массой интересных людей, увидел и даже (хе-хе) потрогал живого Scrum-Coach, обсудил свои идеи и получил подтверждение того, что я на правильном пути (иногда это очень необходимо)...с другой стороны, только за день до этого я прилетел назад из командировки на другом конце земли и меня накрыло акклиматизацией по полной программе так, что я стал засыпать практически каждый раз, когда занимал неподвижную позицию :) т.е. : на докладе Девида Хассмана, на докладе Дэна Рострома, на окне, в кресле,...только беседа с Сергеем Дмитриевым (великим и ужасным :) dmitriev.com) не давала заснуть - спасибо ему за это огромное!
По этой же причине мой собственный доклад "Scrum-Master - кто ты?", задуманный как интересный, провокационный и яркий получился, на мой взгляд, скомканным и недостаточно выразительным... Сделаем зарубку на будущее - обратная акклиматизация исключает публичные выступления и эффективное общение :)
Зато у меня придумалась тема для выступления на московском AD'10. Думаю, что я ее обкатаю сначала в виде статьи в этом блоге (как и было с докладом про Scrum-Мастера)...тема интересная, как всегда провокациями :)

Нужна помощь!

Привет! Если кто-то все же читает этот блог - обратите внимание, что нашему коллеге - Владимиру Левчуку нужна помощь. Если коротко - рак. Все кто хотел бы помочь отцу троих замечательных детей и просто хорошему человеку - заходите на ЖЖ Владимира и сами решайте, как Вы лично можете помочь...

Manager 2.0

Привет! Вот уже несколько дней припадаю на несколько минут в день к занимательной статье на InfoQ о роли менеджера в Scrum-процессах. Статья, надо сказать, весьма интересная. В ней есть и очень качественные и впечатляющие случаи из жизни, показывающие как удачную миграцию менеджера в Agile так и наоборот - катастрофические. Основная мысль статьи спрятана примерно в середине текста, зато добротно сформулирована:

"Проще говоря, менеджер в Scrum не столько 'нянька' для команды, а скорее ментор и гуру, помогающий им учиться, расти и продуктивно работать. Это и есть переход от Manager 1.0 к Manager 2.0"

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

Помимо примеров и идей о "новом" менеджере, в статье приводится анализ обязанностей менеджера, которые "дружат" и "не дружат" со Scrum-ом. Осень хороший анализ, которые несколько отличается от анализа по PMBook, который в свое время делал Асхат Уразбаев на сайте ScrumTrek (или на AgileRussia...не помню).
Так что статься по-любому идет в must read для старых и новых менеджеров, из подчиненных и начальников :)

Сама статья: http://www.infoq.com/articles/scrum-management-deemer

Еще цитаты из Паркера

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

"В успешных организациях должны быть лидеры на всех уровнях...На самом деле, мы все в каком-то смысле являемся лидерами..."

"Сотрудники, которые любят свою работу, заставят клиентов полюбить свою компанию. Сотрудники, которые ненавидят свою работу, заставят и клиентов ее ненавидеть"

"Необходимо серьезно относиться к работе, но не стоит слишком серьезно относиться к себе"

"Зарплата не создает ощущения, что данная компания - ваша, а ее цели - ваши цели"

"Каждая возможность нанять нового служащего - это возможность улучшить команду или отправить ее ко дну"

думаю, достаточно цитат для одного поста...а что Вы извлекли из этой книги?

Шесть качеств Agile-команды. Анализ

Итак, давайте рассмотрим (возможно, даже критически) эти мистические качества члена Agile-команды, которые нам предлагали принять в предыдущем посте. Чем же выделяются такие люди:

1. Они готовы работать сообща
2. Не отказываются от помощи
3. Двигаются небольшими шажками и ориентируются на обратную связь(feedback)
4. Делают то, что нужно именно сейчас
5. Адаптируются к различным (не всегда привычным) условиям

6. Готовы работать вне своих ключевых навыков
Знаете, что интересно? Взглянув на этот список я вижу, что чем больше у разработчика опыт работы (в условиях традиционного менеджмента и процесса), тем хуже у него с этими навыками. Фактически, опыт в этой ситуации является главным врагом! Потому что наиболее профессиональные и опытные разработчики с которыми я сталкивался обычно обладают следующими чертами:

1. Яркие индивидуалисты, которые любят сконцентрироваться на своей задаче(области, технологии)
2. Они с сомнением относятся к возможности помощи со стороны коллег, так как прекрасно осознают, насколько они сам круты. Причем это распространяется и на ситуации, когда им нужна помощь в чем-то ином(например, отладка, поиск ошибки, выбор алгоритма и т.д.)
3. Они действительно рады уйти "в забой" на недельку и полировать свои торпеды до блеска, утверждая, что пока все не будет готово - показывать нечего. Просто у них есть собственные высокие критерии качества и они не готовы показать "недоделанный" код никому.
4. Они склонны к подходу BUFD (Big UpFront Design). То есть еще на этапе прототипирования они уже стараются ввести в архитектуру массу прикольных паттернов и решений, которые должны (в будущем) спасти систему от переделок.
5. Они по-хорошему избалованы. Ведь их ценность очевидна для работодателя и у них, зачастую, есть условия труда, которые их устраивают. Поэтому, попадая в зону дискомфорта(даже минимального, например, низкий уровень влажности в помещении) они весьма болезненно реагируют.
6. Им настолько "в кайф" заниматься своими любимыми технологиями или предметной областью, что они с огромным неудовольствием воспринимают любые идеи о кроссфункциональности. Не то, чтобы они не любят помогать коллегам. Но за ними водится привычка "отсылать к специалистам". Например, они лучше будут попинывать админов, чтобы те настроили выделенный домен и развернули там SQL-кластер чем сами займутся этим. Один из разработчиков объяснял мне это так: "Эта проблема не лежит в сфере моих профессиональных интересов и изучая администрирование WinNT домена я получу опыт и знания, бесполезные для меня в будущем"

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

Так что, соглашаясь с тем, что предложенные критерии действительно крайне желательны для члена Agile-команды, я хочу добавить еще предложение присмотреться к молодым энергичным разработчикам, а так же к их спокойным коллегам за 30, исповедующим (явно или лучше неявно) принципы дзен :)

Agile-team - 6 качеств, которые ее отличают

Привет!

Хочу поделиться попавшей на глаза интересной статьей Джоанны Ротман (рядом фото этой достойной дамы) о том, на какие человеческие качества стоит обратить внимание при формировании Agile-команды. Я позволю себе предложить вольное изложения статьи, но в любом случае рекомендую ознакомиться и с оригиналом.

Итак, чего нам стоит ожидать от кандидатов в наш agile-team? Что это должны быть за люди?

1. Люди, готовые работать сообща

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

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

2. Люди, не отказывающиеся от помощи

Все мы, будучи людьми целеустремленными, где-то амбициозными и довольно уверенными в себе по-умолчанию воспринимаем просьбу о помощи, как проявление слабости. Более того, в некоторых компаниях просто культивируется такая культура: ты - или мачо, или лох! А мачо справляются со всем сами.

Помимо того, что такой подход подрывает доверие людей друг к другу (ведь, по сути, просьба о помощи, это знак высшего доверия человеку), но и нарушает обмен информацией между членами команды. А ведь мы строим agile втом числе ради уменьшения объема формальной административной ерунды. И абсолютно нормально, что я не знаю всего обо всей системе, ведь когда мне становится нужно узнать что-то, я пойду и попрошу помощи у коллеги, который лучше знает тот или иной модуль.

Прощупайте кандидата вопросом типа: "Были ли у вас на последнем проекте ситуации, когда вы чего-то не понимали? Как вы с этим справились?"

3. Люди, которые двигаются небольшими шажками и ориентируются на обратную связь(feedback)

Гибкая разработка стоит на обратной связи. Мы делаем короткие итерации, что бы чаще получать ее. Мы проводим демонстрации, "коридорное тестирование", делаем инкрементальные User Stories... и все для того, что бы всегда быть в курсе того, что сейчас нужно пользователю и верно ли мы идем. Так что очаровательные таланты, которые стараются допилить и наполировать свою фичу до зеркального блеска и только потом показать пользователям - не лучшие кандидаты для нашей agile-команды.

Давайте спросим нашего потенциального кандидата о какой-нибудь фиче, которую он делал. Как он над ней работал? Довел ли до конца и показал заказчику или проводил демонстрации "на живую" и корректировал фичу в соответствие с полученными откликами?

И самое главное - не зависимо от ответа, спросим: "А почему?" И послушаем обоснование.

4. Люди, делающие то, что нужно именно сейчас

Старый добрый YAGNI действительно подходит далеко не всем. Я знаю очень много талантливых программистов и (спаси Господи) архитекторов, которые считают такой подход профанацией и пророчат многие беды его последователям. И они непреклонно, раз за разом, убивают массу времени создавая мега-дизайны...а потом проект закрывают, потому что мы 3 месяца делали супер-ядро с мега-архитектурой вместо того, что бы дать заказчику действительно нужные сейчас функции.

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

В нашем несовершенном мире зачастую нам приходится работать в не совсем идеальных условиях...да что там! Зачастую и в весьма неприемлемых условиях. И собираете вы Agile или Waterfall( :) ) команду - желательно найти людей, который легко адаптируются к среде. В противном случае вы получаете гарантированный геморрой в том числе по "притирке" людей в команде.

У потенциального кандидата можно спросить в лоб о ситуации, когда он находился в не комфортных условиях и о том как он с этим справлялся.
6. Люди, готовые работать вне своих ключевых навыков

Речь, конечно, не идет о извращенной кроссфункциональности, когда кухарка управляет государством, а программисты занимаются маркетингом. Здесь имеется в виду открытость мышления членов команды и готовность(желание) заниматься не только узкой областью, но и множеством других областей и активностей, связанных с проектом. То есть специалист по Data Access Layer не брезгует разработкой WCF Data Contracts и готов заниматься этим вместе с остальными членами команды, если того требует текущая работа.

Для того, что бы понять, насколько кандидат удовлетворяет этому критерию его можно спросить о том, когда он последний раз помогал остальной команде и о том, как это выглядело.
Итак, вот мистические шесть свойств настоящего agile team memeber. Естественно, что это не исчерпывающий список, но как это традиционно принято в agile, автор дает пару советов, и дополняет вечным "use common sense" :)

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

5 опасных вещей

Всем привет!

Я решил откопипастить интересное видео с it4business.ru о "Пяти опасных вещах, с которыми вы должны позволить своим детям играть"... Во много спорный, но так же и во многом правильный спич о том, насколько мы ограничиваем своих детей и свое будущее в стремлении к безопасности. Не уверен, что завтра буквально разрешу своим детям играть с огнем и водить машину, но кое о чем задумался...

И не могу удержаться, что бы не разделить с вами еще одну интересную ссылку с той же конференции TED от того же Славы Панкратова :) на этот раз - о лидерстве.

Agile приходит в Питер!

Ура! Вот и в наше северное болото приходит свежий ветер с материка :)
В сентябре состоится потрясающая(я надеюсь :)) конференция AgileDays'10. Я искренне надеюсь, что в нашем городе мы сможем собрать не только докладчиков, не уступающих по уровню московским коллегам, но и посетители конференции тоже не подкачают и мы соберем действительно яркую, интересную компанию увлеченных профессионалов, с которыми будет интересно пообщаться, познакомиться и послушать. Со своей стороны я постараюсь подготовить достойный доклад. Пока я планирую рассказать о роли Scrum-Мастера в современных процессах. По сути это будет хорошо и связно оформленная версия моих мыслей в этом блоге о миграции SM. Есть еще запасная идея - рассказ о Manageability - все-таки тема не очень известная и она может быть интересна многим.

Миграция Scrum-Мастера. Часть 2.

Итак, в первой части статьи мы смогли выявить обозначившуюся тенденцию к выделению Scrum-Мастера из команды, переводу его из отряда "свиней" в отряд "цыплят" и снятию с него обязанностей по разработке.
Правда, идея провести аналогию между таким SM и XP-Коучем, по прошествии пары дней уже не кажется мне столь удачной. Несмотря на то, что формально XP-Коуч помогает команде следовать процессу, процесс этот - технологический! Ведь надо помнить, что XP в основном покрывает технические стороны разработки ПО, в то время как Scrum делает больший акцент на процессе как таковом. Т.е. XP-Коуч помогает команде делать правильно Continuous Integration, TDD и Pair Programimng в то время, как SM проводит митинги, учит команду общаться друг с другом конструктивно и создает атмосферу доверия... Так что давайте-ка не будем путать теплое с мягким и будем называть "нового" SM просто Scrum-Коуч...Вот черт - вездесущий Scrum Alliance уже ввел этот термин :) . Да..."коуч" становится действительно модной приставкой, которую не только я пытаюсь приклеить куда-попало :)
А теперь давайте вспомним, как внедряется Scrum во многих компаниях. Важным моментом является то, что на первых этапах разумные руководители стараются пригласить консультантов по Scrum со стороны (например, Асхата-и-компанию). И в этом случае консалт выполняет именно роль коуча или тренера, помогая и пока еще неопытному Scrum-Мастеру и команде, PO и заказчику освоить новый процесс и избежать хотя бы тривиальных ошибок, которые допускают многие на первых шагах.

В принципе, такой сторонний Scrum-Trainer/Coach действительно часто нужен только на этапе внедрения, когда участники проекта сталкиваются с множеством новых ситуаций, требующих от них новой реакции. По мере становления проекта тренер становится нужен все реже, пока, наконец, не целует SM на прощанье в лысину, отпуская в вольное плавание по волнам проект, ибо "теперь ты овладел силой, Люк"!

Но дело в том, что real world преподносит нам множество ситуаций, где юному Люку Скайуокеру становится недостаточно знаний и навыков, полученных от своего наставника. В команду приходят новые люди, кто-то ее покидает, появляются новые заказчики, которые преподносят новые грабли, и т.д. В этой ситуации у Люка есть два выхода: бежать к "мамочке", т.е. к Scrum-Coach, который научил его основам джедайства или просто самому постоянно, систематически развивать в себе необходимые навыки, общаться с другими джедаями, много читать о техниках командного взаимодействия, о коучинге о проджект-менеджменте (в певую очередь в том аспекте, который касается обязанностей Scrum-Мастера) и прочее...в то время, как остальные члены команды штудируют Гради Буча, банду четырех, изучают новые технологии типа WWP, WWF, бурно обсуждают новую версию Ruby on Rails и нюансы аспектно-ориентированного прогаммирования. И это день за днем отдаляет Люка от команды. Его техническая квалификация неуклонно отстает от квалификации других разработчиков команды и в конце концов, это приводит к появлению взаимного недоверия...и все...тектоническая плита Scrum дает трещину и все летит в тар-тарары!

Таким образом мы снова возвращаемся к мысли о том, что быть классным Scrum-Мастером и оставаться членом команды разработчиков просто нереально...

продолжение следует...

Супер-книга "Поступай Правильно" Джеймса Паркера!

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

Очень хочется чиркнуть на память несколько цитат из этой книги. Так сказать, для бодрости духа. Вот и первая:

"Когда сомневаешься - поступай правильно!"

Вперед и только вперед

Уже несколько месяцев руки не доходили сделать слайд-каст, как мне казалось, неплохого доклада на AgileDays'09 "Внедрение Scrum от менеджера - собираем все грабли!". На конференции доклад был достаточно неплохо принят и мне очень хотелось поделиться им с друзьями, которые не смогли посетить это суперскую конференцию. И вот, наконец, появилось немного времени, я пересмотрел презентацию и...вдруг понял, что время уже прошло, что собственная презентация, которая казалась мне такой остроумной и интересной для меня сегодняшнего - детский сад. И делать слайд-каст этой презентации стало совсем не интересно, ведь сейчас у меня есть то, что двигает меня вперед: лекции в компании, подготовка к докладу на AD'10, подготовка материалов по Manageability, работа над улучшением процесса найма в компании... в общем, задача "Сделать слайд-каст доклада на AD'09" закрыта как "Obsolete" и мы двигаемся к новым вершинам!

"Защита от темных искусств" Владислава Балина

Наконец-то у меня дошли руки прочитать статью "Защита от темных искусств" Владислава Балина на softwarepeople.ru. И надо сказать, я не пожалел - действительно отличная статья. Всем рекомендую. Ссылка на последнюю - седьму часть, но она то мне и больше всего понравилась :)
А я пошел искать рекомендованную «Практику гештальт-терапии» Фрица Перлза...

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

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

"Встречают по одежке" или Артефакты Первого Контакта

Добрый день!

Когда задумываюсь, почему в компанию не так легко привлечь классных программистов, в первую очередь начинаешь вспоминать свои собственные оценки компаний по первому впечатлению. Новая работа, новая машина, новое знакомство - все это подвержено эффекту первого впечатления и если на входе в XXX-Soft ты столкнулся с ковыряющимся в носу програмером в затертых домашних тапках и грязной чашкой с кофе в руках, то вот не станешь ты там работать (ну это я про себя :) - у всех разные пунктики).
А вот если в вашей компании есть практика интервью в несколько этапов, когда сначала кандидат пишет тестовое задание(кодит), общается с HR, заполняет анкету и лишь на следующем этапе сталкивается со своими будущими товарищами по оружию, то что для него (кроме затертых тапочек) важно? Что дле него - лицо компании-работодателя?

1. Имидж компании - то, что он знал до прихода на интервью. Он либо есть, либо его нет. Для многих софтверных компаний со штатом менее 200 человек его почти что нет. За исключением ярких продуктовых компаний для которых узнаваемость бренда для кандидатов - это побочный эффект от работы отдела маркетинга и рекламы, направленной на совсем другую целевую аудиторию.
   
   
   
2. HR-отдел - саааамое первое, что кандидат узнает о компании, это то как ее рекрутинг пишет письма и разговаривает по телефону. HR бывают девочки и мальчики. Девочки привычнее, так что когда с тобой связывается HR-мальчик, то сразу как-то становится интересно, что это за контора такая? :) Но в целом, в меру профессиональный HR который способен общаться на удовлетворительном деловом уровне и представляет себе область в которой он работает имеет скорее нейтральный pH. То есть воодушевить кандидата ему вряд-ли удастся, поэтому основная задача рекрутера в компании - найти кандидата и бережно передать дальше.
   
   
   
3. Артефакты первого контакта - сайт компании, документы о компании, которые высылает HR для кандидатов, анкета, тестовое задание, офис компании, точнее несколько его ключевых (для первого контакта) мест:
   
   - бизнес-центр, где размещается компания, точнее его фасад и холл
   - коридоры компании
   - кабинет, в котором проводится собеседование с HR
   - кабинет, в котором проводится выполнение тестового задания и заполнение анкеты
   - кабинет, в который тоже захочется сходить, особенно если интервью затянется
   
   Ужас! До чего я договорился - "Сортир - лицо компании!" :) Шутки-шутками, но для меня, например имидж Microsoft был несколько подпорчен тем, что в их офисах в Редмонде перегородки между кабинками едва достигают подбородка.
   Впрочем, думаю, что это суровые американские принципы секьюрити направленные на защиту мирных граждан от угрозы мирового терроризма. Иначе что заставило уважаемую компанию превратить свои "места отдохновения" в прототип игры "Убей Крота!" (по крайней мере это очень похоже на нее когда ты моешь руки в умывальнике и вдруг видишь в зеркало как у тебя за спиной из-за перегородки появляется чья-то голова...а потом еще одна - по соседству :)
   

Теперь давайте взглянем на то, что мы в состоянии изменить в нашей компании (кроме сортиров) для того, что бы классные програмеры после первого контакта даже и не думали о другой компании или, по крайней мере, не посылали бы нас на фиг после первого интервью, а напротив, были готовы продолжать этот процесс дальше!

1. Бизнес-центр (или Ваше здание) - серьезный замах. Думаю, что эту тему мы сейчас не будем даже затрагивать, так как для многих компаний это данность, изменить которую в контексте работы с кандидатами несколько нерентабельно
   
2. Коридоры _вашего_ офиса - ага! Уже ближе! Это уже территория компании и бюджет для интерьерных изысков выглядит более адекватно, чем переезд в бизнес-центр класса А+. Тем более, что в этом аспекте гораздо важнее творческий подход и свежесть идей нежели кисти с бахромой и золотые канделябры. Достаточно вспомнить впечатления господина А. Орлова увековеченные в его статье. Тут главное - отодвинуть подальше бубнил и зануд, призывающих к серьезности и умеренности - большая часть штата IT-компании - молодые ребята, которым эта серьезность в печенках сидит.


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


4. Помещение для выполнения тестового задания.
   Здесь кандидат, скорее всего, столкнется уже с чем-то, что возможно, позволит ему представить свое будущее рабочее место. Рабочий стол, кресло, компьютер - то, что окружаем разработчика 8 и более часов в день. Поэтому, когда его приводят в комнату площадью 2 квадратных метра и сажают за замызганный комп на шаткий стульчик, то темная сторона начинает одолевать даже самых продвинутых джедаев. Вот несколько советов, как заставить медихлорианы в мозгу кандидата крутиться в нужном направлении:
   

   
   
   • Выделите нормальное помещение для работы кандидатов. Как вариант - установите нормальный комп (или выделите лэптоп) в комнате для переговоров. В идеале это помещение должно говорить кандидату у том, какое у него будет рабочее место
     
   • Поставьте туда классную мебель (может даже получше чем на рабочих местах) - стеклянный стол, удобное дорогое кресло на колесиках
     
   • Компьютер должен быть адекватной производительности и конечно же с хорошим TFT-монитором не менее 21". Клавиатура и мышь должны быть новыми и чистыми. Всегда.
     
   • Подсказки. Возможно, у кандидата во время выполнения задания появятся какие-то бытовые вопросы или он закончит раньше времени. Составьте яркий короткий мини-хелп (с контактами HR, расположением туалета, кофе-машины и т.д.) на ламинированной бумаге и оставьте его на кандидатском рабочем месте.
     
   • Мелочи(канцелярия). Все то же самое, что и о помещении для собеседования с HR.
     

   
   

Ну и все же обратите внимание, есть ли в туалете туалетная бумага...а то ведь неловко будет...

Наша работа

Нашел весьма жизненный микро-комикс о работе IT-шников...

И это в который раз напомнило мне о том, насколько важен ФАН в нашей работе. Спасибо судьбе, что сейчас то, чем я занимаюсь дает мне столько энергии и энтузиазма. Все, что мне остается - просто передать его дальше - своим ребятам, всем остальным коллегам в нашей компании... жизнь слишком коротка, что бы тратить время на скучные вещи!

О "троллях" в команде

Всем привет!

Позволю себе небольшой копипаст из своего доклада на AgileDays'09. Речь пойдет о так называемых "троллях". Как известно, "тролль" в agile-энциклопедии - это член команды, который преследует цели, конфликтующие с целями команды в целом. Обычно, это человек с явно деструктивных характером поведения, влияние которого и на проект и на остальных членов команды негативно. Например, команда стремится сделать проект качественно и в срок (ну вот так вот абстрактно :) ) а этот "нехороший человек" каждые полчаса громко жалуется "ну что за г@вняный проект у нас", "ну когда уже мы, наконец завалим этот проект". Так же он может саботировать сессии планирования, ретроспективы да и что там говорить, при попустительстве со стороны остальной команды(или менеджера) он реально способен убить проект и/или команду.

Так что же делать, если вы наблюдаете рядом с собой подобный персонаж? Уважаемые гуру от Agile здесь весьма категоричны (что, обычно, им не свойственно) и едины. "ГНАТЬ ИХ К ЧЕРТОВОЙ МАТЕРИ!" - вот чему нас учат... видимо, когда agile-доки сталкиваются с такими "диверсантами", у них уже просто лопается терпение и они выходят из своего коуч-образа, становясь, наконец, обычными людьми :)

И в этом они, на мой взгляд, неправы! Такой подход ведь противоречит всему, что нам рассказывают о правильном agile-менеджменте. Ведь когда кто-то тупит и говорит "я не знаю как делать эту задачу" мы же не орем на него типа "ты идиот, Тауб! Это же аутоимунное!"...неееет! Мы начинаем его коучить, и коучим его пока он сам не придумает как таки сделать задачу. Для чего - что бы люди росли и развивались и были self-managed и мир вокруг был полон весны...

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

А это значит, что к нам опять приходит на помощь доктор Коуч! Хватайте этого Тролля (но, пожалуйста, по-нежнее) и выводите его на откровенную беседу. Дайте ему выговориться, разберитесь вместе с причинами его не-командного поведения. Поверьте - ему находиться в этой шкуре так же несладко, как и всем остальным работать с таким человеком.

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

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

Многие знания - многие беды. О собеседованиях

Я уже жаловался раньше, что при найме сотрудников в последнее время интервью с ними в нашей компании стали, на мой взгляд, несколько затянутыми. И ведь что интересно - мы, в основном, нанимаем .Net разработчиков и у меня(как и у остальных участников интервью) довольно неплохо пракачаны .Net skills. Такое ощущение, что чем большим экспертом в технологии ты являешься, тем больше затягивается интервью с кандидатом. Так ведь при этом я не могу сказать, что, обладая большими знаниями и опытом, я стал лучше нанимать людей. Точнее, я прекрасно понимаю, что более рподолжительные интервью с, возможно, большим количеством вопросов кандидату, не дают мне настолько больше информации для принятия взвешенного и верного решения.

Забавно, что сегодня как раз интервьюировал кандидата на позицию Java разработчика. Надо сказать, что я программировал на Java последний раз лет эдак 6 назад :)

Естественно, что знания у меня о данном предмете остались весьма поверхностные. Но ведь вот в чем штука: мы уложились ровно в два часа (это, поверьте, немного)! И решение мы приняли вполне взвешенное! Удивительный эффект.

В чем сила XP-2

Итак, в предыдущем посте на эту тему мы разобрали какие ценности приносят в XP-процессы те или иные практики заявленные как must have для настоящего XP. В принципе, цель этого анализа - именно разбор этих самых практик, который, надеюсь, поможет сделать ваш особый уникальный процесс и назвать его как-нибудь красиво :)

Помимо того, что некоторые элементы процесса приносят в него дополнительную ценность, существует второй аспект, который может потребовать введения того или иного принципа или инструмента. Некоторые элементы не только приносят конкретную ценность в проект, но и поддерживают другие практики процесса. Давайте продолжим препарировать XP, раз уж начали, тем более, что все эти принципы и практики по отдельности - все из области Agile, что делает данную статью не столь сильно привязанной к XP.

• Onsite Customer
• Pair Programing
• Collective Code Ownership
• Planing Games
• Coding Standards & Conventions

Перечисленные элементы образуют коммуникационную среду проекта, реализуя принцип Agile "меньше документации - больше кода". Сказать, что это некая ценность я не берусь, так как Agile сам по себе не является таковой с точки зрения проекта. В то же время мы понимаем смысл и предназначение этого набора и можем отдавать себе отчет в том, какие функции выполняют эти элементы. Нельзя, конечно, сказать что это полный набор средств коммуникации (даже напротив - для нормального процесса, на мой взгляд, этого мало :)), однако, надо понимать, что если вы начинаете из этого набора что-то выкидывать, то скорее всего вам придется заплатить за это дополнительной писаниной (переписка по e-mail, wiki, etc).

• Рафакторинг

Рефакторинг с одной стороны поддерживает TDD (который без него просто не работает), с другой стороны(как уже было сказано в первой части этого поста) позволяет привести в порядок код, написанный в концепции KISS, YAGNY и прочий "simple design". То есть, не дай бог у вас в проекте по XP вы начинаете экономить на рефакторинге - иначе готовьтесь получить отсутствие TDD и абсолютно не сопровождаемый код.

• Pair Programing

Без него говорить о совместном владении кодом будет очень тяжело, ведь именно Pair Programing с ротацией пар позволяет знаниям о коде распространяться по команде без дополнительных затрат на документирование.

Эта статья (обе ее части) - это, по сути, обобщенное упражнение по анализу процесса. Здесь я постарался показать, как могут быть связаны элементы вашего процесса и о чем стоит помнить, добавляя или удаляя элементы из него.

Спасибо!

Лучшая презентация

Всем привет!

Несколько месяцев назад, перед проведением AgileDays'09 организаторы решили провести скайпференцию для докладчиков-новичков дабы помочь им в подготовке к выступлению. Мы говорили о том, какой должна быть хорошая презентация и само выступление.

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

1. Короткий

На сегодняшний день мой опыт говорит мне, что за 1 час можно сказать почти все :) То есть этого времени гарантированно достаточно, что бы для каждого слушателя в лекции была явная ценность. Что бы выйдя из аудитории каждый мог сказать: "Я не зря потратил время!".

Самый сложный предмет действительно _возможно_ декомпозировать на короткие лекции. Проверено на практике! Иногда бывает очень жалко резать собственную презентацию, выкидывая оттуда яркие, интересные, но ненужные слайды, но в результате Вы получаете настоящий бриллиант - лекцию, насыщенную материалом, без "воды" и сфокусированную на определенной проблеме.

2. Яркий

Используйте яркие образы. Благо есть поиск картинок в Google. Да, это требует значительного времени: придумать образ, а потом еще и найти подходящий клипарт в Google. Но, поверьте - игра стоит свеч, так как мир полон скучнейших презентаций с клипартами из MS Office а Ваша презентация просто взорвер аудиторию, если использовать неожиданные и яркие образы.

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

И наконец, используя яркие образы Вы можете контролировать эмоциональное состояние аудитории. Дело в том, что даже при такой небольшой продолжительности доклада как 1 час половина слушателей может заснуть. Хороший способ не дать им сделать это - постоянно "раскачивая" их эмоциональное состояние. На мой взгляд, нужно использовать тактику периодических нерегулярных всплесков. Т.е. в начале лекции даем сильный толчок каким-нибудь ярким образом, затем - просто загружаем информацию в слушателей. Но при этом необходимо периодически, раз в 10-15 минут повторять такие вспышки. Тогда слушатели будут в нужной кондиции все время лекции.

3. Структурированный

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

4. Анимированный

Спасибо PowerPoint за чудо анимации! Благодаря этому инструменту даже абсолютно проавльный слайд из 10 "буллетов" можно спасти. Просто сделайте, что бы каждый "буллет" вылетал по вашей команде - это сделает слайд "живым" и избавит вас от ситуации, когда аудитория уже прочитала ваш слайд целиком и, зевая, слушает как вы читаете с экрана. Помимо этого, используя анимацию, Вы можете показать работу каких либо процессов. Меня вот, например, торкнуло и я заанимировал алгоритм работы Taskboard для Scrum и для Kanban - получилось просто феерически + наглядно, что гораздо выигрышнее последовательности статичных слайдов с вашими комментариями о том как тут все должно двигаться.

В чем сила XP

Хотя чистый XP сейчас и мало кто использует, в основном, комбинируя практики из XP с другими процессами, я все же хочу немного разобраться с тем, из чего, собственно состоит Экстремальное Программирование. Итак, вот основные практики, принципы и правила XP:

1. Onsite Customer
2. Small Iterations
3. Simple Design
4. Continuous Integration
5. Refactoring
6. TDD
7. Coding Standards & Conventions
8. Pair Programing
9. Collective Code Ownership
10. Planing Games

А теперь давайте посмотрим, какую функцию выполняет тот или иной компонент XP в процессе. Итак:

1. Onsite Customer + Small Iterations + Simple Design

Распишем, что это значит: команда имеет возможность взаимодействия с заказчиком "на-лету" для получения новых/измененных требований и предоставления результатов работы на ревью. При этом за счет коротких итераций ставятся близкие задачи, результат работы над которыми обсуждается с заказчиком и принимаются меры по корректировке курса. А за счет простых технологических решений команда может выдавать конкурентоспособный темп.

Итого:

Onsite Customer + Small Iterations + Simple Design = Maximum Agility

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

2. Continuous Integration + Refactoring + TDD + Coding Standards

Максимальная гибкость, которую мы реализовали с помощью практик из пункта 1, к сожалению, чревата проблемами с качеством. Да и в принципе в любом технологическом процессе должны быть инструменты для контроля и обеспечения качества. И вот за счет чего мы гарантируем качество в XP:

Непрерывная Интеграция позволяет быстро выявлять и исправлять ошибки кодирования. Рефакторинг приводит в порядок тот код, который появляется под флагом "Simple Design", да и для TDD он необходим как воздух. Сам TDD позволяет поддерживать принцип "SimpleDesign". Стандарты кодирования помимо положительного влияния на качество, так же необходимы для другого принципа XP, который будет упомянут ниже - Совместное Владение Кодом.

Итого:

Continuous Integration + Refactoring + TDD + Coding Standard = Quality Assurance

3. Pair Programing + Collective Code Ownership + Planing Games

Это значит, что вся команда вместе планирует задачи, по ходу уточняя и разъясняя для каждого суть задачи и особенности ее реализации (да-да-да...и убивая часа по 2-4 на Planing Session в каждой итерации). А потом вся команда дружно программирует, меняясь парами и осуществляя перекрестное Code Review. За счет этого нам становятся не страшны такие вещи как неожиданная болезнь ключевого разработчика, отпуск, перемещение на другой проект, увольнение ( :) ) и прочая фигня, которая иногда так некстати сливает все планирование в унитаз. Так же мы снижаем затраты на ввод новых разработчиков в команду.

Таким образом:

Pair Programing + Collective Code Ownership + Planing games = Reliable Process

Итак, мы определили, что заявленные компоненты XP дают нам следующие ценности:

1. Высокая Гибкость
2. Высокое Качество
3. Высокая Надежность Процесса

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