Гибкий подход в управлении проектами подразумевает, что для описания продукта проекта не нужно подробно указывать все его параметры, делать спецификацию, которая как конституция не подлежит изменениям на всем протяжении проекта.
В рамках гибких методов проектного управления не предполагается поэтапное планирование проекта и фиксация его в отдельном документе. Как не предполагается и следование такому плану – гибкие методологии построены на коротких спринтах, временных отрезках, – в неделю–две между встречами команды, на которых ставятся задачи и оценивается выполнение задач, поставленных на предыдущей встрече. Гибкий подход не предполагает формализации функций сотрудников, иерархии внутри команды и отчетной документации. Гибкость также в том, что команда тесно взаимодействует с окружающей средой и заказчиком и финальная форма продукта проекта может значительно отличаться от первоначальной концепции.
Вы наверняка слышали такие термины как SCRUM, Crystal, DSDN, Extreme programming – все это подмножества множества Agile, есть и другие agile-методики, которые упоминаются не так часто.
Как возник Agile
Первоначально гибкие методологии стали применяться при разработке программного обеспечения, особенно предназначенного для массового использования. Финальный продукт в этом случае было сложно формализовать и зафиксировать документально, и сама попытка такой формализации превращалась в трудозатратный и дорогой процесс, причем полученная спецификация в большинстве случаев не соответствовала реальным «плодам» проекта. То есть стоимость планирования проекта оказывалась сопоставима со стоимостью расходов по проекту в целом, а зависимость результата и удовлетворенности клиента от качества реализации этого этапа оказывалась низкой.
На тот момент в ходу был метод «водопада» (waterfall) – последовательной разработки программного продукта из шести стадий:
- Формирование системных и программных требований.
- Анализ требований, существующих процессов и т.п.
- Дизайн архитектуры программного обеспечения.
- Непосредственно написание программного кода.
- Тестирование и исправление ошибок, выявленных тестерами.
- Внедрение и исправление ошибок, выявленных пользователями.
Этот метод жив и по сей день и применяется при разработке сложных промышленных программных комплексов, где четко определены конечные требования к решениям.
Но в конце 70-х годов особенности метода последовательной разработки стали ее недостатками: отсутствие гибкости в ответ на изменение условий; жесткость в отношении этапов проекта; зарегламентированность / бюрократия – все это мешало разработке массового программного обеспечения. Особенно в условиях растущей конкуренции, когда вопросы скорости предоставления готового продукта, оптимизации затрат на единицу выпуска выходили на первый план.
Гибкие методы появлялись органично в ответ на условия конкуренции:
- если нет определенности в отношении финальных параметров продукта, не нужны жесткие спецификации – используем список пожеланий к продукту (back-log), который может меняться и дополняться по мере развития проекта;
- если данные о требованиях рынка противоречивы, и единственное решение – как можно быстрее показать конечному клиенту или начать продавать, то делим продукт на части, которые сразу можно использовать или выпускаем MVP – минимальный жизнеспособный продукт (minimum viable product).
- если сроки «жмут», надо поставить график перед лицом, а для наглядности заменить его доской «Канбан» (см. также про бережливое производство). И так далее.
В какой-то момент, когда мир изменился достаточно сильно не только для отрасли разработки программного обеспечения, но и для других инновационных отраслей, а также для массового производства в целом, Agile-методики стали востребованы гораздо шире и стали конкурировать с классическим проектным менеджментом. Сейчас Agile противопоставляют в основном как раз классическому менеджменту проектов, а не методологиям разработки программного обеспечения.
О принципах Agile четко и ясно
Все основные принципы гибкой разработки изложены в одном документе – Манифесте (Agile Manifesto, 2001). Выше я уже несколько раз упоминал отдельные принципы, лежащие в методологиях объединяемых Agile.
Основные постулаты:
- Люди и взаимодействие важнее процессов и инструментов – акцент на людях и отношениях между ними, как основном факторе успешности проекта. Люди руководят и применяют необходимые им процессы и инструменты, а не работают под управлением заранее принятого регламента. Именно поэтому agile-методики предполагают отбор в команду мотивированных профессионалов, с универсальными навыками. Тогда не потребуется внедрять изощренные методы поощрений и штрафов, люди смогут подменять другу друга, участвовать в дискуссии о продукте осознанно и эффективно. Взаимодействие между членами команды может строиться с помощью любых удобных инструментов, но не документов, регламентов и инструкций.
- Работающий продукт важнее исчерпывающей документации – менять, адаптировать, корректировать легче то, что уже существует и работает, а не то, что подробно и исчерпывающе описано в бумагах. Сначала надо сделать что-то простое и работающее, чтобы затем, оценив и апробировав сделанное, внести коррективы или отказаться от реализованного в пользу иного варианта исполнения. Но в итоге либо продукт есть и работает (пусть и требует корректировок, дополнений и доработки), либо есть проверенная гипотеза, от которой надо отказаться. В противном случае в большинстве случаев будет реализован проект, точно соответствующий описанию на бумаге, но не соответствующий рынку, производству, и главное реальным нуждам клиента.
- Сотрудничество с заказчиком важнее согласований условий контракта – в сложившейся реальности заказчик – а им может быть и соответствующее подразделение внутри компании – не всегда может четко сформулировать требования к продукту, зачастую у него есть только профиль клиента и проблема, с которой тот сталкивается. Заказчик может оценить реализованный продукт с точки зрения соответствия его ожиданиям, но не формализовать их. Ему легче потратить время и деньги на версии продукта, чем на всестороннее и исчерпывающее описание, причем такое описание может оказаться более дорогим, трудоемким и затратным по времени, чем гибкая разработка. Методом оптимизации в данном случае как раз и будет сотрудничество с заказчиком, вовлечение его в работу проектной команды.
- Готовность к изменениям важнее следованию первоначальному плану – это, наверное, самый противоречивый постулат. С одной стороны легче и проще менять все по ходу реализации, с другой - процесс такой разработки может затянуться на неконтролируемое время и привести к неожидаемым результатам.
Ключевые принципы гибкой разработки, изложенные в Манифесте:
-
Удовлетворение клиента за счет ранней и бесперебойной поставки ценного программного обеспечения. Данный принцип относится не только к программному обеспечению. Согласно этому принципу работу над продуктом следует разделить так, чтобы по завершении каждого цикла (спринта клиент получал рабочую версию продукта.
На примере калькулятора для анализа проекта:
- по завершении первого спринта вычисляется NPV в Microsoft Excel – все основные формулы работают, ошибок нет, выдается только финальная цифра – рассчитанный NPV;
- по завершении второго спринта NPV рассчитывается также как по итогам первого спринта, но добавляется функциональность – комментарий о полученном значении, расчет IRR и других критериев – для более полной картины;
- по завершении третьего спринта на основе разработанной в первых двух спринтах логики и формул, выверенных и согласованных с заказчиков текстов готовится десктопная версия продукта;
- по завершению четвертого спринта готовится мобильная версия продукта и… вуаля! Продукт готов к использованию для задач заказчика.
- Изменения требований приветствуются. Разработка продукта ведется в быстроменяющейся конкурентной среде, когда по завершении цикла разработки уже может измениться рынок, например, вышел аналог. Тогда, чтобы не выкинуть в мусорную корзину реализованный проект, его дорабатывают, кстати, можно использовать опыт уже вышедшего на рынок конкурента. Поэтому в рамках гибкого подхода изменения требований продуктов даже в конце разработки – приемлемы и приветствуется.
- Частая поставка рабочего программного продукта. Важность этого принципа все в том же – мир быстро меняется и чем короче цикл поставки, тем точнее финальный продукт будет соответствовать ожиданиям.
- Погружение заказчика в работу над проектом на протяжении всего времени его реализации. Заказчик в этом случае является единственным участником команды, носителем знания, «как надо», соответственно его заключение о соответствии продукта ожиданиям и его удовлетворение от результата – ключевой критерий. Чем чаще ожидания заказчика сопоставляются с работой команды проекта, тем, естественно, выше соответствие ожиданий и результата.
- Проектом занимаются мотивированные личности, которые обеспечены соответствующими условиями работы, поддержкой и доверием. Этим принципом проблемы мотивации выводятся за рамки работы над проектом. Предполагается, что на этапе формирования команды, необходимо отбирать только мотивированных профессионалов, самодостаточных личностей, которых не надо подгонять, уговаривать и т.п. Задача сведется только к созданию условий, не препятствующих реализации их потенциала в этом проекте: инструменты связи, возможности для взаимодействия, оборудование и материалы и др.
- Рекомендуемый метод коммуникации – лицом к лицу. Это спорный принцип в цифровую эпоху, когда многие компании развивают сетевое взаимодействие и внедряют удаленную работу в свои процессы. При этом личное взаимодействие имеет ряд преимуществ, которых нет у других видов коммуникации: например, скорость решения вопросов, невербальные сигналы (эмоции, жесты), мотивация (можно похвалить, выделить, поставить «на место»). В любом случае манифест акцентирует на этом внимание и заявляет, как один из ключевых принципов.
- Работающее программное обеспечение – лучший измеритель прогресса. Перенося этот принцип на более общую систему координат, работающая версия продукта - лучший критерий успешности и прогресса проекта. В большом числе случаев этот принцип реализуем и понятен, а там, где не применим Agile.
- Разработчики, а также их куратор и заказчик должны быть готовы сохранять заданный темп в разработке в течение не определенного (читай - неограниченного) времени. Надо понимать, что в такой парадигме срок разработки финальной версии продукта не известен, более того, финальной версии может и не быть, что мы видим на примере постоянно шлифуемых и дорабатываемых версий десктопного программного обеспечения и мобильных приложений.
- Краеугольным камнем Agile-разработки заявляется стремление к техническому совершенству и качеству планирования спринтов. Этот принцип призван сбалансировать возможный негативный эффект на качество разработки от других принципов, например, частой поставки рабочего продукта. Можно разными методами добиваться частой поставки в условиях отсутствия или недостатка спецификаций продукта, например, использовать готовый, но некачественный код разработанный «индийскими программистами» и пренебречь тестированием. Личные качества, профессионализм разработчиков и коллективная ответственность – заложенные в принципе «стремления к техническому совершенству» требуют более высокого уровня ответственности.
- Простота и минимизация лишней работы. Этот принцип надо бы применять во всех проектах, но в качестве ключевого принципа он заложен только в Agile-методиках. Приоритет отдается тому, что делается быстро с минимальными затратами. Отказываемся от ненужных работ как в процессах, так и в отношении продукта, например, консалтинговая компания обычно готовит многостраничную презентацию по выполненным работам и предполагаемым шагам, но если клиент интегрирован в команду, то ему формальная бумага не нужна, ему важнее то, что уже идет в работу – те самые два-три слайда, которые уже готовы для финальной презентации. В отношении продукта – можно стремиться реализовать все задумки в отношении функционала сразу до первого релиза, однако так уже никто не делает, в каждой итерации продукт совершенствует в соответствии с требованиями рынка, что может подразумевать как добавление нового функционала, так и удаление каких-то фич, не «принятых» клиентами.
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Речь идет не об анархии, а о высокой внутренней дисциплине в команде, четком распределении ролей и высоком уровне профессионализма каждого участника. Если вы не можете самоорганизовываться – не работайте в концепции Agile.
- Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Этот принцип подчеркивает, что вся полнота ответственности за проект и его продукт лежит на всех членах команды, никто со стороны не вносит корректив и не анализирует эффективность – все делают участники внутри своего коллектива в интересах проекта и результата.
Области применения Agile
Agile в своем максимальном объеме применим и эффективен при создании продуктов, которых:
- не существовало ранее,
- у которых нет аналогов;
- которые представляют собой технологически сложный или комплексный продукт.
Таким образом, применение agile-методов оправданно в следующих сферах бизнеса:
- Программное обеспечение для массового сегмента, в том числе мобильные приложения, игры и т.п.
- Стартап-проекты – это идеальная почва для внедрения гибких методологий.
- Интернет-порталы и СМИ.
- Медицинские проекты – тело человека до сих пор в значительной мере «терра инкогнита», что создает высокую долю неопределенности в медицине.
- Образовательные продукты и проекты. Если мы говорим о чем-то новом, а не о компиляции старых методов и практик, то образовательные проекты – стартапы на неизведанной территории, все ищут новые методы цифровой эпохи на замену старым технологиям индустриального мира.
- Консалтинг – любой проект в этой сфере требует применения большинства принципов Agile Manifesto. McKinsey однозначно используют методику соответствующую указанным принципам.
- Разработка финансовых и страховых продуктов (индустрия финтех), так как финансовые компании сегодня, это в большой степени ИТ-компании, а финансовый продукт уже стал в значительной степени ИТ-продуктом или применяет результаты работы ИТ-проектов/продуктов.
Надо помнить один важный факт – Agile строится на предпосылке, что проект реализуется высокопрофессиональной мотивированной самоорганизующейся командой, принимающей и понимающей все принципы гибкой разработки. В противном случае – фокус не сработает.
Применение отдельных инструментов гибких методологий в проектном управлении и внедрение культуры agile в компаниях может оказаться вполне эффективным решением. При этом надо учесть несколько моментов:
- спринты не обязательно должны длиться 2 недели или быть равными по длительности,
- чем больше количество спринтов и, соответственно, вариантов изменений, тем больше работы у тестировщиков,
- принцип «простоты» не следует доводить до абсурда,
- не стоит пренебрегать классическим проектным управлением в случае сложных, составных и длительное время работающих систем – надо хорошо понимать к чему должна привести реализация проекта, какими рисками это грозит, как соблюсти интересы всех заинтересованных лиц и как реализовать управление изменениями в таком проекте.
Чтобы оставить комментарий пожалуйста Авторизуйтесь