Шесть качеств 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" :)

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