Чем инкрементная модель отличается от итеративной

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

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

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

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

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

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

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

2. «V-Model»

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

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

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

• Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
• Для малых и средних проектов, где требования четко определены и фиксированы.
• В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

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». На ежедневных совещаниях участники команды обсуждают:

• отчёт о проделанной работе с момента последнего Scrum’a;
• список задач, которые сотрудник должен выполнить до следующего собрания;
• затруднения, возникшие в ходе работы.

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

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

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

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

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

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

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

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

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

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

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

1. планирование;
2. анализ рисков;
3. конструирование;
4. оценка результата и при удовлетворительном качестве переход к новому витку.

Подытожим

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

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

Модели и методологии разработки ПО

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

Этапы жизненного цикла ПО

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

Рассмотрим эти этапы на примере жизненного цикла интернет-магазина.

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

Проектирование. Иван выбрал компанию-подрядчика и обсудил с её специалистами архитектуру и дизайн будущего интернет-магазина.

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

Поддержка. Иван подписал акт сдачи-приёмки, и подрядчик разместил интернет-магазин на «боевых» серверах. Пользователи начали его посещать и сообщать о замеченных ошибках в поддержку, а программисты — оперативно всё исправлять.

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

А методология включает в себя набор методов по управлению разработкой: это правила, техники и принципы, которые делают её более эффективной.

Основные модели разработки ПО

• Code and fix — модель кодирования и устранения ошибок;
• Waterfall Model — каскадная модель, или «водопад»;
• V-model — V-образная модель, разработка через тестирование;
• Incremental Model — инкрементная модель;
• Iterative Model — итеративная (или итерационная) модель;
• Spiral Model — спиральная модель;
• Chaos model — модель хаоса;
• Prototype Model — прототипная модель.

Из этих моделей наиболее популярны пять основных: каскадная, V-образная, инкрементная, итерационная и спиральная. Разберём их подробнее.

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

В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.

Преимущества «водопада»

• Разработку просто контролировать. Заказчик всегда знает, чем сейчас заняты программисты, может управлять сроками и стоимостью.
• Стоимость проекта определяется на начальном этапе. Все шаги запланированы уже на этапе согласования договора, ПО пишется непрерывно «от и до».
• Не нужно нанимать тестировщиков с серьёзной технической подготовкой. Тестировщики смогут опираться на подробную техническую документацию.

Недостатки каскадной модели

• Тестирование начинается на последних этапах разработки. Если в требованиях к продукту была допущена ошибка, то исправить её будет стоить дорого. Тестировщики обнаружат её, когда разработчик уже написал код, а технические писатели — документацию.
• Заказчик видит готовый продукт в конце разработки и только тогда может дать обратную связь. Велика вероятность, что результат его не устроит.
• Разработчики пишут много технической документации, что задерживает работы. Чем обширнее документация у проекта, тем больше изменений нужно вносить и дольше их согласовывать.

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

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

V-образная модель (разработка через тестирование)

Это усовершенствованная каскадная модель, в которой заказчик с командой программистов одновременно составляют требования к системе и описывают, как будут тестировать её на каждом этапе. История этой модели начинается в 1980-х.

Преимущества V-образной модели

• Количество ошибок в архитектуре ПО сводится к минимуму.

Недостатки V-образной модели

• Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её будет стоить дорого, как и в «водопаде».

V-модель подходит для проектов, в которых важна надёжность и цена ошибки очень высока. Например, при разработке подушек безопасности для автомобилей или систем наблюдения за пациентами в клиниках.

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

Это модель разработки по частям (increment в переводе с англ. — приращение) уходит корнями в 1930-е. Рассмотрим её на примере создания социальной сети.

1. Заказчик решил, что хочет запустить соцсеть, и написал подробное техническое задание. Программисты предложили реализовать основные функции — страницу с личной информацией и чат. А затем протестировать на пользователях, «взлетит или нет».
2. Команда разработки показывает продукт заказчику и выпускает его на рынок. Если и заказчику, и пользователям социальная сеть нравится, работа над ней продолжается, но уже по частям.
3. Программисты параллельно создают функциональность для загрузки фотографий, обмена документами, прослушивания музыки и других действий, согласованных с заказчиком. Инкремент за инкрементом они совершенствуют продукт, приближаясь к описанному в техническом задании.

