Agile и «водопад». Сравнение подходов

Цифровизация

30 Ноября 2020 13:3430 Ноя 2020 13:34

|

Поделиться

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

Что такое agile?

Гибкая разработка впервые упоминается в опубликованной в 1970 г. статье Уильяма Ройса о создании больших программных систем. Четыре ее фундаментальных ценности и 12 принципов были сформулированы позднее в «Манифесте Agile». Agile — это методология управления проектами, состоящая из коротких циклов инкрементальной разработки, называемых спринтами. Каждый цикл нацелен на непрерывное улучшение разработки продукта или сервиса.

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

Agile — это методология управления проектами, состоящая из коротких циклов инкрементальной разработки, называемых спринтами. Фото: ru.depositphotos.com

Для того, чтобы команда разработки была способна работать в agile, она, по мнению Мойры Александер (Moira Alexander), должна соответствовать ряду критериев. Команды гибкой разработки должны уметь фокусироваться на запросах пользователей, адаптироваться к изменениям и быть способными работать «под давлением». От участников команды требуются развитые навыки командной работы и сильное чувство ответственности не только перед командой, но и перед заказчиком.

Что такое «водопад»?

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

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

Agile или «водопад»: за и против

Оба метода разработки имеют свои достоинства и недостатки. Основные из них Мойра Александер свела в таблицу.

Анализ угроз и киберразведка: какие проблемы решает обновленная TIP Security Vision

Безопасность

Достоинства и недостатки «гибкого» и «традиционного» подходов к разработке

Agile	«Водопад»
Преимущество подхода
Быстрый и при этом гибкий процесс разработки	Хотя циклы носят более формальный и последовательный характер, длительные и упорядоченные процессы могут быть легко освоены командами любого размера
Благодаря коротким итеративным спринтам и фокусу на качестве, команды выявляют и исправляют недостатки быстрее, чем при каскадной разработке	Заданные циклы разработки обеспечивают большую стабильность для вновь сформированных команд
Задачи могут быть распределены между небольшими командам таким образом, чтобы они не затрагивали другие аспекты или фазы разработки	Требования к проекту задаются в самом начале, а цели редко меняются в ходе проекта. Это упрощает выполнение проекта
Итерации позволяют быстро вносить изменения в продукт в процессе разработки, если в том возникает необходимость	Бюджет и необходимые ресурсы выделяются для всего проекта в самом начале, это упрощает управление ожиданиями и рисками
Недостаток подхода
Agile	«Водопад»
Для гибкой разработки необходим scrum-мастер с опытом проведения спринтов, способный держать ситуацию под контролем при быстром характере итераций	Разработка ведется последовательно и поэтому медленней и менее гибко — переход к следующей фазе возможен только по завершении предыдущей
Частые запросы на оценку изменений могут вызвать раздражение клиентов	Проблемы обычно выявляются позднее, чем при гибкой разработке — на стадии тестирования
Если команды недостаточно хорошо организованы или не способны к самоуправлению, могут возникнуть проблемы, особенно у территориально распределенных команд	Требования определяются и одобряются в начале проекта, поэтому что-либо изменить в ходе работ становится гораздо трудней
Для каких команд разработчиков, клиентов и проектов подходит наилучшим образом
Для опытных команд, сфокусированных на постоянном улучшении качества продукта	Для менее опытных проектных команд
Для проектных команд, которые тесно и регулярно взаимодействуют с заказчиками	Проектным командам, клиенты которых не имеют времени и ресурсов для частого общения с разработчиками
Для проектных команд, которые не хотят ждать завершения проекта, чтобы получить отзыв на свои продукты	Для проектов с простыми требованиями, сроки готовности которых могут быть отодвинуты
Для заказчиков со сложной структурой, которым гибкая разработка поможет быстрее реагировать на изменения	Для заказчиков, которым не подходят быстрые изменения и риск внедрения «частично готового» ПО

Дмитрий Ганьжа

Классическая (каскадная) модель управление проектами “водопад” (waterfall)

Содержание статьи

• 0. 1 Кто такой Project Manager (PM)
• 1 Последовательность этапов в каскадной модели
• 2 Проектная документация
  • 2.1 1.УСТАВ ПРОЕКТА
  • 2.2 2.ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ
  • 2.3 3.АКТ ВЫПОЛНЕННЫХ РАБОТ
