Agile-планирование релизов

Существует предположение, что вы должны выполнить все 500 пунктов охвата, чтобы удовлетворить потребности пользователя. В Scrum первое, что мы должны сделать, это оспорить это предположение. Сосредоточив внимание на удовлетворении потребностей, а не на выполнении работы, мы часто можем найти более простые решения или определить вещи, которые на самом деле не нужны.

А теперь еще два вопроса:

• Как команда может стать быстрее?
• Как я могу двигаться быстрее, чем может двигаться команда?

Чтобы помочь команде работать быстрее, команда должна проводить ретроспективу и искать улучшения в каждом спринте. Однако любой способ работы достигает пика эффективности, и вам приходится менять подходы к работе, чтобы получить больше скорости от команды. Это здорово, но и опасно. Любое изменение в способе работы замедлит работу команды, пока они к ней адаптируются, и вполне возможно, что у них не получится с первого (или второго) раза. Это должно быть сделано в то время, когда команды могут поглотить замедление, чтобы позже увеличить скорость.

Мы также можем добавить команды. Добавить людей в проект сложно. Вы могли бы подумать, что если одна команда набрала 50 очков, то две набрали бы 100, но это не так. У них есть накладные расходы на совместную работу, не говоря уже о том, что есть время разгона, и это замедлит работу другой команды в этот период. Опять же, это нужно делать осторожно.

Добавление к ответу Даниэля:

Опасно предполагать, что вы не будете добавлять истории в течение 10 спринтов.

Это могло произойти по нескольким причинам:

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

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

Обязательство сдать все к сроку может легко превратиться в марш смерти .