Характеристики проекта "Март смерти"

Ответ 1

У Википедии было довольно хорошее определение:

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

Термин " марш смерти " в этом контексте подробно обсуждался в книге Эдварда Юдона " Смертельный марш: Полное руководство разработчика программного обеспечения по выживанию в проектах" Миссия невыполнима " (ISBN 0130146595),

Я думаю, что "Deathmarches" происходят от нетехнических людей, которые выбирают произвольные сроки для проектов/функций без какого-либо участия со стороны разработчиков с точки зрения оценок. Это приводит к необоснованным срокам, и если вы сочетаете это со свободными требованиями со стороны клиента, у вас есть Deathmarch.

Ответ 2

Когда вы спрашиваете команду, насколько далеко они думают о проекте, довольно важный показатель - это когда менеджер проекта оценивает, что его 70% завершено, бизнес-аналитик догадывается о его 45-55%, и разработчики говорят, что его 5-10% завершено.

Это предупреждающий знак.

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

Ответ 3

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

Я видел пару способов, которые возникают в следующих ситуациях:

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

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

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

Ответ 4

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

Ответ 5

Я бы сказал, что Deathmarch действительно представляет собой системный провал... так что это не одна вещь, которая создает Deathmarch, а скорее слияние событий.

Я бы сказал, что помимо общего плохого управления проектами (нереалистичное планирование, неправильное использование slips и т.д. и т.д. и т.д.) проекты Deathmarch часто связаны с новой технологией, которая рассматривается как своего рода "серебряная пуля". Часто в сочетании с плохой подготовкой и отсутствием понимания.

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

Ответ 6

Обычно это происходит из бизнеса, выполняющего функции клиента и требования, для которых они считают, что система/группа разработчиков могут закончиться за x количество времени... без фактического запроса оценки времени или даже перехода требования, которые они собирали для клиента! И тогда, потому что это такой проект, создающий денежные средства, соглашается на это, потому что "для компании в целом" это хороший производитель доходов! У меня было от 4 до 5 маршей смерти, обычно длительностью от одной до двух недель. Мой последний deathmarch длился около 2 месяцев и состоял из 9-14-часовых рабочих дней.:( не весело.

Ответ 7

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

Если проект не имеет реального интереса к бизнес-ценности - он перемалывается на горький конец, где он должен быть отменен ( "Descoped" или "Reprioritized" ).

Единственный способ, которым это может случиться, - это то, что управление ИТ (a) может иметь полезный вклад, но не оценивается бизнесом, или (b) вообще не имеет понятия.

Марш смерти означает, что команда не строит что-то ценное, оно создает что-то, что соответствует стоимости и графику.

Ответ 8

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

Ответ 9

Обычно это происходит из-за плохого планирования и общения.