Моделирование жизненного цикла проекта – Управление проектами. Том 1

Что такое водопадная модель разработки?

Вам будет интересно:Теория и шкала Ренсиса Лайкерта

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

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

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

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

Scrum методология основывается на понятии спринта (sprint), в течении которого выполняется работа над продуктом. Перед началом каждого спринта проводится планирование (Sprint Planning), на котором производится оценка содержимого списка задач по развитию продукта (Product Backlog) и формирование бэклога на спринт (Sprint Backlog), в рамках которых и действует команда.

По Kanban методологии проект делится на этапы, которые визуализируются в виде канбан-доски. Этапы, это например: планирование, разработка, тестирование, релиз и т.п. Задачи в виде “карточек” перемещаются с этапа на этап. Новые задачи можно добавлять в любое время.

RUP (Rational Unified Process) — разработка продукта при данном методе состоит из четырех фаз (начальная стадия, уточнение, построение, внедрение), каждая из которых включает в себя одну или несколько итераций. RUP огромная методология, которую трудно уложить в абзац текста, но методы, рекомендуемые RUP основаны на статистике коммерчески успешных проектов.

DSDM (Dynamic Systems Development Model) — методология, которая демонстрирует набор принципов, предопределенных типов ролей и техник.

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

RAD (Rapid Application Development) — методология быстрой разработки приложений, которая предполагает применение инструментальных средств визуального моделирования (прототипирования) и разработки. RAD предусматривает небольшие команды разработки,сроки до 4 месяцев и активное привлечение заказчика с ранних этапов.

XP (Extreme Programming) — методология, которая ориентируется на постоянное изменение требований к продукту и предлагает 12 подходов для достижения эффективных результатов в подобных условиях. Среди них:

• Быстрый план и его постоянное изменение
• Простой дизайн архитектуры;
• Частое тестирование;
•  Участие одновременно двух разработчиков в одной задаче или даже за одним рабочим местом;
• Постоянная интеграция и частые небольшие релизы. 

Agile

“Эджайл” (или “агиль”, или “а жаль” – много у него прикольных названий) относится к типу гибкой методологии. Главное его отличие от водопада – рабочий продукт на каждом этапе работы и неясный финал проекта. В примере с тем же деревом, где каждый этап последователен, этот эджайл не покатит: ну купил ты саженец, а толку?

Для примера работы “по агилю” представим проект посложнее. Пусть это будет проект из строительства. Задача: построить дом, где можно жить.

Этапы производства (представим, что каждый этап занимает ровно спринт):

Пусть в состоянии MVP (минимальный жизнеспособный продукт), но этим домом можно будет пользоваться примерно после первого этапа – не очень комфортно, но можно. Также “по эджайлу” этапы могут не следовать друг за другом, а идти параллельно или в разном порядке. Ключевой момент: на каждом этапе реализации продукта продуктом можно пользоваться.

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

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

Agile используют в IT (“диджитале”) – лучше всего он живет в стартапах, когда финальный проект не ясен, нужно проверять гипотезы и делать это быстро и гибко. Эджайл удобно использовать в проектах стороннего клиента (не из компании), когда финал проекта не ясен и у клиента тысяча тысяч идей по ходу разработки.

Agile и lean: принципы разработки по

Начнем с Agile. 

Agile — набор принципов гибкой разработки (всего их 12) и идей. Основные идеи Agile:

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

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

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

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

Во внутреннем планировании и в продуктовой разработке без этого принципа и элементов Agile не обойтись. 

Теперь давайте поговорим о Lean.

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

Когда доходит до разработки продукта, или делается какое-то улучшение, производственное или инженерное, мы сначала делаем его MVP (minimum viable product). Термин MVP сейчас широко распространён и применяется повсеместно, но он родился именно из Lean подхода.

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

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

В упрощении сила и главная “ловушка” Lean: стремление всё упростить иногда приводит к ситуациям, в которых продукт упрощают настолько, что теряются действительно важные функции и продукт по сути оказывается ненужным, поскольку не несёт ценности пользователю.

В заключение о Lean хочется сказать такое: часто когда говорят о Lean то говорят что “Lean это о том чтобы вместо сервиса сделать лендинг с формой контактов”. Нет, это не Lean. Такое тестирование не противоречит Lean, но Lean-методология предлагает гораздо больше приемов чем этот, и стоит внимательного изучения.

