Методологии управления проектами: разбираем ключевые для IT- и digital-проектов

В материале

---

Несмотря на то, что человечество долго не идентифицировало свои цели и задачи при помощи термина «проект» и не стремилось формализовать методологию управления, история управления проектами стара, как сама цивилизация. Возьмём, к примеру, известные египетские пирамиды Гизы, построенные в 2 500 годах до н.э. Их строительство, продолжавшееся около 20 лет, требовало тщательного планирования, координации и огромного управления трудом. Иероглифы позволяют предположить, что египтяне разбили масштабное предприятие на более мелкие, управляемые части — намёк на поэтапный современный подход к управлению проектами.

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

И в XX веке, отмеченном быстрым технологическим прогрессом и повышением сложности проектов, стали укореняться методологии структурированного управления проектами, доставшиеся нам в наследство от промышленного производства и времён разработки первого широко применяемого программного обеспечения.

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

Диаграмма Ганта (1910-е годы)

Названная в честь своего создателя Генри Ганта, диаграмма Ганта была одним из первых инструментов управления проектами. Инженер-механик и консультант по вопросам управления Гант представил линейчатую диаграмму как визуальный инструмент для планирования задач во времени.

Диаграмма Ганта не является полноценной методикой, но с неё начался процесс формализации методов и инструментов. Более того, она остаётся одним из наиболее популярных методов визуализации проекта.

Что из себя представляет и как работает: это диаграмма, где по вертикали в последовательном порядке располагаются блоки: этапы, задачи и подзадачи, — а по горизонтали отображается временная шкала и для каждого из блоков на этой шкале отображаются периоды выполнения этих задач. Это удобный способ показать, какая работа запланирована на определённый день.

Идеально для: проектов малого и среднего размера с чёткими задачами с установленной последовательностью и фиксированными сроками. Обычно используется в разработке программного обеспечения и продуктов, в исследовательских проектах, в планировании мероприятий.

Когда использовать: когда нужен простой и наглядный способ планирования и отслеживания хода выполнения отдельных задач с течением времени. Является базовым инструментом проектного управления.

Преимущества: легко создать и интерпретировать за счёт использования визуальной временной шкалы, позволяет подсветить критические этапы и их последовательность.

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

Ключевые элементы: задачи, последовательность, даты начала и окончания, продолжительность задачи, ход выполнения, временная шкала.

Lean / Бережливое производство (1940-е годы)

Философию Lean (от англ. lean production — бережливое, экономичное производство) разработали Тайичи Оно и Эйдзи Тойода из Toyota. Методика стала известна в 1940-х годах как способ оптимизации производства: создание максимальной ценности при минимизации усилий компании и производственных отходов.

В основе Lean лежит концепция непрерывного совершенствования «кайдзен», цель которой устранить все потери в процессе создания ценности.

Что из себя представляет и как работает:

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

Будучи философией, Lean сама по себе не предлагает конкретных инструментов визуализации или управления. Суть Lean — в концептуальном подходе к исследованию ценности продукта и созданию стратегии улучшений.

В результате вокруг философии бережливого производства сформировались такие инструменты анализа и управления, как:

• Kanban;
• система 5S: сэири, сэитон, сэисо, сэикэцу, сицукэ → сортировка, соблюдение порядка, содержание в чистоте, стандартизация, постоянное совершенствование — принципы создания комфортного и эффективного рабочего места;
• система TPM (Total Productive Maintenance) — поддержание оборудования в отличном состоянии за счёт регулярной профилактики;
• система JIT (Just In Time) — «точно в срок», при которой все компоненты поступают в тот момент, когда они нужны на конкретном этапе производства.

Идеально для: производственных сред, но может применяться к любому чёткому рабочему процессу при стремлении свести к минимуму потери, повысить эффективность и максимизировать ценность для клиента.

Когда использовать: когда нужно сократить потери и неэффективность для создания оптимизированного процесса.

Преимущества: помогает выявлять и устранять потери, оптимизируя процессы и сокращая количество отходов. В итоге Lean помогает значительно повысить эффективность работы.

