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

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

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

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

Проектирование архитектуры системы

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

Ясное дело, вы используете Agile, но что оно говорит об архитекторе? Ведь в основном процессе взаимодействия с заказкиком (владельцем продукта) нет места архитектору. В вашей команде может быть выделена роль архитектора, который будет принимать участие в обсуждении и приоретизации пожеланий. Казалось бы проблема решена, однако, чаще всего подобной выделенной роли нет, а разрабатываемое приложение необходимо интегрировать с массой сервисов и других внешних приложений, уже используемых у заказчика.

Привожу ссылку на интересное выступление о роли архитектора в Agile команде. Надеюсь предложенные решения помогут вам направить работу команды в нужное русло и в итоге добиться желаемого результата.