🔀 SDLC модели: как выбрать правильный подход к разработке и не завалить проект
В этой статье Вадим Кулага, проектный менеджер EPAM Anywhere, расскажет об основных моделях разработки программного обеспечения (SDLC), их плюсах и минусах, а также о реальных примерах их использования.
Более половины ИТ-проектов заканчиваются провалом. Одни из самых распространенных причин неудач ИТ-проектов – неправильная интерпретация бизнес-целей, игнорирование клиентов, неправильная расстановка приоритетов. Но у всех у них общий корень проблемы: неправильный подход к разработке программного обеспечения.
Основные методологии разработки ПО
Методология разработки программного обеспечения (SDLC) представляет собой последовательность действий, которые необходимо выполнить, чтобы получить готовое решение. Проще говоря, это способ создания программного продукта. Проблема в том, что существует множество моделей SDLC, которые используются для разных типов проектов. Как узнать, какой из них подходит для вашего проекта? В статье я перечислил наиболее популярные модели SDLC, их варианты использования, преимущества и недостатки.
Каскадная модель (waterfall)
Это линейная и последовательная модель разработки программного обеспечения, в которой фазы проекта следуют одна за другой и включают:
- Исследование. Группа разработчиков собирает требования к проекту и включает их в документ «Спецификации требований к программному обеспечению» (SRS).
- Дизайн. Команда анализирует все требования и выкатывает прототип системы.
- Кодирование. Как только заинтересованные стороны проекта согласовывают прототип, начинается фаза написания кода.
- Тестирование. Команда QA запускает каждый модуль через различные сценарии тестирования и интегрирует их в систему. Как только все компоненты на месте, они тестируют систему целиком.
- Развертывание. Решение доставляется заказчику в полностью рабочем состоянии.
- Обслуживание. Команда разработчиков следит за проектом и при необходимости вносит обновления.
Плюсы и минусы подхода
| Плюсы | Минусы |
| Простая в использовании модель. | С этой моделью слишком сложно и дорого адаптироваться к изменениям требований. |
| Каждый этап хорошо задокументирован. | Документирование каждой фазы проекта занимает много времени. |
| Результат проекта абсолютно предсказуем. | Вы не можете ничего предоставить заказчику, пока не завершите весь проект. |
| Этапы и роли четко определены с самого начала. | Различные команды (дизайн, разработка, контроль качества и т. д.) изолированы, а взаимодействие между ними ограничено. |
| Минимальное вмешательство клиента. | Без обратной связи клиента результат рискует не оправдать ожидания. |
Каким проектам подходит
Каскадная модель – хороший вариант, если выполняются эти условия:
- Проект короткий и с нулевым риском.
- Требования фиксированные.
- Технологии стабильны.
- Доступны все необходимые ресурсы.
Всего десять лет назад многие компании использовали каскадную модель для разработки корпоративного программного обеспечения, включая CRM, системы управления цепочками поставок и системы точек продаж. Но сегодня эта модель не может удовлетворить быстро меняющиеся технические потребности. Вот почему компании все чаще обращаются к более современным подходам.
V-образная модель SDLC
V-образная модель – это своего рода другая версия каскада, но в её основе лежит контроль качества каждой фазы. Например, когда группа разработчиков собирает требования к проекту, QA-специалисты пишут приемочные тесты на основе этих сценариев. Точно так же на этапе проектирования системы создаются сценарии тестирования и так далее. После написания кода команда QA проверяет продукт на соответствие заранее написанным тестам (правая часть буквы «V»).
| Плюсы | Минусы |
| Легко реализовывать. | В V-образной модели внести изменения в середине проекта крайне сложно. |
| Тест-кейсы создаются заранее. | При таком большом количестве процедур тестирования остается меньше времени на код. |
| Бюджет и продолжительность проекта предсказуемы. | По сравнению с каскадной эта модель требует больше специалистов. |
| У каждого этапа есть свои результаты, и все хорошо задокументировано. | Модель не подходит для проектов с быстро меняющимися требованиями. |
| Это структурированный подход с четко определенными ролями и функциями. | Не подходит для больших и сложных проектов. |
Каким проектам подходит
V-образная модель может быть чрезвычайно полезна в случаях, когда ошибки могут быть фатальными, и в проектах, где точность имеет решающее значение. Например, это решение, основанное на нормативных требованиях, таких как подача налоговых деклараций. Кроме того, эта модель подходит для проектов в сфере здравоохранения. Например, компания Roche Diagnostics однажды использовала его для разработки системы диагностики рака.
Модель эволюционного прототипирования
Это ещё одна вариация каскада. Пока проект проходит через традиционные фазы, прототип продукта пошагово дорабатывается на основе отзывов клиентов. Как правило, первый прототип не проходит приемочный тест, поэтому модель прототипирования включает в себя несколько прототипов. Только после того, как предложенный дизайн продукта будет полностью принят, команда разработчиков сможет перейти к следующим этапам.
| Плюсы | Минусы |
| Получение отзывов пользователей на ранних этапах. | Поскольку прототипы могут развиваться бесконечно, планирование проекта невозможно. |
| Высокие шансы на успех проекта. | Разрабатывать несколько прототипов – дорого. |
| Легко адаптироваться к быстро меняющимся требованиям. |
Каким проектам подходит
Модель эволюционного прототипирования может быть полезна для проектов, которые предполагают взаимодействие с пользователем, используют новые технологии, имеют сложную функциональность или должны учитывать быстро меняющиеся требования, которые трудно или невозможно предсказать.
Итеративная и инкрементальная модель
В инкрементальной и итеративной модели решение разрабатывается небольшими частями через серию циклов. Рабочий процесс выглядит следующим образом:
- Планирование. Собираются все требования к проекту и делятся на составляющие.
- Реализация модулей. Каждая итерация представляет собой «мини-каскад», который имеет такой же процесс: анализ требований модуля, проектирование, реализация и тестирование модулей, интеграция и тестирование всей системы, выпуск версии и оценка. Процесс повторяется до тех пор, пока не будут выполнены все требования.
| Плюсы | Минусы |
| Модель инкрементальной и итеративной разработки обеспечивает быструю и регулярную «доставку» работающего программного обеспечения клиентам. | Во время интеграции модуля могут возникнуть архитектурные проблемы. |
| Легче и дешевле учесть изменения в требованиях проекта. | Несмотря на некоторую гибкость, систему следует планировать с самого начала; в противном случае его нельзя разделить на модули. |
| Обратная связь от клиента на ранней стадии. | Участие клиентов может быть проблематичным. |
| Небольшие части программного обеспечения легче тестировать и исправлять. | Не всегда можно разбить систему на сегменты. |
| Экономия на издержках. | Хотя выпуск одного модуля дешевле, общие затраты на систему будут увеличиваться по мере интеграции новых модулей. |
Каким проектам подходит
Модель будет эффективна в следующих случаях:
- Если система состоит из нескольких сегментов с чёткими требованиями.
- Ограниченные ресурсы на проекте или есть ограничения по времени выхода решения на рынок.
- Для стартапов, проходящих инвестиционные раунды.
- Масштабные проекты.
- Проекты, в основе которых новые технологии.
- Проекты, которые потребуется развивать после выпуска.
По словам Алистера Скотта, каждый программный продукт, который хочет оставаться конкурентным на рынке, требует наращивания мощностей. Даже если вы будете использовать каскадную модель для разработки своего решения, к моменту завершения цикла решение уже устареет. Поэтому необходимы дополнительные итерации.
Спиральная модель
Этот подход основан на оценке риска, он сочетает в себе функции каскадной, прототипной, итеративной и инкрементной моделей. Модель похожа на спираль с несколькими кругами. Каждый круг – это фаза, состоящая из четырёх элементов:
- Сбор требований. Он включает выявление и анализ потребностей заинтересованных сторон и бизнес-целей.
- Анализ рисков и прототипирование. Команда оценивает все возможные способы удовлетворения потребностей клиентов и выбирает лучшее решение. Затем они выявляют и устраняют риски, связанные с решением, и создают прототип, который развивается с каждым последующим циклом.
- Инжиниринг. Команда инженеров продолжает разработку и тестирование того, что было запланировано на двух предыдущих этапах.
- Планирование следующего этапа. Готовый продукт отправляется заказчику для получения обратной связи. Кроме того, команда разработчиков анализирует весь цикл с точки зрения расписания, бюджета и других критериев.
Затем, на основе отзывов пользователей и заинтересованных сторон, планируется следующая итерация.
Как видите, продукт неоднократно проходит через эти этапы, и в конце каждого цикла создаётся и выпускается лучшая версия продукта. И, как и в итеративном подходе, продукт состоит из серии релизов.
| Плюсы | Минусы |
| Анализ рисков на каждой итерации увеличивает шансы проекта на успех. | Требуется опыт управления рисками. |
| Этот метод позволяет создавать стабильные и надёжные системы, поскольку они тщательно тестируются в каждом цикле. | Модель подразумевает работу с большим объёмом документации. |
| Можно менять требования между циклами. | Нельзя изменить требования в середине цикла. |
| Раннее вовлечение разработчиков помогает согласовать бизнес-требования и технические возможности. | Каждый кружок в спирали развития представляет собой «мини-каскад», а это значит, что вы не можете пропускать фазы. |
| Частые выпуски позволяют получать регулярную обратную связь от клиентов даже на ранних этапах цикла. | Поскольку ограничений на количество итераций нет, сложно предсказать, сколько кругов потребуется для создания окончательной версии продукта. |
Каким проектам подходит
Спиральная модель подходит для:
- Больших, сложных продуктов, состоящих из нескольких компонентов.
- Проектов с частыми релизами.
- Проектов средней и высокой степени риска.
- Проектов с неясными требованиями.
Microsoft, IBM и Tata Consultancy используют спиральную модель.
Модели гибкой разработки программного обеспечения
Вопреки распространённому мнению Agile не является ни структурой, ни методологией. Это философия с набором принципов, ориентированных на ускорение процесса разработки программного обеспечения, обеспечение 100% удовлетворённости клиентов и предоставление высококачественных решений в быстро меняющейся среде. Фактически, существует 12 принципов гибкой разработки, которые сводятся к следующим ценностям:
- Люди и взаимодействие важнее процессов и инструментов.
- Рабочее программное обеспечение над обширной документацией.
- Сотрудничество с клиентами вместо переговоров по контракту.
- Реагирование на изменения вместо следования плану.
Ценности Agile породили более 50 методологий, из которых Scrum является самой популярной.
Scrum
Скрам-проекты разбиты на спринты. Спринт – это небольшой объём работы, который необходимо выполнить в течение определённого периода времени. Обычно заказчику доставляется часть проекта, которая была завершена во время спринта (инкремент продукта, от англ. increment). Скрам подразумевает активное общение и сотрудничество между всеми участниками проекта. Наряду с ежедневными 15-минутными встречами разработчиков, есть также:
- Планирование спринта, когда заинтересованные стороны проекта и команда разработчиков встречаются, чтобы обсудить, что нужно сделать во время следующего спринта.
- Обзор спринта, когда команда разработчиков демонстрирует заинтересованным сторонам, что было сделано во время спринта, и анализируется прогресс в достижении цели проекта.
- Ретроспектива спринта, когда команда разработчиков анализирует спринт и обсуждает, как можно улучшить процессы во время следующих спринтов.
Сердце процессов Scrum – это backlog, своего рода список задач, которые необходимо сделать для завершения проекта. По мере того, как проект продвигается, и команда узнаёт о нём больше, они редактируют бэклог продукта, добавляя, удаляя и переупорядочивая его элементы. Тем не менее, нельзя сделать что-то, если этого нет в очереди продукта.
Но на самом ли деле всё так гладко и красиво в Agile? Посмотрим на его основные варианты использования, а также на плюсы и минусы.
| Плюсы | Минусы |
| Не нужно ждать завершения проекта, чтобы внедрить основные функции продукта. | Гибкие методологии разработки ПО сложно внедрить. |
| Кросс-функциональные команды регулярно общаются и обмениваются знаниями между собой и владельцами проектов. | В Agile проектная документация очень быстро устаревает, поэтому понадобятся дополнительные навыки оперативной работы с ней. |
| Возможность адаптироваться к изменениям на любой стадии проекта. | В Agile проектах практически невозможно делать прогнозы и достаточно тяжело с высокой долей точности планировать бюджет. |
| Регулярная обратная связь от пользователей, что позволяет удовлетворить все потребности. | Сбор отзывов пользователей может быть сложной задачей. |
Примеры использования
Большинство современных проектов требуют определённого уровня «маневренности», особенно когда:
- Требования к проекту недостаточно ясны.
- Требования к проекту постоянно меняются.
- Проект включает в себя множество взаимодействий с пользователем.
- У проекта много заинтересованных сторон.
В общем, Agile кажется именно тем, что нужно большинству проектов во времена неопределённости. Неудивительно, что более 70% компаний применяют Agile, включая Microsoft, IBM, Procter & Gamble и другие. И EPAM не исключение.
Резюме
Ни одна из моделей SDLC не является «волшебной пилюлей». Нельзя просто выбрать методологию, которая соответствует потребностям проекта, и слепо следовать ей. В лучшем случае это не улучшит ваш процесс разработки. В худшем вы подвергнете риску проект. Вот почему грамотный подход к выбору и реализации модели разработки программного обеспечения является ключом к тому, чтобы заставить её работать на вас.
Вот несколько советов как подходить к разработке на примере реального проекта EPAM Anywhere:
- Не ограничивайте свой проект одной методологией. Мы комбинируем несколько подходов SDLC в зависимости от текущих потребностей и типа процесса. Для разработки мы используем некоторые практики Scrum, в то время как Kanban хорошо подходит для осуществления дальнейшей поддержки.
- Используйте технические средства для сбора отзывов пользователей. Регулярный сбор отзывов пользователей и их использование для внесения улучшений необходимы проекту, который предполагает много взаимодействий с пользователем. Мы используем Hotjar, чтобы быть в курсе того, как люди взаимодействуют с нашим продуктом. Кроме того, мы постоянно просматриваем сообщения, поступающие из нашей формы обратной связи, чтобы лучше понять, с какими трудностями сталкиваются люди при использовании EPAM Anywhere.
- Пользователем вашего продукта может быть кто-то из ваших знакомых. Некоторые из наших разработчиков пришли к нам через EPAM Anywhere, что означает, что они испытали этот продукт самостоятельно. Это делает их ценным источником обратной связи с пользователями из первых рук.
- Сотрудничайте. Мероприятия по планированию Scrum, ежедневные и другие встречи – это то, что мы делаем регулярно одним составом. Но на встречи по бизнес-анализу, на которых демонстрируется ранний прототип и обсуждаются бизнес-особенности, мы привлекаем наших технических руководителей. Это позволяет нам держать команду в курсе того, с какими задачами они могут столкнуться позже.
- Поделитесь своими знаниями. У нас есть база знаний, доступная каждому, кто участвует в проекте. И она регулярно обновляется по мере развития проекта.
- Позаботьтесь о ваших удалённых участниках проекта. Личное общение – краеугольный камень любого Agile-проекта. Убедитесь, что они понимают цели проекта и участвуют во всех процессах.
- Создавайте небольшие команды. Платформа EPAM Anywhere обслуживается более чем 50 сотрудниками. Чтобы избежать «суеты» внутри проекта, мы разделили их на небольшие команды по 5-7 человек. В результате наши встречи по планированию спринта занимают не более 30 минут.