Waterfall model что это
Методология разработки Waterfall: что это, как работает и чем отличается от Agile
Сейчас Waterfall не так часто используют, но без неё никто бы не придумал Agile. Рассказываем для менеджеров проектов и тех, кто хочет ими стать.
Бывает, что в теории методология ясна, а потом дело доходит до внедрения и начинаются вопросы. На курсе «Руководитель digital-проектов» преподаватели Skillbox разбирают инструменты управления на реальных кейсах, чтобы студенты легко и безошибочно применяли их в работе.
Что ещё за Waterfall?
Waterfall — модель «Водопад», водопадная или каскадная разработка продуктов. Она подобно потоку воды направляет команды решать задачи последовательно и строго по изначальному плану. Название появилось в 1970 году в статье Винстона Уолкера Ройса, директора Lockheed Software Technology Center, а структура позаимствована у диаграммы Ганта.
Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства
CRM-маркетинга Out of Cloud.
Принципы водопадной модели разработки
Как работает Waterfall
Разработка при использовании каскадной модели — это пять строго последовательных этапов.
Команда собирает требования к будущему продукту. Потом пишет подробное техническое задание, планирует график работ и возможные риски. Переходит к следующему этапу, только когда все требования прописаны и есть план. А в плане — инструкции, что и когда делать.
Команда создаёт прототип и готовит дизайн-макеты. Когда это готово, подключаются разработчики.
На этом этапе пишут код продукта согласно плану, макетам и требованиям. Ни шагу в сторону, всё четко по ТЗ.
Код готов, начинается тестирование. Тут могут появиться проблемы. Например, команда обнаружит серьёзные ошибки в коде и потратит много времени, чтобы их исправить. Это главный минус каскадной модели разработки.
Эксплуатация и поддержка
Проект передают заказчику и следят заранее определённое время, чтобы всё работало.
Как отличить Waterfall от гибких методологий
Классическая методология Waterfall — это работа по заранее написанному и согласованному ТЗ. Гибкость здесь не приветствуется. В этом основное отличие водопадной модели от Agile.
Waterfall отличается от Agile и самими принципами работы, о которых мы говорили выше.
12 принципов Agile
Эти принципы появились из agile-манифеста.
Манифест гибкой разработки ПО
Если бы для Waterfall тоже написали манифест, он бы выглядел так:
Манифест водопадной модели разработки ПО
Чем Waterfall отличается от Scrum
Фреймворк Scrum — это часть Agile, поэтому он тоже отличается от водопадной модели разработки. В этой таблице мы собрали их основные отличия.
| Waterfall каскадная модель | Scrum итерационная модель |
|---|---|
| Все требования известны вначале и не меняются | Требования могут меняться по ходу проекта |
| Объемное и подробное ТЗ | Бэклог |
| Тестирование в конце | Тестирование после каждой итерации |
| Негибкая | Гибкая |
| Готовый продукт в конце | Работающая часть продукта после первой итерации |
| Клиент не видит промежуточный результат | Клиент видит и может влиять на промежуточный результат |
Если хотите разобраться подробнее:
Заключение
Waterfall — это методология, где всё изначально продумано и зафиксировано, и в этом есть свои плюсы. Бывают проекты, которым она подходит, — такие, в которых все требования известны заранее и не могут измениться по ходу работы и где нет риска ошибиться.
В Digital такое бывает редко, поэтому команды добавляют к каскадной модели гибкие практики: например, проверяют продукт на соответствие требованиям после каждого этапа работы, а не в самом конце.
Waterfall — итеративная методология разработки
Недавно открыл для себя интересный факт, что товарищ Винстон Ройс (Dr. Winston D. Royce), анонсируя свой знаменитый Waterfall говорил об итеративной модели разработки.
Наверняка, все, кто хоть как-то связаны с разработкой/тестированием ПО, знают о каскадной модели и об ее особенностях:
— высокий уровень формализации процессов;
— большое количество документации;
— и конечно же, жесткая последовательность этапов жизненного цикла без возможности возврата на предыдущий этап.
Ознакомившись с выдержкой из трудов Ройса, оказалось, что он предусматривал обратные связи между этапами на одном уровне (к примеру, дизайн-кодирование, кодирование-тестирование и т.д.).
Насколько я понимаю разницу, во втором варианте, в отличии от первого, речь идет о параллельных работах по двум последовательным этапам, что дает возможность на более ранних стадиях выявить ошибки предыдущего этапа жизненного цикла и решает один из весомых недостатков «классического» водопада — невозможность возврата на предыдущий этап.
К примеру, если рассмотреть параллельные работы по 2 последовательным фазам — Coding и Testing, становится очевидным, что часть программы выдается в тестирование, в то время как другая часть все еще находится на стадии разработки.
Т.е. получается, что речь действительно идет об итеративной методологии разработки ПО.
В таком случае остается вопросом, почему методология в широких кругах разработчиков и тестировщиков воспринимается ошибочно, как отображено на первом рисунке…
Waterfall model что это
Waterfall, или каскадная модель, ― это классика в мире разработки продуктов. Она существует уже больше полувека. За это время она доказала свою эффективность, но обзавелась мощными конкурентами. Главный из них ― гибкий Agile, которым активно пытаются заменить последовательный каскад. Пора ли отказаться от водопада или классика никогда не устареет? Разбираемся в плюсах и минусах Waterfall и говорим о проектах, в которых водопаду до сих пор нет равных.
Что такое Waterfall и кто его придумал
Waterfall (каскад или водопад) — классическая модель разработки продуктов. Американский ученый-информатик Уинстон Уокер Ройс придумал и описал ее еще в 1970 году, а в 1976 году ученые Томас Белл и Томас Тэйер дали ей название. Сначала Waterfall использовали в создании любого программного обеспечения, но потом появилась модель Agile и водопад засох. Теперь каскадную модель применяют в авиастроении, военной или космической отраслях, медицине и финансовом секторе. Там Waterfall самое место, потому что этим сферам нужны четко выстроенные процессы и сроки, а это суть каскада. Отсюда и сравнение с водопадом: каждый этап создания продукта, словно поток воды, продолжает предыдущий и не может начаться, пока прошлый не завершился.
Из каких этапов состоит Waterfall
Уокер Ройс придумал циклы водопада 50 лет назад, и с тех пор они не меняются. Кроме того, этапы создания проекта всегда идут в одинаковой последовательности и пропускать какой-то из них нельзя.
Основной инструмент водопада
Последовательность процессов, соблюдение сроков, выполнение задач в каскадной модели лучше всего отображает диаграмма Ганта (a Gantt Chart) или горизонтальная гистограмма. Она состоит из блоков, расположенных на двух осях. По горизонтали — задачи, по вертикали — время, затраченное на их выполнение. На диаграмме можно проследить, какие задачи входят в проект и кто за них отвечает, а также продолжительность каждого этапа.
Допустим, вы строите быстровозводимый дом ― дачу в Подмосковье, чтобы выбираться туда на лето. Времени мало, максимальный бюджет — три миллиона рублей. Земля в вашей собственности, все документы в порядке. Срок строительства двухэтажного коттеджа, как сообщает застройщик, — от 25 дней. Все этапы известны и определены, а материалы закуплены.
Для начала перечислим каждый этап, затем дату начала и завершения. Первые две задачи офисные специалисты делают только в рабочие дни, далее работа переходит к строительной бригаде, которая трудится каждый день. Срок проекта — 28 дней. Чтобы показать весь проект на нашей диаграмме, представим, что этап поддержки длится неделю. В жизни срок обнаружения ненадлежащего качества работ гораздо больше.
Затем построим диаграмму Ганта. Мы использовали smartsheet, но это можно делать в Excel или просто на бумаге.
По горизонтали перечисляем этапы строительства, по вертикали указываем начало и конец каждого. Теперь диаграмма иллюстрирует принцип Waterfall: этапы идут один за другим, следующий начинается только тогда, когда заканчивается предыдущий. Это логично: невозможно возвести хороший фундамент и покрыть крышу без инженерно-исследовательских работ и четкого плана дома. Мы также видим, из каких этапов состоит проект, какие задачи входят в каждый этап и сколько времени они занимают.
Плюсы и минусы Waterfall
Чек-лист, который подскажет, подойдет ли Waterfall вашему проекту
Подсказка. Вам точно подойдет каскадная модель, если вы делаете строительный проект, работает в авиастроении, медицине, финансовом секторе, военной или космической отрасли. Откажитесь от водопада в пользу Agile, если проект создается для стартапа или IT-компании.
Где искать дополнительную информацию по теме
Почитать
Посмотреть
Хотите научиться справляться со сложными вызовами современного бизнеса? Освойте самые эффективные методы на комплексной программе «Профессия бизнес-аналитика»! Вас прокачают эксперты-практики из McKinsey & Company, EY, «Газпрома», Unilever, KPMG и не только. Уже через полгода вы сможете начать карьеру в топовой компании. Регистрируйтесь!
Кратко о методологиях разработки ПО: Waterfall, Lean и Feature Driven Development
В нашем прошлом материале мы писали о методологиях разработки программного обеспечения, которые помогают оптимизировать рабочие процессы. Тогда речь шла о Scrum, канбан и экстремальном программировании. Сегодня мы расскажем о Waterfall, FDD и Lean — оценим плюсы и минусы подходов и взглянем на опыт организаций, которые их используют, чтобы помочь вашим компаниям оптимизировать процессы.
Waterfall
Waterfall, или каскадная модель, — традиционная методология, которая существует с 1970 года. В ней разработку проекта разбивают на этапы: от анализа системных требований до выпуска продукта.
Каждый шаг — отдельная фаза разработки ПО, и команда должна завершить одну фазу, прежде чем переходить к следующей. В «чистой» реализации Waterfall возвращаться на предыдущий этап запрещено — можно «плыть только по течению», чтобы пройти полный цикл разработки. Пользователи Quora сравнивают эту модель с поездом, который движется от станции к станции и не может повернуть назад.
Изначально автор Waterfall Винстон Ройс (Winston Royce) привел каскадную модель как пример неэффективного способа разработки программного обеспечения, который ведет к ошибкам и выпуску некачественных продуктов. Однако потом в своей статье он довел методологию «до ума», отметив обратные связи и переходы от тестирования к написанию кода и др.
По данным исследования PMI, 12% компаний используют методологию Waterfall на постоянной основе, а 40% респондентов утверждают, что часто к ней обращаются. А по данным LiquidPlanner, каскадную модель используют 25% организаций.
Количество этапов в Waterfall варьируется от компании к компании, но общий подход выглядит следующим образом:
Кроме того, модель подразумевает документирование каждого этапа. Это помогает создавать базу для последующих проектов. Также большое количество отчетности позволяет в любой момент показать заказчику или руководству, на какой стадии находится продукт.
Однако есть и недостатки. Клиенты часто не знают, чего они действительно хотят, пока не взглянут на прототип. А по Waterfall нужно определять все требования заранее, поэтому есть риск что-то упустить. Исследование процесса разработки сайта компании Ericsson AB показало, что каскадная модель привела к путанице, и 26% изначальных требований оказались бесполезными.
Однако главный недостаток Waterfall — внесение изменений. Продукт тестируют в конце жизненного цикла, и может быть слишком поздно, чтобы что-то править. Именно стоимость внесения изменений побудила компанию Toyota задуматься о переходе на другую методологию разработки.
По словам Сатоси Исии (Satoshi Ishii), главного руководителя проектов компании, исправление дефектов, обнаруженных после производства, обходится в 1000–10000 раз дороже. Поэтому в Toyota решили отказаться от Waterfall и перейти к Lean, который мы рассмотрим далее.
Термин означает «бережливая разработка». Его корни уходят глубоко в историю компании Toyota и её подходов к решению задач. В компании вносят только те изменения, которые приносят пользу, требуют минимум затрат и отнимают не более 30% запланированного времени. Это помогло японской компании научиться переключать конвейеры на производство другой модели за считаные часы, в то время как другим автопроизводителям требовались недели.
Применили методологию Lean для разработки Мэри (Mary Poppendieck) и Том Поппендик (Tom Poppendieck). Они написали книгу «Lean Software Development». Дополнительную информацию также можно найти на их сайте, посвящённом Lean.
По данным исследования PMI, 8% компаний постоянно используют принципы Lean, а 26% часто к ним обращаются. Принципы Lean:
При этом, когда команда следует принципам бережливой разработки, она не просто выполняет задачи, а стремится сделать продукт с наименьшим количеством ошибок. В своём исследовании компания ВВС обнаружила, Lean повышает скорость разработки ПО на 37% и снижает количество багов на 24%.
Также, согласно исследованию Lean Business Report, в числе десяти преимуществ подхода указано снижение стоимости проектов — 27% IT-компаний уменьшили затраты за счет внедрения принципов Lean.
Однако они подходят не всем. Команда GlobalLuxSoft отмечает, что бережливую разработку стоит применять, только если к проекту подключены опытные разработчики, так как обучение на ходу оказывается невозможным и ставит создание продукта под угрозу.
Все принимаемые решения должны подкрепляться аналитическими данными и результатами мониторинга процессов, иначе команда рискует погрузиться в слишком большое количество изменений и забыть о главной цели проекта. Здесь можно обратиться к опыту Toyota: жесткий контроль со стороны не позволяет разработчикам отклоняться от приоритетных задач.
/ Flickr / Sebastian Sikora / CC
Feature Driven Development
Feature driven development (FDD) — методология, которая объединяет лучшие практики и сосредотачивает внимание разработчиков на функциональных элементах (features), полезных с точки зрения клиента. По этой ссылке можно найти примерную схему алгоритма разработки по FDD. Согласно исследованиям, 11% компаний постоянно используют Feature Driven Development, а 31% прибегает к использованию этой методологии время от времени.
Создатель FDD — Джефф де Лука (Jeff De Luca), впервые предложил методологию в 1997 году, когда искал оптимальное решение по разработке программного обеспечения для банка в Сингапуре. Тогда он предоставил комбинацию из 5 процессов:
Однако есть и плюсы. Постоянное составление отчетов о проделанной работе на всех уровнях помогает отслеживать прогресс и результаты. Это позволяет регулярно обновлять проект, выявлять ошибки и предоставлять клиенту информацию в любое время. А один из резидентов Stack Overflow утверждает, что главный плюс FDD — возможность в любой момент оценить отстаёт ли проект от графика или продвигается быстрее.
Как уже было отмечено, FDD используется в масштабных проектах, поскольку на первом этапе ведётся разработка общей модели, позволяющей разобраться в продукте. Это же свойство помогает привлекать к работе новых разработчиков. При этом более глубокое понимание проектных требований и ожиданий клиента снижает риск нежелательных «сюрпризов».
Модели и методологии разработки ПО
За прекрасную картинку спасибо Toggl.com.
Подготовлено по материалам вебинара «Модели и методологии разработки ПО» Анастасии Кайгородовой, преподавателя факультета тестирования ПО.
Существуют модели разработки ПО. И существуют методологии. В интернете много противоречивой информации о том, что есть что и как их отличать. Начинающему специалисту бывает сложно в этом разобраться. В этой статье мы расставим все точки над i.
Этапы жизненного цикла ПО
У любого программного обеспечения есть жизненный цикл — этапы, через которые оно проходит с начала создания до конца разработки и внедрения. Чаще всего это подготовка, проектирование, создание и поддержка. Этапы могут называться по-разному и дробиться на более мелкие стадии.
Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.
Подготовка. Иван решил запустить книжный интернет-магазин и начал анализировать, какие подобные сайты уже представлены в сети. Собрал информацию об их трафике, функциональности.
Проектирование. Иван выбрал компанию-подрядчика и обсудил с её специалистами архитектуру и дизайн будущего интернет-магазина.
Создание. Иван заключил с разработчиками договор. Они начали писать код, отрисовывать дизайн, составлять документацию.
Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.
Модель разработки программного обеспечения описывает, какие стадии жизненного цикла оно проходит и что происходит на каждой из них.
А методология включает в себя набор методов по управлению разработкой: это правила, техники и принципы, которые делают её более эффективной.
Основные модели разработки ПО
Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.
Waterfall (каскадная модель, или «водопад»)
В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.
Преимущества «водопада»
Недостатки каскадной модели
«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО.
При работе с каскадной моделью основная задача — написать подробные требования к разработке. На этапе тестирования не должно выясниться, что в них есть ошибка, которая влияет на весь продукт.
V-образная модель (разработка через тестирование)
Это усовершенствованная каскадная модель, в которой заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать её на каждом этапе. История этой модели начинается в 1980-х.
Преимущества V-образной модели
Количество ошибок в архитектуре ПО сводится к минимуму.
Недостатки V-образной модели
Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».
V-модель подходит для проектов, в которых важна надёжность и цена ошибки очень высока. Например, при разработке подушек безопасности для автомобилей или систем наблюдения за пациентами в клиниках.
Incremental Model (инкрементная модель)
Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.
Преимущества инкрементной модели
Недостатки инкрементной модели
Инкрементная модель подходит для проектов, в которых точное техзадание прописано уже на старте, а продукт должен быстро выйти на рынок.
Iterative Model (итеративная модель)
Это модель, при которой заказчик не обязан понимать, какой продукт хочет получить в итоге, и может не прописывать сразу подробное техзадание.
Рассмотрим на примере создания мессенджера, как эта модель работает.
Преимущества итеративной модели
Недостатки итеративной модели
Итеративная модель подходит для работы над большими проектами с неопределёнными требованиями, либо для задач с инновационным подходом, когда заказчик не уверен в результате.
Spiral Model (спиральная модель)
Используя эту модель, заказчик и команда разработчиков серьёзно анализируют риски проекта и выполняют его итерациями. Последующая стадия основывается на предыдущей, а в конце каждого витка — цикла итераций — принимается решение, продолжать ли проект. Эту модель начали использовать в 1988 году.
Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом».
Спиральная модель похожа на инкрементную, но здесь гораздо больше времени уделяется оценке рисков. С каждым новым витком спирали процесс усложняется. Эта модель часто используется в исследовательских проектах и там, где высоки риски.
Преимущества спиральной модели
Большое внимание уделяется проработке рисков.
Недостатки спиральной модели
На основе итеративной модели была создана Agile — не модель и не методология, а скорее подход к разработке.
Что такое Agile?
Agile («эджайл») переводится с английского как «гибкий». Включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно:
Различия между Agile и традиционным подходом к разработке мы свели в таблице:
Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban.
Kanban
Сегодня это одна из наиболее популярных методологий разработки ПО. Команда ведёт работу с помощью виртуальной доски, которая разбита на этапы проекта. Каждый участник видит, какие задачи находятся в работе, какие — застряли на одном из этапов, а какие уже дошли до его столбца и требуют внимания.
В отличие от скрама, в канбане можно взять срочные задачи в разработку сразу, не дожидаясь начала следующего спринта. Канбан удобно использовать не только в работе, но и в личных целях — распределять собственные планы или задачи семьи на выходные, наглядно отслеживать прогресс.
Совсем скоро мы организуем трёхдневный онлайн-интенсив по Agile-методологиям. На нём вы научитесь использовать все преимущества этого подхода, управлять разработкой и выпускать проекты любой сложности. Ждём вас!
За прекрасную картинку спасибо Toggl.com.
Подготовлено по материалам вебинара «Модели и методологии разработки ПО» Анастасии Кайгородовой, преподавателя факультета тестирования ПО.
Существуют модели разработки ПО. И существуют методологии. В интернете много противоречивой информации о том, что есть что и как их отличать. Начинающему специалисту бывает сложно в этом разобраться. В этой статье мы расставим все точки над i.
Этапы жизненного цикла ПО
У любого программного обеспечения есть жизненный цикл — этапы, через которые оно проходит с начала создания до конца разработки и внедрения. Чаще всего это подготовка, проектирование, создание и поддержка. Этапы могут называться по-разному и дробиться на более мелкие стадии.
Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.
Подготовка. Иван решил запустить книжный интернет-магазин и начал анализировать, какие подобные сайты уже представлены в сети. Собрал информацию об их трафике, функциональности.
Проектирование. Иван выбрал компанию-подрядчика и обсудил с её специалистами архитектуру и дизайн будущего интернет-магазина.
Создание. Иван заключил с разработчиками договор. Они начали писать код, отрисовывать дизайн, составлять документацию.
Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.
Модель разработки программного обеспечения описывает, какие стадии жизненного цикла оно проходит и что происходит на каждой из них.
А методология включает в себя набор методов по управлению разработкой: это правила, техники и принципы, которые делают её более эффективной.
Основные модели разработки ПО
Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.
Waterfall (каскадная модель, или «водопад»)
В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.
Преимущества «водопада»
Недостатки каскадной модели
«Водопад» подходит для разработки проектов в медицинской и космической отрасли, где уже сформирована обширная база документов (СНиПов и спецификаций), на основе которых можно написать требования к новому ПО.
При работе с каскадной моделью основная задача — написать подробные требования к разработке. На этапе тестирования не должно выясниться, что в них есть ошибка, которая влияет на весь продукт.
V-образная модель (разработка через тестирование)
Это усовершенствованная каскадная модель, в которой заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать её на каждом этапе. История этой модели начинается в 1980-х.
Преимущества V-образной модели
Количество ошибок в архитектуре ПО сводится к минимуму.
Недостатки V-образной модели
Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».
V-модель подходит для проектов, в которых важна надёжность и цена ошибки очень высока. Например, при разработке подушек безопасности для автомобилей или систем наблюдения за пациентами в клиниках.
Incremental Model (инкрементная модель)
Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.
Преимущества инкрементной модели
Недостатки инкрементной модели
Инкрементная модель подходит для проектов, в которых точное техзадание прописано уже на старте, а продукт должен быстро выйти на рынок.
Iterative Model (итеративная модель)
Это модель, при которой заказчик не обязан понимать, какой продукт хочет получить в итоге, и может не прописывать сразу подробное техзадание.
Рассмотрим на примере создания мессенджера, как эта модель работает.
Преимущества итеративной модели
Недостатки итеративной модели
Итеративная модель подходит для работы над большими проектами с неопределёнными требованиями, либо для задач с инновационным подходом, когда заказчик не уверен в результате.
Spiral Model (спиральная модель)
Используя эту модель, заказчик и команда разработчиков серьёзно анализируют риски проекта и выполняют его итерациями. Последующая стадия основывается на предыдущей, а в конце каждого витка — цикла итераций — принимается решение, продолжать ли проект. Эту модель начали использовать в 1988 году.
Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом».
Спиральная модель похожа на инкрементную, но здесь гораздо больше времени уделяется оценке рисков. С каждым новым витком спирали процесс усложняется. Эта модель часто используется в исследовательских проектах и там, где высоки риски.
Преимущества спиральной модели
Большое внимание уделяется проработке рисков.
Недостатки спиральной модели
На основе итеративной модели была создана Agile — не модель и не методология, а скорее подход к разработке.
Что такое Agile?
Agile («эджайл») переводится с английского как «гибкий». Включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно:
Различия между Agile и традиционным подходом к разработке мы свели в таблице:
Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban.
Kanban
Сегодня это одна из наиболее популярных методологий разработки ПО. Команда ведёт работу с помощью виртуальной доски, которая разбита на этапы проекта. Каждый участник видит, какие задачи находятся в работе, какие — застряли на одном из этапов, а какие уже дошли до его столбца и требуют внимания.
В отличие от скрама, в канбане можно взять срочные задачи в разработку сразу, не дожидаясь начала следующего спринта. Канбан удобно использовать не только в работе, но и в личных целях — распределять собственные планы или задачи семьи на выходные, наглядно отслеживать прогресс.
Совсем скоро мы организуем трёхдневный онлайн-интенсив по Agile-методологиям. На нём вы научитесь использовать все преимущества этого подхода, управлять разработкой и выпускать проекты любой сложности. Ждём вас!