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

Глава 7. Командная работа

Лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

Манифест Agile для разработки программного обеспечения

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

В этой главе содержатся практики, позволяющие создать отличную команду Agile.

• С помощью практики «Вся команда» вы можете создать кросс-функциональную команду, имеющую все необходимые навыки.

• Практика «Командная комната» позволит создать пространство, физическое или виртуальное, в котором команда может эффективно сотрудничать.

• С помощью практики «Безопасность» вы можете создать рабочую среду, в которой члены команды могут делиться опытом и знаниями.

• Практика «Цель» помогает командам понять, как их работа поддерживает глобальные планы компании.

• В практике «Контекст» рассматриваются вопросы о стейкхолдерах команды и выделенных ресурсах.

• Практика «Согласование» дает возможность устанавливать нормы и правила, позволяющие членам команды эффективно сотрудничать.

• В практике «Энергичная работа» рассказывается о том, как работать таким способом, который ваша команда может поддерживать неограниченно долго.

Источники командной работы

Идея кросс-функциональных самоорганизующихся команд была частью Agile с самого начала. В экстремальном программировании эта идея называется «вся команда», данный термин я использую в этой книге. В Scrum это явление называется Scrum-командой. Командная комната – тоже устоявшийся термин, в экстремальном программировании это называется «сидеть вместе», а в оригинальной книге о Scrum [Schwaber2002] говорилось о важности рабочей среды для команды.

Безопасность также была частью обсуждения в Agile в течение многих лет. [Beck2004] рассуждает об этом в своей дискуссии о команде. Джошуа Кериевски называет принцип «безопасность – предварительное условие» руководящим принципом современного Agile. Обсуждение этой темы было включено в данную книгу благодаря приглашенному автору Гитте Клитгаард, которая имеет огромный опыт помощи командам и организациям в создании психологической безопасности.

Практики «Цель», «Контекст» и «Согласование» основаны на великолепной книге Дианы Ларсен и Эйнсли Нис Liftoff: Start and Sustain Successful Agile Teams [Larsen2016]. Вместе они являют собой пример подготовки устава (chartering), который я впервые увидел, в контексте Agile, в методе Джошуа Кериевски Industrial XP (IXP) [Kerievsky2005]. Подготовку устава внес в IXP неподражаемый III[28]28
  III – его полное имя. Произносится как «три».


[Закрыть], который также оказал большое влияние на работу Нис и Ларсен.

Практика «Энергичная работа» – еще одна давняя идея Agile. Термин пришел из XP: в первом издании книги по XP эта концепция носила название «40-часовая неделя», но оно было пересмотрено, превратившись во втором издании в название «Энергичная работа», менее ориентированное на США.

Аудитория

Коучи

У нас есть все навыки, необходимые для достижения отличных результатов.

Современная разработка ПО требует множества навыков. Речь идет не только о навыках программирования, но и о навыках общения с людьми. Художественных навыках. Технических навыках. И когда команда не имеет этих навыков, производительность падает. Вместо того чтобы сконцентрироваться на функциональности и завершить ее, члены команды должны жонглировать множеством задач, отправляя электронные письма, ожидая ответы и улаживая недоразумения.

См. также

Цель (глава 7)

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

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

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

Карго-культ

Провальная команда

«Окей, теперь вы Agile», – говорит ваш руководитель и немедленно исчезает за дверью офиса.

Вы вчетвером нервно смотрите друг на друга. Вы – команда фронтенд-программистов и не совсем понимаете, что вам делать. До вас доходили слухи о новой инициативе и о том, что ваша команда будет участвовать в ней… как?

На следующий день вбегает Клодин. «Привет! Я ваш Scrum-мастер, – говорит она. – Извините, вчера меня не было. У меня еще четыре команды, и я только что узнала, что буду работать еще и с вами. Рамонита будет вашим владельцем продукта, но она сегодня не сможет присутствовать. Я назначила встречу через неделю».

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

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

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

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

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

См. также

Вовлечение реального заказчика (глава 8)

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

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

Управление продуктом (оно же владение продуктом – ownership)

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

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

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

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

Мы не знали, какие у нас приоритеты. Мы не были полностью уверены, над чем работать дальше. Мы вытаскивали истории из общего списка, а заказчик [продакт-менеджер] давал очень мало информации о том, над чем нам работать. Так продолжалось несколько месяцев.

