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

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

Моя компания, Winshuttle, начала переход к подгруппам Agile, разделив нашу большую команду разработчиков из примерно 20 человек на маленькие команды, назвав их подгруппами. Требования были разделены на независимые блоки для каждой подгруппы на основе опыта ее членов. Поскольку члены команды стали отвечать за дизайн, планирование, поставку и качество на выходе, уровень владения вырос драматически. Кроме того, поскольку вся коммуникация шла напрямую, результаты стали быстрее и точнее.

Организация подгрупп

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

Особенности подгрупп

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

Подгруппа состоит из следующих членов команды:

1. Ядро команды - это люди, которые все свое время посвящают работе в подгруппе. Они являются частью всех дискуссий, решений и совещаний. Компетенции ядра команды суммируются в компетенции всей подгруппы. Члены команды, составляющие ядро, могут перемещаться между подгруппами во время или после цикла релиза в зависимости от необходимых навыков.
2. Специалисты-совместители - эти члены команды доступны в качестве временных ресурсов в поддержку конкретным проектным нуждам разных подгрупп. Они могут работать в нескольких подгруппах одновременно. К примеру, это могут быть дизайнер интерфейса, тестировщик или инженер по автоматизации.
3. Лидер подгруппы. Подгруппа возглавляется лидером, отвечающим за расстановку приоритетов в работе совместно с командой бизнес-менеджмента, уточнение требований и периодическое пополнение очереди грядущих проектов. Менеджмент проекта не вмешивается в работу подгруппы, за исключением передачи новых требований и разъяснения сомнений в плане функциональности или приоритета среди выбираемых задач. При этом лидер подгруппы является посредником между подгруппой и менеджментом проекта.

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

Использование подгрупп Agile в работе

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

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

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

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

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

«Надо» и «не надо» при работе в Agile-подгруппах

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

Надо:

• Когда вы решите внедрить у себя подгруппы, то до настоящего перехода подготовьте к нему участников команды, проведя тренинг по данному направлению.
• На старте проведите время с каждым членом команды, чтобы рассеять сомнения относительно процесса.
• Собирая команду, позаботьтесь о совместимости навыков ее участников. Подумайте о личностных проблемах между участниками подгруппы. Вы же не хотите трений или сопротивления между товарищами по команде. Постарайтесь разрешить это все до того, как команда разобьется на подгруппы. Если же трения возникают, руководители проекта должны найти решение. По моему опыту, при работе в подгруппе очень многие проблемы такого рода решаются сами по себе!
• Соберите команду вместе. Даже если она разбросана по земному шару, время от времени собирайте всех вместе, чтобы улучшить уровень коммуникации.
• Заведите постоянный процесс обсуждения, чему научилась команда и с какими ситуациями удалось разобраться быстрее и лучше благодаря работе в подгруппе.
• Делитесь лучшими практиками в одной подгруппе с лидерами других подгрупп и поощряйте открытую атмосферу обучения.
• Как можно полнее используйте инструменты и обращайте внимание на предложения команды.

Не надо:

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

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

Оригинал: http://www.agileconnection.com/print/art[...]g-agile-pods-realize-potential-your-team

Об авторе: Ниши работает тестировщиком ПО, она очень предана своему делу. За более шести лет опыта работы в среде Agile у нее была возможность поработать на всех стадиях жизненного цикла тестирования ПО, от «белого ящика», «черного ящика», автоматизированного тестирования до регрессивного и тестирования юзабилити. Она с рвением относится к работе, верит, что создана быть тестировщиком, и была названа лучшим сотрудником своей компании. Кроме того, ей нравится наставлять новых сотрудников команды, проводить учебные тренинги и сессии обмена знаниями. В свободное время она любит читать, обмениваться знаниями о тестировании ПО, об Agile и различных аспектах процессов и практик тестирования. У нее есть сертификаты CP-AAT, CP-MAT и ISTQB в области тестирования, и ей нравится периодически улучшать свои навыки. Больше всего ей нравится новая страсть к написанию статей об интересных аспектах в ее отрасли.

Перевод: Александра Родсет

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Критерии приёмки для требований в Agile
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Проектная документация в Agile
• 5 причин использовать Story Mapping в вашем следующем проекте
• Оценка трудоемкости при планировании релиза в Agile