Как сжатые сроки и давление графика влияют на TCO и время доставки?

Отец друга, который является менеджером по разработке программного обеспечения, решительно сказал: «Причиной номер один при переполнении расписаний является планирование давления».

Где находится исследование? Является ли умеренное количество давления при планировании бодрым, или менеджер, которого я упомянул, был правильным или неправильным, или это вопрос «чем больше у вас давления при планировании, тем дольше время доставки и больше TCO?» Является ли это одной из тех вещей, где в идеале разработка программного обеспечения будет работать без планирования, но практически мы должны работать с ограничениями реальных ситуаций?

Любые ссылки на программную литературу приветствуются.

Причиной переполнения в расписании является проблема планирования.

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

Другая проблема заключается в том, что продукт должен быть «достаточно хорошим». Это не должно быть идеально. Инженеры и ученые видят упрощающие предположения, которые не совсем верны в некоторых особых случаях. Графические дизайнеры видят проблемы с псевдонимами, которые невидимы для всех остальных. Программисты видят в своих архитектурах бородавки, которые не влияют на поведение продукта. «Лучшее - враг достаточно хорошего», что означает, что иногда нам приходится жить с теми проблемами, которые на самом деле не являются проблемами.

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

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

То, как ваш вопрос сформулирован, подразумевает, что время является вашей переменной, а остальные три (качество, ресурсы и количество функций) все фиксированы. Вопрос может быть полезным, если немного изменить ракурс, установив время ^* и оставив качество на плаву.

Теперь ваш вопрос звучит так: «Влияет ли ограничение времени на качество»? Ответом на этот вопрос является громкое «Да»: исследования подтверждают, что люди испытывают худшие результаты под давлением проблем, связанных с математикой ^**, что они не практиковали раньше (то есть пытались пятьдесят или более раз), поэтому отец вашего друга прав.

^** Здесь подразумевается, что программирование похоже на математику; Я думаю, что это предположение справедливо.

чем больше у вас календарного планирования, тем дольше время доставки и тем больше TCO?

Хорошо, любое планирование, выполненное менеджером без обсуждения с техническим лидером, склонно к этому. Совершенно очевидно, что планирование или оценки, которые НЕ основаны на фактах, подвержены ошибкам .

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

Планирование справа налево.

Кто-то в управлении всегда думает, что это Стив Джобс со своей знаменитой зоной искажения реальности. Пока кто-то в разработке продукта не обучит их, нетехнические менеджеры могут часто иметь представление о планировании, которое является столь же сложным, как в раннем французском фильме «Путешествие на Луну» («Поездка на Луну»), который был для ракетостроения.

Проблема была вокруг некоторое время. Фред Брукс говорит об оценке без интуиции в « Мифическом человеко-месяце» . Барри Бем говорит об этом в своих предложениях относительно подхода Theory-W к управлению. Совсем недавно Стив Макконнелл (автор Code Complete ) выдвигает на первый план концепцию принципиальной проблемы переговоров в разделе «Как защитить непопулярный график» .

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

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

Существует поговорка, что чем раньше вы начнете кодировать, тем дольше это займет. Давление графика может оказать влияние на изменение методологии. Иногда это от водопада до «кода, как ад». Это может оказать негативное влияние на качество, не говоря уже о моральном духе, когда работники не могут сделать все возможное, а их сверстники и будущие сопровождающие видят их в худшем, а не в лучшем виде. В такой среде можно управлять некоторой степенью хаоса с помощью контроля исходного кода, ежедневной сборки и тестирования (или непрерывной интеграции и модульного тестирования), проверки кода с использованием опытной и высококвалифицированной команды, противостоящей искушению добавить персонал в конце проект и старый режим ожидания, сверхурочные.

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

Лицензия Creative Commons - см. Http://en.wikipedia.org/wiki/File:Scrum_process.svg.

Вам не нужна литература по разработке программного обеспечения. Концептуальная вероятность и статистика, от старшекурсника, это все, что вам нужно.

Оценка - это всего лишь оценка. Это не точно, это не гарантировано. Для любой оценки, есть некоторая вероятность того, что вы потеряете его или ударите по носу, и некоторая вероятность того, что вы переполните его.

Вероятность 101: р (недопустимость или попадание точно) + р (переполнение) = 100%.

График, основанный на оценке, имеет точно такие же характеристики.

Вы не можете полностью устранить неопределенность. ВСЕГДА будет некоторая вероятность переполнения. Может быть, мала вероятность того, что Иран уничтожит ваше офисное здание, но оно все еще там. Лучшее, что вы можете сделать, - это смотреть на ВСЕ и максимально уменьшить неопределенность. Как только вы это сделаете, у вас, если вам повезет, будет график с небольшой неопределенностью и 50% вероятностью на каждой стороне.

Теперь подумайте об этом: если вы включите график, вероятность того, что вы не достигнете или точно достигнете графика, уменьшится. Общая сумма еще должна составить 100%. Куда уходит эта вероятность? Ответ, это входит в вероятность переполнения.

General Dynamics / Fort Worth Division изучили этот трудный путь. Они сделали свою первоначальную оценку развития F-16C / D и отправили ее в пищевую цепочку. Кто-то наверху произвольно вырезал год и отправил это в военно-воздушные силы. Как прямой результат, GD / FW был на год опоздал на летные испытания, и ВВС не были счастливы. (Обратите внимание, что «один год с опозданием» соответствовал пересмотренному графику, а это означает, что первоначальное расписание было ПРАВИЛЬНО НА ЦЕЛЕ.)

Я думаю, что определенное давление в проекте в порядке, потому что это помогает сохранять фокус.

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

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

Там много факторов, которые влияют на определение достаточно хорошо.

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

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

В итоге, я думаю, что плохое общение между руководством и техническими специалистами и отсутствие общего понимания того, что является достаточно хорошим для рассматриваемого проекта, может привести к чрезмерному давлению планирования, что приведет к плохому качеству / задержке поставки.

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