Управление проектами Waterfall - сегодня большинство ИТ-специалистов рассматривают возможность внедрения гибких систем управления проектами. Но в конечном итоге они применяют системы Agile Project Management для своих проектов. Это означает сочетание традиционных систем управления проектами (называемых системами управления проектами Waterfall) в сочетании с принципами гибкого управления, как подробно описано в первоначальном манифесте Agile.
Поскольку все больше проектов по всему миру включают в себя методы управления гибкими проектами, означает ли это конец управления проектами водопад? Все ли ИТ-проекты в конечном итоге станут Agile Project Management?
Чтобы понять различные модели, в том числе Agile, и использовать ту, которая лучше всего подходит для вашей ситуации, важно сначала понять, что представляет собой традиционная система управления проектами, называемая моделью управления проектами Waterfall.
Модель управления проектом «Водопад», названная так в связи с характером рабочего процесса, характеризуется следующим:
- Конечный продукт сначала визуализируется в мельчайших деталях.
- Затем этапы рабочего процесса реализуются в последовательности:
- Требования и анализ
- дизайн
- Реализация
- тестирование
- Установка
- техническое обслуживание
- План проекта должен быть надежным, поскольку после завершения этапа в последовательности разработчики не могут вернуться к нему без повторного планирования.
- Существует мало возможностей для изменений или ошибок, и план проекта должен тщательно соблюдаться.
Происхождение модели управления проектом водопад:
На ранних этапах развития ИТ-индустрии не было конкретной модели для разработки программного обеспечения.
Таким образом, в отрасли была принята модель последовательного рабочего процесса, используемая в обрабатывающей промышленности и строительстве. В этих отраслях были четко определенные этапы работы, и они разработали модель, которая удовлетворяла их потребности в строгом контроле над расходами. Таким образом, модель индустрии оборудования была применена к индустрии программного обеспечения.
Уинстон В. Ройс впервые представил эту модель в 1970 году, но он не использовал термин «Управление проектами водопада». На самом деле он представил модель как ущербную. Наглядное изображение модели выглядело как каскадный водопад. Томас Е. Белл и Т. А. Тейер позже использовали термин «водопад» в своей статье 1976 года «Требования к программному обеспечению: действительно ли они являются проблемой?», И этот термин остался.
Существует несколько вариантов этой модели. Широко используемые шесть различных этапов в Модели управления проектами «Водопад» описаны ниже. Однако, в зависимости от проекта, два этапа могут быть объединены вместе.
Давайте рассмотрим пример строительства школы в качестве примера, чтобы лучше понять модель управления проектом водопада.
-
Требования и этап анализа:
Во-первых, мы должны точно знать, что мы проектируем. Для этого мы можем захотеть:
- Провести подробные обсуждения с клиентом
- Постарайтесь четко визуализировать продукт с мельчайшими деталями
- Проанализируйте, какие аппаратные и программные компоненты необходимы
- Перечислите детали, которые включают в себя: проблему, которую должен решить продукт, ограничения клиента, уровень производительности и совместимость с уже существующими системами.
- Провести тематические исследования аналогичного продукта.
- Рассмотрим требования каждого участника
- Перечислите спецификации в документе с требованиями к продукту, который формирует входные данные для следующего шага.
В нашем примере строительства школы на этом этапе мы перечисляем количество классных комнат, материал, который будет использоваться для строительства, необходимые люди, уже существующую инфраструктуру. Кроме того, мы бы отметили, что руководство школы требует (кабинет, комната для персонала) и что требуется студентам (лучшие туалеты, игровые площадки)
-
Дизайн:
На этапе проектирования все, что было визуализировано на первом этапе, превращается в проект.
В ИТ-проектах это состоит из определения:
- Оборудование, которое будет использоваться
- Используемая программная платформа, включая локальное или облачное развертывание.
- Архитектура программного обеспечения, включая различные компоненты и модули, которые будут созданы
- Входные данные, необходимые для успешной работы проекта
- Ожидаемые результаты (в идеале это будет синхронизироваться с требованиями, подробно изложенными на предыдущем этапе)
Есть два типа дизайна, которые вступают в игру в программном проекте:
- Логический дизайн
- Физический дизайн
Логический дизайн:
Это включает в себя основные данные и процессы, которые будут включены в проект. Это детализирует дизайн форм и отчетов, дизайн интерфейса и дизайн базы данных. Например, для веб-сайта по продаже билетов на поезд этот дизайн будет определять, как будет работать весь процесс: на экране, на котором путешественник вводит свои данные, и как эти данные будут поступать в базу данных, а также в какой базе данных будут храниться эти данные.
Физический дизайн:
Это касается проектирования физической базы данных, программ и процессов, а также распределенных систем. Это делается после логического проектирования и будет включать «как» будет реализован проект: аппаратное обеспечение, платформа, на которой он будет разрабатываться, различные базы данных, экраны и формы, которые будут использоваться, и т. Д.
-
Реализация:
- Именно здесь происходит фактическая разработка программного обеспечения / системы.
- Входные данные для этого этапа - это спецификации проекта, предоставленные на предыдущем этапе.
- Результатом является один или несколько компонентов продукта, созданных по спецификациям, отлаженных, протестированных и интегрированных для соответствия архитектуре системы.
- Об этом этапе обычно заботится команда разработчиков, состоящая из программистов, дизайнеров интерфейсов и других специалистов, а используемыми инструментами являются компиляторы, отладчики, интерпретаторы и редакторы мультимедиа.
- Этот этап обычно занимает максимальное время, и важно тщательно отслеживать процессы и дизайн. Изменения в дизайне на этом этапе являются сложными в управлении проектами водопада.
- Для большого проекта, включающего несколько команд, контроль версий рекомендуется отслеживать изменения в дереве кода и возвращаться к предыдущим снимкам для обработки ошибок.
- В нашем примере: Фактическое строительство здания с использованием рабочей силы и материалов выполняется на этом этапе.
-
Тестирование:
Тестирование может быть сделано для продукта в целом или для отдельных компонентов. «Контрольные примеры» могут быть проверены, чтобы увидеть, может ли продукт доставить, как обещано. Возможны тестирование модулей, тестирование системы интегрированного продукта и приемочные испытания. Приемочное тестирование включает в себя тестирование продукта на наличие лазеек конечным пользователем или заказчиком. Дефекты записываются для исправления командой внедрения. После внесения исправлений готовится официальная документация по продукту.
В этом примере инфраструктура школы проверяется, вероятно, аудиторской командой. В некоторых случаях учителям предлагается войти и использовать помещение для обратной связи.
-
Установка:
После того, как тестирование продукта завершено во всех аспектах, продукт может быть выпущен на рынок или установлен у клиента. На этом этапе также передается полная документация по продукту.
В случае с нашей школой, он официально открыт (желательно крупным планом!) И школа начинает свою работу!
-
Техническое обслуживание:
На этом этапе команда ИТ-специалистов устраняет любые проблемы, которые могут возникнуть, когда клиент фактически начнет использовать продукт или произойдет улучшение продукта. Хорошая документация является основой технического обслуживания. Проблемы устраняются путем изменения кодов, называемых «патчи».
Если требуются серьезные изменения, проект может вернуться к команде разработчиков как новый проект.
В нашем примере школа нуждается в регулярном техническом обслуживании, в основном инфраструктурном, например, неисправная электропроводка или протекающие ванные комнаты. Эти проблемы необходимо решать время от времени.
Как вы можете видеть, этапы управления проектами разработки водопадов различны, и, хотя обычно с клиентом происходит постоянное взаимодействие, главное - обсудить ход выполнения проекта, а не дизайн или требования. Однако модель управления водопадными проектами в течение многих лет адекватно служила ИТ-индустрии, и для большинства проектов этапы все еще остаются хорошими, хотя и не такими жесткими.
Однако, есть несколько проектов, для которых Модель управления проектами Водопада очень подходит.
Для какого проекта подходит Waterfall Project Management?
Определение продукта:
Во-первых, конечный результат (продукт) должен быть четко определен в самом начале. Проекты, в которых владелец продукта не очень уверен в точных спецификациях желаемого продукта, могут хорошо следовать методам Agile Management.
Документация:
Проект должен быть одним, который можно задокументировать. Документация является важным требованием Модели управления проектом «Водопад». Требования к продукту, дизайн и исходный код должны быть четко задокументированы на всех этапах. Если первоначальные члены команды выходят, это формирует руководство для непрерывности проекта.
Время и ресурсы:
Не должно быть немедленной необходимости выпуска продукта. Сроки устанавливаются в начале проекта, и команда должна быть в состоянии их придерживаться. Кроме того, должны быть достаточные ресурсы с точки зрения рабочей силы и технологий.
Риск и неопределенность:
Инструменты управления проектами Waterfall плохо работают в условиях риска и неопределенности. Например, мобильное приложение представляет собой тип продукта, который сталкивается с постоянной неопределенностью с точки зрения принятия клиентов и конкуренции аналогичных приложений.
Четко определенные этапы:
Этапы системы должны быть четко определены, так как они должны быть выполнены последовательно и не должно быть перекрытия.
Когда создается новая версия существующего программного обеспечения.
За пределами области ИТ Модель управления проектами «Водопад» успешно используется в таких крупных проектах, как
- Самолетостроение
- Инфраструктурные проекты, такие как мосты
- Производство оборонного оборудования
- Системы здравоохранения в больницах
В ИТ-проектах Waterfall Project Management особенно подходит для тех проектов, в которых требуется внешнее оборудование. Характеристики этого не могут быть изменены на полпути, так как это приведет к потере миллионов долларов.
Когда недостатки в управлении проектами Waterfall стали очевидными в индустрии программного обеспечения, возникла серьезная мысль о том, как ИТ-команды могут обеспечить максимальную отдачу для клиентов, обеспечивая при этом гибкость в процессе рабочего процесса.
Таким образом, появилась Agile Project Management System, которая в настоящее время используется большинством компаний-разработчиков программного обеспечения.
Водопад Управление проектами против Agile Systems:
Agile Project Management - гибкая модель, которая стала популярной в 1990-х годах. Он включает в себя разбиение проекта на «мини-проекты», называемые спринтами, и независимую работу над каждым из них. Такая модель позволяет разработчикам быстрее вносить необходимые изменения, и она очень эффективна, когда среда клиента изменчива.
Положительными моментами этапов управления проектом водопад являются:
- Поскольку конечный продукт известен во всей своей полноте, планирование и дизайн однозначны.
- Потенциальные проблемы, которые могут возникнуть в проекте, могут быть устранены на самой стадии проектирования; прежде чем какой-либо код был написан.
- Измерение прогресса в работе легко, поскольку этапы четко определены.
- Стабильность команды налицо, так как команда остается до конца проекта. В случае Agile, команда постоянно меняется, и это требует определенной корректировки.
- Документация обширна, что облегчает управление командами, если участник уходит.
- Разработчики считают, что с этой моделью легче работать, так как ее легко понять,
- После этапа «Требование» активное участие конечного потребителя необходимо только на этапе тестирования. Это связано с тем, что все требования были обсуждены изношенными, не оставляя двусмысленности.
- Продукт может разрабатываться целиком, а не развиваться по частям.
- Вопросы управления контрактами и клиентами лучше решаются в рамках Модели управления проектами «Водопад».
Положительными моментами Agile Project Management являются:
- Заказчик может взаимодействовать с командой проекта на протяжении всего цикла и время от времени вносить изменения в продукт в соответствии с меняющейся средой.
- Если продукт должен быть выпущен очень скоро из-за рыночных обстоятельств, команда Agile Project Management может выпустить базовую версию, которая может иметь расширенные версии позже.
- Система достаточно прозрачна с точки зрения клиента, и он имеет четкое представление о том, на каком этапе находится его продукт.
- Поскольку клиент предоставляет приоритет функций, команда знает, что ему необходимо сосредоточиться на функциях, предлагающих наибольшую ценность для бизнеса.
- Процесс имеет свой собственный импульс.
- Команды текучие и гибкие, что позволяет мыслить каждому члену
- Документация минимальна, и поэтому время освобождается от этих задач.
После многих лет существования обеих моделей стало очевидным, что:
Модель управления проектом «Водопад» эффективна для управления проектом, когда после завершения проекта изменения минимальны.
Agile Project Management больше подходит для управления продуктами, где важно быть гибким к изменениям.
Несмотря на это, система управления проектами Waterfall остается важным компонентом большинства ИТ-проектов. Нельзя точно сказать, что конкретный проект строго следует Agile Management Practices. Обычно Agile-принципы «включаются» в ИТ-проекты.
В некоторых Agile Project Management есть менеджеры проектов, в то время как в Agile модели есть только Scrum Masters. Это гибридные комбинации моделей Agile и Waterfall Project Management, которые некоторые называют «Agifall» или «Agency Agile».
Популярность системы управления проектами Waterfall также связана с тем, что вопросы управления контрактами и клиентами лучше решаются с помощью методов управления проектами Waterfall.
В то время как все больше и больше проектов попадают под контроль Agile Project Management, и все больше компаний видят преимущества гибкой модели управления, популярность Модели управления проектами Waterfall, несомненно, падает.
Тем не менее, трудно представить будущее ИТ-проектов, которые будут полностью гибкими, в ближайшем будущем. А Waterfall Project Management, которая помогла индустрии программного обеспечения в зачаточном состоянии, будет жить в нескольких компонентах управления проектами, по крайней мере, еще несколько лет.
Первый источник изображения: picjumbo.com
Статьи по Теме
- 6 полезных этапов рабочего процесса в управлении проектами водопада
- Эффективные советы для группового обсуждения (советы экспертов)
- Топ 10 мифов об управлении проектами
- 6 эффективных причин, по которым каждому нужен страстный проект на работе
- Лучшие 5 типов инструментов управления отчетами проекта
- Управление продуктом против управления брендом - полезные различия