Потом мы обнаружили, что золотой владелец [исполнительный спонсор] был очень рассержен – просто в бешенстве. По его мнению, мы работали совсем не над тем, над чем должны были.

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

Экспертные знания в предметной области (Domain expertise, Subject Matter Expertise)

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

См. также

Поэтапные требования (глава 8)

Примеры заказчика (глава 9)

Единый язык (глава 12)

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

Даже если в вашем ПО нет сложных правил предметной области, вам все равно понадобятся люди, которые смогут детально разобраться в том, что именно оно должно делать. В некоторых командах таким человеком может быть продакт-менеджер, дизайнер пользовательского интерфейса (User Experience; UX-дизайнер) или бизнес-аналитик.

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

Дизайн пользовательского интерфейса (UX-дизайн) (он же дизайн взаимодействий)

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

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

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

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

примечание

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

Программирование, дизайн и архитектура

См. также

Разработка через тестирование (глава 13)

Простой дизайн (глава 14)

Инкрементный дизайн (глава 14)

Рефлексивный дизайн (глава 14)

Эволюционная системная архитектура (глава 15)

Игра в планирование (глава 8)

Без багов (глава 16)

Сборка для эксплуатации (глава 15)

Любой команде, разрабатывающей ПО, конечно, необходим навык программирования. Кроме того, в команде поставки каждый, кто пишет код, также делает дизайн и архитектуру, и наоборот. Такая команда использует метод разработки через тестирование, чтобы объединить архитектуру, дизайн, тесты и кодирование в непрерывную деятельность.

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

Навыки программирования позволяют осуществлять планирование, предотвращать дефекты и упрощать развертывание ПО и управление им в производственной среде.

Тестирование

См. также

Поэтапные требования (глава 8)

Примеры заказчика (глава 9)

Обнаружение слепых зон (глава 16)

Без багов (глава 16)

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

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

Эксплуатация (Operations)

См. также

Непрерывное развертывание (глава 15)

Сборка для эксплуатации (глава 15)

Анализ инцидентов (глава 16)

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

В навыки эксплуатации также входит помощь команде в поддержании рабочих реалий: планирование потребностей отдела эксплуатации, таких как безопасность, производительность, масштабирование, контроль и управление; справедливое распределение смен дежурств на линии поддержки (при необходимости); помощь в анализе и предотвращении инцидентов.

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

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

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

Команды – новички в Agile обычно имеют в своем составе одного, иногда двух человек, однозначно определяемых как коучи команды. Работа этих людей – помогать команде стать независимо компетентной, чтобы все ее члены могли выполнять свои задачи без участия коуча. Это не значит, что коуч уходит из команды, но это значит, что он мог бы, и если остается, то постепенно становится постоянным членом команды.

примечание

Даже после того как команда станет независимо владеть навыками, будет полезно присоединять к ней опытного коуча (скажем, раз в год или около того), чтобы помочь ей вспомнить забытые практики и попробовать новые.

Командам нужен коучинг в четырех категориях в зависимости от того, какие уровни свободного владения навыками их интересуют.

• Развитие команды, самоорганизация и посредничество (все команды).

• Практики планирования и командной работы на уровне фокусировки.

• Практики разработки на уровне поставки.

• Практики развития бизнеса на уровне оптимизации.

Для этого может потребоваться несколько коучей.

См. также

Ретроспективы (глава 11)

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

Устранение препятствий (глава 11)

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

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

Коучи-практики

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

Коучи-игроки

Один из вариантов коуча-практика – это коуч-игрок (играющий тренер, player-coach), который имеет опыт в практиках Agile и некие навыки коучинга, но больше сфокусирован на поставке, чем на помощи командам в обучении. В эту категорию часто попадают «доморощенные» коучи (их должность может называться а-ля «технический руководитель» или «ведущий инженер»), как и большинство опытных Agile-разработчиков.

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

Коучи-фасилитаторы

Один из наиболее часто встречающихся типов коучей – коуч-фасилитатор, также называемый Scrum-мастером[29]29
  Название Scrum-мастер пришло из популярного метода Scrum. Оно вводит в заблуждение: предполагает кого-то, кто достиг мастерства в понимании Scrum, а не того, кто имеет власть или контроль над командой.


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

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