• 3 Матрица заинтересованных сторон проекта
• 4 Как составить план управления проектами (10 шагов)
• 5 Где найти больше информации об управлении проектами?
  • 5.1 Что еще почитать об управлении проектами:

Классическая модель управления проектами “водопад” (waterfall) основана на методах управления проектами, разработанных в 50х годах XX столетия в США. В основе этих методов лежит разделение большого на малое (создание структуры и плана проекта), а дальше планирование работ во времени (календарный план работ).

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

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

При планировании проекта определяются основные роли:

– Заказчик (Инвестор)

– Исполнитель

– Подрядчики

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

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

Например, если заказчик хочет чтобы 2х этажный дом площадью 200м2 был построен к концу года при бюджете 100 000$, то основной задачей исполнителя является постройка дома к 31 декабря в рамках данного бюджета.

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

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

Кто такой Project Manager (PM)

Для более эффективного взаимодействия заказчика и исполнителя между ними часто появляется связующее звено – project manager (или управляющий проектом), который обычно назначается со стороны исполнителя для более эффективного взаимодействия между заказчиком и командой исполнителя.

Основные инструменты project manager’a это:

– календарный план работ, согласованный с заказчиком

– детализированный план работ (например, в формате диаграммы Ганта)

– система управления задачами в команде (например Trello, Asana и т.д.)

– регулярные совещания с командой на которых определяются приоритеты и подводятся итоги выполненных работ

Последовательность этапов в каскадной модели

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

Анализ требований
↓
Проектирование
↓
Реализация
↓
Тестирование
↓
Интеграция
↓
Поддержка

Проектная документация

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

1.УСТАВ ПРОЕКТА

С этого документа начинается стадия Инициации работы над проектом. Устав проекта описывает правила игры в проекте, возможные риски и полномочия руководителя проекта.

1. Цель проекта: цель должна быть сформулированная по принципу SMART (об этом читайте в 1й части статьи)

2. Проектные ограничения: сроки, стоимость, объем работ (содержание)

3. Участники проекта: организационная структура с уровнями подчинённости

4. Полномочия руково­­дителя проекта: полномочия использования ресурсов (финансовых, человеческих)

5. Допущения проекта – то что будет использовать руководитель проекта в разработке плана (например для строительства дома – средняя рыночная стоимость постройки 1м2 в данном регионе)

6. Проектные риски – должны быть сформулированы и четко прописаны, например

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

7. Контрольные точки проекта (Milestones) – в примере со строительством дома это может быть, вырыт котлован – залит фундамент – выгнали коробку – положили крышу – облицовали фасад и т. д.

8. Финансовое обоснование – график время и деньги, по вертикальной оси (ось ординат) – деньги, по горизонтальной (ось абсцисс – время)

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

Любое изменение – это отклонение от плана, если изменение принесет большую прибыль, то заказчику оно нужно – решение об изменениях должен принимать заказчик

2.ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ

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

• Перечень работ
• Календарный план
• Бюджет проекта
• План управления персоналом
• План управления коммуникациями
• План управления изменениями
• Матрица ответственности
• Ресурсный план

3.АКТ ВЫПОЛНЕННЫХ РАБОТ

Этот документ заключается между заказчиком и исполнителем в конце срока проекта

В акте фиксируется перечень выполненных работ, сроки и результаты, которые были переданы заказчику.

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

Матрица заинтересованных сторон проекта

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

По вертикальной оси в матрице – Интерес к проекту, а по горизонтальной оси – влияние на проект.

Пример Матрицы заинтересованных сторон проекта

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

Уровни вовлечённости участников

1. Вообще не знают что проект происходит.

2. Сопротивление

3. Нейтральная позиция

4. Поддержка (на словах)

5. Активное участие

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

Как составить план управления проектами (10 шагов)

1. Разработка устава проекта

На этом этапе также определяется руководитель проекта и прописываются основные проектные ограничения

2. Определение заинтересованных сторон проекта

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

3. Сбор требований проекта

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

4. Разработка иерархической структуры работ

На этом этапе крупные уровни проекта раскладываются на более мелкие – происходит

декомпозиция работ по проекту.

5. Определение связей (последовательность работ)

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

6. Определение ресурсов

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

7. Календарный план

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

8. Оценка стоимости (смета проекта)

9. Бюджет проекта

Бюджет проекта составляется в виде сметы, распределенной по статьям затрат и по периодам

10. Согласование плана проекта с заказчиком / инвестором.

Где найти больше информации об управлении проектами?

