Home

Автор: Scott Berkun

Перевод: Андрей Олищук

Материал публикуется при согласии редакции электронного журнала для веб разработчиков PHP Inside.

Статья переведена с разрешения ONLamp.com

В работе с ошибками есть одно золотое правило: исправлять ошибки нужно в том порядке, который вероятнее всего приближает к успеху. Звучит банально, не правда ли? Неправда. Могу поспорить, что свыше половины «глючных» и ненадёжных программ, которые вам приходилось использовать, были такими не потому, что разработчикам не хватило времени сделать их лучше. Просто они исправляли не те ошибки. Желание исправить «нужные» ошибки и знание того, каким образом это сделать, — две разные вещи.

При попытке продуманного подхода к работе с ошибками возникает две основные трудности: первая — необходимо знать, как принять правильное решение по поводу исправления той или иной ошибки, вторая — создание и поддержание рабочего процесса, который обеспечивал бы реализацию этих решений даже в условиях «дедлайна».

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

Это эссе, состоящее из двух частей, является своеобразным учебником для использования таких правил и неприкосновенных запасов. Даже больше — я поделюсь с вами идеями, на основании которых вы сможете создавать свои собственные правила. Мои рекомендации состоят из четырех уровней — от отрывочных советов по оказанию «первой помощи» (Уровень 1) до крупномасштабного планирования (Уровень 4). Но перед тем как начать, рассмотрим список неправильных подходов, которых следует избегать при принятии решений о правке ошибок.

Вот десять худших способов принятия решений:

1. Править только те ошибки, которые раздражают вашего директора;
2. Править все ошибки (никогда не успеете);
3. Не править ошибок вовсе (зато успеете сдать систему уже сегодня!);
4. Править только те ошибки, которые раздражают жену/дочь/хомяка вашего босса;
5. Требовать согласования каждого решения самым надоедливым и недалёким человеком в вашей организации (возможно, пересекается с подходом №1);
6. Начать править случайно выбранную ошибку и, остановившись на полпути, перейти к другой. По завершению повторить;
7. Бояться ошибок. Не править их и свалить все на кого-нибудь другого;
8. Расставить ошибки в алфавитном порядке и править их от А до Я, исключая гласные. При соответствующем подходе к именованию ошибок этот подход может превратиться в №3;
9. Создать сложную избирательную систему представителей, выбираемых двумя третями большинства для написания проекта регламента по формированию трёх двусторонних комитетов, наделённых полномочиями по модерированию будущих дисскуссий на тему стратегического управления ошибками;
10. Тратить все имеющееся время на споры о том, похож ли ваш текущий подход на что либо из только что приведённого списка.

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

1. Первая помощь

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

Это называется сортировкой, разбором ошибок или управлением дефектами. Как и в случае с любыми другими вещами, которые у вас возможно есть, например CD-дисками, книгами, долгами, подружками, — с ошибками лучше всего справляться, объединяя их в высокоуровневые группы. Таким образом становится легче понять ситуацию, обсудить ее с другими и найти подходящего квалифицированного «врача».

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

Вы не можете просто взмахнуть волшебной палочкой над базой ошибок, чтобы они самостоятельно упорядочились. Здесь нужен смельчак (вроде вас), который не побоится грязной работы, засучит рукава и отсортирует их. Можете мне поверить — иначе не получится. Если вы достаточно дисциплинированы, то сможете проводить разборку регулярно, ежедневно в течение всего хода проекта, не позволяя ситуации ни на минуту выйти из-под контроля. Как вариант - вы можете попытаться мотивировать своих программистов систематически разбирать собственные ошибки. Это здорово, но какой бы подход не применялся, дело должно быть сделано.

Прежде чем вы пропустите эти строки со словами «Я знаю о сортировке, но не делаю её по такой-то и такой-то причине», учтите, что сортировка необходима для оздоровления в процессе оказания первой помощи в любом из смыслов — медицинском или техническом. Нет смысла лепить лейкопластырь на коленку больного, если у него из спины торчит полдюжины отравленных стрел. Без сортировки вы не будете точно знать, на что потратить энергию команды наилучшим образом. В отличие от пациента, исступленными жестами привлекающего ваше внимание к своей спине с незваными стрелами, ваша база кода не скажет, где у нее болит больше всего. Вам нужно определить это самостоятельно. Усилия по сортировке важности ошибок имеют еще и несколько полезных последствий. Разбираясь с ошибками, лидер вынуждает всех улучшать своё видение проекта в целом. Он обнаруживает множество дублирующихся ошибок, уже исправленные ошибки, нехватку данных (которые нужно отправить на уточнение тестерам), ошибки, которыми можно пренебречь, и даже нечто нелепое, вроде жалобы на то, что веб-сайт не предсказывает номера выигрышных лотерейных билетов. Практика показывает, что после первой сортировки количество ошибок обычно уменьшается на 30 процентов, что, конечно же, здорово прибавляет настроения. Однако вам не удастся так легко добиться цели без выполнения всей работы.

Очень простая сортировка

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

