какой метод чаще всего применяется для разработки программного обеспечения
Какую методологию разработки выбрать для вашего проекта
За годы нашей работы мы сталкивались со всеми основными методологиями разработки ПО. Мы применяли каждую из них по отдельности, старались совмещать разные методы, использовали лучшие стороны различных подходов, чтобы удовлетворить потребности заказчиков. В этой статье рассмотрели основные методологии и обозначили плюсы и минусы каждой.
Agile (Гибкая модель разработки)
Agile разработка позволяет вносить изменения на каждом этапе проекта, адаптировать проект под требования владельца продукта, снижать финансовые риски и быстро запускать продукт на рынок.
Например, компания-ритейлер запускает портал для интернет торговли. В начале запускается каркас продукта (страница с товарами и корзиной) и тестируется на реальных пользователях, разработка продолжается без остановок, добавляются страницы с обзорами товаров. Обратная связь от пользователей позволяет исследовать поведение клиентов на практике и тестировать новые гипотезы (на сколько вырастут показатели после изменения ключевых запросов).
После запуска продукта проводятся первичные рекламные кампании и отслеживаются результаты через веб-аналитику. На заключительном этапе дорабатываются успешные гипотезы и отсеиваются неудачные.
Гибкая модель предоставляет возможность начать разработку сразу после согласования бизнес-модели, общей стратегии и функциональных требований. Каждый день команда разработчиков и заказчик (product owner) обсуждают текущие действия, проблемы и будущие изменения. Новые идеи анализируются и сразу же внедряются.
Преимущества
Постоянное взаимодействие с владельцем продукта. Можно отследить подходит ли продукт рынку, что требуется изменить и сразу внести необходимые изменения.
Эффективность работы. Сотрудники сами принимают решения относительно основных элементов работы. Документы и инструменты не определяют работу команды. Все процессы и структуры максимально упрощены. Команда концентрируется только на самых важных приоритетах в развитии проекта.
Быстрое выявление и устранение ошибок. Все возможные проблемы выявляются на ранних этапах и тут же устраняются. Это также позволяет избежать проблем с несовпадением ожидаемого и реального результата.
Недостатки
Опасность затягивания сроков. Постоянная обратная связь может оттягивать завершение проекта. Необходимо всегда учитывать происходящие изменения и адаптировать дедлайны под новые задачи.
Сложно оценить конечную стоимость продукта. Все новые и новые итерации расширяют бюджет и не позволяют точно спрогнозировать финальную сумму.
Подходит для новых технологичных проектов
Agile методология применяется в стартапах, где необходимо опередить конкурентов и выпустить продукт как можно быстрее, и в сфере новых технологий, где результаты разработки продукта нельзя предсказать заранее.
Kanban
Подход к разработке ПО по методике Agile, который подразумевает открытость всех рабочих процессов и постоянное улучшение производительности. Каждый член команды выполняет индивидуальный набор задач.
Преимущества
Высокая концентрация на текущей работе. Команда фокусируется на конкретной задаче и направляет все усилия на ее решение. Приоритетность задач может меняться.
Быстрое устранение проблем. Все члены команды могут отслеживать прогресс и давать обратную связь, которая помогает оперативно исправлять ошибки.
Оптимизация издержек. Канбан позволяет анализировать и прогнозировать точное время, необходимое для реализации проекта.
Недостатки
Не удовлетворяет требованиям больших команд. Метод не предназначен для групп численностью больше 5 человек,и команд, где сотрудники не знают функции друг друга. В таких условиях невозможно эффективно контролировать реализацию проекта.
Scrum
Модель управления разработкой с гибкой организацией работы внутри команды, направленной на создание новых сложных продуктов. Scrum позволяет развивать проект в тесном сотрудничестве с заказчиком, постоянно корректируя характеристики продукта и показывая результат на каждом этапе разработки.
Преимущества
Эффективное взаимодействие между участниками проекта. Процесс принятия решений полностью зависит только от членов команды. Все внутренние процессы регулируют сами разработчики. Это позволяет всем участникам проекта четко понимать свои функции и задачи.
Минимум контроля и фокус на постоянные обновления. Весь процесс разбит на 30-дневные периоды с ежедневными собраниями. Любые изменения происходят очень быстро и не требуют лишних затрат и издержек.
Недостатки
Высокая стоимость разработчиков. Результат сильно зависит от профессионализма команды. Сотрудники должны обладать способностями к самодисциплине и самоконтролю.
Нежелательное расширение проекта. Отсутствие единого контроля за реализацией проекта может привести к увеличению бюджетных трат.
Недостаток гибкости в больших проектах. Потеря даже одного члена команды станет серьезной проблемой и снизит эффективность реализации проекта. Scrum и Kanban применяются в большинстве Agile проектов.
Waterfall (Каскадная модель или «водопад»)
Классическая поэтапная методология, в которой каждый следующий шаг начинается только после завершения предыдущего. В отличие от Agile каскадная модель не допускает изменений в этапах разработки.
Преимущества
Постоянный контроль процессов и предсказуемость. Цели и задачи проекта понятны для разработчиков и не вызывают дополнительных вопросов.
Оценка затрат и сроков до начала проекта. Все требования четко проговариваются на начальном этапе и не изменяются в течение всего процесса. Предсказуемость позволяет точно оценить будущие расходы.
Документация каждого этапа. Это позволяет создавать базу для других проектов и предоставлять отчетность заказчику в любое время.
Недостатки
Сложно исправить ошибки. Тестирование проходит только на последних этапах разработки, поэтому возможные недочеты необходимо предусмотреть заранее.
Отсутствие обратной связи от заказчика на протяжении большей части проекта. Заказчик принимает участие в обсуждении целей проекта и возвращается, чтобы оценить финальный результат, который может его полностью не удовлетворить.
Высокая стоимость исправлений. Любая ошибка приведет к необходимости переделывать весь проект. Избежать подобных проблем помогают сильные и дорогие бизнес-аналитики, которые способны точно перевести задачи бизнеса на ИТ язык.
Где применяется
Каскадная модель используется при реализации проектов по жизнеобеспечению, где любая ошибка может привести к фатальным последствиям. «Водопад» предпочитают также военные и воздушные организации, в которых необходимы строгие требования к выполнению проектов. Подобная модель может применяться при разработке программного обеспечения для дорожных светофоров. На начальном этапе проект необходимо согласовать с заказчиком и прописать всю документацию. После этого будет выбрана архитектура, создан код, проведено тестирование, осуществлена интеграция и проверка на ошибки. Каждый из этих этапов будет строго следовать один за другим.
V-model
Вид каскадной модели, в котором предусмотрено тестирование уже на ранних этапах реализации проекта. Модель приобрела особую популярность в сфере авионики (электронные системы на борту воздушного судна), где очень важно контролировать каждый отдельный шаг процесса разработки ПО.
Преимущества
Уменьшение рисков. Постоянное тестирование минимизирует возможность дорогостоящей ошибки.
Сокращение издержек. Цена всех стадий проекта легко прогнозируется и не изменяется.
Адаптивность для пользователей. V-модель четко фиксирует и реализует основные требования пользователей к разрабатываемому продукту.
Недостатки
Сложность исправления фундаментальных ошибок. Отсутствует конкретный механизм решения проблем, выявленных на этапе тестирования.
Недостаток гибкости в процессе разработки. Разработка начинается только после перехода к следующему этапу. Никаких предварительных шаблонов не предусмотрено. Это может затруднить понимание процесса для заказчика.
Где применяется
В сферах, где работа продукта не может быть остановлена. Например, разработка ПО для авиации представляет собой сложный документированный процесс, где каждый уровень тщательно прописывается и отслеживается любая ошибка. Тестирование начинается только после глубокого анализа требований, описанных в документах. Такой процесс занимает много времени и требует высокого уровня профессионализма от исполнителей.
RAD (rapid application development model или быстрая разработка приложений)
RAD позволяет быстро получить нужный результат в короткие сроки. Это достигается с помощью постоянного взаимодействия с заказчиком, своевременных уточнений требований и анализа результатов. Такая модель может использоваться при разработке платформы для анализа и обработки заказов на покупку товара (purchase order). Быстрое создание первоначального прототипа обеспечивается с помощью тесного взаимодействия с департаментом закупок. После первого запуска необходимо сразу же познакомить пользователей с приложением. Это позволит выявить и исправить возможные ошибки и неточности.
Преимущества
Быстрое завершение проекта. Профессиональная команда, эффективные инструменты и создание прототипов обеспечивают высокую скорость реализации процесса разработки.
Минимальные бюджетные затраты. Элементы продукта разрабатываются и внедряются по отдельности. Это исключает ошибки, свойственные каскадной модели.
Вовлеченность заказчика. Заказчик становится активной частью проекта уже на ранних этапах разработки. Высокое качество. Оно обеспечивается за счет постоянного взаимодействия пользователей с будущими прототипами продукта.
Недостатки
Зависимость от заказчика. Заказчик и разработчики могут иметь разное представление о продукте.
Маленький и средний масштаб проектов. RAD сложно применить для больших проектов, где требуется усиленный контроль и нет возможности разделить процесс на маленькие части.
Где применяется
В проектах, где требуется закончить разработку в сжатые сроки. Так, когда финансовый отдел компании хочет получить удобную платформу для составления отчетов по командировкам, мы можем воспользоваться RAD методом. Вместе с сотрудниками компании мы создаем удобный прототип продукта и тут же тестируем его. Это позволяет всем пользователям быстро вносить изменения и улучшать платформу. Результатом такой разработки является значительное сокращение времени на обработку командировочных документов.
Spiral model
Удобная модель для анализа рисков. Идеально подходит для решения ключевых задач бизнеса, запуска нового продукта и проведения исследований.
Преимущества
Устранение рисков на ранних этапах реализации проекта. Этот шаг становится ключевым в данной модели.
Гибкость на всех этапах разработки. Возможность внесения изменений существует на протяжении всего проекта.
Недостатки
Длительная и дорогостоящая разработка. Спиральная модель требует больших временных и денежных затрат на осуществление основных принципов и привлечение квалифицированных специалистов.
Высокая зависимость результата от стадии анализа. Если на этом этапе будет допущена ошибка, то изменения проекта потребуют больших издержек.
Где применяется
В проектах, где необходимо анализировать большое количество рисков. Часто используется при разработке спутников и военных объектов.
Небольшой лайфхак
Выбор только одной методики не гарантирует успешное завершение проекта. Заказчик должен учитывать различные аспекты продукта при выборе того или иного вида разработки. Мы иногда совмещаем различные подходы для достижения желаемых результатов. Каждая из перечисленных методологий имеет свое назначение и сферу применения. Наш опыт позволяет определять тип разработки, который подходит заказчику. Мы всегда готовы помочь в выборе оптимального подхода для решения задач вашего бизнеса.
17. Гибкие методологии разработки программного обеспечения Agile: Scrum, Kanban, экстремальное программирование.
Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum, FDD.
Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с их управлением комбинированным (либеральным и демократическим) методом.
Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.Agile-методы делают упор на непосредственное общение лицом к лицу.
В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].
Это говорит о том, что в Scrum невозможно найти ответы на все вопросы и указания к действию во всех ситуациях (к примеру, в официальном описании Scrum лишь указана необходимость оценки времени, необходимой на выполнение работы, но не уточняется вид оценки. Т.е. это может быть и planning poker и другой способ оценки). Таким образом, само наименование топика не верно 🙂
Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии 🙂
Авторами Scrum заявлены следующие особенности:
🔀 SDLC модели: как выбрать правильный подход к разработке и не завалить проект
Более половины ИТ-проектов заканчиваются провалом. Одни из самых распространенных причин неудач ИТ-проектов – неправильная интерпретация бизнес-целей, игнорирование клиентов, неправильная расстановка приоритетов. Но у всех у них общий корень проблемы: неправильный подход к разработке программного обеспечения.
Основные методологии разработки ПО
Методология разработки программного обеспечения (SDLC) представляет собой последовательность действий, которые необходимо выполнить, чтобы получить готовое решение. Проще говоря, это способ создания программного продукта. Проблема в том, что существует множество моделей SDLC, которые используются для разных типов проектов. Как узнать, какой из них подходит для вашего проекта? В статье я перечислил наиболее популярные модели SDLC, их варианты использования, преимущества и недостатки.
Каскадная модель (waterfall)
Это линейная и последовательная модель разработки программного обеспечения, в которой фазы проекта следуют одна за другой и включают:
Плюсы и минусы подхода
| Плюсы | Минусы |
| Простая в использовании модель. | С этой моделью слишком сложно и дорого адаптироваться к изменениям требований. |
| Каждый этап хорошо задокументирован. | Документирование каждой фазы проекта занимает много времени. |
| Результат проекта абсолютно предсказуем. | Вы не можете ничего предоставить заказчику, пока не завершите весь проект. |
| Этапы и роли четко определены с самого начала. | Различные команды (дизайн, разработка, контроль качества и т. д.) изолированы, а взаимодействие между ними ограничено. |
| Минимальное вмешательство клиента. | Без обратной связи клиента результат рискует не оправдать ожидания. |
Каким проектам подходит
Каскадная модель – хороший вариант, если выполняются эти условия:
Всего десять лет назад многие компании использовали каскадную модель для разработки корпоративного программного обеспечения, включая CRM, системы управления цепочками поставок и системы точек продаж. Но сегодня эта модель не может удовлетворить быстро меняющиеся технические потребности. Вот почему компании все чаще обращаются к более современным подходам.
V-образная модель SDLC
V-образная модель – это своего рода другая версия каскада, но в её основе лежит контроль качества каждой фазы. Например, когда группа разработчиков собирает требования к проекту, QA-специалисты пишут приемочные тесты на основе этих сценариев. Точно так же на этапе проектирования системы создаются сценарии тестирования и так далее. После написания кода команда QA проверяет продукт на соответствие заранее написанным тестам (правая часть буквы «V»).
| Плюсы | Минусы |
| Легко реализовывать. | В V-образной модели внести изменения в середине проекта крайне сложно. |
| Тест-кейсы создаются заранее. | При таком большом количестве процедур тестирования остается меньше времени на код. |
| Бюджет и продолжительность проекта предсказуемы. | По сравнению с каскадной эта модель требует больше специалистов. |
| У каждого этапа есть свои результаты, и все хорошо задокументировано. | Модель не подходит для проектов с быстро меняющимися требованиями. |
| Это структурированный подход с четко определенными ролями и функциями. | Не подходит для больших и сложных проектов. |
Каким проектам подходит
V-образная модель может быть чрезвычайно полезна в случаях, когда ошибки могут быть фатальными, и в проектах, где точность имеет решающее значение. Например, это решение, основанное на нормативных требованиях, таких как подача налоговых деклараций. Кроме того, эта модель подходит для проектов в сфере здравоохранения. Например, компания Roche Diagnostics однажды использовала его для разработки системы диагностики рака.
Модель эволюционного прототипирования
Это ещё одна вариация каскада. Пока проект проходит через традиционные фазы, прототип продукта пошагово дорабатывается на основе отзывов клиентов. Как правило, первый прототип не проходит приемочный тест, поэтому модель прототипирования включает в себя несколько прототипов. Только после того, как предложенный дизайн продукта будет полностью принят, команда разработчиков сможет перейти к следующим этапам.
| Плюсы | Минусы |
| Получение отзывов пользователей на ранних этапах. | Поскольку прототипы могут развиваться бесконечно, планирование проекта невозможно. |
| Высокие шансы на успех проекта. | Разрабатывать несколько прототипов – дорого. |
| Легко адаптироваться к быстро меняющимся требованиям. |
Каким проектам подходит
Модель эволюционного прототипирования может быть полезна для проектов, которые предполагают взаимодействие с пользователем, используют новые технологии, имеют сложную функциональность или должны учитывать быстро меняющиеся требования, которые трудно или невозможно предсказать.
Итеративная и инкрементальная модель
В инкрементальной и итеративной модели решение разрабатывается небольшими частями через серию циклов. Рабочий процесс выглядит следующим образом:
| Плюсы | Минусы |
| Модель инкрементальной и итеративной разработки обеспечивает быструю и регулярную «доставку» работающего программного обеспечения клиентам. | Во время интеграции модуля могут возникнуть архитектурные проблемы. |
| Легче и дешевле учесть изменения в требованиях проекта. | Несмотря на некоторую гибкость, систему следует планировать с самого начала; в противном случае его нельзя разделить на модули. |
| Обратная связь от клиента на ранней стадии. | Участие клиентов может быть проблематичным. |
| Небольшие части программного обеспечения легче тестировать и исправлять. | Не всегда можно разбить систему на сегменты. |
| Экономия на издержках. | Хотя выпуск одного модуля дешевле, общие затраты на систему будут увеличиваться по мере интеграции новых модулей. |
Каким проектам подходит
Модель будет эффективна в следующих случаях:
Спиральная модель
Этот подход основан на оценке риска, он сочетает в себе функции каскадной, прототипной, итеративной и инкрементной моделей. Модель похожа на спираль с несколькими кругами. Каждый круг – это фаза, состоящая из четырёх элементов:
Затем, на основе отзывов пользователей и заинтересованных сторон, планируется следующая итерация.
Как видите, продукт неоднократно проходит через эти этапы, и в конце каждого цикла создаётся и выпускается лучшая версия продукта. И, как и в итеративном подходе, продукт состоит из серии релизов.
| Плюсы | Минусы |
| Анализ рисков на каждой итерации увеличивает шансы проекта на успех. | Требуется опыт управления рисками. |
| Этот метод позволяет создавать стабильные и надёжные системы, поскольку они тщательно тестируются в каждом цикле. | Модель подразумевает работу с большим объёмом документации. |
| Можно менять требования между циклами. | Нельзя изменить требования в середине цикла. |
| Раннее вовлечение разработчиков помогает согласовать бизнес-требования и технические возможности. | Каждый кружок в спирали развития представляет собой «мини-каскад», а это значит, что вы не можете пропускать фазы. |
| Частые выпуски позволяют получать регулярную обратную связь от клиентов даже на ранних этапах цикла. | Поскольку ограничений на количество итераций нет, сложно предсказать, сколько кругов потребуется для создания окончательной версии продукта. |
Каким проектам подходит
Спиральная модель подходит для:
Microsoft, IBM и Tata Consultancy используют спиральную модель.
Модели гибкой разработки программного обеспечения
Вопреки распространённому мнению Agile не является ни структурой, ни методологией. Это философия с набором принципов, ориентированных на ускорение процесса разработки программного обеспечения, обеспечение 100% удовлетворённости клиентов и предоставление высококачественных решений в быстро меняющейся среде. Фактически, существует 12 принципов гибкой разработки, которые сводятся к следующим ценностям:
Scrum
Скрам-проекты разбиты на спринты. Спринт – это небольшой объём работы, который необходимо выполнить в течение определённого периода времени. Обычно заказчику доставляется часть проекта, которая была завершена во время спринта (инкремент продукта, от англ. increment). Скрам подразумевает активное общение и сотрудничество между всеми участниками проекта. Наряду с ежедневными 15-минутными встречами разработчиков, есть также:
Сердце процессов Scrum – это backlog, своего рода список задач, которые необходимо сделать для завершения проекта. По мере того, как проект продвигается, и команда узнаёт о нём больше, они редактируют бэклог продукта, добавляя, удаляя и переупорядочивая его элементы. Тем не менее, нельзя сделать что-то, если этого нет в очереди продукта.
Но на самом ли деле всё так гладко и красиво в Agile? Посмотрим на его основные варианты использования, а также на плюсы и минусы.
| Плюсы | Минусы |
| Не нужно ждать завершения проекта, чтобы внедрить основные функции продукта. | Гибкие методологии разработки ПО сложно внедрить. |
| Кросс-функциональные команды регулярно общаются и обмениваются знаниями между собой и владельцами проектов. | В Agile проектная документация очень быстро устаревает, поэтому понадобятся дополнительные навыки оперативной работы с ней. |
| Возможность адаптироваться к изменениям на любой стадии проекта. | В Agile проектах практически невозможно делать прогнозы и достаточно тяжело с высокой долей точности планировать бюджет. |
| Регулярная обратная связь от пользователей, что позволяет удовлетворить все потребности. | Сбор отзывов пользователей может быть сложной задачей. |
Примеры использования
Большинство современных проектов требуют определённого уровня «маневренности», особенно когда:
Резюме
Ни одна из моделей SDLC не является «волшебной пилюлей». Нельзя просто выбрать методологию, которая соответствует потребностям проекта, и слепо следовать ей. В лучшем случае это не улучшит ваш процесс разработки. В худшем вы подвергнете риску проект. Вот почему грамотный подход к выбору и реализации модели разработки программного обеспечения является ключом к тому, чтобы заставить её работать на вас.
Вот несколько советов как подходить к разработке на примере реального проекта EPAM Anywhere :