В чем отличие инкрементной модели от итеративной

#5. Циклы разработки ПО и принципы Agile

Жизненный цикл это промежуток времени между принятием решения о разработке чего-то и фактическим завершением разработки (запуском проекта). В контексте IT-компании занимающейся разработкой ПО, под жизненным циклом подразумевется в том числе сам подход к разработке ПО.

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

• Прогнозируемый (Predictive Life Cycle)
• Итеративный (Iterative Life Cycle)
• Инкрементальный (Incremental Life Cycle)
• Гибкий / Аджайл (Agile Life Cycle)

Прогнозируемый подход
Также называется традиционным/классическим подходом.

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

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

• Разработка дизайна проекта
• Разработка ПО
• Тестирование ПО
• Сдача проекта

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

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

На основании собранных данных составляется SRS документ (System Requirements Specification) (либо PRD (Product Requirements Documentation) ), в котором описывается все то, что должно было быть разработано. После того, как заказчик подписывается под документом, команда разработчиков раздробляет документ на технические задачи и назначает исполнителей.

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

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

Читатель может заметить, что по сути, этот подход, своего рода «конвеер» (одна из причин, по которой его назвали «Водопадом»), и как и в случае работы любого конвеера — одна ошибка на одном из этапов может остановить всю работу. Другая грубая деталь данного подхода в том, что заказчику показывается только конечный результат, и только по окончанию разработки проекта. Заказчик же, конечно, может выразить свое мнение и запросить какие-то изменения, но нет гарантий, что компания исполнитель это сделает. Ведь, по сути, контракт уже заключен, документы подписаны и список требуемых работ согласован ☺.

Итеративный подход

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

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

Участники проекта одинаково понимают, что итерацию нужно завершить так, чтобы разработанная часть ПО приносила пользу продукту в целом. Еще одно важное преимущество этого подхода в том, что заказчик принимает решения по каждой итерации, а значит, в худшем случае, он рискует запороть лишь один отрезок времени за раз (в среднем, одна итерация длится это 2-4 недели). Также этот подход дает возможность постепенно «учиться». Благодаря своей гибкости, команда, вместе с заказчиком, могут на ранней стадии выявить изменения в желаниях пользователей, и переписать приоритеты того что должно быть разработано в следующих итерациях.

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

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

Очевидно, что длительность итераций вариативна и определяется самими участниками проекта.

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

Инкрементальный подход

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

Часто, для каждого инкремента, еще до начала разработки собирается своя документация с целью минимизации рисков связанных с изменением требований, за что инкрементальный подход иногда называют мульти-водопадом (multi-waterfall). В данном подходе ПО разбивают на несколько независимых, функциональных модулей, и разрабатывают соответственно.

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

Каждый такой модуль в логике инкрементального подхода называется инкрементом (как неожиданно!).

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

Agile подход (также известный как гибкая разработка)

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

Основная цель Agile — это обеспечение условий для создания продукта 24/7 соответствующего конъюнктуре того дня, когда он попадет на рынок. Более того. Так как пользователи изо дня в день становятся все более «жадными» на новые функции, а современное поколение уже имеет целый список постоянно дополняющихся ожиданий от программ, быть «современным» на этом динамичном рынке можно только став динамичным самому. Вот здесь и появляется Agile.

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

Единственная инструкция, звучит как «К завершению каждой итерации ПО должно повышать общую ценность продукта, а также соответствовать требованиям рынка».

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

Обьяснение принципов Agile (скопировано с оригинала):

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.

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

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

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

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

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

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

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

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

1. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

На данный момент, большинство Agile-компаний предпочитает двухнедельные итерации. На практике я не видел итераций длящихся более одного месяца.

1. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

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

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

1. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

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

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

1. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

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

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

1. Работающий продукт — основной показатель прогресса.

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

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

Без комментариев.

1. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

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

1. Простота — искусство минимизации лишней работы — крайне необходима.

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

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

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

1. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

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

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

Пара слов о документации в Agile
(Нашел в заметках, не исключено что что-то попало через copy-paste, но польза не уменьшается.)

• В AGILE не нужно придерживаться строгой документации;
• Документирование может быть как для внутреннего использования командой-разработчиком, так и тех. документом описывающим сам продукт, со всеми его свойствами и особенностями;
• Слишком подробная документация повышает риск неоднозначности, недопонимания и расхождений во взглядах между членами команды;
• Исчерпывающая документация для управления AGILE-проектом практически невозможна;
• Написание документации следует поручить одному лицу, чтобы избежать проблемы раздробленного видения.
• Компания, разрабатывающая только документацию, необходимую для проекта, создает среду, в которой команде доверено делать именно то, что надо (по документу). Это может быть хорошо для отчетности, но губительно для проекта.

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

