Самый популярный подход к управлению проектами - Agil. Он помогает быстрее создавать качественные продукты и развивать их.
Для подхода Agil характерна работа короткими сессиями по две-три недели. Каждая сессия состоит из серии задач: анализ, проектирование, непосредственная работа, тестирование, анализ полученных результатов и расстановка приоритетов для следующей сессии.
Такой подход подразумевает гибкость рабочих процессов и эффективное взаимодействие команды. Благодаря этой стратегии можно быстрее проверять гипотезы, сверяться на промежуточных этапах и изменять планы и приоритеты при необходимости.
Гибкость, адаптивность, эффективность и качество — ключевые особенности Agile‑подхода.
Фактически цель Agile — в сохранении баланса между интересами заказчиков, потребностями пользователей и возможностями команды. Главное отличие управления проектом Agile от других подходов заключается в том, что команда разработки мотивируется не рабочими процессами, а высокоуровневыми ценностями.
Agile — это не методология, а собирательное название различных методик и подходов к управлению, которые:
- Фокусируют команду на нуждах и целях клиентов.
- Упрощают оргструктуру и процессы.
- Предлагают работу короткими циклами.
- Активно используют обратную связь.
- Предполагают повышение полномочий сотрудников.
- Имеют в своей основе гуманистический подход.
- Не являются конечным состоянием, а, скорее, образом мышления и жизни.
Сейчас Agil используют во многих сферах, но начиналось всё с IT.
В 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии (как, например, делается в автомобильном производстве), где новые детали по очереди добавляются в последовательные фазы.
Вместо того чтобы ждать, пока будут поочередно завершены все этапы (фазы), Ройс предложил применять фазовый подход. Суть его в том, что изначально собираются все требования, необходимые для проекта, после чего завершается вся архитектура, создается дизайн, записывается код и т.д.
На основе этого в 90-х удалось создать комплекс гибких методов разработки программных обеспечений, способных заменить сложные и трудоемкие методы.
Происходило это так:
- В 1991 году появился метод быстрой разработки приложений RAD;
- В 1994 году появился метод разработки динамических систем DSDM;
- В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum;
- В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP;
- В 1997 году появилась итеративная методология разработки ПО FDD
- Все вместе эти методы объединились под общим названием гибких методов разработки ПО.
Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием программного обеспечения.
Согласно Agile достижение любой глобальной цели команда должна декомпозировать.
Благодаря такому подходу управление проектами становится эффективнее. Agile позволяет всей команде видеть долгосрочные перспективы проекта и лучше справляться с текущими задачами. Каждый участник может самостоятельно контролировать, помогут ли предложенные им решения достичь глобальной цели, и вовремя предлагать изменения, если нет.
Сильные и слабые стороны Agile:
Почему Agile пользуется такой популярностью и среди менеджеров, и среди исполнителей? Потому что этот подход полезен всем участникам рабочего процесса:
Вся команда может свободно принимать решения во всём, что касается проекта: выбирать технологии, архитектурные решения, подходы и практики.
Каждый участник команды получает возможность работать с интересными ему технологиями и влиять на продукт, а значит, ощущать смысл своей работы и собственную ценность для команды.
Бизнес получает актуальный продукт, соответствующий потребностям пользователей. Сотрудникам комфортно и интересно работать, рабочие процессы подвижные и гибкие.
Пользователь получает по‑настоящему полезный продукт, на развитие которого он может влиять. Продукт своевременно обновляется: появляются новые функциональности, устраняются ошибки.
Все в плюсе: проект завершается появлением качественного продукта, в который легко вносить изменения. Клиентам приятно им пользоваться, команда создателей мотивирована продолжать работу.
Вспомним основные сложности, к которым должна быть готова команда, практикующая Agile:
Проект становится менее предсказуемым. Из‑за этого порой сложно правильно оценить сроки выполнения задач и ресурсы, которые придётся задействовать.
Взаимодействие с клиентами и коммуникация внутри команды будут занимать гораздо больше времени, чем до Agile. Оперативно тестировать и согласовывать результаты можно лишь в том случае, когда все на связи.
Готовить документацию станет сложнее из‑за того, что в парадигме Agile проект и требования к нему меняются в процессе работы над продуктом. Если вы захотите подключить новых сотрудников в середине работы над проектом, ввести их в курс дела может быть непросто.
Проект легко может свернуть не туда, поскольку Agile не предполагает тщательного планирования перед началом работы и подразумевает изменение требований к продукту в процессе его создания. Чтобы избежать этого, важно выстроить однозначную и регулярную коммуникацию с заказчиком.
Полностью исключить недопонимания едва ли получится, но их количество можно минимизировать.
Кому подойдёт Agile:
Когда команда состоит из нескольких человек, для работы достаточно обычного чата в мессенджерах. Но чем больше коллектив, тем труднее эффективно организовать его работу. И тем более сложные инструменты приходится использовать.
Вам стоит попробовать Agile, если:
Команда путается в задачах: сложно определить, где чья зона ответственности, части команды плохо взаимодействуют друг с другом и теряют важную для работы информацию.
Agile помогает сохранить прозрачность рабочих процессов даже очень большим командам. Какую бы реализацию вы ни выбрали, гибкое управление позволит быстро ориентироваться в статусах задач, отслеживать прогресс проекта и чётко понимать, кто за что отвечает.
Вы ограничены жёсткими временными рамками: например, вам нужно выпустить новый продукт раньше, чем конкуренты.
Методы Agile помогают минимизировать последствия неправильных решений и вовремя изменить направление развития проекта.
Результат проекта неизвестен заранее: например, вы что‑то изобретаете или запускаете инновационный стартап. Agile позволит проложить оптимальный путь к работоспособному продукту, несмотря на меняющуюся в процессе работы цель.
Главный критерий того, что вам может не подойти гибкое управление: команда или партнёры не готовы использовать Agile.
Базовый принцип этого подхода — тесное взаимодействие всех участников рабочего процесса. Работа не пойдёт, как надо, если кто‑то не согласен идти на контакт.
Чтобы команда больше фокусировалась на задачах и результатах, используйте решения, которые будут всем удобны и понятны.
Статья подготовлена на основе материалов:
https://cloud.yandex.ru/blog/posts/2022/10/agile-and-project-management