Отличное практическое пособие по agile-управлению проектами для всех и каждого!

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

Agile относится к любому процессу, который соответствует концепциям Agile Manifesto (манифест). В 2001 году 17 разработчиков программного обеспечения встретились, чтобы обсудить простые и эффективные методы разработки. Они опубликовали Манифест Agile Software Development, в котором рассказали о том, как они нашли "лучшие способы разработки программного обеспечения, применяя их самостоятельно и помогая делать это другим".

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

Цикл Agile

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

Анализ требований: Ключевые заинтересованные стороны и пользователи встречаются для определения бизнес-требований, которые являются количественно измеримыми, релевантными и подробными.

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

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

Имплементация или разработка: Разработка функций и планирование итераций для развертывания.

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

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

Преимущества Agile подхода

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

Быстрая реализация

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

Гибкость и принятие изменений

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

Преодоление неясности (Ambiguity)

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

Управление рисками

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

Прочное взаимодействие в команде

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

Методологии Agile

Существует ряд конкретных методологий для внедрения agile. Мы опишем только две из наиболее часто используемых agile-методологий: Scrum и Kanban. Другие методы: экстремальное программирование (XP), Feature-Driven Development (FDD, итеративная методология разработки), Adaptive System Development (ASD, Адаптивная разработка ПО), Dynamic Systems Development Method (DSDM, Метод разработки динамических систем), Lean Software Development (LSD, Бережли́вая разработка ПО) и Crystal Clear (легковесная гибкая методология).

Методология Scrum

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

Этапы Scrum-процесса:

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

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

  3. Ежедневные собрания Scrum: Это 15-минутное совещание, которое должно проходить ежедневно в одно и то же время и в одном и том же месте в течение спринта. Каждый человек в команде должен ответить на 3 вопроса: 1. Что вы сделали вчера? 2. Что вы собираетесь сделать сегодня? 3. Нужна ли вам помощь или существуют ли какие-то препятствия в работе?

  4. Собрание по итогам спринта: В конце каждого спринта команда представляет выполненную работу в виде реальной, рабочей демонстрации. Также в конце каждого спринта команда обсуждает, насколько хорошо Scrum работает для них, и предлагает изменения, которые необходимо внести в следующий спринт. Эта встреча называется "Ретроспектива спринта".

Методология канбан

Канбан в переводе с японского означает "визуальный знак". Это визуальная структура, используемая для внедрения Agile и показывающая, что производить, когда производить и сколько производить. Она поощряет небольшие, постепенные изменения в вашей текущей системе и не требует определенной установки или процедуры, что означает, что вы можете наложить Kanban поверх существующих рабочих процессов.

Kanban доска

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

Макет доски Kanban
Макет доски Kanban

Доска Kanban состоит из различных строк или столбцов. Самые простые доски имеют три колонки: “Выполнить”, “В процессе” и “Выполнено”. Они также могут состоять из столбцов "Бэклог", "Готов к разработке", "Разработка кода", "Тестирование", "Одобрено" и "Выполнено".

Основные практики Kanban

Каждый проект Kanban должен соответствовать этим основным принципам и практикам:

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

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

Незавершенная работа (WIP) определяет минимальный и максимальный объем работы для каждого столбца доски или для каждого рабочего процесса. Установив лимит на WIP, вы можете увеличить скорость и гибкость и уменьшить необходимость в определении приоритетов задач.

Четко сформулируйте принципы работы: Все должны понимать, как все работает или что считается " выполненным". Внесите изменения в доску, чтобы сделать эти процессы более понятными.

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

В моей следующей статье об управлении проектами по методике agile мы обсудим ключевые различия между Scrum и Kanban и то, как использовать один из них или сразу оба метода с пользой для себя.


Скоро состоится открытое занятие "Как сделать ретроспективу в Agile полезной?". Разберём популярные заблуждения о ретроспективах и поговорим про набор полезных практик, чтобы команда радостно ждала нового ретро. Проведем очень иллюстративное упражнение для углубления понимания. Бонусом поговорим про более олдскульные практики проектного управления, которые помогут управлять ожиданиями. Регистрация открыта по ссылке.

Комментарии (1)


  1. maxmydoc
    12.01.2023 11:48

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

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

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

    Agile как набор правил очень крутой для разработчиков чего угодно. Но это не решение всех бед. Иначе бы Siemens и многие крупные немецкие разработчики тоже бы хотели в гибкость, но нет.