Привет!
Мы продолжаем рубрику “СТО на каникулах” и сегодня я, Сергей Никифоров, Head of QA, расскажу, как мы в Skyeng боремся с багами и каких результатов удалось достичь🚀
Если у вас рабочий zero bug policy или lead time от создания до закрытия всех багов меньше недели – перематывайте, вы и так все знаете!
3 года назад для Skyeng нормальным явлением было 5000 багов в бэклоге, и этот тренд уверенно рос. Это нормально для всех стартапов и компаний, где нет иной ценности кроме скорости.
Чаще всего пренебрежение бэклогом сознательное и на то есть несколько причин, давайте назовем их всадниками багоапокалипсиса:
📍 Лень: чем меньше делаешь, тем лучше.
📍 Гордость: баги не мои и вообще такой ерундой разработчик заниматься не хочет.
📍 Отстраненность: ощущение непричастности к продукту и что исправление 1 бага не изменит положение вещей.
📍 Недальновидность: обязательно исправим, но потом.
Давайте разбираться, что и как можно сделать с каждым всадником.
🔥 Лень. Самый коварный противник, но мы его победили. И вот почему: значительную часть багов в core сервисах мы не решали как баги. QA “вспоминали” про их существование при планировании фичи, аргументируя это тем “слушай, ты же все равно полезешь в N, там вот еще это не работало, тебе быстро будет поменять”. И действительно, формулировка “раз ты всё равно полез, поправь попутно” работает лучше, чем отдельно стоящий bug в трекере, который отображается на доске.
Такое поведение создает привычку отдавать готовый продукт и меньше использовать костыли, плюс усиливает code review (ребята сами начинают подсвечивать проблемные зоны без QA друг-другу).
🔥 Гордость. Для большинства крутых разработчиков исправление багов не является интересной задачей. Им хочется запускать ракеты в космос, спасать принцесс, что-то делать с драконами, вот это вот всё.
Этот “всадник” отлично побеждается соревновательным элементом. Введите обязательные политики по жизни багов, SLA по их выполнению и сравните команды между собой, чтобы сильные дяди могли помериться своей силой)
Главное, чтобы все правила задавались “извне”, а не навязывались одной команде другой, чтобы все были в равных условиях.
Завтра поговорим про отстраненность и недальновидность, а также я расскажу, чего мы достигли, выиграв бой у всех “всадников”. Пока делитесь в комментариях своими всадниками багоапакалиписиса 😅
Мы продолжаем рубрику “СТО на каникулах” и сегодня я, Сергей Никифоров, Head of QA, расскажу, как мы в Skyeng боремся с багами и каких результатов удалось достичь🚀
Если у вас рабочий zero bug policy или lead time от создания до закрытия всех багов меньше недели – перематывайте, вы и так все знаете!
3 года назад для Skyeng нормальным явлением было 5000 багов в бэклоге, и этот тренд уверенно рос. Это нормально для всех стартапов и компаний, где нет иной ценности кроме скорости.
Чаще всего пренебрежение бэклогом сознательное и на то есть несколько причин, давайте назовем их всадниками багоапокалипсиса:
📍 Лень: чем меньше делаешь, тем лучше.
📍 Гордость: баги не мои и вообще такой ерундой разработчик заниматься не хочет.
📍 Отстраненность: ощущение непричастности к продукту и что исправление 1 бага не изменит положение вещей.
📍 Недальновидность: обязательно исправим, но потом.
Давайте разбираться, что и как можно сделать с каждым всадником.
🔥 Лень. Самый коварный противник, но мы его победили. И вот почему: значительную часть багов в core сервисах мы не решали как баги. QA “вспоминали” про их существование при планировании фичи, аргументируя это тем “слушай, ты же все равно полезешь в N, там вот еще это не работало, тебе быстро будет поменять”. И действительно, формулировка “раз ты всё равно полез, поправь попутно” работает лучше, чем отдельно стоящий bug в трекере, который отображается на доске.
Такое поведение создает привычку отдавать готовый продукт и меньше использовать костыли, плюс усиливает code review (ребята сами начинают подсвечивать проблемные зоны без QA друг-другу).
🔥 Гордость. Для большинства крутых разработчиков исправление багов не является интересной задачей. Им хочется запускать ракеты в космос, спасать принцесс, что-то делать с драконами, вот это вот всё.
Этот “всадник” отлично побеждается соревновательным элементом. Введите обязательные политики по жизни багов, SLA по их выполнению и сравните команды между собой, чтобы сильные дяди могли помериться своей силой)
Главное, чтобы все правила задавались “извне”, а не навязывались одной команде другой, чтобы все были в равных условиях.
Завтра поговорим про отстраненность и недальновидность, а также я расскажу, чего мы достигли, выиграв бой у всех “всадников”. Пока делитесь в комментариях своими всадниками багоапакалиписиса 😅