Управление требованиями в Agile

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

Рекомендую командам из обоих лагерей (формалистов и "упрощенцев") следующие посты, в которых даются практические советы как поступать с требованиями в том или ином случае:

Сбор требований в Agile проектах
Постановка процесса анализа требований

Как не упустить срыв сроков

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

Из-за чего может измениться скоуп? Например, потому что заказчику показалось, что теперь ему нужны не эти фичи, а еще те и те. Это частый кейс и риск, которым необходимо управлять, то есть следить составом скоупа и вашими договоренностями.

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

Мне понравилась методика, которая используется в DEVPROM. Члены команды просто отмечают часы, система автоматически вычисляет текущую скорость команды и прогнозирует срок завершения итерации и релиза. То есть, вся команда всегда в курсе возможного срыва сроков и отсутствия запаса времени. Используйте эти моменты для понимания проблем в процессе, команде и адаптируйтесь вовремя.