Что такое Agile-подход и зачем он нужен бизнесу?

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

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

Давайте начнем с того, что такое «Agile»

Этот термин появился в начале 2000-х годов в IT-индустрии, когда в штате Юта был издан «Манифест гибкой разработки программного обеспечения». Манифест был разработан группой программистов-энтузиастов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта. Он включает в себя четыре основных идеи и двенадцать принципов эффективного управления проектами, речь о которых пойдет ниже. Также следует добавить, что в настоящее время существует множество Agile-подходов: Kanban, SCRUM, Extreme programming, Lean и другие, но всех их объединяет соответствие 4-м базовым идеям, описанным в том самом Agile-манифесте.

Идеи Agile:

Люди и взаимодействие важнее процессов и инструментов

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

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

 Работающий продукт важнее исчерпывающей документации 

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

 Сотрудничество с заказчиком важнее согласования условий контракта

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

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

Готовность к изменениям важнее следования первоначальному плану

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

12 основополагающих принципов Agile манифеста:

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и своевременной поставке ценного программного обеспечения. 
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. 
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. 
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. 
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. 
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. 
7. Работающий продукт - основной показатель прогресса. 
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки. 
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. 
10. Простота - искусство минимизации лишней работы - крайне необходима. 
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. 
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

SCRUM. Agile метод управления проектами

Одной из распространенных Agile методологией является - Scrum, в котором, как раз и существуют вышеупомянутые Agile Roles. 

Scrum – это методология (фреймворк) управления проектами с определенным и обязательным к выполнению сводом правил.

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

Scrum Artifacts - это инструменты для решения проектных задач. В Scrum существует четыре артефакта: бэклог продукта, бэклог спринта, диаграмма сгорания и инкремент (ваша цель) с вашими критериями готовности. 

Scrum Rituals - это утвержденные процессы, которые команда выполняет на регулярной основе на протяжении всего проекта. К scrum-ритуалам относятся: планирование спринта, ежедневная синхронизация, спринт ревью и ретроспективы. Каждый из этих ритуалов выполняется в строгом соответствии и всей командой.   

Основные роли внутри Agile Scrum-команды:

Product Owner (PO) - является владельцем продукта. Он формирует и описывает требования продукта и его функционал, приоритезирует задачи команды на спринт и помогает команде планировать. Также он несет ответственность за ценность продукта для пользователей и принимает работу команды на ревью, но не несет ответственности за сроки запуска продукта или сдачи функционала. В роли Product Owner также может выступать Product Manager. 

Product Manager (PM) - может выполнять роль Product Owner-a. Этот человек занимается исследованием рынка, доносит желание клиента, отвечает за стоимость продукта, отвечает за все коммуникации с рынком, которые ваш продукт будет выполнять. Вопросы качества и деливери (поставки продукта) не входят в его компетенцию. Может выполнять роли Product Owner и Scrum Master, но никогда обе сразу. 

Scrum Master (SM) - несет ответственность за сроки сдачи спланированных принтов. В этой роли также может выступать Project Manager, так как основные задача скрам-мастера это: оптимизация и улучшение рабочих процессов, создание комфортных условий работы команды, выявление проблем и нахождение путей для их решения, что функционально перекликается с ролью Project Manager.

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

Scrum Team (ST) - включает в себя всех кросс-функциональных членов команды для достижения поставленных целей продукта. Команда не решает какие требования являются приоритетными для продукта, это задача роли Product Owner, но определяет какой набор задач возьмет в спринт. Команда должна быть взаимозаменяемой с фиксированным составом, чтобы чувствовать себя одним целым. 

Полезная литература: 

Дж. Сазерленд «Scrum. Революционный метод управления проектами»

Д. Андерсон «Канбан. Альтернативный путь в Agile»

K. Schwaber, J. Sutherland “The Scrum Guide”