Agile, Scrum, Waterfall, Kanban — методы управления проектами в компании

Классическое управление проектами

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

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

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

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

Каскадная модель или модель «водопад», – это вариант классического поэтапного планирования. 

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

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

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

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

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

Мониторинг и завершение проекта. Руководитель передает проект клиенту, оценивает результат и составляет план по улучшению на будущее.

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

Ограничения Waterfall-модели

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

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

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

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

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

Подробнее о каскадной модели читайте в статье «Как устроена каскадная модель управления проектами».

Вам подойдет каскадная модель, если:

• 
  известно, какой продукт необходимо получить в итоге;

• 
  нужна детальная документация по всем процессам разработки;

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

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

Agile
  – это система ценностей, помогающая создавать новые продукты. 

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

Сам по себе Agile – это не модель управления, а философия, помогающая сформировать отношение к работе. Философия состоит из четырех ценностей и 12 принципов. Они закреплены в
Agile-манифесте разработки программного обеспечения:

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

Создатели воспринимали Agile  как философию, которую можно адаптировать под конкретные задачи. Современные модели проектного менеджмента, например, Scrum и Kanban, основаны на философии Agile.

Рассмотрим преимущества и недостатки Agile.

Особенности Agile

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

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

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

Результат важнее документации. От плана можно отступать, если это принесет пользу проекту. 

Ограничения Agile

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

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

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

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

Гибкий подход подойдет, если:

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

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

• 
  запросы пользователей и ситуация на рынке постоянно меняются.

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

Компании, которые работают по Agile: Spotify, Microsoft, Google, Netflix, Ericsson, Dell, Adobe, Accenture, WordPress, Riot Games, CH Robinson, Magna International, Scrum Alliance, Intronis, General Electric, John Deere.

Подробно о том, что такое аджайл и как он появился, читайте в нашей статье «Agile – новый Lean?».

Scrum – инструкция по запуску нового продукта

Scrum
 – это способ организации рабочего процесса. Скрам помогает проверять идеи, тестировать новые решения, выпускать инновационные продукты.

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

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

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

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

Подробнее об организации работы по Scrum читайте в статье «Agile по правилам Scrum».

Особенности Scrum-подхода

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

• 
  Фокусировка на пользе для потребителя. Методология Scrum и agile-принципы заточены на то, чтобы изучать потребности пользователей, улучшать их опыт использования продукта. А не на то, чтобы сделать продукт в срок и согласовать его с заказчиком. 

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

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

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

Ограничения Scrum

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

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

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

Скрам подойдет, если:

• 
  вы разрабатываете новый продукт, аналогов которого нет на рынке;

• 
  у вас есть возможность собрать команду сотрудников, которые будут заниматься только этим проектом. 

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

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

Артемий Анцупов 

agile-coach, партнер «Скрамтрэк» 

Компании, которые используют Scrum: Google, Apple, Facebook, Spotify, AirBnB, Salesforce, «Промсвязьбанк».

Kanban – инструменты для улучшения рабочих процессов

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

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

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

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

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

Поэтому в канбане есть принцип «перестаньте начинать [новые задачи], начните завершать [задачи, которые уже в работе]»

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

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

Особенности канбана

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

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

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

• 
  Вся команда едина – нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Сделать», «В процессе», «Тестирование», «Согласование» и др.

Ограничения канбана

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

Канбан подойдет:

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

• 
  для отделов, которые поддерживают операционную деятельность: бухгалтерия, финансовый отдел;

• 
  для визуализации процессов и выявления проблем: доску по канбан-методу можно вести даже для личных дел – чтобы видеть приоритетные задачи и заметить дело, которое уже давно висит.  

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

Компании, которые используют канбан: «Альфа-Банк», «Хоум Кредит Банк», «Почта Банк», «Додо Пицца», HeadHunter, Wargaming, Microsoft, Siemens и другие.

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

Артемий Анцупов 

agile-coach, партнер «Скрамтрэк» 

Отличия Scrum и Kanban

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

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

Lean Startup – бережливый стартап

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

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

Базовые этапы Lean Startup:

1. 
   Построить минимально жизнеспособную версию продукта;

2. 
   Выпустить ее и оценить метрики;

3. 
   Сделать выводы и собрать идеи для улучшения продукта.

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

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

Бережливый стартап подойдет для:

• 
  снижения рисков при запуске стартапа. Основатель Zappos не знал , готовы ли люди покупать обувь по интернету. Чтобы проверить гипотезу, он сфотографировал обувь в местных магазинах и загрузил фото на сайт. Если обувь заказывали, он покупал ее в магазине и отправлял. Теперь Zappos – большой онлайн-ретейлер обуви.

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

