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

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

Постоянные изменения в продукте. Завтра проект может свернуть в другую сторону, и вы должны быть к этому готовы.

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

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

А вот заинтересованные лица/пользователи/стейкхолдеры. Они будут использовать, поддерживать продукт, вносить свои идеи и предложения.

Пожелания заинтересованных сторон к продукту выражены в пользовательских историях. Например, что «в системе бронирования авиабилетов пользователь может посмотреть даты прямых рейсов», «администратор интернет–магазина может удалять, добавлять и редактировать позиции в каталоге».

Но идей у стейкхолдеров много. И Сергей помогает оформить их в пользовательские истории.

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

И все бы хорошо, но у заинтересованных лиц идей больше, чем 4-6 в неделю. Если команда будет делать все, что они хотят, то придется выпускать в неделю по 10-12 пользовательских историй. Члены команды начнут жестко стрессовать, часто переключаться между задачами, жертвовать качеством, чтобы все успеть.

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

Каким–то идеям владелец продукта должен будет сказать: «нет». Какие–то — поставит на первое место в очереди на разработку. Ценность и размер истории также обсуждается с командой и стейкхолдерами.

Заметили, чего в этой истории про Agile особенно много?

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

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

• Еще в этой истории совсем ничего не было про документы инструкции и контракты. Но было много про продукт и готовые решения. Так мы плавно подошли ко второй ценности Agile организации: лучше создать работающий продукт, чем гору документации о нем. Представьте, что в компании работают над мобильным приложением по продаже товаров. Разработчики выпустили тестовую версию, маркетологи корпят над разделом вопрос–ответ. Но потом вдруг выясняется, что часть вопросов касается функций, которые внедрят через месяц–полтора. А пользователи, которые скачали тестовый продукт жалуются на глюки и баги. Так, может, маркетологам лучше заняться сбором обратной связи для их устранения? А вопрос–ответ оставить напоследок, когда у пользователей накопятся вопросы, а разработчики выкатят весь функционал продукта. Вот это будет по agile.

• Отсюда же вытекает еще одна ценность: отношения с клиентом важнее юридически выверенного и подробного контракта. Если вдруг в контракте написано про SEO, но в процессе работы вы поняли, что клиенту важнее простота и удобство сайта, пойдите навстречу. Лучше довольный клиент и хороший, работающий сайт, чем «все по документам».

• А еще заметили, как часто в нашей истории звучало упоминание о стейкхолдерах, пользователях и заинтересованных лицах? Все дело в том, что в Agile организации команда может быстро (и безболезненно) повернуть в другую сторону, поменять маршрут, если заказчику или пользователям это нужно или меняется ситуация на рынке. Поэтому так много коммуникаций и обратной связи. Все это про четвертую ценность Agile: готовность к изменениям важнее, чем слепое следование первоначальному плану. Представьте, что вы готовите контент–план по продвижению продукта в соцсетях на месяц вперед. Но перед публикацией очередного поста узнаете, что ваш конкурент выкатил обновление продукта и получил массу негатива от пользователей в первые сутки. Быть Agile — значит реагировать на ситуацию на рынке. И срочно готовить свою публикацию о приложении конкурента, и чем оно так не зашло людям.

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

Но если бы это всегда было так на 100%, то уже бы все перешли на Agile и процветали. К чему же еще кроме плюсов приводит гибкое управление?

• Постоянные изменения в продукте = увеличение сроков. Причем вы сами будете умножать все на 2 (а то и на три) для подстраховки. Нечетко поставленные задачи, переподписание контрактов и допсоглашения — это нормально.

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

• Рискуете, бесконечно набиваете шишки. Потом встаете и все по кругу.

• Бесконечное тестирование всего, что вы создаете.

• Много–много общения. И грустные глаза программистов на 4-х часовых совещаниях.

• Придется довериться команде. Много решений будут принимать сами сотрудники. Или «привет, чайка–менеджмент». Например, когда основатель компании или кто–то из руководства вдруг начинает обсуждать цвет кнопок, которые нарисовал дизайнер.

• Вы знаете клиента, стейкхолдеров и всех заинтересованных в продукте лиц по именам.

• Никого не наказываете штрафами, даже если очень хочется.

• Никакого долгосрочного планирования. Завтра проект может свернуть в другую сторону, и вы должны быть к этому готовы.

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

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

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

Религиозные войны между адептами Agile и сторонниками каскадной модели управления уже в прошлом. Сегодня многие из тех, кто когда–то перешел на «чистый Agile», применяют гибридный подход к управлению проектами. Почему и когда такое происходит?

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

К примеру, такой гибрид Agile и Waterfall применяли в компании Schneider Electric. Это позволило команде разработчиков программного обеспечения работать независимо от команды, которая отвечала за "железо". Разработчики применяли Agile. А вторая команда не отступала от каскадной модели. Планировали все этапы и следовали жестким срокам.

В компании при разработке и развитии продукта используют долгосрочное планирование. Но все стратегии разбивают на задачи, которые, в свою очередь, упаковывают в итерации.

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

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