Ограничения: требуется участие всей организации. Особенно методология Lean требует твёрдой приверженности со стороны руководства, без которого эта сложная концепция легко теряет свой импульс. Её может быть сложно правильно внедрить из-за необходимости перестраивать процессы, которые могут затрагивать почти всю компанию по цепочке создания ценности.

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

Ключевые элементы: ценность — понимание того, что ценит клиент, карта потока создания продукта, анализ временных, финансовых, рабочих и других потерь, Kanban, TPM, JIT.

Самое главное — совершенство, ведь бережливое производство — это непрекращающееся движение к совершенству с постоянными усилиями по устранению потерь и повышению эффективности.

Kanban / Канбан (1940-е годы)

Первоначально разработана компанией Toyota в 1940-х годах как система для улучшения и поддержания высокого уровня производства. Позволяет управлять выполнением задач на разных этапах производственного процесса, необходимого для гибкого внедрения принципов бережливого производства (Lean).

Подход позволяет визуально разделять работу и оптимизировать загрузку команды. Активно используется в проектных командах для управления потоком задач. Лежит в основе популярных программ для управления задачами, например Trello и Jira.

Что из себя представляет и как работает: метод предусматривает составление бэклога — списка задач, который формируется на основе всех задач к выполнению. Задачи из бэклога сортируются, приоритизируются по важности и ценности внедрения, оцениваются по трудозатратам. Далее вся работа визуализируется в виде стадий, например «Сделать», «В процессе», «Готово».

Для каждой стадии существует конечный набор задач и подзадач, которые отображаются на карточках. Задачи-карточки разделяются между участниками команды на специализированной канбан-доске и перемещаются между стадиями по мере их выполнения в соответствии с заранее утверждёнными правилами. Например, задачу можно переносить на этап «В разработке», если только она сформулирована в виде пользовательской истории, составленной по определённым критериям.

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

Помимо чётких критериев перехода задачи от стадии к стадии, Канбан подразумевает ограничение количества задач, находящихся на каждой из стадий в процессе выполнения. Это позволяет фокусироваться в первую очередь на закрытии задач — а не на оставлении задачи на какой-то стадии — и избежать неэффективности многозадачности и переключения между контекстами различных задач.

Ограничения задач в статусе «В процессе» позволяют легче увидеть, где объём работы накапливается, что позволяет командам выявлять и устранять узкие места в рабочем процессе. Помимо этого, Канбан предусматривает регулярные встречи, где участники коротко делятся обратной связью по задачам и процессам.

Идеально для: команд с постоянным потоком входящей работы с разным приоритетом, например IT-операций и групп поддержки. Канбан универсален и может применяться ко многим видам работы, включая производство, разработку программного обеспечения и другую творческую и интеллектуальную работу.

Когда использовать: когда нужно улучшить процесс управления потоком задач, визуально разделить обязанности, чётко ограничить объём выполняемой за определённый промежуток времени работы.

Преимущества: наглядность, гибкость и уменьшение перегрузки за счёт:

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

Ограничения: для эффективной работы командам следует придерживаться лимитов количества задач, находящихся в статусе «В процессе». Это требует дисциплины и может быть сложно выполнять, особенно при возникновении срочных задач.

Помимо этого, работа по Канбан менее предсказуема с точки зрения производительности, так как команда работает в непрерывном темпе, без планирования задач по времени. Из-за этого оценка сроков выполнения задач может быть более сложной по сравнению с такими методологиями, как Scrum.

Ключевые элементы: канбан-доски и канбан-карточки, чёткие цели, приоритеты и сроки, циклы задач, командная работа, система pull, где члены команды самостоятельно берут задачи из бэклога по мере выполнения текущих задач.

и . Метод критического пути (CPM) и метод оценки и анализа проектов (PERT) — 1950-е годы

Critical Path Method (CPM) — метод критического пути — разработали в середине 1950-х годов Морган Р. Уокер из DuPont и Джеймс Э. Келли-младший из Remington Rand для сложных проектов с большим количеством взаимозависимых действий.

