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

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

Гибкая и каскадная модели разработки проекта (Agile и Waterfall соответственно) — одни из наиболее популярных среди прочих методологий управления. Изучив особенности конкретно вашего проекта, и вооружившись знаниями из этой статьи, вы сможете с полной уверенностью ответить на вопрос: «Что подойдёт моему бизнесу — Agile или Waterfall?»

Agile — система идей и принципов «гибкого» управления проектами, на основе которых разработаны популярные методы Scrum, Kanban и другие. Ключевой принцип — разработка через короткие итерации (циклы), в конце каждого из которых заказчик (пользователь) получает рабочий код или продукт.

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

Что такое Agile

Как и другие популярные методологии разработки и управления проектами, Agile появился сравнительно недавно в США. В отличии от CPM и CCPM, за появление гибкой методологии разработки ответственна сразу целая группа людей — 17 американских IT-специалистов из штата Юта. Вместе с «Манифестом гибкой разработки ПО», в котором впервые прозвучал термин «Agile» они прописали 12 принципов Agile-разработки.

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

Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану.

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

Scrum — методология гибкой разработки на основе Agile, в основе которого лежит «спринт» — отрезок от 1 до 4 недель, по окончанию которого должна быть получена рабочая версия продукта.

Lean — метод, который вырос на основе системы управления производством Toyota Production System. В его основе — философия постоянного совершенствования на всех уровнях организации, где одно из ключевых понятий — ценность (то, за что готов платить заказчик).

Экстремальное программирование (XP) — одна из Agile-методик, где важная роль отводится периодической игре в планирование с привлечением заказчика. Она позволяет определить недостатки предыдущей итерации, приоритетность задач, желаемую функциональность продукта с учётом пожеланий заказчика.

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

К преимуществам метода относятся:

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

Не избежала методология и недостатков, которые органично «дополняют» её достоинства:

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

Что такое Waterfall

Методика Waterfall (водопадная система разработки) — детище Винстона Уолкера Ройса, директора Lockheed Software Technology Center в Остине (штат Техас, США), пионера в области разработки программного обеспечения.

С методикой Waterfall получилось также, как и с многими изобретениями: свой вклад в создание методологии сделали Герберт Беннингтон в 1956 г. и Хозьер в 1961 г., а Уолкер использовал их наработки, обеспечив себе славу «создателя Waterfall». Победителей не судят...

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

В оригинальной работе Уолкера «Managing the development of large software systems» описаны 6 стадий разработки продукта, которые в 1985 году Департамент защиты США закрепил в стандартах работы с разработчиками программного обеспечения:

Системные и программные требования : закрепляются в PRD (документе требований к продукту).
Анализ : воплощается в моделях, схемах и бизнес-правилах.
Дизайн : разрабатывается внутренняя архитектура программного обеспечения, способы реализации требований. Это не только об интерфейсе и внешнем виде ПО, но и о его внутренней структурной логике.
Кодинг : непосредственно пишется код программы, идёт интеграция программного обеспечения.
Тестирование : баг-тестеры (тестировщики) проверяют финальный продукт, занося в трекеры сведения о дефектах кода программы или функционала. В случае ошибок и наличия времени/финансов происходит исправление багов.
Операции : продукт адаптируется под разные операционные системы, регулярно обновляется для исправления обнаруженных пользователями багов и добавления функционала. В рамках стадии также осуществляется техническая поддержка клиентов.

Компания Toyota, популяризовавшая методологии Lean и Kanban, до конца 2000-ых пользовалась каскадной моделью разработки ПО для нужд производства.

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

В число наибольших преимуществ методики Waterfall вошли:

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

Среди недостатков водопадного метода можно выделить:

лишенный гибкости процесс — так, если проект требует больше временных и финансовых ресурсов, чем возможно, то под нож пойдёт фаза тестирования. Согласно исследованиям консалт-группы Rothman, стоимость исправления багов после выпуска продукта выше в среднем в 20 раз, чем во время полноценного многоэтапного тестирования в процессе разработки
«стойкость» к изменениям — жёсткий каркас из этапов разработки и условие предоставление только готового продукта определяют невозможность вносить изменения во время разработки
инерционность — на первых стадиях прогноз временных и финансовых трат может измениться в сторону увеличения, но изменить проект в сторону оптимизации затрат, изменения функционала или концепции до выпуска готового продукта невозможно
повышенный риск — классическая система тестирования подразумевает отдельно тестирование каждого из компонентов проекта, в том числе, во взаимодействии с другими. При использовании Waterfall происходит тестирование готового продукта.

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

Сашими или водопадная модель с наслаивающимися фазами — cамая известная среди них. В ней этапы как и в оригинальной методике идут друг за другом, но при этом перекрываются одна другой во времени.