V модель — разработка через тестирование

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

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

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

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

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

Waterfall

Водопад, каскадная методология – традиционная, самая популярная и логичная методология управления проектами. В чистом виде может сработать совсем в простых проектах. Допустим, тебе потребовалось посадить дерево. “По водопаду” выполнение проекта выглядит так:

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

Я работаю с проектами в сфере разработки сайтов и мобильных приложений. Этапы разработки таких проектов по водопаду примерно одинаковы:

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

Waterfall (каскадная модель)

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

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

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

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

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

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

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

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

Waterfall или agile?

Никакая методология не панацея. Ближайшую аналогию могу провести с чеклистами – это такая классная штука (читай статью на моем медиуме @salakhmir), которая люто помогает в работе, но, почему-то, работает не у всех. Любой инструмент – всего лишь инструмент, и сам по себе работать не будет.

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

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

Важные моменты при использовании водопадной методологии

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

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

Источник

Жизненный цикл программного обеспечения: этапы

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

Обычно к этапам жизненного цикла относят:

1. Анализ требований
2. Проектирование
3. Программирование
4. Тестирование и отладку
5. Эксплуатацию, сопровождение и поддержку

Но это не полный перечень. 

Существует некая вариативность в прохождении этапов ЖЦ во время разработки и внедрения продукта на рынок. Для каждого продукта это происходит по-своему, но чтобы процессом как-то управлять были сформулированы модели жизненного цикла ПО – упрощенное и обобщенное представление о том, как развивается продукт. В реальности жизнь продукта не соответствует модели.

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

1. Каскадная модель (она же “водопадная” – waterfall)
2. Итерационные модели
3. Инкрементная модель
4. Спиральная модель

Давайте посмотрим на них подробнее и разберемся, что в них общего, а что отличается.

История возникновения водопадной модели

Вам будет интересно:Корректирующее действие – это… Определение, особенности и принципы

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

Вам будет интересно:Ситуационное руководство: описание модели, стили, уровни развития сотрудников

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

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

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

Итерационная, спиральная и инкрементная модели

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

Поясним разбиение на этапы на бытовом примере. Допустим, нам нужен стол в гостиную.

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

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

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

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

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

Итерационная модель например применялась при разработке СДО проекта Джерело. Детальнее о разработке чата Джерело можно почитать тут.

Спиральная и инкрементная модели являются видами итерационной модели жизненного цикла. 

Что же такое спиральная модель?

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

Теперь поговорим об инкрементной модели.

Принцип, который лежит в основе инкрементной модели, подразумевает расширение возможностей, достраивание модулей и функций приложения. Буквальный перевод слова инкремент: «увеличение на один». Это «увеличение на один» применяется в том числе для обозначения версий продукта.

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

А когда одна из версий эксплуатируется, следующая, учитывая недочеты предыдущей, только планируется или уже разрабатывается, а улучшения заказчику и пользователю хочется доставить прямо сейчас, тогда появляются минорные версии. Туда попадают изменения, которые не влияют на ядро разработки и представлены как под-версии 1.1,1.2,1.3 или релизы 1.1.1, 1.1.2 и т.п.

В совокупности такие поэтапные релизы приводят к полноценной версии 2.0. 

Каскадная модель (waterfall)

Рис. 1.2. Каскадная (водопадная) модель

Особенности каскадной модели:

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

Обязательная актуализация проектной документации. Избыточная документация.• Очень не гибкая методология.• Может создать ошибочное впечатление о работе над проектом (например, фраза «45% выполнено» не несёт за собой никакой полезной информации, а является всего лишь инструментов для менеджера проекта).

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

• Отсутствует возможность учесть переделку, весь проект делается за один раз.Плюсы:• Высокая прозрачность разработки и фаз проекта.• Чёткая последовательность.• Стабильность требований.• Строгий контроль менеджмента проекта.

Методология

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

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

В жизни я использовал и использую две, самые популярные методологии – Waterfall (“водопад”/“каскадная”) и Agile (и его ответвление – Scrum), о них и пойдет речь. Ради расширения кругозора читателя расскажу и о других известных мне вещах. Если читатель работает с диджитал, то “водопада” и “эджайла” хватит за глаза – можно будет использовать их в работе, жизни, рассказывать знакомым и незнакомым людям, на митапах, с умным видом попивая смузи.

Моделирование жизненного цикла проекта

Резюме

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

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