За годы нашей работы мы сталкивались со всеми основными методологиями разработки ПО. Мы применяли каждую из них по отдельности, старались совмещать разные методы, использовали лучшие стороны различных подходов, чтобы удовлетворить потребности заказчиков. В этой статье рассмотрели основные методологии и обозначили плюсы и минусы каждой.
Agile разработка позволяет вносить изменения на каждом этапе проекта, адаптировать проект под требования владельца продукта, снижать финансовые риски и быстро запускать продукт на рынок.
Например, компания-ритейлер запускает портал для интернет торговли. В начале запускается каркас продукта (страница с товарами и корзиной) и тестируется на реальных пользователях, разработка продолжается без остановок, добавляются страницы с обзорами товаров. Обратная связь от пользователей позволяет исследовать поведение клиентов на практике и тестировать новые гипотезы (на сколько вырастут показатели после изменения ключевых запросов).
После запуска продукта проводятся первичные рекламные кампании и отслеживаются результаты через веб-аналитику. На заключительном этапе дорабатываются успешные гипотезы и отсеиваются неудачные.
Гибкая модель предоставляет возможность начать разработку сразу после согласования бизнес-модели, общей стратегии и функциональных требований. Каждый день команда разработчиков и заказчик (product owner) обсуждают текущие действия, проблемы и будущие изменения. Новые идеи анализируются и сразу же внедряются.
Постоянное взаимодействие с владельцем продукта. Можно отследить подходит ли продукт рынку, что требуется изменить и сразу внести необходимые изменения.
Эффективность работы. Сотрудники сами принимают решения относительно основных элементов работы. Документы и инструменты не определяют работу команды. Все процессы и структуры максимально упрощены. Команда концентрируется только на самых важных приоритетах в развитии проекта.
Быстрое выявление и устранение ошибок. Все возможные проблемы выявляются на ранних этапах и тут же устраняются. Это также позволяет избежать проблем с несовпадением ожидаемого и реального результата.
Опасность затягивания сроков. Постоянная обратная связь может оттягивать завершение проекта. Необходимо всегда учитывать происходящие изменения и адаптировать дедлайны под новые задачи.
Сложно оценить конечную стоимость продукта. Все новые и новые итерации расширяют бюджет и не позволяют точно спрогнозировать финальную сумму.
Agile методология применяется в стартапах, где необходимо опередить конкурентов и выпустить продукт как можно быстрее, и в сфере новых технологий, где результаты разработки продукта нельзя предсказать заранее.
Например, когда банки обновляют программное обеспечение, они в первую очередь обсуждают все детали проекта вместе с представителями банка и разработчиками. Основная цель обсуждения — понять как пользователь будет взаимодействовать с системой. Разработчики прописывают каждую линию взаимодействия и тщательно подбирают функционал. Когда этот процесс завершен, все члены команды уже понимают, что от них требуется. На следующей стадии происходит написание кода и проверка на ошибки. На момент завершения проекта все поставленные цели уже достигнуты.
Подход к разработке ПО по методике Agile, который подразумевает открытость всех рабочих процессов и постоянное улучшение производительности. Каждый член команды выполняет индивидуальный набор задач.
Высокая концентрация на текущей работе. Команда фокусируется на конкретной задаче и направляет все усилия на ее решение. Приоритетность задач может меняться.
Быстрое устранение проблем. Все члены команды могут отслеживать прогресс и давать обратную связь, которая помогает оперативно исправлять ошибки.
Оптимизация издержек. Канбан позволяет анализировать и прогнозировать точное время, необходимое для реализации проекта.
Не удовлетворяет требованиям больших команд. Метод не предназначен для групп численностью больше 5 человек,и команд, где сотрудники не знают функции друг друга. В таких условиях невозможно эффективно контролировать реализацию проекта.
Модель управления разработкой с гибкой организацией работы внутри команды, направленной на создание новых сложных продуктов. Scrum позволяет развивать проект в тесном сотрудничестве с заказчиком, постоянно корректируя характеристики продукта и показывая результат на каждом этапе разработки.
Эффективное взаимодействие между участниками проекта. Процесс принятия решений полностью зависит только от членов команды. Все внутренние процессы регулируют сами разработчики. Это позволяет всем участникам проекта четко понимать свои функции и задачи.
Минимум контроля и фокус на постоянные обновления. Весь процесс разбит на 30-дневные периоды с ежедневными собраниями. Любые изменения происходят очень быстро и не требуют лишних затрат и издержек.
Высокая стоимость разработчиков. Результат сильно зависит от профессионализма команды. Сотрудники должны обладать способностями к самодисциплине и самоконтролю.
Нежелательное расширение проекта. Отсутствие единого контроля за реализацией проекта может привести к увеличению бюджетных трат.
Недостаток гибкости в больших проектах. Потеря даже одного члена команды станет серьезной проблемой и снизит эффективность реализации проекта. Scrum и Kanban применяются в большинстве Agile проектов.
Классическая поэтапная методология, в которой каждый следующий шаг начинается только после завершения предыдущего. В отличие от Agile каскадная модель не допускает изменений в этапах разработки.
Постоянный контроль процессов и предсказуемость. Цели и задачи проекта понятны для разработчиков и не вызывают дополнительных вопросов.
Оценка затрат и сроков до начала проекта. Все требования четко проговариваются на начальном этапе и не изменяются в течение всего процесса. Предсказуемость позволяет точно оценить будущие расходы.
Документация каждого этапа. Это позволяет создавать базу для других проектов и предоставлять отчетность заказчику в любое время.
Сложно исправить ошибки. Тестирование проходит только на последних этапах разработки, поэтому возможные недочеты необходимо предусмотреть заранее.
Отсутствие обратной связи от заказчика на протяжении большей части проекта. Заказчик принимает участие в обсуждении целей проекта и возвращается, чтобы оценить финальный результат, который может его полностью не удовлетворить.
Высокая стоимость исправлений. Любая ошибка приведет к необходимости переделывать весь проект. Избежать подобных проблем помогают сильные и дорогие бизнес-аналитики, которые способны точно перевести задачи бизнеса на ИТ язык.
Каскадная модель используется при реализации проектов по жизнеобеспечению, где любая ошибка может привести к фатальным последствиям. «Водопад» предпочитают также военные и воздушные организации, в которых необходимы строгие требования к выполнению проектов. Подобная модель может применяться при разработке программного обеспечения для дорожных светофоров. На начальном этапе проект необходимо согласовать с заказчиком и прописать всю документацию. После этого будет выбрана архитектура, создан код, проведено тестирование, осуществлена интеграция и проверка на ошибки. Каждый из этих этапов будет строго следовать один за другим.
Вид каскадной модели, в котором предусмотрено тестирование уже на ранних этапах реализации проекта. Модель приобрела особую популярность в сфере авионики (электронные системы на борту воздушного судна), где очень важно контролировать каждый отдельный шаг процесса разработки ПО.
Уменьшение рисков. Постоянное тестирование минимизирует возможность дорогостоящей ошибки.
Сокращение издержек. Цена всех стадий проекта легко прогнозируется и не изменяется.
Адаптивность для пользователей. V-модель четко фиксирует и реализует основные требования пользователей к разрабатываемому продукту.
Сложность исправления фундаментальных ошибок. Отсутствует конкретный механизм решения проблем, выявленных на этапе тестирования.
Недостаток гибкости в процессе разработки. Разработка начинается только после перехода к следующему этапу. Никаких предварительных шаблонов не предусмотрено. Это может затруднить понимание процесса для заказчика.
В сферах, где работа продукта не может быть остановлена. Например, разработка ПО для авиации представляет собой сложный документированный процесс, где каждый уровень тщательно прописывается и отслеживается любая ошибка. Тестирование начинается только после глубокого анализа требований, описанных в документах. Такой процесс занимает много времени и требует высокого уровня профессионализма от исполнителей.
RAD позволяет быстро получить нужный результат в короткие сроки. Это достигается с помощью постоянного взаимодействия с заказчиком, своевременных уточнений требований и анализа результатов. Такая модель может использоваться при разработке платформы для анализа и обработки заказов на покупку товара (purchase order). Быстрое создание первоначального прототипа обеспечивается с помощью тесного взаимодействия с департаментом закупок. После первого запуска необходимо сразу же познакомить пользователей с приложением. Это позволит выявить и исправить возможные ошибки и неточности.
Быстрое завершение проекта. Профессиональная команда, эффективные инструменты и создание прототипов обеспечивают высокую скорость реализации процесса разработки.
Минимальные бюджетные затраты. Элементы продукта разрабатываются и внедряются по отдельности. Это исключает ошибки, свойственные каскадной модели.
Вовлеченность заказчика. Заказчик становится активной частью проекта уже на ранних этапах разработки. Высокое качество. Оно обеспечивается за счет постоянного взаимодействия пользователей с будущими прототипами продукта.
Зависимость от заказчика. Заказчик и разработчики могут иметь разное представление о продукте.
Маленький и средний масштаб проектов. RAD сложно применить для больших проектов, где требуется усиленный контроль и нет возможности разделить процесс на маленькие части.
В проектах, где требуется закончить разработку в сжатые сроки. Так, когда финансовый отдел компании хочет получить удобную платформу для составления отчетов по командировкам, мы можем воспользоваться RAD методом. Вместе с сотрудниками компании мы создаем удобный прототип продукта и тут же тестируем его. Это позволяет всем пользователям быстро вносить изменения и улучшать платформу. Результатом такой разработки является значительное сокращение времени на обработку командировочных документов.
Удобная модель для анализа рисков. Идеально подходит для решения ключевых задач бизнеса, запуска нового продукта и проведения исследований.
Устранение рисков на ранних этапах реализации проекта. Этот шаг становится ключевым в данной модели.
Гибкость на всех этапах разработки. Возможность внесения изменений существует на протяжении всего проекта.
Длительная и дорогостоящая разработка. Спиральная модель требует больших временных и денежных затрат на осуществление основных принципов и привлечение квалифицированных специалистов.
Высокая зависимость результата от стадии анализа. Если на этом этапе будет допущена ошибка, то изменения проекта потребуют больших издержек.
В проектах, где необходимо анализировать большое количество рисков. Часто используется при разработке спутников и военных объектов.
Выбор только одной методики не гарантирует успешное завершение проекта. Заказчик должен учитывать различные аспекты продукта при выборе того или иного вида разработки. Мы иногда совмещаем различные подходы для достижения желаемых результатов. Каждая из перечисленных методологий имеет свое назначение и сферу применения. Наш опыт позволяет определять тип разработки, который подходит заказчику. Мы всегда готовы помочь в выборе оптимального подхода для решения задач вашего бизнеса.
