Agile: новый путь или новый инструмент

1761
Кочешков Андрей
главный аналитик ОАО «Издательство «Просвещение»
Методология Agile – термин, который сейчас у всех на слуху, но что за ним стоит? Является ли он панацеей проектного управления или это замена устаревшим методам? Применим ли он где-то, кроме IT? Ответы на эти вопросы в данной статье.

Экскурс в историю вопроса

В настоящее время наиболее широко распространенной моделью планирования и реализации проектов является waterfall model – модель последовательного выполнения работ (каскадная модель, иногда переводят как модель «Водопад»). В основе этого метода управления проектами лежат разработки структуризации работ и планирования, созданные и описанные в США в конце 50-х годов. Такие инструменты как диаграмма Ганта, сетевая диаграмма, метод критического пути и метод PERT до сих пор активно практикуются и обрели второе дыхание благодаря росту доступности персональных компьютеров и совершенствованию программного обеспечения.

Термин и первое структурированное описание концепции каскадной модели появились благодаря работе Уинстона Ройса, в которой он, как ни странно, критиковал применение этой модели в приложении к разработке компьютерных программ. Согласно подходу каскадной модели все фазы проекта реализуются последовательно, и переход к следующей фазе возможен только после полного и успешного завершения предыдущей. Одно из основных свойств данного подхода – высокий уровень формализации при определении требований и проектировании. Это достоинство методик, основанных на этом подходе, – согласование на старте проекта планируемых результатов, процедур внесения изменений и приемки результатов, снимает риски и повышает прозрачность. Но формализация снижает возможности по тонкой настройке работ, учету изменений внешней среды и требований; а процедуры согласований, высокая детализация планирования повышают стоимость проекта. Таким образом, приоритет формального выполнения работ перед сроками, стоимостью и качеством, бюрократизация и жесткое следование очередности фаз проекта стали наиболее критикуемыми аспектами каскадного подхода реализации проектов.

Хотелось бы сказать, что на смену каскадным пришел более эффективный подход, но это не так! Он по-прежнему является наиболее продуктивным в строительстве и больших инженерных проектах, где четко определены и не подвержены изменениям результаты проекта.

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

Появление Agile

Agile – это свод принципов, которые являются общими для ряда новых методов разработки и управления проектами, таких как бережливое производство, SCRUM, Канбан и ряда других. Термин официально появился с подписанием в 2001 году «Манифеста гибкой методологии разработки программного обеспечения» (Agile Manifesto). Задачей манифеста была «сверка часов», выработка общих принципов и терминологии, объединение усилий для продвижения новой концепции в массы.

Следует еще раз подчеркнуть, что Agile это не методика, а общие принципы, серия подходов для существующих и разрабатываемых методов. Несмотря на то, что в манифесте прописано, что agile это методология разработки программного обеспечения, гибкие методы могут быть применены к более широкому кругу задач и ее принципы используются везде, где существует высокая неопределенность конечного результата, критичны сроки и стоимость разработки.

Читайте также:

Основные принципы Agile

Основные принципы методологии изложены в Agile-манифесте.

  1. Наивысший приоритет – удовлетворение потребностей заказчика благодаря ранней и бесперебойной поставке ценного продукта. Согласно этому принципу, разработчикам необходимо не столько стремиться к реализации описанных в проектной документации требований, сколько дать заказчику представление о продукте как можно скорее и в случае несоответствия ожиданиям – внести корректировки. В тренде этой концепции требование к технологическим стартапам по разработке минимально жизнеспособного продукта – minimum valuable product (MVP), задача которого проверить востребованность ключевых качеств продукта на рынке и оценить размер спроса, так как вероятность ошибки с выводом на рынок нового продукта очень высока.
  2. Изменение требований приветствуется, в том числе при завершении разработки, для повышения конкурентоспособности продукта. Это очень важный принцип, в существующих реалиях, когда продукция высоко технологичных отраслей устаревает очень быстро! Какие-то новые требования к продукту могут быть сформированы уже на финальной стадии разработки в связи с изменением конкурентной или рыночной среды. Этот принцип не может быть реализован в каскадной модели управления проектами, или это будет стоить очень дорого для спонсора.
  3. Работающий продукт следует выпускать с периодичностью не реже двух месяцев, а лучше чаще. Это относится в первую очередь к программным продуктам с их версионностью, но по мере конвергенции технологий и появления, например, «интернета вещей», актуальность высокой скорости подготовки новой версии действующего продукта в конкурентной борьбе будет возрастать.
  4. Постоянная коммуникация на протяжении всего проекта между командой и заказчиком. Этот принцип лежит в той же плоскости, что и удовлетворение заказчика как высший приоритет – достичь такого удовлетворения без постоянной коммуникации с заказчиком вряд ли возможно.
  5. Проекты поручать только мотивированным профессионалам. Создайте условия и доверяйте им – тогда проект будет реализован на высоком уровне. Так как современной наукой доказано, что интеллектуальная деятельность слабо мотивируется материальными бонусами, привлекать к работе над проектами надо специалистов, которых мотивирует сам проект. Им требуется только приемлемые условия работы и доверие заказчика.
  6. Оптимальным методом обмена информацией является личное общение. Для этого все члены команды должны находиться в одном пространстве, хотя бы в одном здании. Желательно чтобы в этом пространстве находился бы и сам заказчик.
  7. Работающий продукт – критерий прогресса проекта. Заказчик ждет продукт, его не интересует достижение очередной вехи в диаграмме Ганта или выполненный пункт плана. Клиент должен видеть развитие продукта и основными критериями в таком случае являются работоспособность и соответствие заявленным требованиям, и чем ближе продукт к ожидаемому состоянию, тем большего прогресса достигла команда.
  8. Спонсоры, разработчики и заказчик должны обеспечить постоянный ритм процесса разработки неограниченное время. Устойчивый ритм работы снимает стрессовое состояние у всех заинтересованных сторон из-за ситуации аврала и нарушения дедлайнов.
  9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. Это очень важный принцип, так как критикуемыми аспектами гибкой разработки являются как раз качество и упрощение готового продукта, которым часто пренебрегают в пользу скорости и оптимизации.
  10. Простота, как искусство минимизации лишней работы. Принцип «бритвы Оккама» в действии, суть не в том чтобы упрощать продукт, а в том, чтобы избегать ненужной работы и не добавлять в продукт что-то избыточное для его функционального назначения.
  11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Так считают авторы и подписанты vанифеста, поэтому в рамках всех гибких методик происходит делегирование разработки требований и решений на уровень команды. Добиться эффективной самоорганизации позволяет наличие общего интереса и согласие относительно целей и синергии в достижении этих целей сообща.
  12. Анализ и адаптация к изменяющимся условиям, постоянный поиск способов повышения эффективности работы. Это та самая гибкость, о которой заявлено в названии подхода и к которой должны стремиться все разработчики в рамках концепции методологии Agile.