Преимущества инкрементной модели

• Не нужно вкладывать много денег на начальном этапе. Заказчик оплачивает создание основных функций, получает продукт, «выкатывает» его на рынок — и по итогам обратной связи решает, продолжать ли разработку.
• Можно быстро получить фидбэк от пользователей и оперативно обновить техническое задание. Так снижается риск создать продукт, который никому не нужен.
• Ошибка обходится дешевле. Если при разработке архитектуры была допущена ошибка, то исправить её будет стоить не так дорого, как в «водопаде» или V-образной модели.

Недостатки инкрементной модели

• Каждая команда программистов разрабатывает свою функциональность и может реализовать интерфейс продукта по-своему. Чтобы этого не произошло, важно на этапе обсуждения техзадания объяснить, каким он будет, чтобы у всех участников проекта сложилось единое понимание.
• Разработчики будут оттягивать доработку основной функциональности и «пилить мелочёвку». Чтобы этого не случилось, менеджер проекта должен контролировать, чем занимается каждая команда.

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

Iterative Model (итеративная модель)

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

Рассмотрим на примере создания мессенджера, как эта модель работает.

1. Заказчик решил, что хочет создать мессенджер. Разработчики сделали приложение, в котором можно добавить друга и запустить чат на двоих.
2. Мессенджер «выкатили» в магазин приложений, пользователи начали его скачивать и активно использовать. Заказчик понял, что продукт пользуется популярностью, и решил его доработать.
3. Программисты добавили в мессенджер возможность просмотра видео, загрузки фотографий, записи аудиосообщений. Они постепенно улучшают функциональность приложения, адаптируют его к требованиям рынка.

Преимущества итеративной модели

• Быстрый выпуск минимального продукта даёт возможность оперативно получать обратную связь от заказчика и пользователей. А значит, фокусироваться на наиболее важных функциях ПО и улучшать их в соответствии с требованиями рынка и пожеланиями клиента.
• Постоянное тестирование пользователями позволяет быстро обнаруживать и устранять ошибки.

Недостатки итеративной модели

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

Итеративная модель подходит для работы над большими проектами с неопределёнными требованиями, либо для задач с инновационным подходом, когда заказчик не уверен в результате.

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

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

Рассмотрим, как функционирует эта модель, на примере разработки системы «Умный дом».

1. Заказчик решил, что хочет сделать такую систему, и заказал программистам реализовать управление чайником с телефона. Они начали действовать по модели «водопад»: выслушали идею, провели анализ предложений на рынке, обсудили с заказчиком архитектуру системы, решили, как будут её реализовывать, разработали, протестировали и «выкатили» конечный продукт.
2. Заказчик оценил результат и риски: насколько нужна пользователям следующая версия продукта — уже с управлением телевизором. Рассчитал сроки, бюджет и заказал разработку. Программисты действовали по каскадной модели и представили заказчику более сложный продукт, разработанный на базе первого.
3. Заказчик подумал, что пора создать функциональность для управления холодильником с телефона. Но, анализируя риски, понял, что в холодильник сложно встроить Wi-Fi-модуль, да и производители не заинтересованы в сотрудничестве по этому вопросу. Следовательно, риски превышают потенциальную выгоду. На основе полученных данных заказчик решил прекратить разработку и совершенствовать имеющуюся функциональность, чтобы со временем понять, как развивать систему «Умный дом».

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

Преимущества спиральной модели

• Большое внимание уделяется проработке рисков.

Недостатки спиральной модели

• Есть риск застрять на начальном этапе — бесконечно совершенствовать первую версию продукта и не продвинуться к следующим.
• Разработка длится долго и стоит дорого.

На основе итеративной модели была создана Agile — не модель и не методология, а скорее подход к разработке.

Что такое Agile?

Agile («эджайл») переводится с английского как «гибкий». Включает в себя практики, подходы и методологии, которые помогают создавать продукт более эффективно:

