Самодостаточная и высокоэффективная agile-команда – это залог успешной работы при гибком подходе к разработке программного
обеспечения. От ее профессионализма, слаженных действий и уровня компетенции зависит, каким будет конечный продукт.
Есть ряд критериев, которые принципиально отличают обычный коллектив специалистов и команду, работающую в рамках философии agile.
Понятие и методология работы
Команда «по эджайлу», – это группа людей, отвечающих за поставку продукта от начала до конца (от этапа планирования и до выпуска на рынок). Ее отличительные черты – кросс-функциональность (частичная взаимозаменяемость каждого из участников), высокая самоорганизация, общая ответственность за результат.
И если в обычном коллективе, зачастую, прослеживается четкое распределение ролей, то при гибком подходе эти рамки стерты. Другими словами, коллектив – это единый организм, в котором личные амбиции уходят на второй план. Главное – это совместная работа, главным результатом которой будет получение качественного IT-продукта в кратчайшие сроки.
В такой команде очень важна атмосфера. Доверительные, открытые отношения, умение прислушиваться к коллегам, находить взаимопонимание и общий язык гораздо важнее, чем профессиональное превосходство того, или иного работника.
Обычно в agile-команду входят разработчики, тестировщики, менеджеры, дизайнеры и другие специалисты. Все они находятся на одной линейке в иерархии и территориально размещены в одном офисе.
Гибкая система работы подразумевает то, что любой, пусть даже самый детализированный план действий, может быть изменен, если этого потребует ситуация. При этом практически все договоренности между участниками agile-группы могут носить устный характер, что не затрудняет внесение дополнительных корректировок в работу.
Не менее важная особенность – никаких ограничений в коммуникациях. Разработчики постоянно обсуждают детали проекта, как между собой, так и с заказчиком ПО. Процесс максимально простой, не отягощенный лишними формальностями.
В целом же методология agile подразумевает, что командная работа в коллективе строиться на нескольких базовых принципах. Они четко прописаны в Agile-манифесте – документе, который содержит краткое описание ценностных ориентиров гибкой разработки. Основные из этих принципов звучат следующим образом:
• люди и их взаимодействие важнее процессов и инструментов (никакие инструменты не ограничивают команду специалистов, между заказчиком и исполнителем минимум бюрократических проволочек);
• работающий продукт важнее документации и отчетности (участники agile-команды делают ставку на скорейшее получение готового продукта, а не на его презентацию в процессе создания);
• сотрудничество с заказчиком важнее соблюдения формальных условий (даже жесточайшие договорные обязательства, если того потребует клиент, могут быть изменены в интересах качественного итогового продукта);
• готовность к изменениям важнее, чем следование плану (модификации могут вноситься абсолютно на любом из циклов разработки ПО).
Помимо указанных четырех принципов, есть и другие, уточняющие и дополняющие основные. Среди них можно обозначить: направленность на удовлетворение цели заказчика, максимальная мотивация сотрудников, стремление к простоте и самоорганизации, а также многие другие. Чтобы воплотить эти ценности в жизнь в философии agile выделяют два метода работы – Scrum (подход структуры) и Kanban (подход баланса).
При Scrum-подходе работа над проектом разбивается на небольшие временные промежутки (спринты). Коллектив старается как можно быстрее и качественнее выполнить цели каждого из таких спринтов. На всех этапах допускается внесение кардинальных изменений в план, постоянно проводятся встречи и обсуждения.
Большинство agile-команд при методике Scrum состоит из сотрудников с разными уровнями задач и обязанностей (не путать с иерархическими связами). В них входят разработчики, scrum-мастер (отвечает за эффективность работы команды, ее следование ценностям agile), а также product owner (владелец продукта, несет ответственность за успех проекта). При таком походе, как правило, подразумевается создание продукта с нуля.
Kanban же направлен на то, чтобы сделать уже существующий продукт как можно лучше и удобнее для пользователя. При этом все участники команды разработчиков равноправны и взаимозаменяемы, среди них нет кураторов. Работа разбивается на стадии реализации проекта: от планирования до запуска. Изменения всегда плавные и постепенные. Основной показатель эффективности – как можно скорейшее завершение каждого из этапов.
Знакомство с философией гибкого метода разработки ПО рекомендуется начинать с Kanban. Маленьким бизнес-моделям, которые только готовятся к запуску проекта, желательно выбирать Scrum.
Признаки высокоэффективной agile-команды
Любая команда гибкого проекта (agile) должна обладать рядом особенностей, наличие которых характеризуют ее как высокоэффективную. Среди основных критериев можно выделить следующие:
• компактность;
• соответствующий уровень компетенции всех участников проекта;
• самооргонизация;
• кросс-функциональность;
• удачное размещение.
Приоритетный размер команды, занимающейся гибким проектом, составляет от 7 до 12 человек. Группа специалистов должна быть небольшой, так как в противном случае при интенсивном ритме работы сложно поддерживать тесные и продуктивные коммуникативные связи внутри коллектива.
Эффективное развитие agile-команды невозможно без соблюдения принципа грамотного подбора кадров. В состав группы должны быть включены специалисты, разбирающиеся в различных областях и сферах деятельности, чтобы своими знаниями дополнять друг друга. Без соблюдения этого условия команда будет зависеть от специалистов, привлеченных извне, и утратит свою самодостаточность и мобильность. Также могут возникнуть задержки в принятии ключевых решений.
Желательно не включать в коллектив гибкого проекта тех специалистов, которые могут потребоваться лишь периодически. Лучше взаимодействовать с такими экспертами через так называемые центры компетенций по принципу сервисной модели.
Высокоэффективные agile-команды – это, как правило, самоорганизованные специалисты. Работа по «по эджайлу» подразумевает делегирование большого объема полномочий непосредственно участникам группы. Безусловно, эти полномочия ограничены правилами и стандартами самой организации.
Зачастую, команда сама может принимать решение об очередности и способе выполнения задач, графике работы, взаимодействию внутри коллектива. Не входит в ее компетенции вопрос целеполагания, бюджета, состава группы, так как все это – прерогатива заказчиков и владельцев продукта.
Кросс-функциональность – еще одна черта, которой должны обладать современные команды, внедряющие философию agile. Она заключается в том, что профессиональные навыки одного из специалистов могут при необходимости (например, в случае болезни работника) частично дублировать другие. Из этого не следует, что все участники группы должны быть полностью взаимозаменяемыми, но в идеале нужно стремиться к модели: «все участники группы умеют все».
Для того чтобы обозначить грань требуемой универсальности, введен специальный термин – «T-shape специалист». В данном случае буква «Т» визуально иллюстрирует график уровня знаний сотрудника. В частности, верхняя горизонтальная линия обозначает неглубокие знания во всех необходимых для указанной группы областях, а вертикальная линия – глубокие, экспертные знания в одной из сфер. Так, команда состоящая из T-shape специалистов, априори универсальна.
Приверженцы классической методологии agile утверждают, что участники одной команды должны располагаться в одном офисе. Это дает возможность всем разработчикам беспрепятственно коммуницировать между собой, вести живой диалог, обмениваться мнениями и буквально на ходу корректировать линию поведения. Такой подход делает работу над проектом динамичной и благотворно влияет на сроки его сдачи.
Сегодня существует ряд зарубежных и отечественных компаний, придерживающихся в своей работе эджайл-философии. Среди них можно назвать такие успешные организации и корпорации, как Google, Microsoft, WordPress, Netflix, «М.Видео», «Dostаевский» и многие другие. Все они – узнаваемые бренды, с которыми стремятся сотрудничать по всему миру.
Подбор кадров
Кадровая политика в рамках гибких подходов разработки (agile software) IT-продукта ничем не отличается любой другой. При отборе претендентов на должность внимание обращается на его профессиональные качества, опыт, доброжелательность, коммуникабельность и другие характеристики. Однако есть ряд черт, которые обязательно должны быть присущи кандидату, а именно:
• мотивация и заинтересованность (на всех этапах создания и развития продукта команды должны быть максимально сплочены, поэтому каждому ее участнику должно быть «не все равно»);
• талант к самоорганизации (человеку, привыкшему следовать чьим-то рекомендациям и инструкциям, будет крайне неуютно в коллективе кросс-функциональных специалистов);
• вера в правильность agile-похода (неверие в успех конечно результата, а также желание «отсидеться в стороне» будет разрушать команду изнутри).
Оценка результативности
В связи с тем, что ключевые показатели эффективности (КПЭ) для agile-команды едины, то оценка дается результативности работы всего коллектива в целом. Выделяют глобальные и локальные КПЭ. От того, насколько они достигнуты, создается представление об эффективности выполнения поставленных задач.
К глобальным КПЭ или продуктовым относятся:
• удовлетворенность клиента конечным продуктом (одна из ключевых целей);
• удовлетворенность заказчика всем процессом (носит субъективный характер, тем не менее, очень важный показатель, к которому также следует стремиться);
• удовлетворенность команды конечным результатом;
• финансовая составляющая (объемы продаж, прибыль).
Указанные глобальные КПЭ, зачастую, достигаются одновременно, так как не бывает ситуаций, при которых заказчик и клиент довольны конечным продуктом, он принес ожидаемую прибыль, а среди команды прослеживаются депрессивные настроения и разочарование. Все это лишний раз доказывает – эффективная agile-команда работает как единый организм.
Локальные или операционные КПЭ команды следующие:
• быстрота продвижения продукта на рынок;
• своевременное выполнение плана и четкое перепланирование;
• производительность команды;
• регулярная работа над ошибками и другие.
В каждой организации будет свой список локальных КПЭ, который может изменяться и дополнятся во время работы над проектом.
В любом случае важно помнить, что все ключевые показатели эффективности – это в первую очередь лишь аспект эджайл-философии, качественное отражение результативности проделанной работы. Поэтому не стоит на них зацикливаться, напротив – в ходе ретроспектив (итоговых совещаний) стоит обсудить с участниками команды все возникшие разночтения, учесть ошибки на будущее.