Багскрам
Вчера поднимали вопрос классификации багов. Но иногда бывает, что накапливается много неразобранных багов, или резко появляется несколько критических багов, или в багах сложно разобраться, или непонятны приоритеты багов.
Для таких случаев существует багскрам – встреча с целью однозначно определить суть бага, актуальность, приоритет, назначить исполнителя и сроки исправления. На ней же можно классифицировать баги по причине возникновения.
Кто участвует: тестировщики, команда разработки и руководитель проекта. Если система сложная, то ещё аналитики. Встреча получается дорогой, поэтому проводить её нужно, понимая цель, чётко и быстро.
Подготовка: выбрать скоуп багов, которые хотите разобрать.
Сама встреча:
Ведущий встречи открывает каждый из багов.
Тестировщик, который завёл баг, тезисно описывает проблему.
Команда обсуждает баг, появляется и фиксируется дополнительная информация. Далее определяется приоритет, назначается ответственный. Во время обсуждения ведущему нужно следить за тем, чтобы встреча не уходила не в то русло и шла чётко по плану.
После обработки бага оставляется комментарий, что баг рассмотрен на багскраме, чтобы повторно не обсуждать.
Периодический багскрам в целом не даёт багам накапливаться и превращаться в неуправляемую массу.
А на тех проектах, где у нас проводится багскрам, конечно, зафиксирован процесс: участники, периодичность, правила, примеры фильтрации багов в системе контроля задач. Чтобы любой человек мог ознакомиться с процессом.
Пользователь
В Cloudflare рассказали об опыте, когда небольшая экономия памяти на одной структуре данных, будучи умноженной на сотни миллиардов экземпляров, превращается в десятки терабайт. Сетевые инженеры последовательно внесли пять сравнительно небольших изменений в виде патчей в представление записей кэша DNS-резолвера 1.1.1.1 и в итоге высвободили около 100 ТБ оперативной памяти на серверах IT-инфраструктуры.