Waterfall с субпроектами — модель, в которой вы работаете с трёмя крупными блоками: концептуализацию, проектирование требований и архитектурная структура продукта. Затем для каждого из них вы проходите стадии (субпроекты) детального проектирования, кодирования и тестирования. В конце проводится интеграция всех компонентов на этапе тестирования системы.

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

Сравнительная таблица

		Waterfall
Суть	Гибкая модель разработки, основанная на итеративных принципах	Каскадная система разработки, основанная на жёсткой последовательности процесса разработки
Дата создания		1956 г., 1961 г., 1970 г.
Разработчики	Группа IT-специалистов (США)	Г. Беннингтон, Хозьер, В. Уолкер Ройс
Принципы применения	наивысший приоритет в удовлетворении потребностей заказчика на протяжении всего проекта команда и заказчик ежедневно взаимодействуют между собой и друг с другом работающий продукт — главный показатель прогресса работу можно доверить только самоорганизованной, мотивированной команде оптимальные сроки выпуска рабочего продукта — от 2 недель до 2 месяцев.	жёсткая последовательность этапов разработки переход к новому этапу — только после успешного завершения предыдущего фиксированная стоимость продукта заказчик не привлекается к непосредственному процессу разработки изменения могут быть внесены только после завершения всего процесса разработки.
Плюсы	высокий уровень взаимодействия между членами команды проекта быстрый результат (рабочий код) в итоге «спринтов» стимулирование изменения и улучшений продукта во время его разработки непосредственное вовлечение заказчика к рабочему процессу.	понятная и чёткая схема рабочего процесса возможность просчёта точного количества затраченных на проект ресурсов не требует затрат по налаживанию коммуникаций между всеми членами команды.
Минусы	риск бесконечных изменений продукта большая зависимость от уровня квалификации и опыта команды практически невозможно точно подсчитать итоговую стоимость проекта.	приоритет формального подхода к последовательности процесса работы невозможность внесения изменений заказчиком до окончания разработки продукта в случае нехватки ресурсов страдает качество проекта из-за сокращения этапа тестирования.
Компании-практики	Unilever, ряд банков (Альфа Банк, Home Credit, Райффайзен Банк и т.д.)	Cisco Ericsson AB, Toyota (до 2010)
Подойдёт вам, если...	над проектом работает опытная, высококвалифицированная команда вы работаете над стартапом нужно быстро получить рабочую версию продукта заказчик выступает в качестве партнёра, а не инвестора продукт разрабатывается в сфере, подверженной постоянным изменениям.	большая часть или вся работа над проектом проводится на аутсорсе у вас есть чёткая концепция продукта, который хотите получить вы не ограничены во времени и ресурсах создания продукта создание продукта или бизнеса построено на соблюдении строгой последовательности выполнения задач.
Не подойдёт, если...	вы не готовы тратить дополнительные ресурсы на налаживание ежедневной стабильной коммуникации между всеми участниками процесса продукт должен быть создан к конкретному сроку бюджет проекта строго ограничен вам нужна детальная документация по всем процессам разработки.	вы хотите создать инновационный продукт или крупный проект вы не уверены в концепции предлагаемого проекта финансовые ресурсы не являются ключевым ограничителем в вашем проекте.

Вердикт

Agile и Waterfall — две абсолютно разные методики разработки и управления проектами. Каждая из них породила десятки модификаций и методов, «заточенных» под конкретный формат проектов.

Гибкая модель будет идеальной для IT-компаний, стартапов, проектах в инновационных сферах

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

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

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

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

Можно добавить, что в случае классических методов (например, когда область А представляла каскадная организация разработки и классические методы проектирования целостных ИС, а область Б - подход PI в его классическом варианте) область АБС практически была пустой.

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

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

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

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

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

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

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

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

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

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

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

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

Waterfall - традиционный подход.
RUP (Rational Unified Process) - рациональный.
Agile - общая методология гибкой разработки.
Crystal Clear - подход с уравниванием разработчиков в коллективе.
Spiral - спиральный метод.
DSDM (Dynamic Systems Development Model) - динамическая модель.
FDD (Feature Driven Development) - методология, рассматривающая будущие изменения.
JAD (Joint Application Development) - ориентированный на пользователя подход.
RAD (Rapid Application Development) - модель быстрой разработки.
Scrum - концепция работы в условиях сорванных сроков и идеологического кризиса.
XP (Extreme Programming) - экстремальная разработка в динамической среде.
LD (Lean Development) - метод, предполагающий бережное отношение ко всем участникам процесса.

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

Waterfall

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

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

RUP

RUP - итеративный подход, который решает проблемы, которые есть у Waterfall. Чем хорош RUP:

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

Agile

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

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

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

Crystal Clear

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

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

Spiral

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

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

DSDM

