Работа над дефектами – известная область разработки ПО, вызывающая вечные и непримиримые споры. Заметьте, что я использовал именно слова “работа над”, а не “управление” – из того, что я вижу вокруг, управления дефектами почти ни в одной команде разработки нет.
В чём обычно заключаются споры?
Первая дискуссионная точка – что именно считать дефектом? Почему-то в сфере разработки ПО встречаются странные, зачастую полярные мнения. Например, дефект – это то, что не устраивает заказчика (или владельца продукта, или самого-главного-ключевого-пользователя, или ещё кого-то на стороне клиента). Или, дефект – это неработоспособность приложения, признанная разработчиками (или тимлидом, или командой, или руководителем проекта или ещё кем-то на стороне исполнителя). Эта дискуссионная точка зачастую приводит к известной игре “баг или фича”, играть в которую с переменным успехом можно долгие годы. Другая известная популярная игра – “а ну-ка, докажи”, либо её вариант “у нас не воспроизводится”. Как говорят опытные программисты, “у меня за окном такая же девятиэтажка, и она не горит”.
Второй мегасложный вопрос – следует ли устранять дефекты сразу же после обнаружения? Долгие годы, а то и десятилетия, команды привыкали работать в парадигме “дефекты устраним когда-нибудь в зависимости от их критичности”. Но есть и, условно говоря, новые концепции, такие как Zero Know Defects. Следовать которым традиционные департаменты разработки ПО считают, скажем так, глупостью.
Попробуем разобраться.
Варианты ответов
На мой взгляд, ответ на первый спор прост до банальности. Дефект – это несоответствие поведения ИТ-системы документированным требованиям к ней. Точка. Первый ключевой момент – проверяемость утверждения. Второй – минимизация субъективности. Есть описанное ожидаемое поведение ИТ-системы, есть наблюдаемое действительное поведение. Если между ними есть разница – мы имеем дефект, если разницы нет – дефекта нет. От этой максимы уже можно отталкиваться, можно выстраивать управление дефектами. Когда такое определение нас подведёт? Из опыта хорошо известно когда – не все ожидания будут зафиксированы как требования. Мы переходим в область подразумеваемого. Например, владелец продукта в отчаянии восклицает: “Ну разве не очевидно, что баннер не должен загораживать кнопку?!”. На что команда отвечает: “Нет такого требования, чтобы не загораживал, потому и сделали как поняли”. Эта ситуация снова банальна, и разрешается следующим образом: если вы используете парадигму продуктового подхода, то вы так строите отношения и взаимодействие между владельцем продукта и командой, что команде не всё равно, чем она занята. Включить головы и понять, что баннер не должен загораживать кнопку, просто (если, конечно, вы не набрали команду из джунов, пришедших после SkillBox или подобных “курсов на питоне”). Потому и спора такого не будет.
Если же вы работаете в парадигме “заказчик-исполнитель”, то вам придётся максимально чётко специфицировать свои требования, потому что по умолчанию ни один исполнитель не будет делать ничего сверх того, что от него попросили, и думать за заказчика исполнитель не обязан. Может, но не обязан. Контракт не подразумевает (контракт – в широком смысле слова, например, трудовая функция – тоже контракт).
Теперь ко второму вопросу, стоит ли сразу устранять дефекты. Здесь несколько сложнее, так как есть две крайности. Первая: нет, не стоит; дефекты можно и нужно классифицировать, затем приоритизировать, затем некоторые из них пойдут в работу скорее, некоторые – попозже, другие – никогда. Можно так работать? Конечно. Так почти все вокруг и работают.
Вторая крайность созвучна идеям, высказанным Дж. Хаблом и Д. Фарли десять лет назад:
Having code that is always working is fundamental — we can’t emphasize enough how important this practice is in enabling continuous delivery of valuable, working software.
То есть: и на уровне исходного кода, и на уровне исполняемого кода, ИТ-система должна в любой момент быть полностью работоспособна, а если это не так – следует как можно скорее восстановить работоспособность системы, и только затем вносить в неё следующие изменения. Более простым языком: если есть известные нам дефекты, то сначала мы устраняем их, и только затем можем позволить себе пилить новые фичи. Аргументы в пользу такого подхода известны, они сводятся, в первую очередь, к экономике, а не философии. Иметь дефектный (или дефективный?) программный код дороже, чем работоспособный, особенно при условии постоянного и быстрого усложнения этого программного кода.
Переключиться в такую парадигму (разработка новой функциональности не имеет приоритета перед устранением известных дефектов) сложно. Ведь одно из следствий, к примеру, такое: нет больше понятия приоритет дефекта. Другое следствие: если в бэклоге есть дефекты, то не важно сколько их – пока они не будут устранены новая разработка не начнётся. Ну и далее в том же духе, странные и неприятные ограничения.
Как это всё почувствовать
Написать заметку на эту тему меня побудил опыт проведённой недавно деловой игры “Проект Феникс”. В ней среди “проектов” и “фич” команде время от времени прилетают “issues”. Иногда это инциденты, устраняемые без необходимости исправления программного кода. А иногда это те самые дефекты, для устранения которых придётся программировать, то есть загружать довольно ценный ресурс отдела разработки, который и так загружен бизнес-задачами.
Команда, с которой я играл, в первом раунде решила только 50% поступивших issues. Бизнес-эффект был не очень значительным, потери составили 2 000 условных долларов из 100 000 долларов выручки. Команда подумала, что создание новой функциональности, позволяющее бизнесу заработать больше – более перспективная стратегия, чем устранение прошлых косяков.
Но уже на втором раунде потери составили заметные 26 000 долларов (команда снова устранила только половину issues). А на третьем раунде – 39 000 долларов. При этом нельзя сказать, что софт был очень глючный, или что дефектов было много количеством… Просто эффект от дефектов проявляется и в первом раунде, и во втором, и в третьем – во всех, пока дефект не устранили. Математика, суммирование, легко увидеть. “Ничего себе!” – задумались ребята, и были правы.
Понятно, что в игре есть некоторое упрощение – эффект от наличия дефекта переводится в денежные единицы и быстро влияет на бизнес-показатели. В реальном мире посчитать влияние дефекта намного сложнее. Однако базовый принцип остаётся тем же: наличие дефектов замедляет разработку и приводит к потерям для бизнеса, потому мириться с наличием дефектов не следует.
Хотите получить большую отдачу от вашего ИТ и максимально ускорить свои ИТ-команды? Приглашаем Вас на бесплатный вебинар “Игры в которые играет ИТ” 14 сентября в 11:00.
- Как в безопасной среде тестировать новые гипотезы, идеи и практики, как перенести полученные навыки в реальную деятельность?
- Какую пользу могут принести бизнес-игры вашим ИТ-командам и бизнесу в целом?
- Почему игры эффективный метод обучения сотрудников, какие задачи решают игры?
Презентация лучших бизнес-игр Cleverics, встреча с ведущими игр. Когда, кому и зачем играть.
Итоги
Переход от парадигмы “мы когда-нибудь устраним часть дефектов” к “наш код всегда работает”, по моему опыту, никогда не бывает простым. Есть только один простой кейс – чистое поле, green field. В таком случае с нуля построить работу на принципах Zero Known Defects довольно просто. Но, к сожалению, чаще всего мы налаживаем работу команды, которая уже давно разрабатывает свою систему, или модуль. Есть некоторые методы из нашей практики, которые позволят упростить переход, но их описание оставлю для следующих заметок.
