https://habr.com/ru/news/t/694392/

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

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

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

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

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

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

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

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