В следующей статье мы поговорим о наиболее популярном Agile—фреймворке, о Скраме (SCRUM).

Copyright © 2019 — 2024 Wolf Alexanyan. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation.

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

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

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

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

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

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

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

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

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

• 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 являются некоторые практики, самая известная из которых — парное программирование. Суть его заключается в том, что два разработчика одновременно работают над кодом для одной функции продукта: сначала один пишет, а второй наблюдает и исправляет ошибки, затем они меняются местами. Таким образом, в процессе создания кода есть два альтернативных решения, на каждом этапе выбирается лучшее. Парное программирование работает по принципу: одна голова — хорошо, а две лучшею

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

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

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

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

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

Иногда можно увидеть термин «итеративно-инкрементная модель разработки». Можно подумать, что авторы считают, что итеративная и инкрементная модели – одно и то же. Так ли это?

Тестировщик » QA-блог » База » Чем итеративная модель отличается от инкрементной
8 месяцев назад 4 1475

Итеративная и инкрементная модели: в чем разница

Хотя обе модели были разработаны, чтобы повысить гибкость «Водопада», они различаются. Итеративная подразумевает постепенное приближение циклами к финальному результату, а инкрементная – приращение по частям.

В свете аналогий с другими повседневными предметами: можно создавать их все более и более совершенные версии, а можно сформировать отдельные части и затем объединить в целое.

Что такое модель разработки ПО

Модель разработки — это концепция создания программного обеспечения, определяющая ключевые подходы к проектированию, программированию, тестированию и т.д. Современные IT-команды используют модели разработки, чтобы:

• Организовать свою деятельность;
• Определиться в необходимых ресурсах для проекта;
• Сориентироваться в сроках разработки;
• Адаптировать тестирование под специфику проекта;
• Обеспечить экономическую эффективность IT-продукта;
• Регламентировать взаимодействие (как внутреннее, так и внешнее, со стейкхолдерами и клиентом).

Иногда в отношении модели разработки ПО применяется термин жизненный цикл программного обеспечения (Software Development Life Cycle, SDLC).

В чем особенность итеративной модели

Итеративная (итерационная) модель предполагает движение к выбранному финальному варианту продукта через повторяющиеся циклы разработки. Такие циклы называются итерациями. После каждого цикла создается новая версия ПО. По мере продвижения по итерациям IT-продукт становится все более качественным и удобным.

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

• Нет необходимости в четко определенном техническом задании на старте проекта;
• Быстрый выпуск продукта, хотя и с минимальными функциями;
• Раннее обнаружение дефектов – снижение затрат на их исправление;
• Экономия ресурсов – не нужно разрабатывать невостребованные функции;
• Возможность использовать накопленный опыт из предыдущих итераций.

Минусы итеративной модели разработки:

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

В чем особенность инкрементной модели

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

Плюсы инкрементной модели разработки:

• Быстрая разработка базовой модификации как работоспособного продукта;
• Клиент видит созданные инкременты и сразу дает обратную связь;
• Можно вносить изменения в продукт поэтапно;
• Можно снизить вложения в продукт, отказавшись от реализации некоторых инкрементов;
• Раннее обнаружение дефектов – снижение затрат на их исправление.

Минусы инкрементной модели разработки:

• Архитектура продукта изначально не всегда прозрачна, могут возникнуть трудности при стыковке инкрементов;
• Необходимость тщательного планирования, иначе могут быть большие потери ресурса из-за несогласованности действий команды;
• Стоимость и сроки разработки могут превышать запланированные, если потребуются дополнительные инкременты.

Разница итеративной и инкрементной моделей

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

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

Итеративно-инкрементная модель разработки

Все чаще в практике IT-компаний используется итеративно-инкрементная модель. Это гибрид, он объединяет в себе оба подхода. Например, разработка инкрементов может происходить параллельно и циклами (итеративно).

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

Резюме

В истории развития программного обеспечения есть две модели, которые более гибкие, чем классический «Водопад»: итеративная и инкрементная. Итеративная предполагает разработку ПО циклам и целиком, инкрементная – по частям. Существует также созданная на основе их объединения гибридная модель – итеративно-инкрементная.

Автор Михаил Кулешов

Михаил, профессиональный партнерский маркетолог, является основателем компании South Media OÜ, которая была создана в 2018 году и базируется в Таллинне. С 2016 года Михаил уехал из Финляндии и жил как настоящий «цифровой кочевник» в IT-индустрии, путешествуя по миру только с ноутбуком. Михаил работает и пишет статьи, связанные с IT-индустрией.