Текст книги "Искусство Agile-разработки. Теория и практика гибкой разработки ПО"

Команды Agile работают наилучшим образом, когда состоят из специалистов широкого профиля, также называемых людьми с профилем компетенций T, или T-людьми (T-shaped people). Специалист широкого профиля обладает глубокими знаниями и опытом сразу в нескольких областях, что символизирует вертикальная линия буквы Т, но полезен и в некоторых других областях, необходимых команде. Это символизирует горизонтальная черта. (Иногда используют термин «М-люди» (M-shaped people), чтобы подчеркнуть, что такие специалисты могут развить у себя экспертные навыки во многих областях.)

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

В Agile-организации ресурс – это команды, а не индивидуумы, поэтому процесс формирования ресурсов значительно более простой: все или ничего. Команда или берется за разработку функциональности, или нет. Или нужного человека назначают в команду, или она не приступает к работе.

Но вы можете столкнуться с узкими местами и внутри команды. Представьте команду с двумя фронтенд– и двумя бэкенд-разработчиками. Иногда бывает больше работы по фронтенду, и тогда разработчики бэкенда бездельничают. (Или они работают на опережение, что в конечном итоге приводит к постоянным дорогостоящим переделкам, что мы будем обсуждать во врезке «Минимизируйте объем незавершенной работы» в главе 8.) В другое время ситуация в такой команде может быть противоположной.

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

Вам не нужно, чтобы члены команды были специалистами широкого профиля, когда вы впервые ее формируете. Это больше про их отношение к данному вопросу, чем возможности. Любой специалист при желании может научиться работать в областях, близких к его основной специализации. При подборе людей в команду убедитесь, что у них есть такое желание.

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

Примечание

В недавно сформированных Agile-командах полезно четко обозначить продакт-менеджера и коуча. Для опытных команд четкие роли могут только мешать, но новичкам в Agile будет полезно точно знать, к кому обращаться в случае вопросов.

У вас может не получиться найти в команду человека, имеющего навыки продакт-менеджера или экспертные знания в предметной области. Во многих компаниях такого человека назначают на неполный рабочий день координировать команду в качестве владельца продукта. Рассматривайте это как знак того, что члены команды должны сами развить у себя навыки менеджмента продукта и экспертные знания в предметной области. Такой внештатный владелец продукта может помочь им начать, однако не сможет поддерживать их в долгосрочной перспективе. Лучшие Agile-команды прекрасно разбираются в сфере деятельности заказчиков. Это хорошо сформулировал Бас Водде[30]30
  В личном общении.


[Закрыть]:

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

Даже в случае высокопрофессиональной команды некоторые решения будут приниматься людьми, не входящими в вашу команду. Например, если она работает над компонентом большого продукта, решения о системной архитектуре могут оказаться вне вашей компетенции. Хорошо, если эти решения – только часть каких-то процессов, происходящих на заднем плане. Но если вы постоянно ждете, пока люди, не входящие в вашу команду, примут решение или сделают что-то для вас, – значит, ваша команда неполная. Члены вашей команды должны иметь требуемые навыки и ответственность, или же данный компонент продукта нужно отдать куда-то вне команды. Больше информации о кросс-командной координации доступно в главе 6.

Постоянные члены команды

Каждый постоянный член команды должен быть полностью приписан только к одной команде. Дробные назначения (когда человек назначается одновременно в несколько команд) дают ужасные результаты. Частично занятые работники не связаны со своей командой, часто не присутствуют при обсуждениях и не слышат ответы на вопросы, к тому же должны постоянно переключаться между задачами, что влечет за собой множество скрытых потерь. «Минимальные потери – 15 процентов. Работники с частичной занятостью могут выглядеть загруженными, но их загруженность – по большей части бестолковая суета» [DeMarco2002] (гл. 3).

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

Даже если кто-то временно является частью вашей команды, договоритесь, чтобы эти люди были полностью приписаны к вам на этот период. Лучше иметь кого-то, назначенного в команду на полный рабочий день на одну неделю, а потом – к другой команде на другую неделю, чем того же человека, назначенного в обе команды одновременно на две недели.

Стабильные команды

См. также

Динамики команды (глава 11)

Команде может потребоваться несколько месяцев на то, чтобы научиться эффективно работать вместе. В некоторых организациях команды создаются и расформировываются для каждого нового проекта. Однако сохранять состав команды – менее расточительный вариант. Даже если цель команды достигнута или жизненный цикл продукта завершен, не распускайте команду. Вместо этого дайте ей новую цель или продукт.

То же самое применимо и к изменению состава. Если вы добавляете человека в существующую команду, то он встраивается в ее культуру и нормы. А если вы добавляете нескольких, то команда практически начинает все с нуля. Мое правило – добавлять или удалять не больше одного человека в месяц.

Рекомендации в этой книге предназначены для команд численностью 3–20 человек. Для новых команд хорошей отправной точкой будет численность 4–8 человек. Превысив количество в 12 человек, вы начнете замечать проблемы в общении, так что будьте осторожны при создании больших команд. И наоборот, если у вас очень маленькие команды, то подумайте о том, чтобы объединить их. Это уменьшит расходы, и вы будете менее чувствительны к текучести персонала.

