Что стоит за названиями: RAD-модель, SCRUM, Канбан, экстремальное программирование, спиральная модель? Какая модель лучше подойдёт для вашего проекта, даже если он не в ИТ?

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

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

«RAD Model» или быстрая разработка приложений

Является разновидностью итертивной модели. Здесь несколько команд параллельно разрабатывают отдельные компоненты продукта. В дальнейшем эти разработки объединяются в единый рабочий прототип. Модель ориентирована на быструю разработку и предоставление заказчику рабочего продукта для получения обратной связи и внесения изменений в проект. Разработка каждого модуля жестко ограничивается по времени.

В каком случае использовать
● Наличие высококвалифицированных узких специалистов
● Есть четкое представление о бизнес-процессах заказчика
● Требуется срочная разработка в короткие сроки

SCRUM

Метод представляет собой фреймворк для управление проектами ориентированный на итеративный подход и основан на принципах Agile. Ставится цель проекта, процесс разбивается на отдельные итерации (спринты) продолжительностью от 1 до 4 недель. В результате каждого из спринтов получается рабочая модель продукта. Спринты, в свою очередь, формируется как выборка определенных задач из общего списка (бэклог).

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

Команда по методологии состоит из следующих ролей.
● Заказчик. Лицо, инициирующее и оплачивающее разработку.
● Владелец продукта. Представитель со стороны заказчика, который отвечает за бэклог и расстановку приоритетов отдельных задач. Находится в
● постоянной связи с Заказчиком и пользователями, а также осуществляет коммуникацию с рабочей группой.
● Scrum-мастер. Менеджер, отвечающий за эффективность всей команды, решающий возникающие сложности в процессе разработки. Задача scrum-мастера заключается в том, чтобы команда понимала методологию и ожидание заказчика, работала в рамках процесса. Также данная роль подразумевает связь между заказчиком и командой.
● Разработчики. Сама команда, которая осуществляет разработку продукта. Сюда могут входить программисты, дизайнеры, тестировщики, контент-менеджеры и другие.

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

Kanban или «канбан-доски»

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

Канбан-доска состоит из:
● Столбцы. Здесь представлены основные циклы работы. Например, «Хотим сделать», «Анализ», «Реализация», «Тестирование», «Готово»
● Карточки. Сами задачи, которые продвигаются по столбцам в зависимости от своего статуса
● Лимит незавершенных задач. Лимит на количество задач в каждой колонке (за исключением итогового столбца). Это позволяет грамотно распределить нагрузку на команду и избежать перегруза.
● Поток. Карточки задачи проходят каждый из этапов до финальной стадии

Метод прекрасно интегрируется с другими, повышая эффективность процессов. Например, можно использовать комбинированную модель SCRUM и Kanban.

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

Если нет жесткой привязанности к конкретным срокам.

«Extreme Programming» или «Экстримальное программирование»

Является одной из методик Agile, ориентированная на оптимизацию кода, сокращение времени разработки и постоянном взаимодействии с Заказчиком.

Для понимания специфики подхода можно обратиться к основным принципам данного метода:
1. Парное программирование. Суть заключается в том, что программисты работают вдвоем на одном компьютере. Так, один программист пишет код, а второй наблюдает за его частотой и правильностью, предлагая свои идеи.
2. Планирование всеми участниками процесса. Так в планировании задействована как команда разработчиков, так и сам клиент. Это позволяет обеспечить информированность всех участников и наиболее объективный подход.
3. Участие заказчика в тестах. Заказчик может обращать внимание, на чем следует сделать акцент, и что следует протестировать. Это позволяет получать более быстрые согласования.
4. Быстрые релизы. Еженедельные согласования позволяют понять, что работа идет в соответствии с намеченным планом.
5. Простота дизайна. Избежание лишних сложностей ускоряет процессы и позволяет добиваться эффективности при минимальных сложностях.
6. Сначала тесты, потом код. Прежде чем реализовывать какую-то часть составляются критерии, по которым будет тестироваться результат.
7. Коллективное владение кодом. Каждый из членов команды способен работать с кодом своего коллеги.
8. Постоянное улучшение кода. После завершения каждого этапа вся команда просматривает код. Его можно оптимизировать без изменения функционала.
9. Планирование реального списка задач. Команда определяет список задач для итерации, которые точно смогут выполнить. Это позволяет избежать перегрузок.
10. Единые стандарты. Процесс происходит по единому обговоренному стандарту, что помогает минимизировать ошибки и избежать недопониманий.
11. Единый язык. Команда описывает отдельные элементы, использует единую терминологию для лучшего понимания.
12. Постоянная выгрузка в общую базу. Команда может выявить ошибку на ранней стадии и исправить ее.

Данный подход имеет множество преимуществ, как скорость разработки, ее качество, прозрачность процесса и гибкий подход к меняющимся требованиям. Чтобы метод работал эффективно нужно четко понимать условия, при которых он сможет быть таковым. Необходимо, чтобы Заказчик был готов принимать активное участие в процессе. Метод эффективен в небольших командах (до 10-12 человек). Команда должна быть дисциплинирована и слажена, чтобы метод был эффективен.

В каком случае использовать
● Если нет конкретных требований в проекте, либо они постоянно меняются.
● Если в процессе задействована небольшая команда (от 2 до 12 человек), так как коллективное владение кода сложно масштабировать на большие группы.
● Если выставляются высокие требования к качеству кода.
● Если требуется быстрый запуск MVP-версии продукта.
● Если клиент готов принимать активное участие в проекте.

«Spiral Model» или «спиральная модель»

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

Модель состоит из этапов:
● Планирование
● Анализ рисков
● Конструирование
● Оценка результата. В случае успеха переход к следующему витку

В каком случае использовать
● В больших проектах
● Если требования к проекту сложные
● Предполагаются серьезные изменения в проекте на стадии разработки

В заключение

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

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