• экстремальное программирование (Extreme Programming, XP);
• бережливую разработку программного обеспечения (Lean);
• фреймворк для управления проектами Scrum;
• разработку, управляемую функциональностью (Feature-driven development, FDD);
• разработку через тестирование (Test-driven development, TDD);
• методологию «чистой комнаты» (Cleanroom Software Engineering);
• итеративно-инкрементальный метод разработки (OpenUP);
• методологию разработки Microsoft Solutions Framework (MSF);
• метод разработки динамических систем (Dynamic Systems Development Method, DSDM);
• метод управления разработкой Kanban.

Различия между Agile и традиционным подходом к разработке мы свели в таблице:

Не всё перечисленное в списке — методологии. Например, Scrum чаще называют не методологией, а фреймворком. В чём разница? Фреймворк — это более сформированная методология со строгими правилами. В скраме все роли и процессы чётко прописаны. Помимо Scrum, часто используют Kanban.

Kanban

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

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

Совсем скоро мы организуем трёхдневный онлайн-интенсив по Agile-методологиям. На нём вы научитесь использовать все преимущества этого подхода, управлять разработкой и выпускать проекты любой сложности. Ждём вас!

Модели и методологии разработки стартапа

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

11K открытий
Что такое модель разработки продукта и для чего она нужна

Модель разработки продукта — это то, через какие стадии он проходит во время создания и что происходит на каждой из них. Если речь идет о разработке программного обеспечения, то, как правило, проект проходит через шесть основных фаз. Это:

• Планирование. Определяем, что делаем и какие проблемы решаем. Ставим цели, выясняем, какие ресурсы нам нужны для реализации проекта. Изучаем рынок и конкурентов, прорабатываем альтернативные варианты разработки продукта.
• Анализ системы. Определяем и документируем требования конечного пользователя системы. Какие ожидания есть у нашего потребителя и как мы можем их осуществить? Можем ли мы это сделать вообще?
• Дизайн. Определяем элементы системы, ее компоненты, уровень безопасности, архитектуру, интерфейсы, типы данных. Рисуем дизайн, обсуждаем, проектируем.
• Разработка и внедрение. К началу этой стадии дизайн уже завершен, наступает очередь разработки. Пишем код, настраиваем систему под определенные требования и функции. К концу фазы система готова к установке и запуску.
• Тестирование. Проверяем, получили мы в итоге то, что хотели, или же результаты работы оказались другими. Тестируем продукт автоматизированными тестами, командой, предлагаем поработать с системой потенциальным пользователям. Определяем дефекты и недостатки в работе системы и устраняем их.
• Поддержка системы. Подготовка и выпуск обновлений, оценка производительности системы, замена/деактивация устаревших компонентов.

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

Вот список классических моделей:

• Code and Fix (написание кода, проверка и устранение ошибок),
• Waterfall (проект последовательно проходит все стадии),
• V-Model (проведение тестирования одновременно с разработкой),
• Инкрементная модель (проект делится на составные компоненты, команда по очереди готовит каждый из них, затем происходит финальная сборка),
• Спиральная модель (предусматривает тщательную проработку рисков),
• Итеративная модель (сначала делается базовая модель продукта, затем следуют итерации по ее усовершенствованию),
• RAD-Model (скоростная разработка продукта).

Классические модели предполагают акцент на последовательности, сроках, конечных требованиях к продукту.

Что касается гибких моделей, то это всем известный Agile. Когда мы работаем над продуктом по гибкой модели, наш проект и требования к нему могут меняться в течение каждой итерации (гибкая модель, когда проект может изменяться с каждой итерацией), а что касается сроков, то работа может вестись бесконечно — вы будете совершенствовать продукт и добавлять в него новый функционал.

Наконец, методологии разработки — это применение той или иной модели на практике. Так, Agile-модель имеет целый ряд довольно популярных методологий — от мягкого Kanban, когда команда работает с доской с задачами, до жестких Scrum и XP.

Теперь рассмотрим особенности каждой из упомянутых моделей.

