В современном бизнесе царит философия гибкости. Ранний выпуск продукта и быстрая обратная связь от клиентов – залог успешной торговли и высоких прибылей. Для правильной организации рабочего процесса разработан ряд приемов, объединенных общей концепцией готовности к изменениям. Agile-методологии зародились в сфере информационных технологий, но уже подтвердили свою эффективность в разных секторах рынка.
Философия Agile
В переводе с английского название концепции означает "быстро и легко двигаться, думать или понимать". В русском языке крепко прижилось определение "гибкий".
Скрывающиеся под термином Agile methodology подходы и приемы направлены прежде всего на обеспечение отзывчивости продукта к запросам покупателей. Когда ситуация на рынке изменяется, гибкий товар меняется вслед за ним и быстро получает признание.
Agile vs Waterfall
В природе, технике, обычной жизни все процессы происходят последовательно, проходя через ряд этапов. Бизнес изначально принял эту концепцию, получившую название "каскадная модель" или "модель водопада" (waterfall model), и многие годы успешно ей следовал. Сначала шли фазы планирования и проектирования, затем продукт реализовывался, проверялся и внедрялся. От начала до конца процесса могли проходить годы.
В современном бизнесе – это верный путь к краху. Клиент не готов ждать, он хочет получить продукт прямо сейчас. Более того, потребитель изменчив, непостоянен, сегодня он хочет одно, а завтра - другое. Если при каждом изменении придется заново запускать весь цикл работ, продукт никогда не выйдет в мир.
В конце 20-го века самой динамично развивающейся сферой рынка была разработка программного обеспечения. Здесь острее всего чувствовалась потребность в изменениях. Появилось сразу несколько новых подходов к организации производственного процесса, стремящихся уйти от модели водопада. Они отличались в деталях, но были необычайно похожи в главном. Потребовалось некоторое время, чтобы собрать их воедино и создать единую философию.
В 2001 году в штате Юта в США группой разработчиков был создан и обнародован "Манифест agile-методологии разработки ПО", известный как Agile Manifesto. Он не содержал ни одного конкретного указания, как следует работать. Вместо этого обозначались базовые идеи и принципы, которым нужно следовать.
Идеи и принципы Agile
В манифесте сформулированы четыре ценности методологии:
- Люди важнее вещей и процессов.
- Продукт важнее документации, которую никто не читает.
- Сотрудничество важнее контракта.
- Постоянная готовность к изменениям.
Эти базовые идеи подробнее раскрываются в принципах:
- Главный приоритет работы – удовлетворение потребностей клиента.
- Главное условие работы – ежедневное общение разработчиков и заказчика на равных.
- Работа должна вестись короткими итерациями, что позволяет оперативно вносить изменения в требования.
- Работающий продукт является главным показателем прогресса и должен выпускаться как можно чаще.
- Каждый член команды разработчиков должен быть мотивирован.
- Залог успеха – простота и качественное исполнение.
- Постоянный мониторинг работы команды с целью увеличения производительности и коррекции ошибок.
Сам по себе agile – это не конкретная методология, а единая философия управления проектами, образ мышления. Это гуманистический подход, учитывающий как потребности бизнеса, так и интересы людей.
Пример гибкой организации
Рассмотрим принципиальную схему гибкого управления проектом в его родной сфере - разработке программного обеспечения.
Важно правильно распределить роли:
- Владелец продукта – человек, который точно знает, что должно получиться в итоге, и может это объяснить команде.
- Команда – небольшая группа специалистов, способных создать продукт.
- Мастер, координатор - человек, следящий за правильной организацией рабочего процесса согласно принятой методологии.
Agile development начинается с составления бэклога - полного списка требований владельца к конечному продукту на текущий момент. В процессе работы в бэклог могут вноситься изменения, добавляться новые пункты, удаляться неактуальные, меняться приоритеты.
Проводится первое собрание клиента и команды разработчиков под наблюдением мастера. Список требований рассматривается, корректируется. На первой встрече делаются предварительные оценки временных затрат, большие цели разбиваются на составные части, составляется карта целей.
Методология Agile предусматривает итеративную разработку: короткие спринты продолжительностью от недели до месяца. Перед каждой итерацией формируется список конкретных задач, над которыми будет работать команда. До конца спринта изменения в этот список уже не вносятся. Результатом работы должен быть работоспособный продукт, который можно представить потребителю.
Во время работы команда ежедневно устраивает короткие обязательные собрания, где каждый участник рассказывает, что он делал вчера в рамках задач спринта, что будет делать сегодня и с какими проблемами столкнулся. Это позволяет каждому члену команды понимать, чем занимаются другие.
По окончании спринта устраивается встреча, на которой владельцу продукта предъявляются результаты работы. Затем команда проводит ретроспективу – анализирует прошедшую итерацию, обсуждает проблемы.
Недостатки гибкого управления
Методологии Agile обладают огромным потенциалом, если их правильно применять. Эта оговорка не случайна, не зря существует огромное количество бизнес-тренингов по «внедрению Agile». Важно понимать суть гибкой философии, а не следовать досконально каждой букве Agile Manifesto.
Бездумное использование принципа «продукт важнее документации» может привести к полному отсутствию документации проекта и абсолютному хаосу. «Готовность к изменениям» порой выливается в постоянные переделки продукта из-за капризов клиента.
Грамотное применение гибких методик способно раскрыть потенциал любого проекта и сделать его успешным.