Вас также может заинтересовать статья:

SCRUM – одна из наиболее известных методик Agile 

SCRUM  (читается как «скрам») – термин из регби, примененный для названия наиболее структурированной на данный момент методики гибкой разработки. В спорте это командное и высокоинтенсивное действие по достижению результата – получение мяча для последующей атаки, которое длится короткое время. Для этой фазы игры из-за ее высокой травматичности используются лучшие и самые подготовленные игроки команды, а если таких игроков по какой-то причине не хватает (из-за удаления, например, или травмы) scrum не проводится.

В России методология получает все большее распространение и хочется на ней отдельно остановиться.

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

Очень важным элементом методологии является бэклог продукта (acklog) – список структурированных по степени важности технических и бизнес-требований к финальной версии продукта, из которого берутся задачи для каждого следующего спринта, этот список может пополняться по мере реализации проекта и уточнения параметров.

Новый функционал разрабатываемого продукта для очередного спринта определяется на этапе планирования, после чего составляет бэклог спринта (Sprint Backlog), который не изменяется на всем его протяжении.

Методология предусматривает также структуру ролей в проекте:

  • Scrum-master – посредник между заказчиком и командой;
  • Product Owner – представитель заказчика, задачи которого - формировать и приоритизировать Product Backlog, и принимать промежуточные результаты спринтов;
  • Team – команда проекта, в которой нет отдельных ролей, она является самоорганизующейся системой из кроссфункциональных мотивированных профессионалов.

Ключевые достоинства методологии для финансистов:

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

Ключевой проблемой является юридическое оформление такой формы организации работы с внешней командой разработчиков.

Перспективы Agile

Группа подписавших манифест опубликовала его на сайте и предложила подписать его в знак поддержки принципов гибкой разработки. Сейчас движение тех, кто присоединился к манифесту, превратилось в Альянс Agile, в котором состоит почти 30 000 человек.

Самое главное достоинство методологии Agile – его гибкость и адаптивность. Он может подстроиться под практически любые условия и процессы организации. Agile отлично подходит для проектов с «открытым концом» — например, запуск интернет-сервисов, разработка компьютерных игр, операционных системы. Однако гибкость может приводить к потере фокуса и к снижению предсказуемости.

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

Методические рекомендации по управлению финансами компании



Подписка на статьи

Чтобы не пропустить ни одной важной или интересной статьи, подпишитесь на рассылку. Это бесплатно.

Рекомендации по теме

Школа

Школа

Проверь свои знания и приобрети новые

Записаться

Самое выгодное предложение

Самое выгодное предложение

Воспользуйтесь самым выгодным предложением на подписку и станьте читателем уже сейчас

Живое общение с редакцией

А еще...


Рассылка



© 2007–2016 ООО «Актион управление и финансы»

«Финансовый директор» — практический журнал по управлению финансами компании

Зарегистрировано Федеральной службой по надзору в сфере связи,
информационных технологий и массовых коммуникаций (Роскомнадзор)
Свидетельство о регистрации Эл №ФС77-43625 от 18.01.2011
Все права защищены. email: fd@fd.ru


  • Мы в соцсетях
×
Чтобы скачать документ, зарегистрируйтесь на сайте!

Это бесплатно и займет всего 1 минуту.

У меня есть пароль
напомнить
Пароль отправлен на почту
Ввести
Я тут впервые
И получить доступ на сайт
Займет минуту!
Введите эл. почту или логин
Неверный логин или пароль
Неверный пароль
Введите пароль

Внимание!
Вы читаете профессиональную статью для финансиста.
Зарегистрируйтесь на сайте и продолжите чтение!

Это бесплатно и займет всего 1 минут.

У меня есть пароль
напомнить
Пароль отправлен на почту
Ввести
Я тут впервые
И получить доступ на сайт
Займет минуту!
Введите эл. почту или логин
Неверный логин или пароль
Неверный пароль
Введите пароль