О дедлайнах
Любой проект живет в трилемме: сдвинуть дедлайн, ухудшить качество или вернуть в беклог фичу?
Не жертвовать ничем на практике не получается.
Но дедлайн — самый важный из трех, имхо.
Отсутствие дедлайна раздувает скоуп проекта — ведет к выгоранию команды из-за незавершающейся работы.
Его наличие (достаточно строгое, но с запасом на ошибку оценки), наоборот, отфильтровывает неприоритетные пользовательские сценарии, формулирует необходимые минимальные требования к качеству, приносит удовольствие от закрытия проекта.
Слишком строгий дедлайн также сжигает команду из-за жертв в функциональности, качестве; или переработок.
Я заметил, что при запуске проекта нужно:
2. Под сроки отприоритизировать пользовательские сценарии.
3. Ещё раз отсортировать сценарии под технические ограничения проекта, учитывая QA и степень технической задолженности кода.
Так определится компромиссный скоуп, с которым бизнес, продукт и разработка согласятся.