Согласно простейшей схеме, все ошибки можно разделить на три группы: «необходимо исправить», «надо бы исправить», «не нужно исправлять». Перебирая ошибки, относите их к одной из этих категорий. При этом чем больше ошибок будет отнесено в «надо бы исправить» и «не нужно исправлять», тем более эффективной будет сортировка, поскольку эти группы представляют собой чёткие решения. Чего вам точно не нужно — так это чтобы 99 процентов ваших ошибок попадало в «необходимо исправить». Такой подход к сортировке называется «трусливым». Если все ошибки нужно исправить, то это равносильно тому, что они равнозначны, но это бессмысленно. Иными словами, вы просто сбежали от решения проблемы. Запомните золотое правило: чтобы добиться успеха, расставьте ошибки в порядке их приоритета.

Сортируя ошибки, стремитесь к тому, чтобы 50 процентов попало в «необходимо исправить», а все остальное в «надо бы исправить» и «не нужно править». Затем остановитесь и серьезно взгляните на ошибки. Оцените оставшиеся ресурсы (время и людей) и решите, что наиболее важно для проекта (заказчиков и бизнеса).

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

Врачи первой помощи не выбрасывают белый флаг и не просят таймаутов, когда им приходится выбирать, кого из пострадавших спасать в первую очередь. Если они могут делать ТАКОЙ выбор ради человеческих жизней, то уж вы точно справитесь с расстановкой приоритетов для ошибок. Не прячьтесь за невежеством «трусливой сортировки» — будьте тверды, упрямы и ведите свою команду вперед!

Правила очень простой сортировки

Вот основные правила для трех групп ошибок:

1. Если ошибку «должны исправить», то это означает, что она важнее любой ошибки из группы «надо бы исправить» и «не будем править»;
2. Если ошибку «надо бы исправить», значит, она менее важна, чем любая из группы «должны исправить», и более важна, чем из группы «не будем править».
3. Если ошибку «не будем править», значит, она менее важна, чем любая другая ошибка в категории «надо бы исправить».

Несомненно, все решения по поводу правки ошибок являются относительными. Здесь нет абсолютов. Определение степени важности включает много факторов, и отнести ошибку к той или иной группе может быть очень сложно.

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

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

Группа ошибок «должны исправить» — вот над чем нужно работать программистам. Они ничего не должны трогать в «надо бы исправить», за исключением тех случаев, когда они помогают с сортировкой. Смысл прост: не трогай того, что может понадобиться, до тех пор, пока это не понадобится на самом деле.

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

Когда сортировать

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

Уровень 2. Более детальная сортировка

За исключением тех случаев, когда вы правите ошибки по мере их поступления (хорошая, но на удивление редко применяемая стратегия), обычно все решения касательно ошибок принимаются уже в самом конце, когда наиболее велико давление сроков. Следовательно, вам необходимо иметь сведения по каждой ошибке в достаточном количестве, чтобы принять правильное решение быстро.

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

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

База ошибок требует постоянного сопровождения и усердия со стороны тех, кто открывает ошибки. Чем выше качество информации в базе ошибок, тем меньше времени и сил вы потратите на сортировку, и тем больше ваша команда проведет времени в реальной правке ошибок.

Внимание: качественное описание ошибки (или отсутствие такового) могут быть первым критерием для сортировки ошибок по их важности.

Чтобы улучшить качество информации об ошибке, прежде всего необходимо детализировать группы, на которые эти ошибки делятся. Помимо групп (Должны/Надо бы/Не будем), нужно ввести еще два понятия: «Приоритет» и «Серьезность».

Смысл приоритетов прост: вместо «Должны сделать» назовите это «Приоритет 1», вместо «Надо бы сделать» — «Приоритет 2», и вместо «Не будем делать» — «Приоритет 3». Некоторые команды идут еще дальше и добавляют приоритет 4. Таким образом, Приоритетом 3 становится «вероятно, не будем делать», а Приоритетом 4 — «Не будем делать, пока не остынет преисподняя, потом снова не запылает и опять не остынет». Я не встречал успешных команд, у которых градация приоритетов имела бы более четырех уровней.

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

К примеру, перед вами может быть ошибка, которая приводит к взрыву монитора пользователя (Серьезность 1), но возникает она только после тройного клика на пункт меню при напевании австралийского национального гимна на немецком языке, что маловероятно (Приоритет 3).

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

Вот пример системы определения серьезности. Рекомендую вашей команде собраться вместе и оценить следующее:

• Уровень серьезности 1. Потеря данных. Заказчик теряет данные или серьезно повреждает их. Восстановление данных может быть невозможно или требуется переустановка приложения (или нажатие кнопки «обновить» в браузере»);
• Уровень серьезности 2. Часть функционала не работает или работает с большими проблемами. Большая часть возможностей не работает или работает не так, как ожидалось, поэтому рабочие задачи нельзя решить или приходится искать обходные пути;
• Уровень серьезности 3. Раздражение. Второстепенные функции работают не так, как ожидалось. Обходные пути существуют, но их сложно найти или они раздражают и разочаровывают.

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

Третий важный критерий, который нужно учитывать при работе с ошибками, — это часть проекта, на которую ошибки воздействуют. Чем больше ваша команда, тем важнее учитывать этот критерий. Необходимо понять, какая часть проекта страдает от ошибки: возможность печати или поисковый механизм? Разбейте весь проект на четыре-пять частей и учитывайте их в базе ошибок. Это даст вам новый взгляд на проект — вы сможете определять, какие части проекта наиболее «сырые» или какие части наиболее важны для вас и ваших заказчиков. Если каждый программист отвечает за конкретную часть проекта, то такой подход позволит распределять ошибки для правки.

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