Переводы, выпуск 1: О сумасшедших числах и критериях релиза (Джоанна Ротман)

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

Так, в разное время мне нравились блоги Кема Канера, Джеймса Баха, Майкла Болтона, Джерри Вейнберга, Майкла Ларсена. Я ими просто зачитывался. Сейчас я столкнулся с творчеством Джоанны Ротман, которая пишет об управлении проектами, о тестировании, о найме в IT. И пишет очень здорово!

Как мне кажется, это подходящий момент для того, чтобы начать рубрику переводов в моем блоге. Я собираюсь переводить статьи, которые мне понравились. Не обязательно это будут новые статьи. Это будут статьи, которыми мне бы хотелось поделиться с вами и которые я бы хотел обсудить.

Итак, давайте начнём со статьи Джоанны Ротман о критериях релиза. Текст оригинала я буду выделять другим шрифтом.

О сумасшедших числах и критериях релиза
Джоанна Ротман
Ссылка на оригинал статьи

У нас с Джеймсом Бахом уже несколько лет не прекращается дискуссия о моём определении критериев релиза.

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

Иногда решение о выпуске принимается, когда люди очень устали и напряжены. Иногда решение о выпуске основывается на потребности компании в получении дохода. Я предпочитаю уменьшить напряжение при принятии решения о выпуске, заранее уделяя внимание тем вещам, которые создают напряжение. Количественные критерии релиза - это один из способов сделать это, и я действительно использую их. Это правда, что критерии могут показаться случайными и даже сумасшедшими человеку, не знакомому с деталями конкретного проекта.

Ценность магических чисел

Недавно мне пришлось поработать менеджером проекта в маленькой группе по разработке приложений промежуточного уровня. Группа состояла из шести программистов, трёх тестировщиков и одного технического писателя, работавшего на частичной занятости. Когда я прибыла на место, группа была в самом разгаре подготовки к выпуску беты. После быстрой оценки я поняла, что программное обеспечение не будет достаточно стабильным для выпуска беты в то время, в которое хотелось бы команде. Недостаток стабильности был вызван слишком большим числом дефектов в текущем релизе, а также слишком долгим временем исправления дефектов предыдущего релиза.

Но команда не фиксировала дефекты. Поэтому я разработала ориентированные на дефекты критерии выпуска беты и релиза. Бета критерии требовали, чтобы все известные баги были занесены в систему баг трекинга и чтобы число открытых багов высокого приоритета было меньше 36. Критерии релиза же состояли в полном отсутствии открытых багов высокого приоритета. Были и другие критерии, но именно перечисленные критерии были ориентированы на дефекты.

Когда я описала эту ситуацию Джеймсу, он выпучил глаза и спросил: "Почему 36? Какой смысл заключен в этом числе?"Я объяснила, что, когда я поняла невозможность выпуска успешной беты при таком уровне стабильности продукта, мне захотелось, чтобы команда осознала то большое число багов, с которым мы имеем дело. Знание реального числа багов могло способствовать этому пониманию, потому что до этого команда не думала о других дефектах, она думала только о том дефекте, над которым работала в данный момент.

У команды был интересный взгляд на дефекты. В любой момент времени разработчики предполагали, что проблема, над которой они работают, была последней, оставшейся в продукте. Заглядывая в прошлое, это кажется немного глупым. Но представьте себя в этой ситуации. В течение последних пяти лет вы все время застревали между двумя возможными состояниями: размышлениями о том, что вы близки к релизу, и пониманием того, что вы только что сделали недостаточно качественный продукт. Ваше руководство хочет релиз в последнем квартале. Ваши клиенты хотят выпуска беты. Не все разработчики понимают весь продукт и вы все измождены. Тестировщики не совсем понимают, как тестировать продукт, и они тоже устали.

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

Мне хотелось рассеять это заблуждение. Чем верить в то, что мы занимаемся последней проблемой, мне хотелось создать буфер проблем и дать проекту разрешение на выпуск с некоторыми известными и признанными проблемами. Если бы мы могли договориться о ненулевом критерии дефектов, команда бы выбралась из колеи, в которую она попала. Она бы перестала думать, что создала совершенство и перестала бы быть расстроенной по поводу того, что она его не достигла. Тогда бы мы могли довести продукт до беты и, в конечном счёте, до релиза.

Как получаются магические числа