Одновременно с этим для ракетного проекта Polaris с аналогичными сложностями планирования консалтинговая компания «Буз, Ален и Гамильтон» создала очень похожую методологию, известную как метод оценки и анализа проектов — Program Evaluation Review Technique (PERT).

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

Waterfall / Модель водопада (1970-е годы)

Термин «Waterfall» для обозначения каскадной методологии управления проектами ввёл в 1970 году американский учёный Уинстон Ройс.

Модель водопада представляет собой линейный — каскадный — подход к управлению проектами, где каждый этап проекта перетекает в следующий, неуклонно стекая вниз, как водопад. Waterfall — стандартный и широко распространённый из классических методов управления проектами на сегодняшний день.

Что из себя представляет и как работает: все требования собираются до начала работ в виде неизменяемого списка, на основании которого формируется перечень задач, выстраиваемых в соответствии с требованиями и этапами.

Методология выделяет следующие этапы:

• Формирование концепции.
• Сбор информации.
• Анализ требований.
• Дизайн или визуализация концепта — например, верхнеуровневая визуализация продукта или визуализация пользовательского пути.
• Разработка.
• Тестирование.
• Внедрение.
• Обслуживание.

Эти этапы идут последовательно и взаимосвязаны друг с другом. Закончен один — команда переходит к следующему, при этом пропуск отдельного этапа и возврат на предыдущие стадии не предусмотрен, что обеспечивает поступательное выполнение работ и контроль над всем процессом разработки проекта.

Участие заказчика в промежуточных точках не подразумевается. Результат проекта виден только в самом его конце.

Идеально для: проектов с определёнными и неизменными требованиями, в основном таких как разработка программного обеспечения или в таких отраслях, как строительство и производство, где модель водопада часто используют из-за высокой стоимости внесения изменений в конструкцию на более поздних этапах.

Когда использовать: когда результат проекта ясен, когда нужен структурированный подход, есть желание спланировать всё с самого начала, когда не готовы к отклонениям от заданного результата.

Преимущества:

• Последовательный характер методологии Waterfall — она проста для понимания и использования.
• Фиксированная структура.
• Понятные сроки.
• Чёткое ТЗ.
• Подробная согласованная документация.
• Нет необходимости вовлекать заказчика на промежуточных этапах проекта.
• Конечный объём работы.
• Понимание требуемых ресурсов.

Ограничения: недостаточная гибкость для изменений и пересмотров — не подходит для проектов с неопределёнными или меняющимися требованиями.

Применима, только когда заказчик чётко знает, что он хочет получить. В противном случае есть высокий уровень риска получить не тот результат, так как в ходе формирования ТЗ что-то может быть упущено.

Также можно выделить в качестве недостатков позднее тестирование — из-за чего ошибки и проблемы могут стать очевидными, когда будет проделан значительный объём работы, — и мотивационные риски для сотрудников, вовлечённых в разработку крупного сложного проекта, — итоговый продукт они увидят только в самом конце.

Ключевые элементы: последовательные этапы — требования, проектирование, реализация, проверка, техническое обслуживание, визуализация через диаграмму Ганта, техническое задание, проектная документация, чёткая процедура перехода с этапа на этап (project handoff).

Scrum / Скрам (1986)

Основателями методологии Scrum считают японских учёных Хиротаку Такеути и Икуджиро Нонака. В 1986 году во время наблюдения за компаниями-инноваторами — Fuji-Xerox, Honda и Canon — они заметили, что более эффективны те команды, в которых несколько разнопрофильных специалистов одновременно работают над задачей. А традиционный подход, в котором задача поэтапно переходит от одного специалиста к другому, проигрывает по результатам.

Однако в том виде, в которым мы его знаем, Scrum-метод сформулировали спустя почти 10 лет программисты Кен Швабер и Джефф Сазерленд. Также спустя ещё некоторое время они участвовали в разработке манифеста метода Agile, о котором расскажем ниже.

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

Это простая для понимания и сложная в освоении методология помогает командам работать над проектами с высокой долей неопределённости или необходимостью гибко менять приоритеты и результаты каждой итерации.