Code-and-Fix

Это одна из самых старых моделей разработки: она очень проста и подойдет стартапам, где команда невелика, нет особых конфликтов, вы знаете, что хотите сделать и имеете представление, как это сделать.

Как работает Code-and-Fix: у нас есть понимание, что мы хотим сделать. Начинаем программировать, затем смотрим, что получилось. Выявляем баги, правим их и снова смотрим — и так, пока наш продукт не начнет работать.

Плюсы методологии: не нужно тратить время на планы, документацию, митинги.

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

Одним из первых выходов стал Waterfall, или водопадная (каскадная) модель разработки. Это классическая жесткая модель: у вас есть план, бюджет и вы строго выполняете этап за этапом.

Разработка продукта идет по ступенькам: вы изучаете требования, проектируете продукт, разрабатываете его, тестируете и затем поддерживаете его работу. Новый этап не начинается, пока не завершится предыдущий. Ошибки, допущенные на этапах изучения требований и проектирования, очень сложно исправить — как в финансовом плане, так и в техническом — и это самая большая проблема этой модели.

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

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

Эта модель используется при разработке программ для строительства, медицины, работы с государственными контрактами. Если говорить о непрограммных продуктах, то каскадная модель применяется для строительства крупных объектов.

Емко этот метод описал Чак Кобб, автор книг по проектному менеджменту:

Если бы вы строили мост через реку, было бы смешно сказать: «Мы построим первый пролет, посмотрим, как это выходит, а затем решим, как закончить оставшиеся пролеты!”

Действительно, в таких объектах должен быть заранее утвержденный план, макет, прототип, и изменения, как правило, не предусматриваются.

Каскадную модель применяли: компания Cisco для разработки систем безопасности, IBM, Microsoft IT и даже Toyota.

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

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

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

Инкрементная модель

Эта модель разработки дает возможность делать продукт по частям — инкрементам. Каждая часть представляет собой готовый фрагмент итогового продукта, который в идеале не переделывается.

Мы получаем несколько циклов разработки — своеобразный “мультиводопад”. Каждый цикл делится на модули, каждый модуль — на фазы: определение требований, проектирование, написание кода, внедрение, тестирование.

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

Спиральная модель

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

Для разработки продукта по спиральной модели часто проводятся специальные научные исследования и аппробации.

Разработка идет по спиралям, каждая из которых состоит из четырех основных этапов: планирования, анализа рисков, конструирования, оценки результатов.

Спиральная модель довольно затратна в применении, поэтому не подходит для небольших проектов. А вот для средних и больших ее можно применять, особенно, если вы боитесь прогореть.

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

Кейс GanttPRO. Приложение для управления проектами и задачами GanttPRO разрабатывалось по принципам спиральной модели, а также фреймворка Agile — Scrum, о котором расскажу чуть ниже. Разработчики выбрали довольно короткие двухнедельные периоды релизов для того, чтобы иметь возможность часто получать отзывы. Также был создан детальный план того, что должно было быть реализовано на первой итерации и как проработать различные риски. Например, перед первой итерацией каждый разработчик высказался по поводу того, что из запланированного может не быть реализовано и почему. Кроме того, команда уделила особое внимание снижению рисков, вызванных необходимостью быстрой адаптации к нуждам пользователей и рынка.

Итеративная модель

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

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

Модель подходит для стартапа, который хочет как можно быстрее выйти на рынок и привлечь клиентов.

Кейс “Самокат”. Метафорически итеративную модель можно проиллюстрировать на примере разработки транспортного средства. Результатом первой итерации может стать самокат. Это пример транспорта, хоть и максимально простого. Результатом второй итерации может стать самокат с электродвигателем, третьей — электровелосипед, четвертой — мотоцикл. Таким образом, с каждой итерацией повышаются функциональные возможности продукта, созданного еще во время первой итерации. Сравним разработку этого же транспортного средства по водопадной модели: траспорт мы получим в самом конце, после того, как будут завершены все стадии проекта.

RAD-Model, или Rapid Application Development Model

