| Рубрикатор |  |
 |
Реклама
| Статьи | |
|
| Светлана ГАЦАКОВА | 29 мая 2018 |
Внедрение Agile – это смена парадигмы управления проектами
В каких случаях подход Agile полезен, какие выгоды он дает, какие риски с собой несет, как эти риски нивелировать?
Agile -- это целостная система принципов и приоритетов в управлении практически любыми проектами, четко сформулированная в документе «Манифест Agile», который стоит прочесть каждому современному руководителю. Применение этих принципов позволяет решить целый ряд задач, на которых «буксует» традиционная технология управления проектами:- обеспечить высокую адаптивность создаваемого продукта/решения к меняющимся требованиям заказчика и бизнес-среды;
- выявлять ошибки в выборе целей проекта и требований к создаваемым продуктам, а также исправлять их на более ранних этапах, когда цена такого исправления еще не слишком высока;
- удерживать сфокусированность проекта на важных моментах, даже если траектория движения к конечным целям часто меняется;
- относительно легко интегрировать в проект новые требования заказчика и новые знания о нем, об отрасли, управленческих методиках, тенденциях и др.;
- создать и поддерживать на протяжении всего проекта эффективную обратную связь с пользователями разрабатываемого продукта/решения;
- создать и поддерживать атмосферу вовлеченности и сотрудничества, существенно улучшить взаимодействие членов проектной команды и не давать им забыть, что действительно нужно конечному пользователю создаваемого продукта или выполняемого проекта.
Такой разный Agile
В рамках подхода Agile предложено много конкретных методик организации работ (SCRUM, Канбан и др.). Особенно это заметно в области разработки ПО, хотя подход Agile можно успешно применять и в других сферах деятельности. Оставаясь полноценными представителями подхода Agile (в смысле соответствия манифесту), эти методики сильно различаются, гораздо больше, чем варианты классического управления проектами. В этом разнообразии состоит как сильная сторона Agile (возможность выбрать простое и эффективное средство решения своей задачи), так и один из главных рисков (выбор «не той» методики).
Так, SCRUM делает основной акцент на стабильном ритме выпуска очередных версий продукта, которые появляются через равные короткие промежутки времени (спринты). Причем каждая версия должна как можно быстрее попадать к пользователям. Из-за высокой частоты изменений системы, находящейся в промышленной эксплуатации, методика SCRUM должна опираться на особую технологию развертывания (DevOps), без которой в информационной системе крупной организации может наступить хаос. Кроме того, SCRUM достаточно четко определяет роли координаторов и процедуры взаимодействия внутри проектной группы (совещания, оценки трудоемкости задач). В SCRUM важно во что бы то ни стало выполнить каждый спринт в срок. Если какая-то задача затягивается, ее просто переносят на один из следующих спринтов.
Канбан же сфокусирован на другом: здесь важно выполнить каждую задачу, а также визуализировать весь поток задач и предотвратить грубое нарушение установленных ограничений, в частности, на число задач с определенными статусами.
Организация, решившая применить подход Agile, должна ясно понимать, что для разных ее проектов могут подходить разные методики или даже их сочетания. Это нормально. Подбирая методику для конкретного проекта, необходимо уяснить главные ее особенности (на каких проблемах она сфокусирована). А конкретные параметры методик (например, длительность спринта в SCRUM) можно (и даже нужно!) будет не раз «подкручивать» потом, опираясь на приобретенный опыт.
На собственном опыте
Мы к использованию Agile пришли с двух сторон. Во-первых, два года назад мы начали разработку собственных информационных технологий и программных продуктов, причем достаточно сложных и разноплановых. Одни из них упрощают создание и эксплуатацию современных ERP-решений для крупных организаций на основе технологической платформы и продуктов «1С»; другие наши разработки связаны с поддержкой управления на основе данных (data-driven management), оптимизацией бизнес-процессов (process mining), роботизацией управленческих решений и ускоренным внедрением управленческих инноваций у организации-заказчика. Разработка такого ПО включает большой объем НИОКР. При этом на старте проекта практически невозможно сформулировать исчерпывающие требования к конечному продукту.
Сейчас мы углубили и расширили оба сценария применения Agile, о которых я говорила выше. Главное, мы приобрели большой практический опыт применения Agile в двух существенно различных областях (создание ПО и внедрение ERP-систем). И убедились в том, что результаты не заставляют себя долго ждать. Так, в проектах разработки собственных программных продуктов значительно улучшился ключевой параметр time to market (временной интервал от начала проекта до выхода продукта на рынок). Например, для одной из наших разработок он сократился в 2 раза! Именно благодаря Agile часть разработок сегодня уже находится на стадии промышленной эксплуатации, причем их не пришлось дорабатывать и перерабатывать сразу после выпуска, как это нередко бывает при традиционном подходе к созданию софта.
При внедрении ERP-систем средняя удовлетворенность заказчика качеством услуг повысилась до 4,5 баллов (в нашей компании оценка проводится по пятибалльной шкале на основе полноты функциональности, юзабилити для пользователей и качества управления проектом). Применение Agile повысило вовлеченность заказчика в процесс создания ERP-решения, которое получается более качественным и внедряется гораздо легче.
Основные преимущества
При внедрении ERP-систем для заказчика Agile дает два основных преимущества. Во-первых, это раннее выявление слабых мест и возможность оперативно реагировать на них. В свою очередь, это улучшает управление ожиданиями заказчика. Второе преимущество связано с существенно более высокой вовлеченностью сотрудников заказчика и исполнителя: постоянно работая как единая команда, мы получаем на выходе продукт, максимально соответствующий ожиданиям заказчика.
Применение agile-подхода для управления собственными разработками резко сокращает time to market.
И, конечно, в обоих случаях качество продукта повышается, ведь тестирование, проводящееся на ранних этапах, позволяет гораздо раньше выявить всевозможные «баги», оперативно их устранить и снова протестировать исправленный продукт, повторяя этот цикл несколько раз за то время, которое при традиционном управлении проектами потребовалось бы на создание первой версии. В процессе разработки происходит адаптация продукта к потребностям заказчика и на выходе он получает ровно то, что ему действительно нужно.
Еще одно преимущество Agile связано с тем, что запрос на добавление той или иной функции возникает в формате «пользовательской истории», показывающей конкретные ситуации, в которых эта функция будет востребована. Это гораздо информативнее, чем простые списки требований, входящие в традиционные ТЗ.
Опираясь на опыт нашей компании, могу с уверенностью сказать, что применение Agile оправданно и полезно как при управлении разработкой собственных ИТ-продуктов, так и при внедрении ERP-систем.
В то же время мы не перешли на agile-управление полностью. Есть заказчики, которые, хорошо понимая все издержки традиционного управления проектами, все же не могут от него отказаться. Например, из-за того, что в их организациях требуется утверждение ТЗ на проекты уровня внедрения ERP-систем, а уполномоченный комитет может обращаться к этой теме не чаще раза в год или даже в два года, такое бывает. Поэтому мы на равных поддерживаем обе технологии управления проектами, предлагая Agile как опцию и разъясняя ее преимущества. Но окончательное решение остается за заказчиком.
Основные риски
Вместе с тем применение Agile сопряжено с определенными рисками. При управлении собственными разработками основной риск -- архитектурный. Если на начальном этапе не продумана вся архитектура и логика построения продукта, разработка получается «кусочной». Дальше происходит итеративное надстраивание функциональных модулей, а в результате вполне может получиться «клубок» программного кода, который потребует рефакторинга. Чтобы этого не происходило, в команде должны быть квалифицированные технические эксперты, которые смогут контролировать процесс разработки. Иначе почти неизбежно возникнет несоответствие «внешней» картинки продукта его внутреннему содержанию, результатом чего станут несбывшиеся ожидания и неудовлетворенность результатом. Отмечу, что этот риск зависит также от применяемой agile-методики. Например, в SCRUM (с его ориентацией на короткие спринты) этот риск выше, чем в Канбан и некоторых других agile-методиках.
Главный риск применения agile-подхода к управлению созданием и внедрением ERP-систем я назвала бы неумеренной адаптивностью. Он связан с тем, что проект может превратиться в долгострой, если вместо интенсивного движения по основным линиям развития создаваемого решения фактическим содержанием работ станет бесконечная шлифовка функциональности, созданной и предоставленной пользователям в ходе ранее выполненных спринтов. Возникновение этой проблемы можно предотвратить, включив в проектную группу высококвалифицированного скрам-мастера.
Количественно просчитать риски перехода к Agile, я думаю, сегодня невозможно. Слишком это новая тема, слишком мало специалистов, уже набравших серьезный положительный и отрицательный опыт применения Agile в действительно сложных проектах. А вот правильно подойти в внедрению Agile определенно важно и даже необходимо. Однако и здесь нет одной единственно правильной методики.
Путь к внедрению
В то же время уже можно рекомендовать некоторые универсальные приемы, всегда дающие ощутимый положительный эффект. Так, чтобы справиться со «стрессом» при переходе к новой парадигме управления проектами, организации желательно выбрать сильного agile-тренера, четко определить цели и мотивацию, как можно лучше подготовить и обучить сотрудников. Идеальный вариант: провести тест-драйв внедрения Agile на пилотном проекте и тщательно разбирать ошибки как тест-драйва, так и «боевого» применения Agile в настоящих проектах. Анализ ошибок поможет понять:
- какие инструменты лучше использовать для управления, распределения задач, ведения отчетности;
- как оценивать выполненные задачи;
- как управлять бюджетом проекта;
- как выстроить работу команды;
- как скорректировать параметры применяемой методики.
Внедрение Agile – это смена парадигмы управления проектами. Переход на такие методологии не должен быть «агрессивным» – это может привести к неправильному отношению к работе, когда она делается ради самой себя. Число ошибок и разочарований возрастет, а персонал, не прошедший хорошую подготовку, будет преувеличивать значение каждой неудачи. Конечно же, лучше нанять agile-тренера, чтобы процесс внедрения сразу был организован правильно. А поскольку формируется единая команда «исполнитель -- заказчик», то важно убедиться, что и заказчик хорошо понимает все выгоды и перспективы кардинально изменившегося подхода к управлению проектами.
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!
Адрес: 105082, Россия, г. Москва, 2-й Ирининский пер, д. 3