См. также

Парное программирование (глава 12)

Групповое программирование (глава 12)

Для большинства команд программирование поначалу будет узким местом. Поэтому, планируя размер команды, начните с того, чтобы подумать, сколько времени уходит на программирование. Для удобства я буду называть человека, на 100 % занятого программированием, «один программист», но это не значит, что в вашей команде должны быть строго обозначенные роли.

• Команды, которые не используют парное или групповое программирование, должны состоять из 3–5 программистов. По мере увеличения команды у них начинаются проблемы с координацией.

• Команды с парным программированием должны состоять из 4–10 программистов. Оптимальное количество – шесть. Команды – новички в практиках поставки не должны насчитывать больше 6–7 программистов, пока не приобретут достаточного опыта.

• Команды с групповым программированием должны состоять из 3–5 программистов. Можно работать и с более многочисленными группами (это хорошая обучающая техника), но в какой-то момент вы достигнете точки падения эффективности.

Обычно оставшуюся часть команды комплектуют пропорционально объемам выполняемого программирования. Соотношение должно быть примерно эквивалентно количеству работы, которую надо сделать так, чтобы не образовывались узкие места, а наличие специалистов широкого профиля должно позволять справляться с неравномерностью загрузки. В целом нужно планировать:

• навыки в сфере деятельности заказчика – один-два локальных заказчика на каждые три программиста. От четверти до половины их времени будет уходить на менеджмент продукта. Оставшееся будет тратиться на сочетание экспертных знаний в предметной области и UX– и UI-дизайна в зависимости от вида вашего ПО;

 навыки тестирования – один тестировщик на каждые 2–4 программиста, если команда не имеет свободного владения навыками на уровне поставки, или один тестировщик на каждые 4–8 программистов, если имеет;

 навыки эксплуатации – от нуля до двух специалистов эксплуатации в зависимости от типа продукта;

• навыки коучинга – один или два коуча, которые могут делить свое время с другими командами.

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

Почему так много заказчиков

Два заказчика на каждых трех программистов – это очень много, не правда ли? Я начинал с гораздо меньшего соотношения, но часто видел, что заказчики держатся наравне с программистами. В итоге я пришел к соотношению «два к трем» после экспериментов с разными соотношениями в различных успешных командах.

Все эти команды свободно владели навыками на уровне поставки, что подразумевало наличие в команде менеджмента продукта. Большинство работали в сложных предметных областях. Если у вас простое ПО и вы не стремитесь к свободному владению навыками на уровне поставки или у вас в команде отсутствует менеджмент продукта, то, вероятно, сможете обойтись меньшим количеством заказчиков.

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

Никто в команде не отвечает за других. Далеко не каждое решение подлежит обсуждению; но люди имеют решающий голос в своей экспертной области. Например, программисты не могут не учитывать мнение заказчиков о приоритетах продукта, а заказчики не могут не принимать во внимание мнение программистов о технических необходимостях. Вдобавок у вас есть старшие члены команды, которые берут на себя принятие важных решений. Но внутри нее нет иерархии подчиненности. Даже люди с впечатляющими должностями, наподобие «продакт-менеджер», не управляют командой.

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

При этом трудно передать, насколько весело и с удовольствием проводят время высокопродуктивные Agile-команды. Брайан Марик, один из авторов Манифеста Agile, говорил, что радостный настрой (Joy) – еще одна ценность Agile[31]31
  Марик определял четыре ценности, которые он видел в ранних Agile-командах: навык, [само]дисциплина, легкость, радостный настрой [Marick2007a].


[Закрыть]. И он прав. Отличные Agile-команды ее ощущают. Они оптимисты, энтузиасты своего дела и получают истинное удовольствие от совместной работы. Есть чувство превосходства, но они не воспринимают его слишком серьезно. Например, когда есть задача, за которую никто не хочет браться, разговор о том, кто ее будет делать, может вестись в игривой и веселой манере. И он протекает быстро. Эффективные Agile-команды легко принимают решения.

См. также

Динамики команды (глава 11)

Такая эффективность требует значительного времени и работы над собой. В практике «Динамики команды» показано, как это сделать.

Ключевая идея

Самоорганизующиеся команды

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

Это не значит, что руководителям нечем заняться. Фактически, делегируя детали своим командам, руководители освобождают свое время, чтобы иметь возможность сконцентрироваться на более значимой деятельности. Их работа – настраивать команды на успех, управляя более широкой системой, в которую встроены их команды. Более подробная информация представлена в разделе «Менеджмент» главы 10.

Давайте еще раз взглянем на историю провальной команды (см. врезку «Провальная команда» ранее в текущей главе). Что пошло не так?

• Руководитель удивил команду и сразу ее покинул, вместо того чтобы настроить ее на успех.

• Коуч Клодин не помогала команде учиться.