Разновидность инкрементной модели. Появилась в конце 80-х годов и стала одной из попыток создания гибкого процесса разработки.

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

Плюсы такой модели разработки — скорость. Минусы — финансирование.

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

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

Agile имеет множество вариаций и фреймворков. Среди самых известных: Scrum, Kanban, экстремальное программирование (XP), Lean.

Является одной из методологий Agile. Метод базируется на концепции бережливого производства, основанной на стремлении к устранению всех потерь — временных, производственных, логистических, качественных.

Особенность Kanban — задачи должны выполняться точно в срок, нагрузка между командой распределяется равномерно.

На практике это выглядит следующим образом. Каждая задача по проекту описывается в отдельной карточке и добавляется на доску — виртуальную или настоящую. Карточка и доска — неотъемлемые элементы Kanban. Все задачи, которые необходимо сделать, собраны в специальной колонке, условно, она может называться “сделать”/ “to do”. Исполнитель выбирает задачу и перемещает в колонку “в процессе” / “in progress”. Когда задача сделана, она попадает в соответствующую колонку “готово” / “done”. На практике колонок может быть гораздо больше, чем три. К примеру, колонки на доске могут выглядеть так: “обсуждается” (backlog), “согласовано” (ready), “кодируется” (coding), “тестируется” (testing), “подтверждается” (approval) и “сделано” (done).

Есть множество инструментов для того, чтобы выстроить работу команды по Kanban. О некоторых из них можно почитать в статье “Инструменты для командной работы над стартапом”.

Кейс “Тойота”. Методология Kanban родилась на производстве в компании Toyota. Мастера участков перечисляли выполняемые работы на бумаге и вывешивали их на видном месте — так и родилась доска канбан, один из элементов методологии. В основе производства Toyota — годовой план производства и сбыта авто, на базе которого составляются месячные и оперативные планы среднесуточного выпуска на каждом участке, основывающиеся на прогнозировании покупательского спроса. Методология базируется на принципе “точно в срок”, что, помимо четкого следования таймингу по каждой задаче, позволяет раскрывать дефекты производства вовремя. Например, ежедневные контроль запасов продукции и деталей выявляет неисправности или простои.

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

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

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

Рассмотрим пример применения Scrum.

1. На этапе формирования продукта вы с командой решаете, кто из вас будет исполнять роль product owner — человека, который отвечает за связь команды с потребителем и инвесторами (если ваши инвесторы будут интересоваться ходом разработки продукта).

2. Product owner формирует список пожеланий к продукту, собирает первичную информацию от возможных пользователей и затем формирует бэклог продукта — список задач, выполнение которых в конце концов приведет вас к выходу на рынок.

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

4. В течение первого спринта вы отслеживаете качественные и количественные характеристики своей работы. Неотъемлемая часть скрама — ежедневные короткие (5–10) минут митинги, в течение которых каждый из участников команды рассказывает, что он планирует сделать за день, делится возникающими сложностями или, наоборот, успехами.

5. Ход выполнения задач отслеживается по скрам-доске, на которой все задачи двигаются от условной позиции “сделать” до “выполнено”.

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

7. Цикл спринтов повторяется до того момента, пока продукт не будет полностью завершен.

Экстремальное программирование (XP)

eXtreme Programming, экстремальное программирование, XP — гибкая методология разработки, которая появилась в конце 90-х годов прошлого столетия. Авторы взяли лучшие, на их взгляд, практики гибкой разработки и усилили их до максимума — отсюда и слово “экстремальный” в названии.

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

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

Другая особенность экстремального программирования заключается в том, что сначала готовятся тесты, и только потом — код. При этом тесты пишут сами программисты. Тестирование позволяет исправить большинство ошибок на стадии создания кода.

Третья особенность — коллективное владение кодом: каждый программист в команде имеет доступ к коду продукта и может вносить в него изменения. В том случае, если изменения привели к некорректной работе системы, исправить все должен тот программист, который внес эти изменения.

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

Наконец, интеграция новых частей в систему происходит так быстро как это возможно. Как только тесты показали, что функция работает корректно, она интегрируется в систему.