По правде, мое оригинальное предложение было таким, что все известные баги будут заведены в системе баг трекинга и что будет меньше 40 открытых багов высокого приоритета. Когда я сделала это предложение, меня пригласили в офис руководителя подразделения. И у нас состоялся впечатляющий разговор:

РП: "Джоанна, вы обидели всю команду проекта. Не понимаю, почему вы такой менеджер проекта? Почему вы думаете, что в системе так много багов высокого приоритета? Не думаю, что у нас всего есть 80 багов и, я бы поспорил, что всего несколько из них высокого приоритета."

ДР: "Ну, судя по нашему тестированию, я думаю, что у нас больше 100 багов и большая их часть - баги высокого приоритета. Я думаю, что, когда мы исправим высокоприоритетные баги, мы найдём больше низкоприоритетных багов."

РП: "Нет, это не так. Я бы поспорил, что у нас всего 70 багов. Может быть только 6 из них высокого приоритета."

ДР: "Ну, у нас 40-процентное соотношение возникающих снова ошибок и тестировщики находят больше 5 багов в день. Мы не сможем исправлять их быстрее, чем их находим. Я думаю, что 100 - это крайне оптимистичная оценка." 40-процентное соотношение числа возвращающихся ошибок означает, что для каждых 10 исправленных багов, возникает 4 новых бага. (см. книгу Дж.Вейнберга Quality Software Management, том 2, Dorset House, 1993.)

РП: "Нет, вы не правы. У нас не может быть больше 60 багов. Если на самом деле у нас больше, я должен вам кофе."

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

ДР: "ОК. Давайте прийдем к соглашению. Скажем, вы думаете, что может быть 70 открытых багов. Скажем, я безнадёжно пессимистична и половина из них - высокоприоритетные. Возьмём 35 как число высокоприоритетных багов, добавим ещё один на всякий случай, назовём критерий беты как 'Не больше чем 36 высокоприоритетных бага'. ОК?"

Обращение с дефектами

Руководитель подразделения согласился при условии, что я буду должна ему кофе за каждый баг высокого приоритета, меньший числа 36. Мы стали использовать систему баг трекинга. В конце первой недели, у нас было больше 100 открытых багов, причём больше 70 из них были высокого приоритета. Было сложно уменьшить это количество до 36 для выпуска беты, но мы это сделали. И мы были честными с самими собой.

Ведь я не только хотела, чтобы проектная команда узнала о дефектах, я хотела, чтобы им не было не комфортно признать эти дефекты. Они должны были понять, что они произвели много дефектов и что они не обязательно смогут исправить их все для определённого релиза. Это, в том числе, делает осведомленность о дефектах менее ошеломляющей. Это делает дефекты подъёмными, переносимыми.

Пользователи были в восторге от беты. Они никогда не получали настолько качественного релиза от организации. Когда мы выпустили финальную версию, они звонили, чтобы поздравить нас.

Я не говорю, что меньше 36 дефектов является хорошим качеством и 37 дефектов уже является неприемлемым качеством. Я использовала эту метрику дефектов как способ помощи команде в том, чтобы сделать первый шаг в осведомленности о качестве. Если кто-либо в команде скажет: "Я не думаю, что 36 является правильным числом" - тогда мы поговорим о том, что значит качество для этого продукта.

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

Заключение

В этом случае счетчики дефектов были собирательным обще командным измерением. Команда могла стать успешной только когда каждый работал вместе как команда. Я толкала команду к конкретной цели, которая затем позволила мне помочь им улучшить их процесс разработки (использование системы баг трекинга, планирование работы, использование системы управления конфигурациями, и так далее).

К концу проекта, команда поняла, что число 36 было обычным ненулевым числом, числом, которое не требовало безупречности и идеальности. Но это число было ценным, потому что оно заставило людей думать о данных - откуда они приходят и для чего используются. Цель дала команде стимул использовать процесс, который может помочь ей быть успешной. Команда выяснила, как выполнить свою работу.

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

Для меня не важно, если числа не имеют связи с тем, что нормальные люди с нормальными кишками (:) - дословно) могут думать. Мне только важно, чтобы критерии релиза помогали команде проекта выпустить правильный продукт во время с дефектами, которые не заставят пользователей вопить. И то, чтобы они делали это без язв и измождения, и без того, чтобы сводить друг друга с ума.