Вопрос 16 Итеративная и инкрементальная модель – эволюционный подход
Итеративная модель предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает “мини-проект”, включая все фазы жизненного цикла в применении к созданию меньших фрагментов функциональности, по сравнению с проектом, в целом. Цель каждой итерации – получение работающей версии программной системы, включающей функциональность, определенную интегрированным содержанием всех предыдущих и текущей итерации. Результата финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации, продукт развивается инкрементально.
С точки зрения структуры жизненного цикла такую модель называют итеративной (iterative). С точки зрения развития продукта – инкрементальной (incremental). Опыт индустрии показывает, что невозможно рассматривать каждый из этих взглядов изолировано. Чаще всего такую смешанную эволюционную модель называют просто итеративной (говоря о процессе) и/или инкрементальной (говоря о наращивании функциональности продукта).
Эволюционная модель подразумевает не только сборку работающей (с точки зрения результатов тестирования) версии системы, но и её развертывание в реальных операционных условиях с анализом откликов пользователей для определения содержания и планирования следующей итерации. “Чистая” инкрементальная модель не предполагает развертывания промежуточных сборок (релизов) системы и все итерации проводятся по заранее определенному плану наращивания функциональности, а пользователи (заказчик) получает только результат финальной итерации как полную версию системы. С другой стороны, Скотт Амблер [Ambler, 2004], например, определяет эволюционную модель как сочетание итеративного и инкрементального подходов. В свою очередь, Мартин Фаулер [Фаулер, 2004, с.47] пишет: “Итеративную разработку называют по-разному: инкрементальной, спиральной, эволюционной и постепенной. Разные люди вкладывают в эти термины разный смысл, но эти различия не имеют широкого признания и не так важны, как противостояние итеративного метода и метода водопада.”
Брукс пишет [Брукс, 1995, с.246-247], что, в идеале, поскольку на каждом шаге мы имеем работающую систему:
можно очень рано начать тестирование пользователями;
можно принять стратегию разработки в соответствии с бюджетом, полностью защищающую от перерасхода времени или средств (в частности, за счет сокращения второстепенной функциональности).
Таким образом, Значимость эволюционного подхода на основе организации итераций особо проявляется в снижении неопределенности с завершением каждой итерации. В свою очередь, снижение неопределенности позволяет уменьшить риски. Рисунок 3 иллюстрирует некоторые идеи эволюционного подхода, предполагая, что итеративному разбиению может быть подвержен не только жизненный цикл в целом, включающий перекрывающиеся фазы – формирование требований, проектирование, конструирование и т.п., но и каждая фаза может, в свою очередь, разбиваться на уточняющие итерации, связанные, например, с детализацией структуры декомпозиции проекта – например, архитектуры модулей системы.
Рисунок 3. Снижение неопределенности и инкрементальное расширение функциональности при итеративной организация жизненного цикла.
Наиболее известным и распространенным вариантом эволюционной модели является спиральная модель, ставшая уже по сути самостоятельной моделью, имеющей различные сценарии развития и детализации.
Вигерс, ты не прав! Ещё раз об итеративной и инкрементальной разработке
Наверное, всякий, кто когда-либо пытался осознать специфику различных подходов к разработке программного обеспечения, задавался вопросами: в чём отличие между итеративной и инкрементальной разработкой? Agile – итеративный? RUP – инкрементальный?
Под катом очередное рассуждение на эту тему и заочный спор с Карлом Вигерсом.
В 3-м издании книги Карла Вигерcа «Разработка требований к программному обеспечению» есть иллюстрация, демонстрирующая распределение усилий по работе с требованиями на протяжении проектов с разным жизненным циклом разработки (SDLC). 
Итак, картинка разделяет Agile и итеративные подходы. Корректно ли это?
- Итеративность – повторение операций в целях переработки результатов предыдущего этапа.
- Инкрементирование – приращение результатов предыдущего этапа.
Значит, если в рамках спринта в гибком Scrum’е или итерации в RUP Вы перерабатываете результаты предыдущего этапа и одновременно реализуете новые части продукта, Ваша разработка и итеративна, и инкрементальна.
Ниже изображение, поясняющее разницу между итеративной и инкрементальной разработкой на примере создания портрета Карла Вигерса. 
Вывод
Разделять гибкие и итеративные подходы некорректно. Вигерс, ты не прав!
IT для неайтишников: Какими бывают IT-шники? Часть 6
Периодически мне задают вопрос: «Кто есть кто в мире ИТ?». Вопрос этот интересный и объёмный. Чтобы не рассказывать всё по много раз, я напишу несколько статей и буду на них ссылаться. Шестая часть статьи посвящена людям, которые руководят проектами и продуктами. Заодно попробуем понять, чем проект отличается от продукта и почему процессы их управления сильно отличаются.
Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи МегаБокс/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT
BP (партнёрство между IT и бизнесом) .
Я не пишу продающие тексты и не являюсь копирайтером, в конце статьи не будет коммерческого предложения и призыва к действию. Мне более интересно делиться знаниями и опытом. Некоторым людям мои статьи кажутся слишком длинными, если вам более привычен формат небольших сообщений, то обратите внимание на telegram-канал Записки ITBP.
В первой части мы составили примерный список IT-специалистов, который хотим рассмотреть, список получился объёмным, но на полноту не претендующим. Затем мы рассмотрели эникейщиков, специалистов технической поддержки второй и третьей линии, системных администраторов (первая часть), программистов, поняли, чем младшие (junior), средние (middle) и старшие (senior) специалисты отличаются друг от друга (вторая часть), руководителей технической поддержки, технических лидеров и лидеров команд разработки (третья часть), специалистов по тестированию (QC), специалистов по обеспечению качества (QA), и DevOps-специалистов (четвертая часть), бизнес-аналитиков, UI/UX-специалистов, системных аналитиков (пятая часть).
В шестой части мы рассматриваем людей, которые занимаются процессом управления изменениями, кто-то через реализацию проектов, кто-то через развитие продуктов. Для того чтобы лучше понять различия между этими двумя специализациями, будет необходимо понять, чем проект отличается от продукта. Кроме того, разберём очень интересный вопрос вида: «Agile» vs «Waterfall». Здесь слово «Agile» умышленно взято в кавычки, так как к настоящему Agile оно имеет опосредованное отношение. Плюс ко всему рассмотрим некоторые модели разработки программного обеспечения.
От квалификации руководителя проекта и руководителя продукта часто зависит, станут ли вообще необходимые/запланированные изменения доступны конечным пользователям. Рассмотрим для начала с чем им приходится работать.
Разработка проекта и разработка продукта предполагают процесс управления изменениями. Разработка проекта — это мероприятие по достижению заранее известного и ограниченного набора изменений за ограниченное время и за счёт ограниченного объёма (бюджета) ресурсов. При этом проектом может быть создание нового продукта либо внесение изменений в уже существующий продукт. Разработка продукта — это доработка уже чего-то существующего и обладающего показателями, которые нужно достигать либо улучшать.
Когда мы разрабатываем проект, то работаем с зафиксированным объёмом требований, внесение изменений в который нужно согласовывать. Вместе с требованиями у нас ограничены либо зафиксированы сроки и бюджет на реализацию проекта.
Когда мы разрабатываем продукт, то зафиксированного объёма требований у нас нет. Вместо этого у нас есть метрики (показатели) продукта, которые мы должны достигать и улучшать. Например, это может быть количество посещений сайта, количество обрабатываемых заявок либо заказов и т.д. Для достижения метрик мы проверяем гипотезы, то есть внедряем какие-то изменения и замеряем результат. Разработка (развитие) продукта — это постоянный процесс, поэтому мы не имеем ограничений по срокам. То есть мы ограничены лишь бюджетом на развитие продукта и целями по достижению метрик продукта.
Нужно помнить, что метрики продукта появляются не на пустом месте, они отражают ценность продукта для бизнеса. Улучшение метрик продукта должно быть неразрывно связано с улучшением бизнес-показателей продукта. Если не достигать нужных бизнес-показателей к нужному сроку, можно лишиться бюджетов.
При этом развитие продукта может представлять из себя последовательность проектов. А реализация проекта может подразумевать изменение сразу нескольких продуктов.
Таким образом понятия проекта и продукта настолько же разные, насколько они похожие. Следовательно, процессы управления разработкой проекта и разработкой продукта будут столь же похожи, насколько являться разными. Именно из-за этого возникает много проблем и недопонимания.
Вообще в противопоставлении «Agile», то есть гибких методологий, и «Waterfall» (водопад), то есть каскадной модели разработки, прекрасно решительно всё. Потому, что это сравнение манифеста (Agile Manifesto), который не является ни моделью разработки, ни методологией, с моделью разработки, которой «не существует».
К сожалению, на курсах экспресс-обучения руководителей проектов/продуктов от онлайн-школ об этом не рассказывают. И когда начинаешь спрашивать кандидатов на собеседованиях про смысл и историю вопроса, многие начинают заметно плыть. Вопрос противостояния «рыцарей Agile» хтоническому чудовищу «Waterfall» уже несколько поднадоел.
Поймите меня правильно, я не имею ничего против Agile и семейства методов, которые в него входят. Но то, что теперь часто слышится на собеседованиях, к настоящему Agile не имеет никакого отношения.
В 1970 году доктор Winston W. Royce опубликовал статью «Managing the development of large software systems», в которой для обоснования преимуществ итеративной модели разработки привёл пример наивного подхода к управлению разработки, который потом назовут каскадной моделью (Waterfall, водопад). В 1976 году T. E. Bell и T. A. Thayer в своей статье «Software requirements: Are they really a problem?» уже называли описанный Ройсом наивный подход, как «Waterfall» (страница 62, если кому интересно).
В заключении своей статьи Ройс напишет, что, исходя из его опыта, описанный им наивный подход никогда не работает при разработке больших систем. А в самой статье продемонстрирует, как перейти от наивного подхода к итеративной модели разработки. То есть к модели разработки, на которой основана популярная методология Scrum (хотя он и позиционируется не как методология, а как фреймворк) из семейства Agile. Часто Scrum вообще путают с Agile, хотя это очень разные вещи.
То есть вопросу уже больше полувека, а каскадная модель разработки — это просто какой-то абстрактный и методический пример, который используется как некоторое упрощение при изучении процессов управления изменениями и процессов управления качеством.
Бесполезно рассказывать, как что-то лучше чем «Waterfall». Сложно придумать что-то хуже, чем пример того, как делать не надо из статьи 1970-го года.
При этом ещё следует понимать, что при разработке продуктов и разработке проектов используются разные модели разработки. Хотя бы потому, что процессы имеют разные цели и исходят из разных ограничений.
Моделей разработки программного обеспечения существует достаточно большое количество. Нас же будут интересовать всего три из них, поскольку именно на них сейчас основываются многие современные методы управления разработкой продуктов и проектов.
Итеративная модель разработки предполагает внесение доработок короткими итерациями с использованием цикла «Планирование — Реализация — Проверка — Корректировка» (PDCA: Plan-Do-Check-Act), иначе говоря — цикла Деминга, известного из процессов управления качеством. В простом случае каждая итерация — это небольшой проект по доработке, включающий в себя сбор, анализ и формализацию требований, разработку, тестирование и внедрение. В более сложных случаях итерации идут «внахлёст», то есть пока идёт реализация текущей итерации, ведётся проработка требований к последующей итерации. Таким образом получается непрерывный поток анализа пользовательского опыта, требований, их формализация и постановка задач на следующие итерации, а так же непрерывный поток разработки, отладки и тестирования.
При итеративной разработке, за счёт коротких итераций снижаются риски неверной постановки задачи (глубина планирования меньше), плюс можно работать с не до конца проработанными требованиями, ориентируясь просто на какую-то цель. Разработка ведётся итерациями, достаточно большими, чтобы в их рамках можно было получить какую-то бизнес-ценность в виде результата разработки, но достаточно небольшими, чтобы можно было проработать и зафиксировать требования к итерации.
С учётом того, что мы не до конца знаем, какой результат будет на выходе, когда мы его достигнем и сколько на это потратим, то модель для ведения проектов не подходит. Но очень хорошо подходит для разработки продуктов.
В целом не надо изобретать велосипед, можно просто взять Scrum, который неплохо проработан и описан. Собственно, именно это пробуют сделать многие продуктовые команды разработки, хотя иногда без помощи консультанта по Agile всё равно не обойтись.
Помните, что работа по Scrum (как и весь Agile) предполагает работу команды мотивированных профессионалов. Без этого процесс может просто не запуститься. Не потому, что процесс плохой, а потому, что это базовый принцип Agile.
Инкрементная модель разработки предлагает последовательную разработку инкрементов, которые представляют из себя модули готового и протестированного функционала. Причём разрабатываемая система разбивается на модули таким образом, чтобы ей можно было пользоваться как можно скорее, желательно после реализации первого же этапа, а последующие инкременты добавляли бы бизнес-ценность к «базовому» функционалу.
Модель даёт возможность разделить изначально большую систему на набор сравнительно небольших модулей, которые можно разрабатывать последовательно либо параллельно (если повезёт). За счёт небольшого размера модуля, снижается его сложность, поэтому его легче проектировать, реализовывать и тестировать.
Иногда инкрементный подход неверно называют «мульти-водопад». С наивной моделью разработки, которую когда-то описал Ройс, инкрементная модель имеет немного общего. В ней уже используются развитые механизмы управления рисками и неопределённостью. И кроме того, происходит поэтапная контролируемая и запланированная поставка ценности бизнесу.
Инкрементная модель позволяет вам реализовывать системы, требования к которым вы себе представляете нечётко. То есть вроде понятно, что и где «в целом» должно быть, но система настолько большая и сложная, что описать её целиком не получается.
В отличии от работы по методологии Scrum можно использовать команды разработки невысокого уровня. Но всё равно понадобится либо опытный руководитель проекта, либо опытный архитектор, чтобы правильно разделить вашу систему на модули. Особенно помня о том, что целое всегда больше, чем просто сумма частей.
Модель хорошо подходит для разработки проектов. При разработке продуктов могут проявляться новые требования рынка, в результате чего придётся резко менять дорожную карту продукта. Такой манёвр лучше делать, имея команду из мотивированных профессионалов, которые работают в рамках итерационной модели разработки, чем с менее профессиональной командой разработчиков, хоть и под руководством высококвалифицированного человека.
Потому что в первом случае перегрузка от резкого манёвра будет принята командой, в которой много людей, а во втором случае всего одним человеком. Риски того, что команда разом сгорит под нагрузкой меньше, чем риски того, что сгорит один человек. Хотя есть нюансы и опции.
Инкрементно-итеративная модель разработки позволяет реализовывать действительно большие и сложные проекты, в том числе и с фиксацией требований, объёмов работы, бюджета денег, бюджета ресурсов и сроков. Проект разбивается на инкременты, под каждый из которых закладывается свой бюджет, а между инкрементами закладывается буфер на итерационную доработку. Прелесть подхода в том, что можно проработать требования лишь для первых инкрементов, а дальше осуществлять процессы разработки, проработки требований и корректировки параллельно друг другу.
Именно на инкрементно-итеративной модели разработки основаны самые мощные методологии ведения проектов, например Unified Process (UP), которые по гибкости и манёвренности превосходят итеративную модель разработки, при этом сохраняя надёжность и предсказуемость инкрементного подхода.
Просто для понимания, ядро Unified Process было опубликовано в 1995 году, Rational Unified Process увидел свет в 1998 году, а Agile Manifesto появился только в 2001 году. Методология Scrum была впервые описана в 1995 году. То есть UP и Scrum — это ровесники, которые появились ещё до Agile. Кроме того есть несколько адаптаций UP под Agile, например Agile Unified Process (AUP). Ну как адаптаций, просто выкинули половину из методологии.
Unified Process весьма требовательный к архитектуре приложения. Это фундамент, на который встанет ваша система. Без хорошей архитектуры, следовательно без сильного технического архитектора, у вас ничего не получится.
При этом нельзя не упомянуть, что в продуктовой разработке может использоваться своя вариация инкрементно-итеративной разработки. Это когда в базе используется итеративная модель, но поверх нее используется хорошо проработанная дорожная карта и архитектура продукта. Потребуется сильный бизнес-архитектор.
Есть люди, которые хорошо умеют заканчивать, есть люди, которые хорошо умеют продолжать. Первые входят в команду создания и внедрения, а вторые — в команду развития. Руководитель продукта входит во вторую команду.
Часто новые продукты начинаются с масштабного проекта, после ввода которого в эксплуатацию, команда внедрения передаёт новый продукт команде развития. То есть происходит передача управления от руководителя проекта к руководителю продукта.
Когда мы говорим о развитии продукта, мы подразумеваем, что у продукта есть бизнес-цель существования, бизнес-метрики, по которым можно оценить успешность достижения бизнес-цели, бюджет ресурсов на развитие. Обычно у ИТ-продукта есть постоянная команда разработчиков, которая занимается его развитием.
Конечно, развивать продукт можно и серией проектов, причём используя под каждый проект новую команду. Но если продукт сложный, то каждый раз придётся нести какие-то затраты на ознакомление команды с продуктом и его кодовой базой. Поэтому для развития стараются использовать стабильные команды разработки.
У руководителя продукта есть метрики, которые он должен достичь либо которые он должен улучшить. Для этого руководитель продукта придумывает гипотезы, отбирает какие-то из них и проверяет их на продуктиве (версия продукта, доступная конечным пользователям). Для проверки гипотез команда разработки производит какие-то доработки и осуществляет их внедрение. Если гипотеза подтвердилась и метрики улучшились, то гипотезу начинают развивать. Если нет, то берут следующую гипотезу.
Это процесс непрерывного улучшения, то есть команда разработки загружена непрерывным потоком задач. Часто для продуктовой разработки используют Scrum либо Kanban. Под Kanban сейчас могут понимать как самые примитивные методы потоковой разработки, так и подходы на базе Lean.
Product owner — это разновидность руководителя продукта. Точнее просто название роли руководителя продукта в Scrum. Суть работы не меняется, просто происходит некоторая формализация процесса работы.
Тем не менее с какой-то ритмичностью на продуктив попадают доработки, которые должны нести в себе бизнес-ценность. С точки зрения Scrum — это поставка ценности на продуктив. В Scrum нет ограничения на сроки и объёмы работ, есть только цели и бюджет. В целом, как и у продуктов.
Для получения первой версии продукта можно использовать продуктовый подход и проектный подход. Проектный подход покажет в разы большую эффективность, но потребует от вас более чётких представлений о продукте. Продуктовый подход в итоге более дорогой, но позволяет доформулировать требования к продукту прямо на ходу.
Это руководитель команды разработки проекта. На самом деле проектная и продуктовая команда может состоять из одного и того же набора специалистов, это даже могут быть одни и те же люди. А вот методология работы над проектом будет очень сильно отличаться от методологии ведения продукта.
Руководитель проекта разобьёт проект на этапы, каждый из которых будет сдаваться отдельно. Это нужно, чтобы не потерять управление проектом из-за того, что объём задач слишком большой. Нужны дополнительные точки контроля. Выполнит декомпозицию задач в рамках этапа с точки зрения бизнес-функционала и будет контролировать ход работ, чтобы задачи закрывались в срок и без выхода за оценки трудозатрат. А ещё руководитель проекта координирует действия команды и устраняет препятствия на пути команды разработки, многие из них заранее и незаметно для команды.
За счёт того, что мы знаем, с чего мы начинаем и какой точки мы должны достигнуть, можно подобрать оптимальный путь реализации проекта. Для этого существует много методологий. Желательно, чтобы руководитель проекта понимал, что такое итеративная модель разработки, инкрементная модель разработки, итеративно-инкрементная модель разработки, чем критическая цепь отличается от критического пути, что такое PERT-диаграмма, и как на проекте расставить календарные буферы и буферы ресурсов. В конце концов именно руководитель проекта управляет рисками на проекте, добиваясь выполнения ожидаемого объёма работ по проекту в оговорённые сроки и бюджеты.
Хорошим руководителем проекта может быть только человек, который умеет заканчивать. Есть проекты, которые готовы на 95%, но доработка последних 5% занимает вечность. Есть проекты, которые не могут сдвинуться с начальной стадии. Без умения заканчивать и без желания увидеть конечный результат своей работы руководителем проекта лучше не становиться.
Руководитель проекта должен быть основной движущей силой проекта. Это сложная роль, требующая высокой степени самоотдачи.
В шестой части мы поняли, чем отличается продукт от проекта, какие модели разработки программного обеспечения используются для проектов, а какие для продуктов. Немного коснулись маркетингового противостояния «Agile» и «Waterfall» и поняли, что этому вопросу уже больше 50 лет. В конце мы рассмотрели специализации руководителя продукта и руководителя проекта.
Основное отличие в том, что руководитель проекта либо создаёт с нуля, либо внедряет масштабные изменения, после чего заканчивает свою работу, а работа руководителя продукта подразумевает непрерывный процесс развития продукта. Они могут использовать похожие инструменты и методологии при разработке программного обеспечения, в этом их работы очень похожи, но вот по своей сути они очень разные и имеют разную направленность. Именно поэтому они похожи друг на друга ровно настолько же, насколько отличаются друг от друга.
Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.
Модели и методологии разработки стартапа
Когда вы решаете запустить технологический стартап, то рано или поздно становитесь перед выбором: каким образом создавать продукт. Стоит ли жестко распланировать все этапы и делать все шаг за шагом? Или лучше работать короткими итерациями, чтобы была возможность отследить свою результативность и вовремя внести правки в будущий прототип? Или разбить работу на несколько не зависящих друг от друга частей, и для каждой из них выделить отдельную команду? Все это определяют модели и методологии разработки продукта, которых десятки, и каждая из них имеет свои преимущества и недостатки. В этой статье рассмотрим наиболее популярные из них.
Что такое модель разработки продукта и для чего она нужна
Модель разработки продукта — это то, через какие стадии он проходит во время создания и что происходит на каждой из них. Если речь идет о разработке программного обеспечения, то, как правило, проект проходит через шесть основных фаз. Это:
- Планирование. Определяем, что делаем и какие проблемы решаем. Ставим цели, выясняем, какие ресурсы нам нужны для реализации проекта. Изучаем рынок и конкурентов, прорабатываем альтернативные варианты разработки продукта.
- Анализ системы. Определяем и документируем требования конечного пользователя системы. Какие ожидания есть у нашего потребителя и как мы можем их осуществить? Можем ли мы это сделать вообще?
- Дизайн. Определяем элементы системы, ее компоненты, уровень безопасности, архитектуру, интерфейсы, типы данных. Рисуем дизайн, обсуждаем, проектируем.
- Разработка и внедрение. К началу этой стадии дизайн уже завершен, наступает очередь разработки. Пишем код, настраиваем систему под определенные требования и функции. К концу фазы система готова к установке и запуску.
- Тестирование. Проверяем, получили мы в итоге то, что хотели, или же результаты работы оказались другими. Тестируем продукт автоматизированными тестами, командой, предлагаем поработать с системой потенциальным пользователям. Определяем дефекты и недостатки в работе системы и устраняем их.
- Поддержка системы. Подготовка и выпуск обновлений, оценка производительности системы, замена/деактивация устаревших компонентов.
Это классическая схема, которая изменяется в зависимости от того, каким образом идет разработка, а также от специфики работы команды, размера бюджета и особенностей продукта. Именно здесь и наступает момент выбора модели разработки. Они подразделяются на классические и гибкие.
Вот список классических моделей:
- Code and Fix (написание кода, проверка и устранение ошибок),
- Waterfall (проект последовательно проходит все стадии),
- V-Model (проведение тестирования одновременно с разработкой),
- Инкрементная модель (проект делится на составные компоненты, команда по очереди готовит каждый из них, затем происходит финальная сборка),
- Спиральная модель (предусматривает тщательную проработку рисков),
- Итеративная модель (сначала делается базовая модель продукта, затем следуют итерации по ее усовершенствованию),
- RAD-Model (скоростная разработка продукта).
Классические модели предполагают акцент на последовательности, сроках, конечных требованиях к продукту.
Что касается гибких моделей, то это всем известный Agile. Когда мы работаем над продуктом по гибкой модели, наш проект и требования к нему могут меняться в течение каждой итерации (гибкая модель, когда проект может изменяться с каждой итерацией), а что касается сроков, то работа может вестись бесконечно — вы будете совершенствовать продукт и добавлять в него новый функционал.
Наконец, методологии разработки — это применение той или иной модели на практике. Так, Agile-модель имеет целый ряд довольно популярных методологий — от мягкого Kanban, когда команда работает с доской с задачами, до жестких Scrum и XP.
Теперь рассмотрим особенности каждой из упомянутых моделей.
Code-and-Fix
Это одна из самых старых моделей разработки: она очень проста и подойдет стартапам, где команда невелика, нет особых конфликтов, вы знаете, что хотите сделать и имеете представление, как это сделать.
Как работает Code-and-Fix: у нас есть понимание, что мы хотим сделать. Начинаем программировать, затем смотрим, что получилось. Выявляем баги, правим их и снова смотрим — и так, пока наш продукт не начнет работать.
Плюсы методологии: не нужно тратить время на планы, документацию, митинги.
Минусы: иногда исправление одной ошибки приводит к тому, что у вас ломается вся система. В итоге приходится переделывать — снова и снова. Поэтому когда-то давно программисты, которые мучились с этой моделью разработки, решили уйти от ее мнимой простоты и изобрести другую.
Waterfall
Одним из первых выходов стал Waterfall, или водопадная (каскадная) модель разработки. Это классическая жесткая модель: у вас есть план, бюджет и вы строго выполняете этап за этапом.
Разработка продукта идет по ступенькам: вы изучаете требования, проектируете продукт, разрабатываете его, тестируете и затем поддерживаете его работу. Новый этап не начинается, пока не завершится предыдущий. Ошибки, допущенные на этапах изучения требований и проектирования, очень сложно исправить — как в финансовом плане, так и в техническом — и это самая большая проблема этой модели.
Водопадная модель хороша при разработке продукта, очень похожего на какой-либо другой: у вас есть модель, и вы просто работаете по образцу. Поскольку стартап — это не всегда разработка абсолютно нового продукта, иногда это создание усовершенствованной версии существующего решения, то каскадная модель может оказаться подходящим вариантом при выборе модели разработки. Главное, не наделать ошибок в расчетах.
Когда используется водопадная модель
Эта модель используется при разработке программ для строительства, медицины, работы с государственными контрактами. Если говорить о непрограммных продуктах, то каскадная модель применяется для строительства крупных объектов.
Емко этот метод описал Чак Кобб, автор книг по проектному менеджменту:
Если бы вы строили мост через реку, было бы смешно сказать: «Мы построим первый пролет, посмотрим, как это выходит, а затем решим, как закончить оставшиеся пролеты!”
Действительно, в таких объектах должен быть заранее утвержденный план, макет, прототип, и изменения, как правило, не предусматриваются.
Каскадную модель применяли: компания Cisco для разработки систем безопасности, IBM, Microsoft IT и даже Toyota.
V-Model
V-Model — улучшенная версия водопадной модели. В отличие от последней V-model предполагает тщательную проверку и тестирование продукта уже на ранних стадиях разработки — оба процесса идут параллельно. При переходе на следующий этап разработки предусмотрен контроль всего, что было сделано до этого. Все найденные ошибки устраняются, и только затем наступает новая фаза работы над продуктом.
Тестирование начинается еще на стадии написания требований, для каждой фазы разработки предусмотрен свой тест-план. Кроме того, уже во время проверки текущего уровня идет разработка стратегии тестирования для следующего. При создании тестов определяются ожидаемые результаты тестирования, указываются критерии входа и выхода для каждого этапа работы над продуктом.
Здесь тоже нужно планирование и четко определенные требования к продукту, кроме того, у вас в команде должны быть тестировщики — без них модель окажется нерабочей.
Инкрементная модель
Эта модель разработки дает возможность делать продукт по частям — инкрементам. Каждая часть представляет собой готовый фрагмент итогового продукта, который в идеале не переделывается.
Мы получаем несколько циклов разработки — своеобразный “мультиводопад”. Каждый цикл делится на модули, каждый модуль — на фазы: определение требований, проектирование, написание кода, внедрение, тестирование.
Такая модель позволяет проработать риски и вывести базовую версию продукта на рынок, когда весь запланированный функционал может быть еще в стадии проектирования. Стартапы могут ее использовать, если у них есть общее понимание, каким должен быть их продукт в итоге.
Спиральная модель
Эта модель схожа с инкрементной, однако имеет существенную отличительную особенность — детальную проработку рисков. Спиральная модель применяется для ведения критически важных проектов, где неудача приведет к закрытию компании. Таким образом, стартапы вполне могут ее применять, ведь существование проекта напрямую связано с тем, понравится ли его продукт рынку.
Для разработки продукта по спиральной модели часто проводятся специальные научные исследования и аппробации.
Разработка идет по спиралям, каждая из которых состоит из четырех основных этапов: планирования, анализа рисков, конструирования, оценки результатов.
Спиральная модель довольно затратна в применении, поэтому не подходит для небольших проектов. А вот для средних и больших ее можно применять, особенно, если вы боитесь прогореть.
Эту модель хорошо использовать для работы над продуктом стартапа в том случае, если вы еще не определились с конечными требованиями к нему, но знаете, что в любом случае они достаточно сложные. В там случае, работая итерациями и планируя риски, вы сможете благополучно выпустить свой продукт на рынок и затем постепенно его дорабатывать — опять же, с оглядкой на риски.
Кейс GanttPRO. Приложение для управления проектами и задачами GanttPRO разрабатывалось по принципам спиральной модели, а также фреймворка Agile — Scrum, о котором расскажу чуть ниже. Разработчики выбрали довольно короткие двухнедельные периоды релизов для того, чтобы иметь возможность часто получать отзывы. Также был создан детальный план того, что должно было быть реализовано на первой итерации и как проработать различные риски. Например, перед первой итерацией каждый разработчик высказался по поводу того, что из запланированного может не быть реализовано и почему. Кроме того, команда уделила особое внимание снижению рисков, вызванных необходимостью быстрой адаптации к нуждам пользователей и рынка.
Итеративная модель
Для того, чтобы начать работать с этой моделью, не нужно иметь все требования и спецификации. Продукт создается таким образом, что в первую очередь вы создаете базовый работающий функционал. Затем с каждой итерацией вы совершенствуете его, добавляя новые функции.
Итеративную модель можно сравнить с картиной, когда сначала мы рисуем некий набросок, исходя из которого можно увидеть, что будет изображено. С каждым шагом мы добавляем новые цвета и переходы. В итоге получаем готовую картину. А в случае стартапа — готовый продукт.
Модель подходит для стартапа, который хочет как можно быстрее выйти на рынок и привлечь клиентов.
Кейс “Самокат”. Метафорически итеративную модель можно проиллюстрировать на примере разработки транспортного средства. Результатом первой итерации может стать самокат. Это пример транспорта, хоть и максимально простого. Результатом второй итерации может стать самокат с электродвигателем, третьей — электровелосипед, четвертой — мотоцикл. Таким образом, с каждой итерацией повышаются функциональные возможности продукта, созданного еще во время первой итерации. Сравним разработку этого же транспортного средства по водопадной модели: траспорт мы получим в самом конце, после того, как будут завершены все стадии проекта.
RAD-Model, или Rapid Application Development Model
Разновидность инкрементной модели. Появилась в конце 80-х годов и стала одной из попыток создания гибкого процесса разработки.
Заказчик привлекается к процессу на самых ранних стадиях — он участвует в разработке и оценке состояния продукта. Обязательное требование этой модели — проект должен легко разбиваться на небольшие части, которые при необходимости могут создаваться параллельно друг другу несколькими командами.
Плюсы такой модели разработки — скорость. Минусы — финансирование.
Agile
Гибкая модель разработки, по которой сегодня работает большинство ИТ-проектов. Вы получаете определенный результат после каждой итерации, можете вносить изменения в первоначальное видение продукта практически в любой момент работы — исходя из того, какой функционал больше нравится пользователям вашего продукта.
Минусы такой модели — готовый продукт может на рынок так никогда и не выйти, вы постоянно будете заниматься его усовершенствованиями, дополнениями, тем временем бюджет может закончиться. Плюсы — чтобы начать работать над продуктом не нужно иметь детальное представление о том, что вы хотите получить в конце. Не нужно иметь весь бюджет и просчитывать все риски.
Agile имеет множество вариаций и фреймворков. Среди самых известных: Scrum, Kanban, экстремальное программирование (XP), Lean.
Kanban
Является одной из методологий Agile. Метод базируется на концепции бережливого производства, основанной на стремлении к устранению всех потерь — временных, производственных, логистических, качественных.
Особенность Kanban — задачи должны выполняться точно в срок, нагрузка между командой распределяется равномерно.
На практике это выглядит следующим образом. Каждая задача по проекту описывается в отдельной карточке и добавляется на доску — виртуальную или настоящую. Карточка и доска — неотъемлемые элементы Kanban. Все задачи, которые необходимо сделать, собраны в специальной колонке, условно, она может называться “сделать”/ “to do”. Исполнитель выбирает задачу и перемещает в колонку “в процессе” / “in progress”. Когда задача сделана, она попадает в соответствующую колонку “готово” / “done”. На практике колонок может быть гораздо больше, чем три. К примеру, колонки на доске могут выглядеть так: “обсуждается” (backlog), “согласовано” (ready), “кодируется” (coding), “тестируется” (testing), “подтверждается” (approval) и “сделано” (done).
Есть множество инструментов для того, чтобы выстроить работу команды по Kanban. О некоторых из них можно почитать в статье “Инструменты для командной работы над стартапом”.
Кейс “Тойота”. Методология Kanban родилась на производстве в компании Toyota. Мастера участков перечисляли выполняемые работы на бумаге и вывешивали их на видном месте — так и родилась доска канбан, один из элементов методологии. В основе производства Toyota — годовой план производства и сбыта авто, на базе которого составляются месячные и оперативные планы среднесуточного выпуска на каждом участке, основывающиеся на прогнозировании покупательского спроса. Методология базируется на принципе “точно в срок”, что, помимо четкого следования таймингу по каждой задаче, позволяет раскрывать дефекты производства вовремя. Например, ежедневные контроль запасов продукции и деталей выявляет неисправности или простои.
Scrum
Одна их самых популярных методологий Agile. В отличие от канбан, у скрама гораздо больше элементов — различные митинги (от ежедневных пятиминутных, до планирований спринтов, демо), четкое разделение по ролям. Кроме того, разработка подразделяется на спринты — которые длятся от недели до четырех недель и заканчиваются выпуском части продукта.
В переводе с английского scrum — это драка либо схватка вокруг мяча. Термин пришел из регби и означает специфическую игровую ситуацию, в которой участники команд смыкаются в три линии с каждой стороны, когда в игру вводится мяч после нарушения правил; задача игроков — выиграть за счет совместных усилий команды.
Почти так же применяется методология Scrum при разработке ПО: команда кросс-функциональных специалистов совместно реализует проект. Важно, чтобы это были профессионалы с высокой мотивацией, инициативные и готовые вносить изменения как в ход реализации проекта, так и в продукт.
Рассмотрим пример применения Scrum.
1. На этапе формирования продукта вы с командой решаете, кто из вас будет исполнять роль product owner — человека, который отвечает за связь команды с потребителем и инвесторами (если ваши инвесторы будут интересоваться ходом разработки продукта).
2. Product owner формирует список пожеланий к продукту, собирает первичную информацию от возможных пользователей и затем формирует бэклог продукта — список задач, выполнение которых в конце концов приведет вас к выходу на рынок.
3. Ваша команда определяет размер спринта — периода, в конце которого вы должны сделать какой-то рабочий кусок продукта, и выбирает задачи для первого спринта из бэклога.
4. В течение первого спринта вы отслеживаете качественные и количественные характеристики своей работы. Неотъемлемая часть скрама — ежедневные короткие (5–10) минут митинги, в течение которых каждый из участников команды рассказывает, что он планирует сделать за день, делится возникающими сложностями или, наоборот, успехами.
5. Ход выполнения задач отслеживается по скрам-доске, на которой все задачи двигаются от условной позиции “сделать” до “выполнено”.
6. По завершении спринта вы демонстрируете выполненную часть работы и собираете обратную связь — от членов команды, клиентов, в т.ч. потенциальных.
7. Цикл спринтов повторяется до того момента, пока продукт не будет полностью завершен.
Экстремальное программирование (XP)
eXtreme Programming, экстремальное программирование, XP — гибкая методология разработки, которая появилась в конце 90-х годов прошлого столетия. Авторы взяли лучшие, на их взгляд, практики гибкой разработки и усилили их до максимума — отсюда и слово “экстремальный” в названии.
В отличие от канбана, скрама, которые можно применять в самых разных стартапах и бизнесах, да и в организации личных дел, XP применяется исключительно в разработке программных продуктов. В рамках экстремального программирования выделяются четыре процесса: кодирование, тестирование, дизайн, слушание. Если описать эту методологию несколькими словами, то ее характеризуют оперативность, высокое качество, командная работа.
Особенностью XP являются некоторые практики, самая известная из которых — парное программирование. Суть его заключается в том, что два разработчика одновременно работают над кодом для одной функции продукта: сначала один пишет, а второй наблюдает и исправляет ошибки, затем они меняются местами. Таким образом, в процессе создания кода есть два альтернативных решения, на каждом этапе выбирается лучшее. Парное программирование работает по принципу: одна голова — хорошо, а две лучшею
Другая особенность экстремального программирования заключается в том, что сначала готовятся тесты, и только потом — код. При этом тесты пишут сами программисты. Тестирование позволяет исправить большинство ошибок на стадии создания кода.
Третья особенность — коллективное владение кодом: каждый программист в команде имеет доступ к коду продукта и может вносить в него изменения. В том случае, если изменения привели к некорректной работе системы, исправить все должен тот программист, который внес эти изменения.
Экстремальное программирование предполагает также работу в рамках небольших релизов — от одного дня до месяца. При этом чем короче релизы, тем лучше качество продукта.
Наконец, интеграция новых частей в систему происходит так быстро как это возможно. Как только тесты показали, что функция работает корректно, она интегрируется в систему.
Lean Software Development, или бережливая разработка программного обеспечения — гибкая методология, основанная на концепции бережливого производства. Среди принципов методологии — исключение потерь (к ним относится все, что не добавляет ценности для потребителя — излишняя функциональность, паузы в процессе разработки, нечеткие требования и пр.); акцент на обучении (предполагаются короткие циклы разработки, раннее тестирование), принятие решений на основе фактов, мотивация команды.
Выводы
Как видим, даже если вам кажется, что вы работаете “без заморочек” — без всяких там методологий и прочего — на самом деле даже это прописано в теории:) Скорее всего, вы работаете по модели Code-and-Fix и, возможно, уже совсем скоро столкнетесь со всеми ее недостатками. Чтобы их избежать, важно перед началом работы над продуктом проанализировать его и вместе с командой, решить, по каким фазам будет идти разработка. Оптимальный вариант выбирается, исходя их того, сформировали вы уже конкретные требования к своему продукту или планируете “совершенствовать” его во время работы; какой у вас бюджет и насколько кросс-функциональна команда; насколько длителен проект по времени выполнения и как обстоят дела с финансированием.
Нет идеальной модели и нет идеальной методологии, однако в ваших силах подобрать такую, которая позволит вам максимально эффективно выстроить свою работу и в конце концов вывести продукт на рынок.