Чем инкрементная модель отличается от итеративной

1.2.2.2. Инкрементальная (инкрементная, поступательная) модель разработки

1.2.2.2. Инкрементальная (инкрементная, поступательная) модель разработки

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

Смысловую путаницу вызывают понятия итеративной и инкрементальной разработки. Согласно Алистеру Кокбернц (Alistair Cockburn) здесь имеем дело с двумя разными моделями разработки:

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

Согласно Яну Соммервиллю (Ian Sommerville) «итеративная модель разработки» скорее общее название для ряда так называемых гибридных моделей (в том числе, и инкрементальная и спиральная модели). Слово «итеративный» подчеркивает то, что действия в этой модели повторяются.

Независимо от того смысла, который стоит за итеративной разработкой, инкрементальная (поэтапная) разработка довольно однозначно описана в различных источниках.

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

Рисунок 1-2. Инкрементальная разработка

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

Ход действий заключается в следующем: прежде всего, определяются требования в более общей форме и подразделяются на более и менее важные. Затем определяются части поставки, то есть, в каком количестве и из чего состоящие поставки начнет получать клиент в качестве своего программного обеспечения. Под поставкой понимаются части системы, то есть инкремент (increment). Каждая поставка должна добавлять к системе определенную функциональность. При этом выпуск начинают с компонентов (частей) с наивысшим приоритетом. Когда части системы определены, берут первую часть и начинают ее детализировать, используя для этого наиболее подходящий процесс (и почему бы не водопадную модель). В то же время можно уточнять требования и для других частей, которые в текущей совокупности требований данной работы были заморожены. Если очень необходимо, можно позже возвратиться к этой части. Если часть готова, то она поставляется клиенту (заказчику), который может использовать ее в работе (или, по крайней мере, серьезно испытать). Это позволит клиенту уточнить требования для следующих компонентов (частей) (или для последующих версий того же самого компонента). Затем занимаются со следующей частью системы. Новые части состыковываются с существующей системой. Все части не должны разрабатываться с использованием одного и того же процесса.

Преимущества инкрементальной (поэтапной) разработки:

1. Затраты, которые получаются в связи с изменением требований пользователей, уменьшаются, повторный анализ и совокупность документации значительно сокращаются по сравнению с водопадной (каскадной) моделью.

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

3. У клиента имеется возможность быстро получить и освоить созданное программное обеспечение — клиенты могут получить реальные преимущества от системы раньше, чем это было бы возможно с водопадной моделью.

Проблемы инкрементальной (поэтапной) разработки:

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

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

Гибкие (ускоренные, agile) методы разработки

Для гибких методов разработки пригодно использование инкрементальной модели. Начало распространения гибкого метода разработки программного обеспечения уходит в 2001 год, когда те, кто отвечали за тогдашнее перепланирование методов разработки, подписали «Манифест гибкой разработки» (или просто «Гибкий манифест», «The Agile Manifesto»), в котором в наиболее важные пунктах внимание акцентируется на человеке и на взаимодействии между людьми:

• люди, и общение важнее, чем процессы и рабочие инструменты.
• Работающая программа важнее, чем документация.
• Сотрудничество с клиентами является более важным, чем переговоры по контракту.
• Идти навстречу пожеланиям об изменениях более важно, чем следование плану.

Больше считаются с информацией, полученной в процессе обратной связи (нагрузочное тестирование, мнение пользователей и т.д.), чем полагаются на предварительное тщательное планирование технологии. Основное внимание уделяется людям, в том числе пользователям и постоянному тестированию. Говорят, что с гибким методом достигается лучший результат за те же деньги, однако при использовании гибкого метода труднее заранее запланировать, когда какая-то функция программного обеспечения будет готова — «Agile process will provide the most bang for the buck, but won’t say exactly when that bang will be». («Agile-процесс обеспечит максимальную отдачу, но не скажет точно, когда это произойдет».)

Наиболее известными и наиболее распространенными гибкими методами являются экстремальное программирование (XP), Scrum, Feature Driven Development (FDD), Open Unified Process (OpenUP) и др.

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