Больше об управлении проектами читайте в следующих статьях (некоторые готовятся к публикации, а некоторые уже опубликованы):

Что такое проект: классификация и основные характеристики

Классическая (каскадная) модель управление проектами по принципу “водопад” (waterfall) – текущая статья

Agile методология управления проектами – готовится к публикации

Что такое Scrum – готовится к публикации

Что такое Kanban – готовится к публикации

Что такое Scrumban – готовится к публикации

С уважением Александр Цыглин,
основатель Мастер Продуктивности и проекта SkillsMarketplace. ru
(Facebook / Linkedin / Instagram / Youtube)

P.S. Если вам нужна дополнительная консультация по внедрению Scrum в вашей организации – напишите мне в Facebook, обсудим чем можем быть друг другу полезны.

---

Что еще почитать об управлении проектами:

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

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

Что такое скрам – mind-карта (mind map)

Ваш браузер не отображает фреймы. Пожалуйста, посетите Что такое Scrum в MindMeister. Ссылка на карту: https://www.mindmeister.com/ru/1309123858/scrum …
Подробнее

Scrum: Планирование спринта в Story Points и Диаграмма сгорания задач (Burndown Chart)

Содержание статьи1 Что такое Спринт (Sprint) в Скрам (Scrum)2 Как оценить силы команды на Spint (показатель Velocity)3 Как оценить сложность задачи – играем в Planning Poker. 4 Планирование спринта в Story Points и Диаграмма сгорания задач (Burndown Chart)4.1 Что еще почитать …
Подробнее

Что такое Scrum? Революционный метод управления проектами!

Содержание статьи1 Как появился термин Scrum (Скрам)?2 Основные участники Scrum (Скрам)2.1 Владелец продукта (Product owner)2.2 Команда скрам (Scrum team)2.3 Скрам-марстер (scrum-master)3 Скрам-артефакты (Scrum artefacts)3.1 1.Планирование проекта – составление бэклога (Backlog grooming)3.2 2.Планирование спринта (Sprint planning meeting)3.3 Оценка сил на спринт …
Подробнее

Что такое Agile (Аджайл) методология управления проектами

Содержание статьи1 Что такое Agile2 Основные принципы Agile-философии 2.1 1. Давайте результат чаще (Deliver value faster)2.2 2.Изменения приветствуются (Welcome changes)2.3 3.Выпускайте обновления продукта регулярно (Deliver working software frequently)2.4 4.Работайте сообща день за днем (Work together daily)2.5 5. Создавайте проекты вокруг …
Подробнее

---

Agile против каскадного управления проектами

Вклад редактора: Лаурели Маллек, руководитель программы

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

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

Что такое гибкое управление проектами?

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

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

Что такое каскадное управление проектами?

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

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

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

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

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

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

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

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

Недостатки водопада

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

Agile против водопада

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

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

Итеративные выпуски открывают для команды многочисленные возможности:

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

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

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

Agile-принципы

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

Преимущества гибкого управления проектами проблем раньше

• Более высокий потенциал для удовлетворения клиентов
• Время выхода на рынок резко сокращается
• Лучшая видимость и подотчетность
• Выделенные команды со временем повышают производительность
• Гибкая расстановка приоритетов, ориентированная на получение ценности

Недостатки гибкой разработки

Элементы, которые следует учитывать при переходе на agile

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

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

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

Дорожные карты

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

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

Требования

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

Незавершенная работа

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

Agile-метрики

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

Agile работает на доверии

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

В заключение…

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

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

Дэн Радиган

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

Полное руководство по методологии управления каскадными проектами

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

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

Что такое методология каскадного управления проектами?

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

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

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

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

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

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

Этапы управления каскадным проектом

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

2. Проектирование системы

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

3. Реализация

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

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

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

5. Доставка/развертывание

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

6. Техническое обслуживание

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

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

Хотя большинство компаний используют некоторую комбинацию стилей управления проектами, отчет LiquidPlanner за 2017 год показал, что 25,5% производственных компаний в настоящее время используют каскадный подход. Что делает эту методологию успешной для многих команд?

Упрощает обучение

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

Показывает прогресс

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

Упрощает управление проектом

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

Экономит время и деньги

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

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

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

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

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

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

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

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

Как Lucidchart может помочь вам задокументировать ваш проект

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

Lucidchart может помочь с момента сбора требований до этапа тестирования:

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

  This entry was posted in Продвижение