пятница, 30 июля 2010 г.

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

вторник, 27 июля 2010 г.

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

Всем привет!

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

понедельник, 19 июля 2010 г.

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-Мастером и оставаться членом команды разработчиков просто нереально...
продолжение следует...

понедельник, 12 июля 2010 г.

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

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

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

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

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

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

четверг, 8 июля 2010 г.

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

Наконец-то у меня дошли руки прочитать статью "Защита от темных искусств" Владислава Балина на 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. Столько идей, столько идей..... :)