Ретроспектива

Ретроспектива /retro – в agile это встреча, проводимая после окончания спринта для обсуждения того, что произошло в процессе разработки и выпуска продукта для улучшения ситуации в будущем на основе этих знаний и обсуждений.

Что такое Agile-ретроспектива?

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

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

Формат встречи является ключом к эффективной ретроспективе, поскольку ценность исходит из разговора и диалога, а не только из набора отдельных заявлений. Должен присутствовать представитель от каждой группы (если не все участники), и каждому дается время, чтобы поделиться своим мнением об опыте. Сюда также могут входить представители по маркетингу, продажам, обслуживанию клиентов и операторы.

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

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

Каков идеальный исход ретроспективной встречи?

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

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

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

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

Участники должны уйти от ретроспективы, чтобы лучше понять, как проект воспринимался всеми участниками. Это возможность для службы поддержки клиентов рассказать, как они были завалены жалобами на неуклюжее развертывание или как команда UX предоставила действительно четкие каркасы, которые ускорили процесс кодирования.

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

Как часто нужно проводить ретроспективы?

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