Компании, которые используют Lean Startup: Dropbox, Zappos, General Electric, Slack, «Модульбанк».

Подробнее о применении бережливого стартапа читайте в статье «Бережливый стартап».

Главное о методах управления проектами в компании

• 
  Каскадная модель, или Waterfall, – это методология управления проектом, в котором все этапы идут последовательно друг за другом. Относится к классическому типу управления проектами.

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

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

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

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

Agile или Waterfall. Какой метод организации выбрать для работы с заказчиками? / Хабр

Это статей я крупно рискую быть затоптанным армией фанатов Scrum, Kanban, XP и других методик гибкого планирования. Мне придется привести аргументы в пользу того, что мир не черно-белый, и что стандартная диаграмма Ганта тоже полезна, а в некоторых случаях даже приоритетна для менеджмента проектов в IT.

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

Небольшое введение для новичков в проектном менеджменте. Что такое Agile и Waterfall модели, и чем они отличаются друг от друга?

Waterfall — каскадная модель, в которой четко видна последовательность действий в проекте. Рабочие задачи выставлены одна за другой, что визуально показано сменой блоков. По оси X отложено время выполнения, поэтому диаграмма Ганта показывает не только последовательность и взаимосвязи, но и время на каждую задачу.

В целом, бессмысленно словами описывать визуально понятную вещь. Проще показать.

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

Agile — с английского название этой модели переводится как «Гибкая», и это лучшее описание принципов метода планирования. На самом деле, Agile — это целая группа методов проектного менеджмента, самые известные из которых: Scrum, Kanban, FDD и другие концепции.

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

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

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

• Высокая скорость достижения результатов.

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

• Постоянный фидбек от заказчика и гибкое планирование.

• Распределенная и децентрализованная модель работы команды.

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

Возвращаемся к вопросу в заголовке: «Agile или Waterfall.

Какой метод организации выбрать для работы с заказчиками?»

Большинство новичков в менеджменте IT проектов выросли в парадигме: «Agile/Scrum — хорошо, Диаграмма Ганта — устаревший метод». Для них тезис: «Waterfall — лучшее решение для разработки проектов на заказ» звучит почти как оскорбление. Но реальный опыт работы с заказчиками показывает, что 90%+ клиентов IT-компаний хотят еще до начала сотрудничества точно знать, сколько времени и денег нужно для получения результата.

Абсолютное большинство заказчиков — это представители бизнеса. Их почти никогда не устраивает формулировка: «Точно сказать сложно, давайте начнем работу над проектом, а потом определимся, когда сможем закончить, и сколько это стоит» от менеджера IT-компании. Для предпринимателя подписаться на что-то неограниченное по времени и бюджету очень сложно. Это договор с неизмеримой степенью риска. И сколько ты не доказывай ему преимущества Scrum и гибкого подхода, в мозгу бизнесмена эти доводы будут звучать как попытка обмануть поубедительней.

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

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

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

• Заказчик полностью погружен в работу над проектом. Это более реалистичный сценарий, актуальный для стартапов. Когда у клиента бизнеса еще по факту нет, он прямо сейчас строится силами сторонней команды. Тогда он на правах руководителя будет ежедневно включен в разработку, а также лично будет видеть и утверждать объем работ. Заказчик должен понимать, что подписывается на «открытый» бюджет и сроки разработки.

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

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

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

Но именно для продаж, взаимодействия с клиентами ничего лучше старой доброй диаграммы Ганта придумано не было. Американский институт управления проектами (PMI) до сих пор рекомендует Waterfall в качестве оптимальной методологии планирования и управления. По версии организации, лучший подход — использование гибридных моделей, когда этапы работы идут не строго последовательно, а некоторые дела выполняются параллельно. В целях экономии времени и оптимизации управления проектом.

Источник — Курс «Как стать классным менеджером проектов и не ох..еть»

Ссылка на курс для жителей России

Традиционный водопадный подход

Традиционный водопадный подход

Водопадный подход к системному анализу и проектированию был первым установленным современным подходом к построению системы. Этот метод был первоначально определен Уинстоном В. Ройсом в 1970 году («Методология развития водопада», 2006). Он быстро получил поддержку менеджеров, потому что все шло логично от начала проекта до конца (Jonasson, 2008). Источники различаются, когда речь заходит о конкретных шагах процесса Waterfall (Jonasson, 2008), и я подробно расскажу о некоторых из этих различий в следующем абзаце. Тем не менее, основная логика и шаги присутствуют в каждой интерпретации.

Рисунок 1 : Метод водопада

(«Методология разработки водопада», 2006 г.)