Модель развития динамических систем была разработана в Великобритании в середине 1990-х годов и является эволюционным развитием быстрой разработки приложений (RAD). Основная идея стандартная: при планировании в самом начале невозможно понимать всех тонкостей разработки, поэтому весь процесс - исследовательская работа.

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

FDD

FDD - процесс для обеспечения масштабируемости и повторяемости, при этом поощряющий творчество и инновации. Вот основные принципы:

Разработка каждого крупного проекта должна иметь системность.
Процессы должны быть простыми и проработанными.
Ценность и логичность процесса должна быть ясна каждому члену команды.
Предпочтение отдаётся коротким итеративным циклам разработки. Это уменьшает количество ошибок и позволяет быстрее наращивать функциональность.

FDD регламентирует время, которое должно затрачиваться на каждый из процессов. Организационной деятельности в цикле должна занимать не более 23−25%, в то время как на непосредственную разработку, сборку и тестирование функций необходимо тратить 75−77% времени.

JAD

JAD - это методология, нацеленная на максимальную занятость в разработке конечного пользователя. Происходит это посредством встреч и проведения совместных семинаров. JAD была придумана в 1970-х годах сотрудниками IBM и нацелена на бизнес в целом. Однако со временем данная концепция стала успешно применяться и для разработки программного обеспечения.

В отличие от подхода Waterfall, JAD приводит к сокращению времени разработки, большей удовлетворенности клиентов и экономии средств на изучении рынка. С другой стороны, это требует большой клиентской выборки и необходимости разработчиков работать не со строгими требованиями ТЗ, а с постоянно меняющимся мнением.

RAD

RAD - методология, которая во главу угла ставит скорость и удобство разработки. Одно из главных условий - использование языка быстрой разработки. Это название абстрактного языка программирования, с помощью которого программист способен решать задачи быстрее, чем с представителями третьего поколения (C / C ++, Pascal или Fortran). Вот ещё несколько пунктов концепции:

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

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

Scrum

Scrum - гибкий метод управления проектами, целью которого является повышение производительности труда в командах, ранее парализованных более тяжелыми методологическими процессами. В основе концепции лежат «спринты». Спринт - короткая итерация, строго ограниченная по времени (обычно 2−4 недели). В это время минимизируется длительность совещаний, но увеличивается их частота (они называются «схватками»).

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

XP

Экстремальное программирование - возможность вести разработку в условиях постоянно меняющихся требований. Вот несколько признаков:

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

LD

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

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

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

Стартап - это проект. А когда вы делаете проект, всегда возникает вопрос: как его реализовывать, как организовать команду. От методологии, по которой реализовывается стартап зависит и качество продукта и сроки выполнения.

Зачем нужна методология? Просто берешь - и делаешь!

Вы примерно представляете свою идею, примерно сроки и что должно получиться в результате. Но “примерно” - это хаос.

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

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

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

Как мы проанонсировали в заголовке, батл состоится между Agile и Waterfall. Сразу заметим, что однозначного ответа нет, выбор зависит от проекта.

Но рассказать о достоинствах и недостатках мы можем:)

Waterfall

Waterfall четко структурирует разработку проекта, мы имеем план, который состоит из этапов. Следуя им, мы получаем конечный продукт:

Идея продукта

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

Инициация

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

Анализ

Ищем лучшие средства для реализации идеи, исследуем рынок и конкурентов, осознаем, кем является целевая аудитория.

Благодаря такому анализу идея трансформируется, уходят элементы, которые не будут востребованы, а на их место приходят новые фишки, необходимые для реализации.

В Waterfall этот процесс стоит особняком. Разрабатывается весь дизайн, интерфейс (front end), когда программное наполнение неизвестно (back end).

Разработка

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

Тестирование

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

Запуск продукта

Выводим проект на рынок, запускаем маркетинг, делаем так, чтобы о продукте узнал весь мир! (по крайней мере, целевая аудитория)

Эксплуатация

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

Структура Waterfall очень проста, все этапы следуют друг за другом и мы знаем, какой шаг сделаем следующим.

Agile

Agile - это гибкая методология разработки. У команды нет строгих этапов, все они связаны между собой и повторяются:

Проект разбивается на итерации - циклы. В каждом из них проводится планирование, анализ, проектирование, разработка и тестирование .

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

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

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

Посмотрим на преимущества и недостатки обеих методологий:

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

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

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

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

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

Чтобы работать по Agile, нужно помнить о вызовах и знать, как с ними справляться:

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

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

Например, IT-сфера постоянно развивается, возникают новые тенденции, и с помощью Agile Artjoker отлично справляется со стартапами!

Программирование ,

Разработка мобильных приложений

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

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

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

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

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

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

2. «V-Model»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда используется RAD-модель?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подытожим

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

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

О технологиях разработки:
.
.
.
.

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

КАТЕГОРИИ