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

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

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

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

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

Agile

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

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

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

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

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

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

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

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

Недостатки:

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

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

Waterfall

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

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

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

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

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

Недостатки:

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

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

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

V-model

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

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

• уменьшение рисков. Постоянное тестирование минимизирует возможность дорогостоящей ошибки;
• сокращение издержек. Цена всех стадий проекта легко прогнозируется и не изменяется;
• адаптивность для пользователей. V-model четко фиксирует и реализует основные требования пользователей к разрабатываемому продукту.

Недостатки:

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

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

RAD

RAD, rapid application development model, или быстрая разработка приложений, — позволяет быстро получить нужный результат в короткие сроки. Это достигается с помощью постоянного взаимодействия с заказчиком, своевременных уточнений требований и анализа результатов.

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

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

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

Недостатки:

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

Spiral model

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

Вы запускаете систему «Умный дом», хотите реализовать управление бытовыми приборами с телефона и начинаете с телевизора. Команда разработки использует каскадную модель и представляет готовую версию продукта. Вы анализируете риски необходимости следующей версии (управление холодильником), рассчитываете сроки, бюджет и понимаете, что в холодильник нужно встроить вайфай-модуль, а производители не заинтересованы в сотрудничестве по этому вопросу. Риски превышают потенциальную выгоду, и вы останавливаете разработку, чтобы улучшать действующий функционал.

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

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

Недостатки:

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

Где применяют. В проектах, где необходимо анализировать большое количество рисков. Часто используется при разработке спутников и военных объектов.