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

Описание

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

Ретроспектива должна быть направлена на выявление проблем с процессом. Она должна выявить точки улучшения процесса, а не быть личностной в каком-либо смысле. Ключевым элементом ретроспективы является то, что команда чувствует себя свободно, чтобы обсудить любой вопрос, который относится к ней.

В идеале, ретроспектива должна проводиться нейтральным посредником, а не членом команды.

Элементы

Подготовка

Команда готовит идеи из последних итераций, которые могут быть проанализированы в ретроспективе.

Проверка безопасности

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

Определение проблем

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

Выбор будущих действий.

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

Особенности использования

Преимущества

• Отличный способ для команды, чтобы найти общее мнение по возможностям улучшения процесса.

Недостатки

• Члены команды могут чувствовать себя обязанными делать вид, что они доверяют друг другу, даже если это не так.
• Ретроспективы полезны только в случае, если при этом команда обучается совершенствованию процесса.
• Большинство идей, возникших в ретроспективе, известны по крайней мере одному из членов команды. Зрелая команда должна решать вопросы по мере их поступления, а не их группировать их до обработки в ретроспективе.

--

Усилиями членов IIBA и экспертами сообщества Agile был разработан черновик The Agile Extension of the BABOK, описывающий роль бизнес-аналитика или владельца продукта, а также применяемые техники, в процессе разработки программного обеспечения с использованием методологий, производных от Agile.

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

Основной целью бизнес-анализа является понимание потребностей заказчика, пользователей программных продуктов, правильное и своевременное преобразование их в виде программного приложения, сервиса или продукта. Мы хотим познакомить пользователей DEVPROM с современными техниками в стиле Agile, которые они могут использовать для создания своих программных продуктов.

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• Критерии приёмки для требований в Agile
• Дисциплинированная гибкая поставка - Disciplined Agile Delivery
• Проектная документация в Agile
• 5 причин использовать Story Mapping в вашем следующем проекте
• Оценка трудоемкости при планировании релиза в Agile