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

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

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

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

Суть в том, что многие (не все, но всё же) изменения не являются зависимыми и в действительности легко могут быть перенесены на следующую итерацию, если времени на их проверку и интеграцию в апстрим сейчас нет. На первый взгляд кажется, что такой подход тормозит разработку, но это может быть заблуждением. Почему?

  1. При переносе на следующую итерацию прогресс, достигнутый по задаче никуда не пропадает. От следующей итерации он не отнимет время повторно. Заново ничего не потребуется разрабатывать, повторное интеграционное тестирование можно не проводить (точнее его не стоит проводить до мержа) - только слить. А это повышает объём полезного выхлопа следующей итерации. Какая к чёрту разница в какой именно версии появится некоторое улучшение, в случае, если оно атомарно и от него пока никто не зависит?
  2. Качественно выполненная работа отнимает одинаковое количество времени, вне зависимости от того, на какой итерации. Но я лукавлю - здесь есть подводный камень в специфике разработки - чем дольше откладывается мерж, тем больше вероятность и объём мерж-конфликтов. Но это может быть меньшим злом, чем пытаться успеть впихнуть невпихуемое за вечер пятницы перед релизом.

Даже если взять условный agile/scrum или что там ещё про самоорганизующиеся команды разработчиков (ядро Linux под это, конечно не подходит) - конечная цель итерации - сделать нечто полезное для заказчика, чтобы это работало и можно было потрогать. Т.е. у любой итерации должна быть цель, если работа итерациями, конечно, не карго-культ, потому что “в книжке же написано!”. И тут возникает вопрос, а что важнее руководителю на самом деле:

  1. Поставляемая ценность - в таком случае нет никакой проблемы в том, чтобы продлить срок итерации и обновить свои прогнозы по сроку окончания проекта/следующим итерациям).
  2. Прикрытие своей жопы / соблюдение обязательств - т.е. соблюдение сроков поставки - в таком случае нет проблемы резать качество и выкатывать промежуточный результат. За счёт грамотно расставленных приоритетов ещё где-то на середине итерации уже должно существовать рабочее нечто, которое можно показывать заказчику. А если приоритеты не расставлены - это уже проёб не исполнителя, а именно руководителя.

Ну и про обязательства дополню. Если руководитель берёт на команду обязательства, не взяв сопутствующих обязательств с исполнителя - это его и лишь его обязательства и его и лишь его проблемы. Попросить сделать прогноз - это не взять обязательство.