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 от того же Славы Панкратова :) на этот раз - о лидерстве.