Во время своей командировки пообщался с одним мудрым руководителем о методологии Agile и ее смысле. Это простое и понятное объяснение он узнал от консультанта, проводившего Agile-трансформацию в крупной российской компании.
Обычно объяснение методологии Agile сводится к перечислению идей и принципов из манифеста. Но основатели Agile заложили в методологию решение конкретной проблемы.
Итак, у нас есть команда, разрабатывающая разные и непохожие друг на друга проекты.
Для полноценного планирования проекта необходимо провести оценку задач, просчитать риски, нарисовать диаграмму Ганта и т.д. На этом бюрократическая часть не заканчивается, ведь нужно еще поддерживать построенную диаграмму Ганта и остальное описание проекта. Это много времени и сил.
Agile предлагает высвободить время по утомительному планированию и потратить его на улучшение продукта.
Тщательное планирование на начальном этапе исчезает, т.к. в нашем изменчивом мире технические требования также «плывут». Очень часто по мере движения IT-проекта всплывают сюрпризы, в корне меняющие сроки завершения проекта.
Но видение конечного результата, разумеется, никуда не девается. Помимо видения важно обзавестись измеримым показателем конечного результата и желаемым таргетом.
Далее этот измеримый показатель декомпозируется на несколько более гранулярных метрик.
Например, сервис хочет заработать больше денег на 30%. Декомпозируем метрику на две: вырастить аудиторию на 10% и повысить конверсию в рекламном продукте на 18%. Рост аудитории также можно декомпозировать по способу получения трафика: 2% через SEO, 3% через продуктовые запуски и 5% с помощью маркетинга.
Автономные команды со всеми нужными ресурсами работают над этими метриками и пытаются всеми силами достигнуть таргета. Как они будут достигать требуемых результатов — неважно. Дается полная свобода. Главное, чтобы метрика росла :)
Такой подход растит вовлеченность команд, творчество и в конечном итоге и общую эффективность системы.
И если изначальная “главная” метрика была выбрана верно, то Agile подход поможет добиться хороших результатов.
Все остальные рекомандации и практики Agile — вторичны и лишь облегчают ведение процесса: — оценка в сторипоинтах — чтобы быстрее шипить то, что дешевле в разработке и дает бОльший эффект на метрику — короткие спринты в разработке — чтобы быстрее увидеть прогресс по метрике — ретроспективы — чтобы понять, почему метрика не растет
С учетом этих новых вводных методология Agile выглядит в другом свете. Agile-ритуалы воспринимаются не как бюрократия, а как фреймворк, помогающий улучшать твою метрику.
У адептов Agile нет –цели– дедлайна, есть только путь.