Ретроспективный анализ ошибки

Нельзя найти все баги. Вы все равно что-то упустите. И в продакшене всплывет ошибка, которую вы не заметили.Что делать в такой ситуации?

Я пропустил баг...

Искать виноватых бесполезно. Окей, виноваты не вы, проверку не выполнил Вася. Дали втык, отобрали зарплату. Полегчало? Через месяц Маша допустит ту же ошибку. Повторяем наказание. Ничего не меняется. Ребята ходят по граблям, на которые уже наступали.

Но ведь важен не сам факт допущения ошибки. Важно, какой урок из нее вынес человек. Почему мы не любим новичков? Потому что у ребят со стажем есть опыт. Не только хороший, но и плохой. Они знают, что бывает, когда забываешь проверить поле на пустоту. Они видели, отчего может развалиться сервер. Помнят, что значит ошибка ORA-54032 по горькому опыту. Они уже наступили на грабли и не повторят ошибку.

Мой метод

Я сохранила себе шаблон для заполнения. Фактически это набор вопросов, на которые стоит ответить. Чек-лист «а не забыл ли я подумать вот о чем?». Он помогает не забыть копнуть чуть глубже и понять, что надо сделать, чтобы ошибка не повторялась.

А еще это краткое описание проблемы. Ведь в задаче в баг-трекере может быть 100500 комментариев ща время ее исправления. А тут только сжатая информация — где был корень зла, какие предприняты меры предосторожности. Можно перечитать даже спустя год и все вспомнить. Или показать коллеге, у которого возникла схожая проблема.

Шаблон

Примеры


В гуглодоке оно как-то лучше смотрится, чем в блоггере =)
Но список вопросов могу продублировать:

1. Когда и где обнаружена?
2. Суть проблемы 
3. Причина проблемы
4. Решение проблемы
5. Меры по обнаружению и исправлению у Заказчиков
6. Более подробная информация

Agile-ретроспектива. Эстер Дерби, Диана Ларсен

Ссылка на OZON

Тоненькая книжка о том, как проводить ретроспетивы раз в релиз (2-3-4 недели). рекомендую в паре с книгой «Ретроспектива проекта» Керта. Они дополняют друг друга. Норм Керт рассказывает, как проводить большую ретроспективу по результатам работы всего проекта. Это может быть полгода, года, два года... В таком случае за час все обсудить точно не успеете! А вот если повторять ретроспективу каждый релиз, то можно уложиться в пару часов.

Перед чтением книги я прочитала этот отзыв на нее (судя по вкладке My Talks, автора зовут Никита Макаров). Отзыв не шибко позитивный, поэтому на книгу посматривала скептически. Но она зацепила меня тем, что началась с примера. Да, в этом примере команда все обсудила за час. Да, в этой команде каждую ретро меняется ведущий. Но, читая пример, ты прям представляешь, как это можно применить у себя. Простое описание "вот 5 упражнений, выбирай" навевает скуку, а тут сразу видно, в каком порядке и какие применить. Мне очень понравилось, как Дана (ведущий) просила описать свои чувства от релиза, как коллеги голосовали точками и вообще как все здорово получилось.

Если ретроспектива приводит к одним и тем же рекомендациям — выделите больше времени!

Выдержка из книги Нормана Керта «Ретроспектива проекта»:

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

И хоть я и слышал о ретроспективах, проводимых за один час или за полдня, следующие комментарии описывают итоги таких ретроспектив:

«Мы пробовали проводить ретроспективы. Через некоторое время мы заметили, что каждая ретроспектива приводила к одним и тем же рекомендациям. Было очевидно, что ничего не менялось, и мы решили, что ретроспектива — это потеря времени. Поэтому больше их не проводим»

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

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

**************

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

Я понимаю, что в ИТ чаще всего ретроспективы проводятся в agile и прочих «гибких» командах, где ретроспективы проводятся каждый месяц, а не каждый год, поэтому ретроспектива на полдня не кажется такой уж короткой. Но книга про agile-ретроспективы на русском еще не вышла, черпаю опыт из проектных работ 

Меня зацепил этот отрывок словами «каждая ретроспектива приводила к одним и тем же рекомендациям». Бывало ли у вас такое? Что периодически одна и та же мысль всплывала на ретроспективе раз за разом. Например, делать большие задачи в отдельном бранче или начинать тестирование до линии N?

Разумеется, тупо выделить больше времени на ретроспективу тут не поможет. Однако стоит задуматься... Если одна и та же идея всплывает раз за разом → необходимо уделить ее анализу чуть больше времени. Да, тогда ретро займет не час, а полтора или два, но это окупится! Ведь ведь смысл ретроспектив — научиться. Научиться быть лучше, повторять успех и не повторять ошибок.

А как можно не повторять ошибку, если не проанализировать ее? Только задумайтесь, мы же тестировщики. Как можно вообще завести баг-репорт, не проанализировав ошибку, не найдя корня зла? Да, разработчик исправит поверхностное проявление, но через месяц ошибка снова всплывет. Снова исправим последствие — снова всплывет. И так по кругу. А все потому, что лень было найти причину, а не последствия.

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