Что такое итеративный подход
Итеративная разработка программного обеспечения
Итеративная разработка ПО — это процесс создания программного обеспечения, который осуществляется небольшими этапами, в ходе которых ведется анализ полученных промежуточных результатов, выдвигаются новые требования и корректируются предыдущие этапы работы.
Жизненный цикл проекта при итерационной разработке разбит на последовательность итераций, каждая из которых, по сути, является проектом в миниатюре, то есть включает в себя все процессы разработки ПО (сбор и анализ требований, составление спецификаций, непосредственную реализацию, тестирование и запуск), но в рамках одной итерации разрабатывается не весь проект, а только его версия или отдельная часть.
Как правило, цель каждой итерации — это получение версии ПО, включающей в себя как новые или преработанные возможности, реализованные в ходе текущей итерации, так и функциональность всех предыдущих итераций. Результат же финальной итерации содержит всю требуемую функциональность продукта.
Бюджет и сроки, необходимые для реализации финальной версии обычно изначально не устанавливаются, так как не определяется общий объём работ и требования формируются по ходу реализации.
Итеративная, итерационная, инкрементная и эволюционная разработка — фактически, это синонимы.
Итеративность (iteration, «повторение») в данном случае означает подход, основаный на выполнении задач в рамках «мини-проектов», инкрементность (increment «увеличение») означает последовательное добавление функционала к разрабатываемому продукту, а эволюционность (evolutio, «развёртывание») — процесс развития продукта, напоминающий естественное развитие биологических видов.
Водопадная и итеративная модели разработки
Метафорически сравнение водопадной и итеративной моделей разработки часто описывают на примере разработки транспортного средства.
В случае с «водопадом» сначала описываются требуемые характеристики автомобиля, затем по этим требованиям разрабатывается проектная документация. После составления проектной документации собираются отдельные узлы автомобиля и происходит их взаимная интеграция. Результат сборки тестируется на соответствие проектной документации и после это созданный автомобиль передается заказчику. Все эти этапы занимают достаточно продолжительное время, а пригодный для использования продукт заказчик получает только в самом конце.
В случае с итеративным подходом всё несколько иначе. Изначально ставится задача разработки транспортного средства. И результатом первой итерации может быть вариант такого транспортного средства — например, самокат. Для него не нужен двигатель внутреннего сгорания и собрать его можно в десятки раз быстрее, чем автомобиль. Да, самокат проигрывает автомобилю по очень многим характеристикам, но он всё же более эффективен для передвижения, чем хождение пешком. Результатом второй итерации может быть уже самокат с электродвигателем. На третьей итерации — у самоката могут быть увеличены колеса и он превратится в электровелосипед. На четвертой — электровелосипед может быть оснащён ДВС и станет мотоциклом.
По сути, с каждой итерацией повышаются функциональные возможности. И пока сторонники водопада ждут готовность создаваемого автомобиля, любители итерационного подхода уже пользуются транспортным средством. И вполне может быть, что получившийся в итоге мотоцикл — более правильный бизнес-результат.
Основные преимущества итеративной модели разработки
Снижение рисков — раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта; большая фокусировка на основных задачах; динамическое формирование требований и управление ими.
Организация эффективной обратной связи проектной команды с потребителем, создание продукта, реально отвечающего его потребностям.
Быстрый выпуск минимально ценного продукта (MVP) и возможность вывести продукт на рынок и начать эксплуатацию гораздо раньше.
Основные недостатки итеративной модели разработки
Проблемы с архитектурой и накладные расходы — при работе с хаотичными требованиями и без проработанного глобального плана архитектура приложения может пострадать, а на её приведение к адекватному виду могут потребоваться дополнительные ресурсы. По сути, за возможность менять требования в ходе создания продукта, приходится так или иначе расплачиваться.
Нет фиксированного бюджета и сроков, а также нужна сильная вовлеченность Заказчика в процесс — для некоторых Заказчиков это неприемлемые условия сотрудничества с разработчиком, им лучше подойдёт водопадная модель.
Резюме
Итеративная разработка отлично подходит для больших проектов, для проектов с неопределенными требованиями и для программных продуктов, которые носят инновационный характер и основаны на бизнес-гипотезах, требующих проверки.
Итеративная разработка — это оптимальный выбор:
Водопадная модель разработки
Водопадная модель разработки программного обеспечения — это процесс разработки, в котором все необходимые этапы проходят строго последовательно.
Разработка ПО по водопадной модели начинается со сбора и анализа требований, затем следует фаза проектирования и прототипирования. После завершения полного проектирования начинается этап программной реализации. После завершения этапа программирования разработанный продукт тестируется на соответствие требованиям. Затем осуществляется интеграция и запуск, после чего проект переходи в фазу поддержки и сопровождения.
Разработка ПО на основе водопадной модели эффективна при полном и детальном понимании целей и задач проекта. Благодаря работе по строгой спецификации, эта модель позволяет строго зафиксировать бюджет и сроки проекта.
Что такое итеративный подход
Проект, в котором применяется итерационная разработка, имеет жизненный цикл, состоящий из нескольких итераций. Итерация включает приблизительно последовательный набор задач бизнес-моделирования, требований, анализа и проектирования, реализации, тестирования и развертывания в различных пропорциях, в зависимости от расположения итерации в цикле разработки. Итерации на начальном этапе и этапе уточнения фокусируются на управлении, требованиях и проектировании; итерации на этапе построения фокусируются на проектировании, реализации и тестировании; а итерации на этапе внедрения фокусируются на тестировании и развертывании. Итерациями следует управлять как timeboxed, то есть расписание итерации следует считать фиксированным и управлять областью содержимого итерации, чтобы она соответствовала этому расписанию.
Зачем нужна итерационная разработка?
В начальном проекте по отношению к его ключевым требованиям с большой вероятностью будут содержаться ошибки. Позднее обнаружение дефектов проекта приводит к дорогостоящим затратам и, в некоторых случаях, даже к прекращению проекта.
Любой проект влечет за собой определенные риски. Чем раньше в жизненном цикле можно проверить отсутствие рисков, тем более точно можно выполнять планирование. Многие риски не удается обнаружить до тех пор, пока не будет предпринята попытка интеграции системы. Невозможно предугадать все риски, независимо от опыта коллектива разработчиков.
В водопадном жизненном цикле невозможно убедиться в отсутствии рисков на ранних этапах жизненного цикла.
В итерационном жизненном цикле вы на основании списка ключевых рисков выбираете инкремент для разработки в итерации. Поскольку в итерации создается протестированный исполняемый продукт, то можно проверить, были ли в результате снижены риски или нет.
Преимущества итерационного подхода
Итерационный подход в целом имеет преимущество перед линейным или водопадным подходом по целому ряду причин.
Однажды заказчик сказал: «При водопадном подходе все выглядит прекрасно практически до конца проекта, иногда вплоть до середины интеграции. А затем все распадается. При итеративном подходе очень трудно долго скрывать правду.»
Руководители проектов часто оказывают сопротивление итерационному подходу, считая его бесконечным. В Rational Unified Process итерационный подход полностью управляем; планируется число, продолжительность и цели итераций. Определяются задачи и ответственности участников. Собираются объективные показатели выполнения. От одной итерации к следующей существует некоторый объем повторяющихся действий, однако это также тщательно контролируется.
Снижение рисков
Итерационный подход позволяет снизить риски раньше, поскольку многие риски обнаруживаются только во время интеграции. При развертывании ранней итерации вы проходите через все разделы, изучая многие аспекты проекта: инструменты, готовое программное обеспечение, навыки сотрудников и так далее. Предполагаемые риски могут не подтвердиться, в то время как могут быть обнаружены новые, неожиданные риски.
Внесение изменений
Итерационный подход позволяет учитывать изменения в требованиях, поскольку обычно они будут изменяться по мере работы над проектом.
Итеративный жизненный цикл обеспечивает управление путем внесения тактических изменений в продукт. Например, для того чтобы составить конкуренцию существующим продуктам, вы можете принять решение выпустить продукт с ограниченным набором функций раньше, для того чтобы опередить действия конкурента, либо можно адаптировать другого вендора для данной технологии.
Итерации также поддерживают технологические изменения по мере продвижения работы над проектом. Если какая-либо технология изменяется или становится стандартом при появлении новой технологии, то это может дать проекту определенные преимущества. Это в особенности относится к изменениям платформы и изменениям инфраструктуры на более низких уровнях.
Достижение более высокого качества
Итерационный подход позволяет получить более устойчивую архитектуру, поскольку ошибки исправляются на протяжении нескольких итераций. Первые дефекты обнаруживаются уже в первых итерациях продукта. Обнаруживаются узкие места в производительности, которые можно исправить сразу, а не непосредственно перед доставкой.
Итерационная разработка, в отличие от выполнения тестов в конце проекта, позволяет протестировать продукт более тщательно. Наиболее важные функции можно протестировать в нескольких итерациях.
Обучение и улучшение
Разработчики могут обучаться по мере продвижения работы, и различные умения и специализации более полно используются в течение всего жизненного цикла.
Тестеры, вместо длительного ожидания, в течение которого они только строят планы и оттачивают свои навыки, начинают выполнять тестирование раньше, раньше начинается создание технической документации и так далее. При оценке ранних итераций можно обнаружить необходимость в дополнительном обучении или помощи извне.
Также можно улучшить сам процесс. Оценка в конце итерации не только дает обзор состояния проекта с точки зрения планирования продукта, но также позволяет проанализировать, что необходимо изменить в организации и проекте для улучшения работы в следующей итерации.
Увеличение возможностей повторного применения
Итерационный жизненный цикл облегчает повторное применение. Облегчается идентификация стандартных компонентов, если они разрабатываются или реализуются по-отдельности, по сравнению с идентификацией всей общности.
Идентификация и разработка многоразовых компонентов является сложной задачей. Обзоры проекта в ранних итерациях позволяют архитекторам программного обеспечения обнаружить возможность потенциального повторного применения, и в последующих итерациях они могут далее разрабатывать и развивать этот стандартный исходный код.
Применение итерационного подхода облегчает использование преимуществ коммерческих готовых продуктов. На протяжении нескольких итераций можно выбрать такие продукты, интегрировать их и убедиться, что они соответствуют данной архитектуре.
© Copyright IBM Corp. 1987, 2006. Все права защищены..
Итеративный подход к решению инженерных задач
Ну вот, дожил и я до того дня, когда меня потянуло написать в этот блог.
Доброго времени суток, хабрачеловек!
Так уж сложилось, что многие из обитающих на славном Хабре жителей так или иначе связаны с разработкой. Под разработкой я здесь подразумеваю чуть более широкий и абстрактный термин, чем написание программ. Разработка — это прежде всего созидательные действия, творческий процесс. На входе этого процесса — мысль, идея, а на выходе — осязаемый продукт, детище разработчика. Конечным продуктом может быть все, что угодно: сайт, дизайн, программа, хитроумный девайс, умный дом и пр.
Привыкнув к некоторой самостоятельности в своих действиях и не брезгуя принимать решения я зачастую сам создаю себе проблемы ставлю себе задачи, которые потом приходится решать. Этим, собственно, и зарабатываю на хлеб с маслом. Заимев за плечами некоторое множество успешно решенных задач и потратив на это кучу времени, пришла банальная мысль, что каждый раз сталкиваешься с одной и той же последовательностью шагов по их решению, при прохождении которых наступаешь на одни и те же грабли. Потерев в очередной раз ушибленный лоб, мои руки решили наконец положить конец такому положению вещей и начали что-то судорожно записывать в склерозник. В итоге родился хитроумный план по борьбе с шишками на лбу, который за последние несколько месяцев сэкономил мне некоторое количество человеко-часов. Подробности по катом.
Представим себе стандартную для инженера ситуацию — в нашем мозгу появилась идея. Родилась сама, была подкинута сочувствующими товарищами или инъецирована заказчиком очередного бредового проекта — механизм ее появления в мозгу не важен. Предположим, что идея звучит так: «Счастья всем, даром! И пусть никто не уйдет обиженным!» (с). Обычно, из формулировки идеи очевидно, ЧТО мы хотим получить в итоге. Зато не очевидно КАК мы хотим этого добиться. Вот тут-то перед нами и появляется задача. Задача реализации идеи.
Задачи нужно решать. Так учили в школе. Но каким образом взяться за эту гладкую без единой зацепки особу? Мы чувствуем смятение, вызванное незнанием, что конкретно необходимо сделать для решения поставленной задачи. Итак,
предлагаю следующий алгоритм. Сразу обмолвлюсь, что не претендую здесь на оригинальность, возможно подобный поход уже был описан где-то еще, но я его раньше не встречал. 
Отправным пунктом будем считать формулировку задачи («раздобыть где-нибудь счастья на всех»). Будем считать, что мы работаем над проектом по его добыче. Что же нужно первым делом сделать для его выполнения? Для начала необходимо сформулировать то, как проект на выходе для себя представляет заказчик (в данном конкретном примере — все человечество, в общем же случае это может быть работодатель или даже мы сами). То есть выявить внешние требования к проекту. В нашем случае все просто — каждый житель земного шара должен стать счастливым. В общем же случае результатом данного шага может быть пара страниц текста, содержащая самые общие сведения о конечной цели. В случае, когда результат трудно описать общими фразами, можно прибегнуть к описанию желаемого через способ его употребления конечными пользователями (пользователи должны видеть две кнопки «еще счастья» и «поделиться счастьем с соседями». При нажатии на кнопку 1… и т.д.).
Так, уже лучше, так как половина дела сделана — мы приступили к работе! Что дальше? Далее необходимо изучить предметную область, в которой придется работать. Цель данного этапа — познакомиться или обновить в памяти способы работы с сущностями данной предметной области, научиться разговаривать и думать в терминах решаемой задачи. Конечным результатом второго этапа является преобразование общих требований, полученных на шаге 1, в четкие подзадачи по достижению этих требований. В нашем случае это может выглядеть примерно так: «Счастье… Что же это такое и с чем его едят? Счастье — это состояние души, достигаемое при благоприятной совокупности внешних и внутренних факторов, влияющих на конкретного индивида. Детей счастливыми делает мороженое, влюбленных — поцелуи, политиков — власть, сисадминов — резервное копирование. Следовательно, необходимо следующее: построить заводы по производству власти, наделить детей мороженным. »
Наконец-то мы как никогда близки к самому любимому — к собственно реализации. Но не спешим — сначала необходимо оценить время, которое потребуется на выполнение каждой подзадачи в отдельности. К этому моменту мы уже максимально упростили себе жизнь, написав спецификации, осталось лишь проставить цифры («Сделать счастливыми жителей Австралии — 48 часов, Албании — 32 часа, Америки — 72 часа. »). Основная цель данного этапа — постараться загнать каждую из подзадач в некоторые временные рамки. На самом деле, несмотря на существование огромного числа методик планирования и оценки трудозатрат, данный этап является весьма абстрагированным от действительности и рядом с цифрами правильнее было бы проставлять не часы, а попугаев, но некоторая аппроксимация все же будет получена. И это приближение будет все точнее при каждой последующей итерации (о которых мы пока ни слова не сказали). Результат — графики работ над проектом.
Ну вот и настал сладостный момент, когда нужно поработать руками. Смело хватаемся за клавиатуры, молотки, паяльники и прочие орудия труда и претворяем задуманное и описанное в жизнь. Мы на этапе реализации. Результатом будет являться код, микросхема, девайс, что угодно, но — лишь пробная версия. Вот тут появляется развилка — удовлетворяет ли наше детище тому, о чем мы так давно говорили на этапе 1? Если да — смело подводим итоги и отправляем его во взрослую жизнь. Но с первой попытки ответить «да» на этот вопрос удается очень редко. Скорее всего по прошествии всех вышеописанных этапов мы лишь осознаем, что теперь лучше понимаем, чего же мы хотели добиться в результате, что нужно делать, чтобы реализовать идею и добиться цели. Что же мы имеем в качестве настоящего результата этапа реализации? Более четкие, осознанные, опробованные на практике, родившиеся в боях требования! Ну что, уже догадались? Смело на этап 1! Первая итерация прошла успешно, поздравляю, коллега!
Заключение
Описанный метод — суть инструмент, позволяющий унифицированно подходить к решению любой технической задачи, минимизировав стадию смятения. Итеративность и разбиение на этапы внутри каждой итерации позволяют максимально концентрироваться над каждой из задач. А концентрация — залог качества и успешности. Правда стоит помнить, что лучшее — враг хорошего, поэтому излишнего перфекционизма все же следует избегать.
Успехов в ваших начинаниях, друзья!
UPD: Пользователь iasonov предложил смотреть в направлении ТРИЗ:: АРИЗ, в котором имеется вот такая интересная схема. Все дружно топаем и изучаем.
Непрерывный цикл разработки — это как?
CI/CD на простых примерах
В разработке любого софта есть два подхода: итеративный и непрерывный. Они отличаются методами работы и сложностью организации. Если будете работать в сфере ИТ, наверняка вам встретятся оба подхода.
Итеративный подход
Итеративный — это значит, что разработка идёт итерациями, отдельными шагами. Разработчики пишут код, потом проверяют его и выпускают новую версию программы. После этого отдыхают, и снова за работу — пилить следующую версию.
👉 В итеративном подходе заказчик или пользователи видят результат только в самом конце этапа и до этого пользуются старой версией.
Непрерывный подход
Непрерывный подход — это когда разработка идёт маленькими шажками каждый день, и каждый день в репозиторий отправляются какие-то мелкие изменения. Если вы не знаете, что такое репозиторий, почитайте наш гит-словарик, с ним будет гораздо проще.
👉 При непрерывном подходе пользователи каждый день получают новую версию, которой уже можно пользоваться.
Непрерывная интеграция
Чтобы непрерывная разработка работала как задумано, для неё нужно подготовить особые условия работы:
👉 В программировании непрерывный подход называют непрерывной интеграцией (Continuous Integration, CI), потому что результаты работы за день сразу интегрируются в мастер-ветку продукта.
Непрерывная доставка
Ежедневная внутренняя сборка ещё не означает, что эта версия сразу попадёт к пользователям. Для этого нужно настроить другие процессы:
👉 Такие действия называют непрерывной доставкой (Continuous Delivery, CD), потому что они доставляют пользователям свежие результаты работы программистов. Обычно эти две аббревиатуры, CI/CD, используются вместе, потому что это взаимосвязанные процессы. Непрерывная интеграция постоянно выдаёт свежие версии, а непрерывная доставка делает их доступными для пользователей.
Кто это настраивает
Почти всё из этого зависит от тестировщиков и девопсов.
Тестировщики следят за тем, чтобы все новые изменения работали без сбоёв и не ломали то, что было до этого. Так как новые версии появляются каждый день, то тестировщикам нужно переложить как можно больше задач на автоматическое тестирование. Это позволяет держать темп и тестировать вручную только сложные моменты или то, что не удалось покрыть автотестами.
Задача девопсов — подготовить среду разработки и тестирования, чтобы всё работало максимально автоматически:
Зачем это нужно
Смысл CI/CD в том, чтобы не откладывать процесс финальной сборки на самый конец, как это делается в итеративном подходе, а собирать все кусочки по чуть-чуть, но сразу. Это позволяет пользователям постоянно получать свежие версии программ, а разработчикам — не опасаться того, что на этапе финальной сборки всё сломается.
Кому не подходит
Непрерывная разработка — дорогой и сложный процесс, который не подходит маленьким командам с ограниченным бюджетом. Для настройки и запуска такого процесса нужно нанимать много разных специалистов, а это дорого и не всегда оправданно.
А ещё есть области, в которых важна не скорость появления новых фич, а стабильность — медицина, космонавтика, пассажирские перевозки. Там новые версии могут выходить раз в три года, и это нормально — главное, чтобы работало без сбоёв.
Ещё раз про семь основных методологий разработки
Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся 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 не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.