что такое водопадный тип жизненного цикла

Кратко о методологиях разработки ПО: 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 используется в масштабных проектах, поскольку на первом этапе ведётся разработка общей модели, позволяющей разобраться в продукте. Это же свойство помогает привлекать к работе новых разработчиков. При этом более глубокое понимание проектных требований и ожиданий клиента снижает риск нежелательных «сюрпризов».

Источник

Методологии управления проектами: водопад, эджайл

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

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

Методологий управления проектами великое множество – они бывают используемыми только в одной компании, бывают глобальными. Методологии бывают в виде инструментов (типа Agile), бывают в виде большой книги с набором этих инструментов (PMBoK, тоже методология).

В жизни я использовал и использую две, самые популярные методологии – Waterfall (“водопад”/“каскадная”) и Agile (и его ответвление – Scrum), о них и пойдет речь. Ради расширения кругозора читателя расскажу и о других известных мне вещах. Если читатель работает с диджитал, то “водопада” и “эджайла” хватит за глаза – можно будет использовать их в работе, жизни, рассказывать знакомым и незнакомым людям, на митапах, с умным видом попивая смузи.

Само собой, ничто ниоткуда не берется, и Петр Первый ничего не слышал про эджайл. Методологии придумываются всякими разными организациями и ассоциациями, где умные дядьки собирают свои проблемы в кучи, затем понимают, как их можно было избежать, и делятся после решениями с такими обывателями как я, например. Иногда продумывание методологий происходит на государственном уровне – там тоже решают проблемы и собирают best practices (в приличном обществе так не выражайся) в книги и руководства.

Речь сегодня пойдет в основном об этих двух зверятах. После прочтения этого раздела можешь смело идти и требовать себе самое классное место менеджера проектов в самой крупной подходящей организации города.

Водопад, каскадная методология – традиционная, самая популярная и логичная методология управления проектами. В чистом виде может сработать совсем в простых проектах. Допустим, тебе потребовалось посадить дерево. “По водопаду” выполнение проекта выглядит так:

Каждый этап в таком проекте идет следом за предыдущим и не может быть выполнен раньше предыдущего – это и есть “водопад”. Еще это пересекается с “методом критического пути”, но о нем расскажу в отдельной статье – напомни мне.

Я работаю с проектами в сфере разработки сайтов и мобильных приложений. Этапы разработки таких проектов по водопаду примерно одинаковы:

Чтобы двигаться по водопаду, нужно иметь четкое техническое задание и понимание шагов, следующих друг за другом. Из практики скажу, что работать по чистому водопаду нереально – обязательно где-то выясняется, что что-то упустили, где-то нужно откатиться на предыдущий этап и делать это параллельно с текущим этапом. Тем не менее, чем четче техническое задание, тем меньше шансов на то, что проект уйдет в сторону. Для проектов, где “уход в сторону” приемлем, есть Agile.

“Эджайл” (или “агиль”, или “а жаль” – много у него прикольных названий) относится к типу гибкой методологии. Главное его отличие от водопада – рабочий продукт на каждом этапе работы и неясный финал проекта. В примере с тем же деревом, где каждый этап последователен, этот эджайл не покатит: ну купил ты саженец, а толку? У эджайла достаточно широкая область применения, однако более всего он прижился в IT. А его виды и подтипы толстой пленкой накрыли прилегающие сферы – бизнес-планирование, продуктовый менеджмент и так далее, и тому подобное.

Для примера работы “по агилю” представим проект посложнее. Пусть это будет проект из строительства. Задача: построить дом, где можно жить.

Этапы производства (представим, что каждый этап занимает ровно спринт):

Пусть в состоянии MVP (минимальный жизнеспособный продукт), но этим домом можно будет пользоваться примерно после первого этапа – не очень комфортно, но можно. Также “по эджайлу” этапы могут не следовать друг за другом, а идти параллельно или в разном порядке. Ключевой момент: на каждом этапе реализации продукта продуктом можно пользоваться.

Чтобы фиксировать этапы, умные дядьки придумали спринты, каждый из которого содержит набор операций и сроки (чаще равные) их реализации и планируются непосредственно перед спринтом. Задачи, прилетающие в процессе спринта складываются в бэклог – корзинку с тем, что при следующем планировании спринта кто-то будет разгребать. Ну и еще одна особенность эджайла: у проекта может не быть технического задания – вот думали вы строить одноэтажный таунхаус, а в процессе решили, что для вас окей построить шестиэтажный особняк и вы вот его строите, гибко меняя планы в процессе производства.

Agile используют в IT (“диджитале”) – лучше всего он живет в стартапах, когда финальный проект не ясен, нужно проверять гипотезы и делать это быстро и гибко. Эджайл удобно использовать в проектах стороннего клиента (не из компании), когда финал проекта не ясен и у клиента тысяча тысяч идей по ходу разработки. В таком случае определяешь, сколько времени команды в неделю можешь выделить, считаешь стоимость этого времени и выставляешь счета в финале каждого спринта.

Если ты работаешь со внешними клиентами, эджайл гораздо удобнее водопада в любых проектах – ты же знаешь, сколько комментариев клиент может выдать на каждом этапе проекта и как сложно объяснить клиенту, что его комментарии превышают заложенное время на разработку, а значит и бюджет проекта. Доплачивать-то он вряд ли будет – есть же смета, и ты вроде как профессионал, должен был сразу понять, что ему вообще нужно. Эджайл работает с понимающими клиентами, остальным будет крайне сложно объяснить, почему это окей.

Еще одна особенность методологии: в ней нет как такового менеджера проекта. Есть владелец продукта, скрам-мастер (в Scrum), члены команды. То есть, менеджер здесь выступает в роли владельца продукта и делает примерно то же самое, что делает при любой другой методологии. Внутри любой проектной команды продакт-оунером выступает менеджер проекта – он заказывает продукт у команды, а не тот человек, который брифует менеджера.

В одно семейство с эджайлом (“гибкие методологии”) входят Scrum, XP и Lean – хипстерские вещи из мира стартапов – читайте интернеты.

Никакая методология не панацея. Ближайшую аналогию могу провести с чеклистами – это такая классная штука (читай статью на моем медиуме @salakhmir), которая люто помогает в работе, но, почему-то, работает не у всех. Любой инструмент – всего лишь инструмент, и сам по себе работать не будет. Представь, что лопату положили на землю и ждут, когда что-то произойдет – так и тут, чтобы что-то сделалось, нужно что-то сделать.

Преимущественно использую гибридную методологию (и водопад, и эджайл), где есть техническое задание, понятны этапы, но случаются отклонения по ходу проекта. Со стороны может казаться, что творится хаос, главное делать лицо с понтом всё идёт по плану. Часто отклонения уходят в отдельные проекта, но чаще остаются внутри текущего и тянут за собой увеличение времени (бюджета) проекта. Кажется, это плохо, но момент политики в работе с людьми (мы же работаем с людьми, а не с сайтами, помнишь?) исключать нельзя.

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

Project Management Institute – наш друг. Питаю к этой организации особую привязанность – у них мощная комьюнити и хорошая база. Организация базируется в США, существует с 1969 года, а их стандарты управления проектами признаются ANSI.

Основной продукт PMI – свод знаний по управлению проектами PMBoK, осенью 2017 года вышла шестая часть. Свод знаний содержит канвы выполнения проектами в мелочах – от сбора требований стейкхолдеров до закрытия проекта. Рекомендую хотя бы ознакомиться с книгой – в ней же можно почитать и про ватерфолл с эджайлом, и про метод критического пути и метод быстрого прохода – темы одной из будущих моих статей.

Дополнительно к PMBoK у PMI есть такие основные вещи: стандарты управления портфелями (проектов) и программой, стандарты управления рисками и Scrum Guide. PMBoK – не IT-книга, методики из свода применимы фактически ко всем проектам (для некоторых типов есть отдельные расширения) – маст хэв, в общем.

У PMI куча куч видов сертификаций, со ступенями и наворотами. Сертификаты PMI известны и популярны. Например, PMP – профессионал управления проектами – типа подтверждает, что ты можешь руководить проектами. Получить сертификаты организации не имея опыта нельзя, потому они больше как подтверждение, нежели как этот твой университетский диплом, который ты получил, пока учился учиться.

Международная Ассоциация Управления Проектами – такая же организация, как PMI, только европейская (Швейцария), и о ней меньше слышно. Работает с 1965 года, и изначально называлась Internet (когда интернета в помине не было).

Что они там делают – понятно мало. Ну, сертифицируют менеджеров. Выпускают свои журналы – сами и под представительствами. Зарабатывают деньги. И слава Б-гу.

“Принц” (PRojects IN Controlled Environments). Появилась методология в 1989 году, в Великобритании (и тут отделились). Ключевой особенностью методологии является польза, которую принесут процессы внутри проекта проекту. Минимизация рисков, соблюдение качества проекта. Еще у проектов PRINCE2 сложная организационная структура с комитетом проекта. В остальном, такие проекты, как проекты по другим методологиям, имеют старт, этапы и завершения – все знакомо и привычно.

«A Guidebook of Project and Program Management for Enterprise Innovation». Японская методология управления проектами – на этот раз свежее, она 1999 года. Тентаклями тут является акцент на инновации и управление ожиданиями заинтересованных лиц. Близко не сталкивался, не изучал, оценки дать не могу.

“Частная” методология управления проектами, MSF, была придумана и введена в работу в 1994 году майкрософтом. Она особенна тем, что разрабатывалась непосредственно под разработку программного обеспечения, а не адаптировалась, что можно сказать о том же PMBoK. Внешне похожа на список внутренних рекомендаций (типа как у вас в интре) для менеджеров проектов. В чистом виде не используется даже Microsoft – добавляют тот же эджайл, например. В википедии есть познавательная статья об этом фреймворке, прошу пройти туда – там больше, чем могу рассказать я.

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

В следующей части постараюсь рассказать про планирование задач и времени, включая собственный микроменеджмент. Статья должна помочь не только начинающим менеджерам, но и тем, кто с ними работает. Если хватит запала, то статья будет прям на этой неделе. Пишите письма.

Источник

Методология разработки 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 — это методология, где всё изначально продумано и зафиксировано, и в этом есть свои плюсы. Бывают проекты, которым она подходит, — такие, в которых все требования известны заранее и не могут измениться по ходу работы и где нет риска ошибиться.

В Digital такое бывает редко, поэтому команды добавляют к каскадной модели гибкие практики: например, проверяют продукт на соответствие требованиям после каждого этапа работы, а не в самом конце.

Руководитель digital-проектов

Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания. Вы будете работать над собственным проектом или над проектом реального заказчика по стандартам scrum-студии — отточите навыки тайм-менеджмента, научитесь конструктивной коммуникации в боевых условиях, овладеете искусством постановки задач и контроля команды.

Источник

Ещё раз про семь основных методологий разработки

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

1. «Waterfall Model» (каскадная модель или «водопад»)

Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.

С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний — рентгеновский микротомограф, мелкий — автообновление службы Windows на AWS.

Когда использовать каскадную методологию?

2. «V-Model»

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

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

Когда использовать V-модель?

3. «Incremental Model» (инкрементная модель)

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

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

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

Когда использовать инкрементную модель?

4. «RAD Model» (rapid application development model или быстрая разработка приложений)

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

Модель быстрой разработки приложений включает следующие фазы:

Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.

5. «Agile Model» (гибкая методология разработки)

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

В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:

Когда использовать Agile?

6. «Iterative Model» (итеративная или итерационная модель)

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

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

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

Когда оптимально использовать итеративную модель?

7. «Spiral Model» (спиральная модель)

«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.

Спиральная модель предполагает 4 этапа для каждого витка:

Подытожим

На слайде продемонстрированы различия двух наиболее распространенных методологий.

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

Источник