Можно ли использовать Agile в инфраструктурных проектах, объем которых заранее известен?

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

Примеры проектов

  1. Миграция/перемещение центра обработки данных
  2. Миграция SAN
  3. Для решения Cisco Telepresence
  4. Телефония Проекты

Объем не меняется, большая часть проекта будет запускаться из Runbook.

Если это невозможно, означает ли это, что инфраструктурные проекты в основном выполняются с использованием Waterfall?

Недостаточно информации, чтобы ответить на ваш вопрос, как написано. Например, где находится ваша WBS для миграции центра обработки данных? Практически любой проект может быть agile-проектом , если он структурирован таким образом.
Короткий ответ: да, конечно. слишком много деталей отсутствует.
Я разместил свое мнение об этом здесь: linkedin.com/pulse/…
Говоря, что область известна, вы подразумеваете, что известна реализация. Если это так, вам не нужно меняться, адаптироваться или учиться. Вы по-прежнему можете получать выгоду от итеративного предоставления ценности, но не более того. Вы исключили все возможные риски. Если это так, конечно, адаптивный подход Agile ничего вам не даст и будет стоить вам дороже, но я никогда в своей карьере не видел подобного инфраструктурного проекта, поэтому я опасаюсь этой предпосылки.
Ценности и методы Agile могут помочь любому проекту, но очереди поддержки и неитеративная работа не подходят естественным образом. Какие проблемы вы на самом деле пытаетесь решить с помощью выбранного вами фреймворка? Я постоянно занимаюсь гибкими инфраструктурными проектами, но оптимизирую масштабы, прозрачность и тесную обратную связь.
Участвуя в нескольких инфраструктурных проектах, пытаясь впихнуть их в один из популярных итерационных фреймворков (обычно Scrum), проектная команда может запутаться. Они пытаются установить произвольные временные рамки, которые не соответствуют действиям по миграции, и принимают формат пользовательской истории, что очень сложно. Однако в настоящее время вопрос слишком широк. Ловкость — это, прежде всего, чувство масштаба. Даже инфраструктурные проекты используют формат MVP для тестирования и обучения. Мы не переносим ВСЕ данные; мы переносим тестовое приложение или куб данных и извлекаем из этого уроки.

Ответы (3)

Agile/Scrum не подходит для предсказуемой работы

Пожалуйста, смотрите мой ответ на аналогичный вопрос ранее .

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

Как вы сами указали:

масштаб не меняется, большая часть проекта будет запускаться из Runbook

Все ваши примеры являются прогнозными проектами:

  1. Миграция/перемещение центра обработки данных
  2. Миграция SAN
  3. Для решения Cisco Telepresence
  4. Телефония Проекты

Дело не в том, возможна ли Agile:

Если это невозможно, означает ли это, что инфраструктурный проект в основном выполняется Waterfall?

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

Можно ли использовать Agile в проектах, объем которых заранее известен ? Да.

Это лучший подход ? Может быть.

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

Например, при настройке проекта видеоконференций знаете ли вы...

  • сможет ли сеть удовлетворить новый спрос?
  • этот новый спрос будет стабильным в разных офисах?
  • знаете ли вы, как это сделать, если вам нужно сменить сетевого провайдера в определенном месте?

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

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

Подход Lean Agile Kanban лучше подходит для эксплуатации и обслуживания, чем подход Scrum. Большая разница в том, что Канбан не имеет фиксированных временных рамок. Работа переходит из незавершенной работы в незавершенную и выполненную. Ключевой концепцией является ограничение незавершенного производства. Это предотвращает одновременное выполнение слишком большого количества одновременных задач. Делайте 2 или 3 дела за раз, а не 17 дел за раз. Уменьшите переключение контекста и выполняйте каждую задачу быстрее.

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

Можно ли использовать Agile в инфраструктурных проектах, объем которых заранее известен?
СпросиСетьПолитика конфиденциальности1y, 1v