Другое

Ретроспективный анализ IT-проектов в несколько простых этапов

Lorem ipsum dolor

Ретроспектива или ретроспективный анализ IT-проектов — это взгляд на свой проект с высоты своего опыта, а именно взгляд в прошлое, чтобы понять:

  • все ли вы там делали правильно

  • какие ошибки допускали;

  • что у вас получалось очень удачно;

  • и т. д.

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

 

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

Гадалки и предсказатели анализируют  и предсказывают возможное будущее, а ретроспектива — это анализ прошлого.

Ретроспектива может показать:

  • проблематичные области в рабочем процессе: неудобный график, плохая рабочая атмосфера, некачественное техническое задание, неправильно подобранная команда и др.;

  • успешность ваших идей и гипотез по решению возникших в прошлом проблем;

  • уязвимость рабочего процесса, команды или проекта;

  • систематические проблемы или ошибки, которые повторяются от спринта к спринту;

  • и др.

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

 

Как проводится ретроспектива

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

Когда проводится такой совместный ретроспективный анализ, обычно назначают одного координатора или ведущего, в общем «главного» по ретроспективе. В качестве такого координатора не всегда выступают лидеры IT-команд, очень часто это могут быть обычные активные разработчики из команды или вообще человек «со стороны», который профессионально проводит такие «разборы».

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

  • должны собираться мнения участников по поводу насущных вопросов, причем собираются как позитивные, так и негативные мнения;

  • выделение насущных и давно нерешаемых проблем в команде, которые мешают «двигаться вперед»;

  • поиск и принятие решений по поводу насущных проблем;

  • фиксация результатов ретроспективного анализа.

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

 

Насколько часто проводится ретроспективный анализ

Ретроспектива — это добровольный процесс. Для того чтобы проводить ретроспективный анализ, нужна определенная база проблем, которые можно будет обсудить. При этом время не играет большого значения между ретроспективами. То есть если командой выполняется большой объем работ в каждом спринте, а спринт длиться 1-2 недели, при этом за время спринта накапливается много вопросов для обсуждения, то ретроспективу можно проводить хоть после каждого спринта.

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

  • окончание спринта;

  • итерация;

  • окончание фазы проекта;

  • релиз продукта;

  • закрытие проекта;

  • и др.

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

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

  • низкая эффективность ретроспективного анализа из-за ее непостоянства или низкой активности ее участников, также низкая эффективность возникает из-за невыполнения  решений, которые были приняты на прошлой ретроспективе;

  • «раздувание проблем» получается в том случае, когда действительно трудно определить цели ближайшей ретроспективы, в этом случае лучше ее не проводить;

  • ложные проблемы — это те проблемы, которые напрямую не влияют на качество работы команды, например: «слишком твердые стулья», «нет зеленого чая», «мало места на парковке автомобилей»;

  • разногласия и ссоры в команде  в процессе ретроспективы;

  • поиск «виновного» в процессе ретроспективы.

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

 

Заключение

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

Нужна ли ретроспектива или нет конкретно вашей команде? решать вам.

Схожие статьи

Как обучиться на программиста самостоятельно и без посещения курсов
Другое

Как обучиться на программиста самостоятельно и без посещения курсов

Декоратор Java: пример паттерна, шаблон проектирования на языке Java
Другое

Декоратор Java: пример паттерна, шаблон проектирования на языке Java

Что такое APC, простой способ установки зависимых пакетов
Другое

Что такое APC, простой способ установки зависимых пакетов

Плагин проксирования CloudFlare: что это и как его подключить к сайту?
Другое

Плагин проксирования CloudFlare: что это и как его подключить к сайту?

×