Профилактика багов
Как исправить баг
Управление багами
Не тонуть в багах и глюках
Профилактика багов
Как исправить баг
Управление багами
Не тонуть в багах и глюках
В прошлых советах я рассказывал, как бороться с уже найденными багами. В сегодняшнем совете расскажу, как вписать процесс исправления багов в процесс разработки так, чтобы не утонуть в бесконечных багах и глюках.
Не откладывайте баги на конец итерации. В процессе разработки новых фич не откладывайте исправления багов на конец спринта или итерации, исправляйте баги по мере их появления. Баги, оставленные на конец итерации — это чистый технический долг, который демотивирует команду и не даёт спрогнозировать пуск: неизвестно, сколько команда будет чинить уже найденные баги и сколько ещё их найдётся в процессе починки.
Назначайте дежурных для срочных багов. Если в процессе итерации клиенты, бизнес или техподдержка приходят со срочными и важными багами, не стоит бросать всё и переключаться на них: так вы рискуете сорвать пуск. Назначьте дежурного, разработчика в эксплуатации, который будет разбираться с такими багами за понятное время. В свободное от багов время дежурный будет работать над качеством: разберётся с техдолгом, понапишет автотестов.
Если багов уже очень много, действуйте системно. Если вы оказались в ситуации, когда багов настолько много, что хочется взять шестинедельный спринт на их исправление, действуйте системно:
Перестаньте брать в долг. Баги — это технический долг. Как и в случае с обычным долгом, в первую очередь нужно остановить его рост, перестать брать новые деньги в долг. Договоритесь с командой, что новый код будет написан с минимумом багов.
Убедитесь, что для этого всё есть: Гит и Гитхаб, разработка в пулреквестах, линтеры, автотесты и система непрерывной интеграции. Убедитесь, что это всё работает: разработчики программируют в пулреквестах, а не пушат изменения напрямую в мастер; в каждом пулреквесте есть тесты и автоматические проверки линтерами; в продакшен код выкатывается автоматически, а не вручную по ФТП.
Выстройте процесс, с помощью которого вы системно и методично избавляетесь от накопившихся багов. Например, договоритесь с разработчиками и продактами тратить два часа в пятницу на приоритизацию, исправление существующих багов и рефакторинг.
Если встречаются пачки багов, связанные с одним и тем же модулем, значит, в нём есть серьёзные проблемы с архитектурой или принципом работы. Выделите для его исправления спецназ — мини‑команду из самых опытных разработчиков. Спецназ оперативно разберётся с причиной проблем и либо исправит её, либо предложит план по исправлению в рамках мини‑итерации.
Ещё по теме
P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.