• У Рамониты, продакт-менеджера, совсем не было времени на команду.

• В команде не было никого, кто разбирался бы в сфере деятельности заказчика.

• У команды не было возможности самостоятельно выпускать продукт. Им требовалось координироваться с внешними командами: отделом контроля качества, эксплуатации и бэкенда.

А вот как все это должно было произойти.

«Окей, сегодня день Agile», – говорит ваш руководитель. Вы согласились на этот эксперимент несколько недель назад, так что никто не удивлен. «Как мы обсуждали, мы формируем новую команду для работы над этим продуктом. Почему бы вам всем не представиться и не рассказать о себе заново?»

Все присутствующие поочередно представляются. У вас три фронтенд-программиста (один имеет опыт работы с полным стеком (full stack experience)), один бэкенд-программист, тестировщик и один UX-дизайнер. Вы уже познакомились со своим коучем Клодин. Она представляет вам Рамониту, вашего продакт-менеджера.

Входит Клодин. «Я знаю, что вам всем не терпится узнать, как работает Agile, поэтому сразу перейду к делу. Мы начнем с активности, называемой подготовкой устава. Рамонита работает со стейкхолдерами нашего проекта, чтобы понять, что мы будем создавать, почему и как это на всех повлияет. Мы тоже с ними встретимся через пару минут. Кроме того, мы уделим некоторое время тому, чтобы понять, как нам взаимодействовать наилучшим образом».

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

Проходят недели. Рамонита появляется часто, и Микки учится заменять ее, когда она отсутствует. Благодаря тому, что ответственные за фронтенд, бэкенд, тестирование и эксплуатацию становятся одной командой, вам удается продвигаться быстро. Через неделю вы проводите первое демо для стейкхолдеров, и их реакция заряжает вас новой энергией. Вы – хорошая команда. И вам не терпится увидеть, что будет дальше.

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

Для начала проверьте, не нанимает ли ваша компания слишком много программистов по сравнению с остальными экспертами, нужными командам разработки ПО. Это распространенная ошибка. Если это так, то попробуйте изменить приоритеты найма.

Если у вас несколько команд, работающих над одним продуктом, то рассмотрите возможность использования вертикального масштабирования, что позволит разумно объединить их усилия, как описано в подразделе «Вертикальное масштабирование» главы 6.

Если эти варианты не сработают, то ваша компания может сформировать вспомогательную команду, ответственную за инструкции, стандарты и тренинг для других команд, как описано в подразделе «Горизонтальное масштабирование» главы 6. Например, какая-либо UX-команда может создать руководство по стилям и научить людей, как его использовать применительно к программному обеспечению, разрабатываемому их командами. Это позволяет командам решать собственные проблемы, не нуждаясь в полноценном опыте.

Когда требуется больше навыков, вы можете запросить, чтобы соответствующего специалиста назначили в вашу команду временно. За этот период он сможет обучить членов команды. Отложите любую работу, требующую определенных навыков, до тех пор пока они не появятся. Таким образом вы не останетесь с наполовину выполненной работой, что ведет к потерям, как обсуждается во врезке «Минимизируйте объем незавершенной работы» в главе 8.

Младшие члены команды наравне с остальными?

Члены команды необязательно наравне (у всех разная квалификация и опыт), но они коллеги. Для младших членов команды будет разумным обращаться за советом и наставничеством к более опытным коллегам. А для тех, в свою очередь, разумным будет обращаться ко всем с уважением, создавать товарищеские отношения и помогать младшим коллегам расти, иногда делая шаг назад и позволяя им взять инициативу в свои руки.

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

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

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

Когда ваша команда кросс-функциональна:

• она способна решать проблемы и выполнять свою задачу, не дожидаясь внешних специалистов;

• люди в команде работают, выходя за рамки своей специализации, чтобы предотвратить появление узких мест и замедление работы;

• команда способна принимать решения легко и эффективно;

• люди в команде плавно перенимают роли лидерства от задачи к задаче.

Теория, лежащая в основе этой практики, очень простая. Чтобы избежать задержек и проблем в общении, следует:

1) найти всех, кто нужен для достижения ваших целей;

2) собрать их всех в одну команду;

3) организовать согласованную работу команды так, чтобы она достигла этих целей.

Это основная идея Agile, и на самом деле нет никаких альтернатив, соответствующих философии Agile. Но есть много возможностей для оптимизации деталей. Накопив опыт использования этой практики, несколько месяцев применяя ее буквально, как написано в этой книге, попробуйте немного поэкспериментировать.

Например, как ваша команда может экспериментировать с изменением способов принятия решений? Улучшается ли процесс, если назначить специального человека для фасилитации дискуссий? Или пусть дискуссии текут свободно? Следует ли возлагать некоторые решения на конкретных людей? Или ответственность руководства должна быть более гибкой?

Простых ответов на эти вопросы не существует. Сделайте предположение. Проверьте его, посмотрите, как все работает, и сделайте другое предположение. Проверьте и его. Никогда не переставайте экспериментировать. Только так можно достичь мастерства.