Agile – это термин, который сейчас у всех на слуху, но что за ним стоит? Является ли он панацеей проектного управления или это замена устаревшим методам? Применим ли он где-то, кроме IT? Ответы на эти вопросы читайте статье.
Agile методология
Agile (англ. «проворный, сообразительный») – философия, совокупность гибких подходов к разработке программного обеспечения, которые стали использовать для управления проектами. Гибкие подходы подразумевают, что продукт создают в результате итераций, заказчик формирует требования постепенно, причем изменения требований приветствуются даже на поздних стадиях разработки. Исполнение требований заказчика обеспечивают рабочие группы, которые состоят из специалистов различного профиля.
Скачайте и возьмите в работу:
«Agile» – это свод общих принципов, которые являются общими для ряда новых методов разработки и управления проектами, таких как SCRUM, экстремальное программирование, Канбан и ряда других, как противопоставление традиционному бюрократизированному и часто не отвечающему современным требованиям подходу. Но, кроме того, это и маркетинговый термин, зонтичный бренд, для синергии продвижения гибких методологий.
Подчеркну, что Agile – это не методика, а общие принципы. Несмотря на то, что в манифесте прописано, что Agile – это методология разработки программного обеспечения, гибкие методы можно применять к более широкому кругу задач и ее принципы используются везде, где существует высокая неопределенность конечного результата, критичны сроки и стоимость разработки.
Считается, что методы эджайл эффективны для организации труда небольших групп (которые делают однородную творческую работу).
Основные принципы Agile
Термин «agile», применительно к проектному подходу, официально появился с подписанием в 2001 году «Манифеста гибкой методологии разработки программного обеспечения» (Agile Manifesto). Задачей Манифеста была «сверка часов», выработка общих принципов и терминологии, объединение усилий для продвижения новой концепции в массы.
Рассмотрим 12 основных принципов Agile.
1. Наивысший приоритет – удовлетворение потребностей заказчика благодаря ранней и бесперебойной поставке ценного продукта. Согласно этому принципу, разработчикам необходимо не столько стремиться к реализации описанных в проектной документации требований, сколько дать заказчику представление о продукте, как можно скорее и в случае несоответствия ожиданиям – внести корректировки. В тренде этой концепции требование к технологическим стартапам по разработке минимально жизнеспособного продукта – minimum valuable product (MVP), задача которого проверить востребованность ключевых качеств продукта на рынке и оценить размер спроса, так как вероятность ошибки с выводом на рынок нового продукта очень высока.
Узнайте, каким образом модная технология позволила медикам больше зарабатывать. Мы внедрили Agile в реальном бизнесе. Что из этого вышло?
2. Изменение требований приветствуется даже при завершении разработки - для повышения конкурентоспособности продукта. Какие-то новые требования к продукту могут быть сформированы уже на финальной стадии разработки в связи с изменением конкурентной или рыночной среды. Этот принцип нельзя реализовать в каскадной модели управления проектами, или это будет стоить очень дорого для спонсора.
3. Работающий продукт следует выпускать с периодичностью не реже двух месяцев, а лучше чаще. Это относится в первую очередь к программным продуктам с их версионностью, но по мере конвергенции технологий и появления, например, «интернета вещей», актуальность высокой скорости подготовки новой версии действующего продукта в конкурентной борьбе будет возрастать.
4. Постоянная коммуникация на протяжении всего проекта между командой и заказчиком. Этот принцип лежит в той же плоскости, что и удовлетворение заказчика как высший приоритет – достичь такого удовлетворения без постоянной коммуникации с заказчиком вряд ли возможно.
5. Проекты следует поручать только мотивированным профессионалам. Создайте условия и доверяйте им – тогда проект будет реализован на высоком уровне. Так как современной наукой доказано, что интеллектуальная деятельность слабо мотивируется материальными бонусами, привлекать к работе надо специалистов, которых мотивирует само задание. Им требуются только приемлемые условия работы и доверие заказчика.
6. Оптимальным методом обмена информацией является личное общение. Для этого все члены команды должны находиться в одном пространстве, хотя бы в одном здании. Желательно чтобы в этом пространстве находился и сам заказчик.
7. Работающий продукт – критерий прогресса задачи. Заказчик ждет продукт, его не интересует достижение очередной вехи в диаграмме Ганта или выполненный пункт плана. Клиент должен видеть развитие продукта и основными критериями в таком случае являются работоспособность и соответствие заявленным требованиям, и чем ближе продукт к ожидаемому состоянию, тем большего прогресса достигла Agile команда.
8. Спонсоры, разработчики и заказчик должны обеспечить постоянный ритм процесса разработки неограниченное время. Устойчивый ритм работы снимает стрессовое состояние у всех заинтересованных сторон из-за ситуации аврала и нарушения дедлайнов.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. Это очень важный принцип, так как критикуемыми аспектами гибкой разработки являются как раз качество и упрощение готового продукта, которым часто пренебрегают в пользу скорости и оптимизации.
10. Простота, как искусство минимизации лишней работы. Принцип «бритвы Оккама» в действии – суть не в том чтобы упрощать продукт, а в том, чтобы избегать ненужной работы и не добавлять в продукт что-то избыточное для его функционального назначения. См. также про систему Канбан>>
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Так считают авторы и подписанты манифеста, поэтому в рамках всех гибких методик происходит делегирование разработки требований и решений на уровень команды. Добиться эффективной самоорганизации позволяет наличие общего интереса и согласие относительно целей и синергии в достижении этих целей сообща.
12. Анализ и адаптация к изменяющимся условиям, постоянный поиск способов повышения эффективности работы. Это та самая гибкость, о которой заявлено в названии подхода и к которой должны стремиться все разработчики в рамках концепции методологии Agile.
Agile SCRUM
SCRUM («скрам») – термин из регби. его применяют для названия наиболее структурированной на данный момент методики гибкой разработки Agile. В спорте – это командное и высокоинтенсивное действие по достижению результата – получение мяча для последующей атаки, которое длится короткое время. Для такой фазы игры из-за ее высокой травматичности используются лучшие и самые подготовленные игроки команды, а если таких игроков по какой-то причине не хватает (из-за удаления, например, или травмы) scrum не проводится.
В России методология получает все большее распространение. В основе scrum лежат так называемы спринты – жестко фиксированные и небольшие по времени итерации работ, в течение которых необходимо разработать и предоставить конечному пользователю работающий продукт с новыми, относительно предыдущего спринта, возможностями. Длительность спринта жестко фиксируется, и определяет гибкость и предсказуемость процесса разработки, чем короче спринт – тем выше гибкость и предсказуемость, но повышается относительная стоимость каждой иттерации, также возрастают затраты времени на планирование и проведение встреч с заказчиком и внутри команды.
Очень важным элементом этой гибкой методологии является бэклог продукта (backlog) – список структурированных по степени важности технических и бизнес-требований к финальной версии продукта, из которого берутся задачи для каждого следующего спринта, этот список может пополняться по мере реализации проекта и уточнения параметров.
Новый функционал разрабатываемого продукта для очередного спринта определяется на этапе планирования, после чего составляет бэклог спринта (Sprint Backlog), который не изменяется на всем его протяжении.
Методология предусматривает также структуру ролей в проекте:
- Scrum-master – посредник между заказчиком и командой;
- Product Owner – представитель заказчика, задачи которого - формировать и приоритизировать Product Backlog, и принимать промежуточные результаты спринтов;
- Team – команда проекта, в которой нет отдельных ролей, она является самоорганизующейся системой из кроссфункциональных мотивированных профессионалов.
Зачем Agile подход финансистам
Agile вышел за рамки IT и успешно используется в маркетинге, продажах, логистике и управлении компаниями. Ключевые достоинства методологии управления проектами Agile для финансистов:
- возможность экономии средств на длительной проработке проектной документации;
- высокий уровень контроля над бюджетом (читайте также, как составить бюджет доходов и расходов);
- возможность вносить коррективы без больших потерь финансов для компании;
- возможность раннего запуска продукта и получение первых доходов от него.
Ключевой проблемой является юридическое оформление такой формы организации работы с внешней командой разработчиков.
Какие еще методы проектного управления можно применить в управлении задачами финансовой службы? Комбинируйте подходы, используя элементы разных методов, отказывайтесь от тех, которые утратили актуальность.
Перспективы гибкой методологии Agile
Группа подписавших манифест опубликовала его на сайте и предложила подписать его в знак поддержки принципов гибкой разработки. Сейчас движение тех, кто присоединился к манифесту, превратилось в Альянс Agile, в котором состоит почти 30 000 человек.
Самое главное достоинство методологии Agile – его гибкость и адаптивность. Она может подстроиться под практически любые условия и процессы организации. Agile отлично подходит для проектов с «открытым концом» – например, запуск интернет-сервисов, разработка компьютерных игр, операционных системы. Однако гибкость может приводить к потере фокуса и к снижению предсказуемости.
Agile не только повышает качество бизнес-процессов в компании, но и делает их максимально прозрачными. Появляется ясность во взаимодействии. Люди начинают искренне говорить о том, о чем раньше молчали: какие инструменты не работают, что необходимо изменить.
Очень важно отделять ошибки применения гибкого подхода, от недостатков самой методологии. Прежде чем будут реализованы все достоинства подхода, потребуется некоторое время на адаптацию подхода к реалиям конкретного бизнеса и за это время будет допущено множество ошибок. Но неоспоримый факт – методология завоевывает своего клиента и в мире и в России.