Блог a1qa

О тестировании и качестве ПО

Ретроспектива как способ оптимизации проектного менеджмента в тестировании

В процессе работы на проектах в сфере IT, в том числе при тестировании ПО, у менеджеров и руководителей команд возникает ряд типичных, часто встречающихся проблем. Эта статья Павла Новика, менеджера компании a1qa, в Intelligent Enterprise призвана их систематизировать и предложить единый инструмент, который способен решить большинство из них.

Одна из самых распространённых проблем менеджера в QA – его команда допускает ошибки в работе. Причём ошибки могут выражаться как в «пропуске» дефектов программного обеспечения, так и в проблемах с таймингом и коммуникацией, нарушением общего проектного процесса. Это список можно продолжать бесконечно.

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

Зачастую дела идут вроде бы довольно неплохо: и команда хорошо справляется, и дефекты «находятся», и документация актуализируется, и отчёты приходят вовремя. Но внутренний голос будто подсказывает менеджеру – что-то не так!

Вот-вот наступит какая-то неприятная ситуация, перерастающая в глобальную проблему. Возможно, команде просто перестал нравиться проект, на котором она работает, и задачи, которые на нем решаются. Или вы чувствуете, что главному техническому эксперту на проекте надоело заниматься тестированием и он со дня на день придёт и «заявит», что решил уйти в разработчики. При этом, согласно принципу Паретто (речь о соотношении 20 на 80), этот технический эксперт как раз входит в 20% эффективных ресурсов, делающих всю важную работу на проекте.

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

Понятие Ретроспекти́ва (от лат. retrospectare – «взгляд назад») трактуется в Википедии так: взгляд в прошлое, обозрение того, что было в прошлом. Применительно к области IT, наиболее оптимальным определением представляется следующее: Ретроспектива – это систематическая командная деятельность, направленная на анализ результатов, с целью улучшения эффективности работы команды в IT-проекте.

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

Что конкретно даёт менеджеру ретроспектива?

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

В структуре проведения ретроспективы можно выделить четыре основных пункта:

  • сбор мнений (позитивных и не очень),
  • голосование и выделение основных проблем,
  • принятие решений,
  • фиксирование результатов

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

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

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

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

Так, например, ретроспективу можно проводить после релиза.

Во-первых, очевидно, что сразу после релиза программного продукта команда ещё находится в «собранном» состоянии, что способствует генерации идей.

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

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

Оптимальнее всего митинг по ретроспективе запланировать за пару дней или даже за неделю до события. Тогда у команды будет время для предварительного анализа своих собственных «ощущений», что позволит ускорить опрос на митинге. Отталкиваясь от практики, в среднем по времени процесс ретроспективы может занимать от получаса до 2-3 часов. Поэтому удобнее проводить ее днём, чтобы с утра никто из команды не «спал», а вечером не спешил домой или по своим делам.

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

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

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

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

После завершения митинга «жизненно» необходимо подвести итог.

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

Читать далее

Поделиться статьей: