Какие бывают гибкие методологии разработки

В начале появилось бережливое производство Lean, из которого развились гибкие методологии управления проектами Agile. В статье расскажем, что это за подходы, а также в деталях рассмотрим Scrum, Kanban и Extreme Programming.

Agile и Waterfall

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

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

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

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

Рассмотрим на примере, как может выполняться ИТ-проект по методике Waterfall:

1. Сначала команда совместно с заказчиком определяет подробное техзадание. Изменения требований в ходе выполнения проекта не приветствуются.
2. Затем специалисты полностью разрабатывают продукт и передают готовый код тестировщикам. Продукт новый, поэтому разработчики не могут заранее предусмотреть, как будет работать код.
3. Тестировщики проверяют программу, составляют список дефектов и отправляют разработчикам на исправление. Если одна из ошибок допускается на ранних стадиях разработки, специалистам приходится переделывать задачи.
4. После нового тестирования продукт передают команде внедрения, потом на поддержку.
5. Заказчик получает готовый проект. Результат может не удовлетворять его потребности. Допустим, за полгода разработки бизнес-процессы компании изменились, и продукт уже не соответствует ситуации.
6. Заказчик формулирует новые требования, чтобы доработать программу, и процесс начинается заново.

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

Agile и бережливое производство

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

Цель Agile и Lean совпадает — дать максимальную ценность заказчику, получить результат с минимальными усилиями. Это достигается изменением подходов на многих уровнях. Например:

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

Идеология Lean по сути не является методологией, поскольку не декларирует конкретные практики и инструкции. Это делает бережливый подход универсальным, подходящим для применения в любой области. Например, для производств на базе концепции были разработаны методы организации производственных процессов TPS — Toyota Production System. А Agile — это методология, которая конкретизирует философию бережливого производства по отношению к разработке программных продуктов с помощью различных фреймворков, например, Scrum, Kanban, XP и др. Таким образом, Lean ― это основа гибкого подхода.

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

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

Суть гибких методик

Гибкие методологии опираются на итеративный подход, когда большая задача (проект) делится на итерации — небольшие этапы и задачи. В рамках итерации повторяется полный цикл поэтапной разработки ПО: проводится обследование, выполняется запланированный объем работ, выпускается релиз и собирается обратная связь от клиентов. Данные, полученные с оценки рыночных тенденций, используются в следующей итерации, а в разработке участвует вся команда.

Гибкая модель управления позволяет избежать рисков, характерных для Waterfall. При Agile заказчик постоянно тестирует продукт на практике и обсуждает с командой требования. Любые изменения можно быстро внедрить, последствия ошибок невелики, потому что выявляются на ранних стадиях. Сроками выполнения проекта можно гибко управлять с учетом внедрения изменений. Команда вовлечена и мотивирована, рутина отсутствует.

При этом в финале может получится совсем не то, что планировалось изначально. Сроки и бюджеты могут увеличиться (или уменьшиться), т. к. зависят от требований заказчика. Клиент не сможет передать требования разработчику и «забыть» о проекте до внедрения. Без готовности заказчика уделять время проекту Agile не работает.

Каждая итерация проекта включает все этапы разработки: от обследования и формулирования требований до тестирования релиза

Scrum

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

Как организован процесс. В основе разработки по Scrum лежат спринты — короткие повторяющиеся итерации длительностью от 14 до 30 дней. Продолжительность спринтов в рамках проекта фиксированная. Например, команда выпускает релизы каждые 3 недели.

Цикличность при итеративном подходе в Scrum

В рамках Scrum используются два бэклога:

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

Бэклог спринта формируется из самых приоритетных задач бэклога продукта.

Команда проекта обычно состоит из специалистов разного профиля. Участники ежедневно собираются на Scrum-митинги или стендапы — 15-минутные встречи для синхронизации задач.

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

На доске можно разместить бэклог спринта и получать наглядное представление о готовности

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

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

Kanban

Определение. Kanban — способ организации работы команды по принципам Agile с помощью Kanban-доски. Суть этой методики в непрерывном внесении небольших изменений и выпуске релизов.

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

Доска разлинована на столбцы в соответствии с этапами выполнения. Например, «Новое», «В работе», «Готово». Также на доске могут быть горизонтальные строки, соответствующие пользователям, проектам и т. п. Количество задач, которое одновременно может находиться в одном столбце, лимитировано и зависит от ресурсов команды. Неограниченное количество задач можно размещать только в столбце «Новое».

Сотрудник заканчивает выполнять задачу, перемещает соответствующую карточку в столбик «Готово» и берет новую задачу в работу из столбика «Новое». При этом сотруднику не нужно что-то планировать и расставлять приоритеты: закончил задачу, взял с доски новую. Таким образом, процесс выполнения задач непрерывный и напоминает конвейер, нагрузка равномерно распределяется по участникам команды.

На Kanban-доске можно размещать задачи для команды проекта и отслеживать их выполнение

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

Пример. Команда разрабатывает сайт компании. На доске размещены карточки с задачами: создание главной страницы сайта, разработка раздела «О компании», «Продукты и услуги» и т. п. Участники команды берут в работу задачи, выполняют их и сразу внедряют изменения на сайте. Прогресс проекта наглядно виден на доске. Также с ее помощью можно узнать, что еще нужно сделать.

Экстремальное программирование, XP

Определение. Экстремальное программирование — еще одна из методологий на базе Agile, фокусирует команду на создании качественного программного обеспечения и оперативном внесении изменений.

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

Планирование — обязательный этап в начале каждой итерации. Команда разрабатывает ПО строго в соответствии с требованиями заказчика, ничего не добавляя «от себя». Над кодом работает пара специалистов: один пишет код, другой проверяет и представляет альтернативную точку зрения. Код постоянно тестируется и проверяется полностью. Продукт обновляется непрерывно за счет частого выпуска релизов с небольшими изменениями. Фокус на тестировании и проверке качества кода позволяет выпускать качественное ПО в короткие сроки. Результат проекта предсказуемый, а процесс — прозрачный.

Так выглядит процесс планирования в экстремальном программировании

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

К выводам

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

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

Что еще интересного