Что такое Расползание границ проекта? [закрытый]

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

Вы запускаете с мыши и заканчиваете со слоном.

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

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

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

Расползание границ проекта может быть результатом:

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

Существует два определения для расползания границ проекта.

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

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

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

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

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

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

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

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

Если у Вас есть соответствующий контроль изменений, возможно дойная корова.

Существует известное изображение лодки крупной державы с небольшой малолитражкой в буксировке. Малолитражку называют "Первоначальным договором", и моторный катер называют "Запросами на изменение"

функции, бюджет, расписание: выберите любые 2, но не все 3

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

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

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

Расползание границ проекта рассматривают в том же свете как излишнее усложнение только на уровне объема продуктов... Например:

Ваша команда создает "Воздушного Сосунка" (TM), которая сосет воздух из одного местоположения и транспортирует ее к фабрике через два квартала. Объем воздушного сосунка - то, что это перемещает воздух.

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

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

Расползание границ проекта является любым изменением в, первоначально договорился об объеме/определении спецификации/проекта. Изменение могло произойти из-за исследования предшествующих неизвестных, внутренних/внешних изменений рынка, технологических изменений или запланировать, ole' спонсирует желание чего-то больше. Это негативно влияет на проект, когда там не существует никакой процесс контроля изменений, чтобы рассмотреть и принять или отклонить изменение.

Расползание границ проекта похоже на порнографию: Вы знаете это, когда Вы видите его.

И как расползание границ проекта влияет на расписание продукта? Существует ли способ не допустить расползание границ проекта в Ваш процесс разработки? Как Ваш PM обрабатывает расползание границ проекта? Что лучшая функция должна была когда-либо выходить из расползания границ проекта? и т.д. и т.д.