Оригинальный метод водопада, разработанный Ройсом, показан на рис. 1 . Шаги включают определение требований, проектирование, реализацию, проверку и обслуживание. Другие модели заменяют фазу требований фазой идеи (Jonasson, 2008) или разбивают фазу требований на этап планирования и анализа (Hoffer, George, Valacich, 2008). Кроме того, некоторые модели дополнительно разбивают этап проектирования на подэтапы логического и физического проектирования (Hoffer, et al, 2008). Однако, как упоминалось ранее, основные основополагающие принципы остаются прежними.

Водопадный метод предполагает, что все требования могут быть собраны заранее на этапе Требования (Kee, 2006). Общение с пользователем происходит на этом этапе в первую очередь, поскольку менеджер проекта делает все возможное, чтобы получить подробное представление о требованиях пользователя. После завершения этого этапа процесс идет «по наклонной» (Hoffer, et al, 2008).

Фазу Design лучше всего описать, разбив ее на Logical Design 9Подэтапы 0008 и физического проектирования . На этапе логического проектирования аналитики системы используют информацию, собранную на этапе требований, для проектирования системы независимо от какой-либо аппаратной или программной системы (Хоффер и др., 2008). После завершения логического проектирования более высокого уровня системный аналитик начинает преобразовывать его в физический проект в зависимости от спецификаций конкретных аппаратных и программных технологий («Жизненный цикл разработки программного обеспечения», nd)

Фаза Реализация — это когда написан весь фактический код («Фазы SDLC», n. d.). Этот этап принадлежит программистам по методу водопада, поскольку они берут требования и спецификации проекта и кодируют приложения.

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

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

Водопадный метод имеет определенные преимущества, в том числе:

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

К сожалению, метод Waterfall несет в себе довольно много недостатков, таких как:

• Клиентам часто бывает трудно сформулировать свои требования на абстрактном уровне функциональной спецификации, и они полностью оценят то, что необходимо, только когда приложение доставляется. Затем становится очень сложно (и дорого) перепроектировать приложение.
• Модель не учитывает возможность изменения требований в ходе цикла разработки.
• Реализация проекта часто может занять значительно больше времени, чем при разработке с использованием итеративной методологии, такой как метод гибкой разработки. («Методология развития водопада», 2006 г.).

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

Что такое модель водопада?

Качество программного обеспечения

От

• Бен Луткевич,
  Технические характеристики Писатель
• Сара Льюис

Что такое модель водопада?

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

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

Доктор Уинстон В. Ройс из Центра программных технологий Lockheed представил эту концепцию в статье, опубликованной в 1970 году, о своем опыте разработки программного обеспечения для спутников. Однако Ройс не использовал термин 9.0097 водопад ; вместо этого он упомянул о последующей ценности документации.

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

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

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

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

Например, в строительстве обычно следуют этим трем основным шагам:

1. Физический проект здания создается до начала строительства.
2. Фундамент заливается до возведения каркаса здания.
3. Каркас здания готов до возведения стен.

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

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

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

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

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

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

Фазы модели водопада

При использовании в процессе разработки программного обеспечения метод водопада состоит из семи этапов:

1. Требования . Потенциальные требования, сроки и рекомендации по проекту анализируются и помещаются в формальный документ с требованиями, также называемый функциональной спецификацией . Этот этап разработки определяет и планирует проект без упоминания конкретных процессов.
2. Анализ. Спецификации системы анализируются для создания моделей продукта и бизнес-логики для управления производством. Это также когда финансовые и технические ресурсы проверяются на предмет осуществимости.
3. Дизайн. Создается документ спецификации проекта, в котором излагаются технические требования к проекту, такие как язык программирования, аппаратное обеспечение, источники данных, архитектура и службы.
4. Кодирование и реализация. Исходный код разработан с использованием моделей, логики и спецификаций требований, указанных на предыдущих этапах. Как правило, система кодируется в более мелких компонентах или модулях перед их сборкой.
5. Испытания. Это когда проверка качества, модульное, системное и бета-тестирование выявляют проблемы, которые необходимо решить. Это может привести к принудительному повторению этапа кодирования для отладки. Если система проходит интеграцию и тестирование, водопад продолжается.
6. Эксплуатация и развертывание. Продукт или приложение считаются полностью функциональными и развернуты в действующей среде.
7. Техническое обслуживание. Корректирующее, адаптивное и улучшающее техническое обслуживание осуществляется на неопределенный срок для улучшения, обновления и улучшения продукта и его функциональности. Это может включать выпуск обновлений исправлений и новых версий.

Метод водопада — это линейный способ структурирования процедур и процессов в проекте разработки программного обеспечения.

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

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

Сегодня методология Agile часто используется вместо модели водопада. Однако у каскадного подхода есть свои преимущества, например:

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

Недостатки водопадной модели

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

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