Что из себя представляет и как работает: для применения подхода Scrum выделяют роли:

• владелец продукта ― отвечает за список требований к продукту и за результат работы команды, является основным стейкхолдером для команды разработки, так как совмещает функции спонсора, менеджера продукта и руководителя проекта;
• скрам-мастер ― организует процесс и знает, как следить за ходом его реализации;
• команда ― формируется из специалистов с различными компетенциями — до 9 человек; считается, что в командах, насчитывающих более 9 участников, будут возникать сложности с координацией и взаимодействием.

На старте создаётся и приоритизируется список всех требований к задаче ― бэклог. Далее задачи оцениваются командой на предмет сложности и затратности временных ресурсов.

Затем участники, скрам-мастер и владелец продукта проводят скрам-собрание, на котором они планируют спринт — определённое время для выполнения части заданий продолжительностью от недели до месяца. В течение спринта на скрам-доске с 4–5 колонками — к примеру, «Бэклог», «Спринт», «В процессе», «На ревью», «Сделано» — распределяются стикеры с заданиями, которые в процессе работы поочерёдно перемещаются из одной колонки в другую (практика Канбан).

Каждый день участники подключаются на короткие встречи и рассказывают, что сделали, что будут делать и есть ли какие-то сложности. По завершении спринта проводится его ревью, а по завершении задачи — ретро всего процесса выполнения, на котором обсуждают, что команда делала хорошо, что можно сделать лучше и что можно улучшить прямо сейчас.

Идеально для: сложных, быстро меняющихся проектов с неясными долгосрочными целями. Часто используется в разработке программного обеспечения, но может применяться и в других областях.

Когда использовать: Scrum способствует командному сотрудничеству, прозрачности и быстрой разработке высококачественных продуктов, особенно когда ожидается, что цели и задачи могут меняться на протяжении всего процесса разработки.

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

Ограничения: при неправильном управлении может произойти расползание масштаба (scope creep).

Не подходит для проектов с неизменными требованиями. Ограничивает команду 5–9 участниками, из-за чего опытный скрам-мастер может управлять сразу несколькими командами.

Ключевые элементы: спринты, скрам-мастер, владелец продукта, бэклог, скрам-встречи, спринты, скрам-доски, стендапы (ежедневные собрания), обзор спринта, ретро-ревью проекта.

PRINCE2 (1996)

PRINCE2 (PRojects IN Controlled Environments, или Проекты в контролируемой среде) — вторая редакция более раннего метода PRINCE, который в 1989 году разработало Центральное агентство по компьютерам и телекоммуникациям (CCTA) Великобритании в качестве стандарта для управления IT-проектами.

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

Стандарт требует подробной документации каждой стадии проекта, что делает PRINCE2 подходящим методом для проектов, где важен контроль.

Что из себя представляет и как работает

Методология PRINCE2 основывается на:

• Принципах ― неизменных правилах успешной реализации проекта, которые включают в себя делегирование полномочий, постоянное обучение и улучшение, а также применение методологии с учётом конкретной проектной ситуации.
• Темах, областях знаний ― аспектах управления проектами: управление рисками, контроль изменений, управление стейкхолдерами и другие.
• Процессах ― обязательных шагах, которые следует пройти от начала до конца проекта. Включают в себя инициирование, планирование, выполнение, контроль и закрытие проекта.

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

Рассмотрим подробнее процессы, темы и принципы.

Согласно методологии PRINCE2, проект проходит через 7 процессов — наборов операций, направленных на достижение конкретной цели:

• Начало проекта — предпроектная стадия, которая включает в себя идентификацию идеи проекта, разработку предварительного проекта, сбор команды по управлению проектом и планирование следующего этапа.
• Инициация проекта — подготовка стратегий управления рисками, качеством, коммуникациями и конфигурацией проекта, создание плана проекта и установка средств контроля проекта. Этот процесс выполняет менеджер проекта. Результат — проектная документация.
• Руководство проектом ― принятие ключевых решений стейкхолдерами и делегирование оперативного управления менеджеру проекта. Этот процесс не равен фактическому управлению проектом менеджером проекта.
• Управление границами стадии ― предоставление управляющему совету проекта информации для оценки успехов текущей стадии и утверждения плана следующей стадии с учётом экономической обоснованности.
• Контроль стадии ― переход проекта на следующий этап и отслеживание выполнения работы в рамках каждой стадии проекта, формирование отчётов о прогрессе, принятие решений по инцидентам и коррекция каких-либо действий в рамках реализации проекта.
• Управление разработкой продукта ― управление связью между менеджером проекта и менеджером команды при помощи формальных требований к приёмке, выполнению и поставке результатов проектной работы.
• Закрытие проекта ― завершение всех работ по проекту, документирование полученного опыта и официальное закрытие проекта. Признание достижения целевых показателей проекта или основания для досрочного прекращения проекта.

Для успешного прохождения обозначенных выше процессов проектная команда должна проработать 7 направлений — областей знаний:

• Бизнес-обоснование: оцениваем, стоит ли делать проект с коммерческой и стратегической точек зрения. Этот документ следует обновлять по мере продвижения проекта и поступления новых вводных.
• Организация: описываем роли и обязанности каждого участника проекта. На этой стадии определяется, кто принимает решения, управляет проектом, контролирует качество и другое.
• Управление качеством: фиксируем требования к качеству и то, как оно будет измеряться и поддерживаться на протяжении всего проекта.
• Планирование: подробно описываем, как и когда проект будет реализован, включая ресурсы, время и стоимость.
• Управление рисками: определяем риски проекта, их вероятность и влияние, а также стратегии управления ими.
• Управление изменениями: согласовываем действия участников проекта в случае изменения требований, обстоятельств или планов проекта.
• Прогресс: формулируем, как будет контролироваться и управляться прогресс проекта.

Методология PRINCE2 требует реализовывать проект в соответствии с 7 фундаментальными принципами:

• Постоянная оценка целесообразности проекта его заказчиком. Если потребность в проекте отпала, его нужно остановить.
• Учёт предыдущего опыта: постоянный анализ хода текущего проекта и других, использование извлечённых уроков.
• Чёткие роли и обязанности: формирование оргструктуры проекта, роли и уровень ответственности.
• Управление по стадиям: формулирование, планирование, осуществление и контроль на каждом этапе.
• Управление по исключениям: принцип, по которому представители каждого уровня управления осуществляют действия в рамках собственных полномочий, привлекая вышестоящий уровень только, если возникает серьёзная проблема, выходящая за пределы их компетенций.
• Фокус на продукте. Главная цель — конечный продукт и его качество, а также соответствие итогового продукта запланированному.
• Адаптация принципов методологии к внешним условиям — например корпоративным стандартам или оргструктуре. В целом подразумевается не жёсткий набор правил.

Вот как с помощью PRINCE2 можно реализовать проект разработки ПО ↓

1. Подготовка проекта

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

Формируем список ключевых участников проекта, включая разработчиков, дизайнеров, менеджеров магазина, представителей клиентов.

2. Разработка бизнес-кейса

Аргументированно объясняем, почему этот проект стоит реализовать. Бизнес-кейс может включать прогнозирование увеличения продаж, улучшения удовлетворённости клиентов или повышения эффективности работы сотрудников магазина.

3. Планирование

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

4. Инициация проекта

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

5. Управление стадиями

Разрабатываем и реализуем план для каждого этапа проекта. После завершения каждого этапа проводим проверку его результатов и при необходимости адаптируем планы для следующего этапа.

6. Контроль этапов

На протяжении каждого этапа проекта регулярно проверяем ход выполнения работ, управляем рисками и проблемами, убеждаемся, что проект продвигается в соответствии с планом.

7. Завершение проекта

Оцениваем результаты проекты, сравниваем их с ожидаемыми выгодами из бизнес-кейса и проводим анализ опыта, полученного в процессе работы над проектом, чтобы использовать его в будущих проектах.

Идеально для: больших и сложных проектов, особенно в государственном секторе и IT.

