В разработке программного обеспечения проект смертельного марша обычно относится к проекту с фиксированной датой релиза с фиксированными функциональными возможностями и фиксированными ресурсами, что приводит к безумным требованиям руководства, которые разработчики работают над долгими часами и выходными.
Как вы думаете, какой проект смерти и как оно происходит?
У Википедии было довольно хорошее определение:
В отраслях разработки программного обеспечения и разработки программного обеспечения марш смерти является дисфемизмом для проекта, который обречен на провал. Обычно это является результатом нереалистичных или чрезмерно оптимистичных ожиданий в отношении планирования, области функций или того и другого, и часто включает отсутствие соответствующей документации или какого-либо соответствующего обучения. Знание обреченной природы проекта тяжело давит на психику его участников, как будто они беспомощно наблюдают за командой, когда она выходит в море. Часто марш смерти сопровождается отчаянными попытками исправить ход проекта, предлагая членам команды работать особенно изнурительные часы, выходные (иногда с невозмутимым лицом) или пытаясь "бросить (достаточно) тела в проблему" с различные результаты, часто вызывая выгорание.
Термин " марш смерти " в этом контексте подробно обсуждался в книге Эдварда Юдона " Смертельный марш: Полное руководство разработчика программного обеспечения по выживанию в проектах" Миссия невыполнима " (ISBN 0130146595),
Я думаю, что "Deathmarches" происходят от нетехнических людей, которые выбирают произвольные сроки для проектов/функций без какого-либо участия со стороны разработчиков с точки зрения оценок. Это приводит к необоснованным срокам, и если вы сочетаете это со свободными требованиями со стороны клиента, у вас есть Deathmarch.
Когда вы спрашиваете команду, насколько далеко они думают о проекте, довольно важный показатель - это когда менеджер проекта оценивает, что его 70% завершено, бизнес-аналитик догадывается о его 45-55%, и разработчики говорят, что его 5-10% завершено.
Это предупреждающий знак.
Я думаю, что они могут произойти из-за плохого планирования и оценки, необоснованных требований бизнеса, командной имплозии, объема и характеристик ползучести с ужесточением сроков, а также старого старого , который является глупой идеей в первую очередь.
Из моего немного ограниченного опыта я бы сказал, что проект "Death March" - это любой проект, который заставляет разработчиков работать безумными часами в течение длительного периода времени. Эти разработчики обычно сжигаются задолго до крайнего срока.
Я видел пару способов, которые возникают в следующих ситуациях:
Я бы сказал, что номер один - лучший показатель для меня, потому что он обычно является причиной всех других факторов. Например: overoptimism приводит к преувеличенным претензиям к клиенту, призраку, чтобы принять ползучесть области, лень и т.д.
Я также считаю, что стоит отметить, что это не всегда вина руководства, команды разработчиков или любых других сторон, которые непосредственно не участвуют в программировании. Программисты часто переоценивают свои способности и могут также писать багги-код, который возвращает проект.
Другим признаком deathmarch все больше и больше людей прыгает с корабля, поскольку проект приближается к "крайнему сроку".
Я бы сказал, что Deathmarch действительно представляет собой системный провал... так что это не одна вещь, которая создает Deathmarch, а скорее слияние событий.
Я бы сказал, что помимо общего плохого управления проектами (нереалистичное планирование, неправильное использование slips и т.д. и т.д. и т.д.) проекты Deathmarch часто связаны с новой технологией, которая рассматривается как своего рода "серебряная пуля". Часто в сочетании с плохой подготовкой и отсутствием понимания.
Во всех случаях большое количество команд должно знать, что проект обречен действительно претендовать на титул "Deathmarch".
Обычно это происходит из бизнеса, выполняющего функции клиента и требования, для которых они считают, что система/группа разработчиков могут закончиться за x количество времени... без фактического запроса оценки времени или даже перехода требования, которые они собирали для клиента! И тогда, потому что это такой проект, создающий денежные средства, соглашается на это, потому что "для компании в целом" это хороший производитель доходов! У меня было от 4 до 5 маршей смерти, обычно длительностью от одной до двух недель. Мой последний deathmarch длился около 2 месяцев и состоял из 9-14-часовых рабочих дней.:( не весело.
Проекты Deathmarch подчеркивают нерелевантность ИТ-организации, которая позволяет ей произойти. Если есть ощущение, что расписание и бюджетные козыри такие вещи, как функциональность, технический выбор или ценность для бизнеса, то управление ИТ было сделано неуместным. ИТ-менеджеры должны просто следить за МВЗ, о которых сообщают программисты.
Если проект не имеет реального интереса к бизнес-ценности - он перемалывается на горький конец, где он должен быть отменен ( "Descoped" или "Reprioritized" ).
Единственный способ, которым это может случиться, - это то, что управление ИТ (a) может иметь полезный вклад, но не оценивается бизнесом, или (b) вообще не имеет понятия.
Марш смерти означает, что команда не строит что-то ценное, оно создает что-то, что соответствует стоимости и графику.
К сожалению, в некоторых консалтинговых компаниях также есть стандартная операционная процедура, в которой некоторые квалифицированные инженеры оценивают реальные человеческие часы, необходимые для проекта, а затем менеджер HALVE, который в конечном предложении, чтобы выиграть заявку на проект, тем самым обеспечивая болезненный Марш смерти для команды.
Обычно это происходит из-за плохого планирования и общения.
