В разных условиях и для разных проектов эффективны различные методологии разработки👨🏻💻. Ошибка в выборе методологии ведёт к удорожанию проекта и накладывает риски на качество конечного результата📊. Делайте свой выбор тщательно.
✅Итеративная разработка
Задача и ТЗ размыты. Мы не до конца понимаем, что предстоит разработать. Поэтому процесс ведётся итерациями — небольшими проектами по доработке: сбор, анализ и формализация требований, разработка, тестирование и внедрение. Получается такой непрерывный поток действий. От фазы к фазе. Есть риск в объёмах работы в рамках итерации. Больше всего подходит для продуктовой разработки.
✅Инкрементная модель разработки
Проект выполняется по этапам, каждый из которых представляет из себя инкремент. Разрабатываемая система разбивается на модули так, чтобы ей можно было пользоваться как можно скорее. Желательно, после реализации 1-го этапа, а последующие инкременты добавляют бизнес-ценность к «базовому» функционалу. Такой подход часто применяется при разработке больших и сложных систем. Хорошая возможность разделить весомую задачу на сравнительно небольшие модули.
✅Каскадная модель разработки (Waterfall)
Это модель, в которой процесс выглядит как поток последовательно проходящих фаз анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. В каскадной модели нет возможности сделать шаг назад и изменить требования. Всё известно заранее. Проектирование выполнено до начала разработки. Из плюсов — можно быстро провести разработку и тестирование за рассчитанный бюджет и в указанные сроки.
🔹Scrum
Популярная тема. По ней очень много всего написано. В такой методологии над проектом работают небольшие команды из специалистов разного профиля. Благодаря этому результаты более впечатляющие. Однако, как любая итерационная модель, Scrum скорее подходит к продуктовой разработке.
🔹Agile
Это не методология, а подход и манифест, где заявляются 4 ценности и 12 базовых принципов. Agile имеет смысл именно для продуктовой и итеративной разработки. Да, можно провести проект, но для этого потребуется «мотивированный профессионал» в ведении проектов, которого достаточно сложно найти.
🔹Kanban
Нет, это не тот Канбан, что был у Тойота в 1962 году. Канбан — это не методология, а средство визуализации. Успешно применяется в любой методологии разработки. Не смотря на свою простоту, всё же подходит для поддержки продуктов маленькими командами и разбора инцидентов.
Напомним, что ошибка в выборе методологии ведёт к удорожанию проекта и накладывает риски на качество конечного результата. Подходите к выбору осознанно.
