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" :)

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