Когда использовать: когда проект сложный и требует высокого уровня контроля и организации.

Преимущества: хорошо структурированный, широко признанный. Формируются определённая структура команды проекта и зоны ответственности каждого участника. Методология требует детальной документации для успешной разработки продукта, гарантирует грамотное управление рисками, подходит для проектов в любой области.

Ограничения: может быть бюрократическим и негибким подходом, а также излишним для небольших проектов. Нет рекомендаций по конкретным инструментам для менеджеров, таких как диаграмма Ганта или канбан-карточки.

Ключевые элементы: бизнес-обоснование, определённая организационная структура команды управления проектом, подход к управлению рисками, подробная документация, управление по исключениям.

 Agile (2001)

Родом из мира разработки программного обеспечения, Agile является ответом на ограничения модели Waterfall. Манифест Agile написали 17 разработчиков, включая Джеффа Сазерленда и Кена Швабера, которые сформировали Scrum-метод. В манифесте создатели предлагают универсальный набор принципов, ведущих к улучшению процессов разработки проектов для любого направления деятельности и размера команды.

Что из себя представляет и как работает: методология Agile хорошо подходит для проектов, в которых некоторые детали с самого начала непонятны. Фокус на гибкости, сотрудничестве, удовлетворённости клиентов и высокое качество результатов.

Вместо линейного последовательного процесса проектирования в Agile используется итеративный подход и допускается смещение приоритетов от итерации к итерации. Работа разбивается на небольшие управляемые блоки — пользовательские истории — и выполняется короткими фазами продолжительностью 1–4 недели — спринтами.

При принятии решений Agile способствует частому общению и постоянной обратной связи с участием всех заинтересованных сторон — от членов команды до клиентов. Ежедневные стендапы проводятся для обсуждения прогресса и препятствий.

В основе Agile лежат 4 основные концепции, которые влияют на принцип и подход к управлению проектом:

• Люди и взаимодействие между ними важнее процессов и инструментов → отказ от формализма в пользу постоянной прозрачной и регулярной коммуникации между всеми заинтересованными сторонами, стремление к взаимопониманию.
• Работающий продукт или программное обеспечение важнее исчерпывающей документации → объём проектной документации сводится к необходимому минимуму на усмотрение команды, составление которого не сильно задерживает начало проекта. Например, верхнеуровневая диаграмма с архитектурой вместо детальной спецификации, если таковая на самом деле не нужна, или фиксирование достаточных требований в виде пользовательских историй. Главный принцип — создание документации в объёме, в котором она действительно нужна.
• Коллаборация c клиентами важнее формальной стороны отношений → это не означает, что контракт не важен, но смещает фокус с формализации сделки — когда составляется подробный контракт и обе стороны выполняют работу точно в соответствии с соглашением, даже если во время реализации возникли изменения — на перспективу сотрудничества, когда заказчик и команда разработчиков являются партнёрами, которые стремятся достигнуть общую цель, решая любые проблемы и обсуждая меняющиеся требования по мере их возникновения.
• Обязательное оперативное реагирование на изменение вместо следования плану → готовность к изменениям на любой стадии, оперативная подстройка проекта под меняющиеся нужды.

Идеально для: проектов разработки программного обеспечения или любого проекта с частыми изменениями и итерациями. Отлично подходит для проектов, где решающее значение имеют отзывы клиентов и постоянная перестройка и совершенствование на их основе.

Когда использовать: когда нужна гибкость и адаптируемость, особенно в быстро меняющихся условиях с неопределёнными или меняющимися требованиями. Или когда быстрое развитие технологий приводит к изменению требований.

Преимущества: очень гибкий и адаптируемый метод, позволяет сонастраиваться с целями и потребностями клиентов в течение всего цикла проекта.

Ограничения: менее предсказуем, требует плотного участия заказчика и команды на протяжении всего проекта. Может привести к расползанию масштаба (scope creep).

Ключевые элементы: итеративная разработка, самоорганизующиеся команды, сотрудничество с клиентами, постоянная обратная связь.