Разделы портала

Онлайн-тренинги

.
Исправление ошибок: в нужное время и в нужном месте. Часть II
05.10.2008 18:14

Автор: Scott Berkun

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

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

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

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

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

Уровень 3. Критерии выхода

Как вы определяете, что завершили работу над чем либо?

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

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

Этот критерий наиболее прост для достижения, но он не имеет никакого отношения к качеству программного продукта. Вы уложитесь в сроки поставки вне зависимости от того, реализовано у вас 10 или 90 процентов функционала. Но если смотреть с точки зрения качества, то дата выпуска продукта — это всего лишь произвольная точка времени.

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

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

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

Должны ли быть исправлены все ошибки с приоритетом №1, или должны быть исправлены все ошибки с приоритетом №1, но только для какой-то конкретной части проекта? Если этого не знаете вы, то не знает и ваша команда, и вы обречены на споры по поводу каждой ошибки.

 

Определение критериев выхода — это одно из проявлений лидерства. Для этого необходима постоянная забота о проекте, что сможет произвести эффект катализатора для всей организации.

Ключевой вопрос таков: как много ошибок, какого типа, в каких частях проекта допустимы? Вот несколько наводящих вопросов, которые могут помочь:

  • Чем вы были заняты в последнее время? Вам необходимо выпустить несколько релизов. Их количество случайно, но это даст вам точку отсчета. Вы можете увеличивать или понижать качество относительно чего-либо, и это позволит вам выразить то, что вы имеете ввиду. Если вы никогда ранее не делали этого, то поставьте перед собой цели. Решите, какие действия вам необходимо проделать, чтобы выпустить версию 2.0. Периодически вы сможете определять качество в сравнении с предыдущими версиями и направлять работу в нужном русле.
  • Какие части проекта наиболее важны? Составьте упорядоченный список частей проекта/функциональных возможностей. Те элементы, которые наиболее важны для заказчика, должны иметь больший вес. Вы можете определить одни критерии выхода для функций А, Б и В и другие — для Г, Д и Е. Используйте основные ресурсы для наиболее используемых функций.
  • Какие тесты (тест-кейсы) вы используете? Критерии выхода не должны основываться на количестве ошибок. Если вы используете тест-кейсы для каждой функции своего ПО, то вы можете установить критерий выхода в процентном соотношении пройденных тестов. Если вы до сих пор не использовали тестов, то пришло время начать делать это (http://en.wikipedia.org/wiki/Test_case). Они могут инкапсулировать много различных критериев в один, зачастую автоматизированный, тест. Если вы будете их делать, то тесты помогут вам определить не только критерии выхода, но и просто помогут в завершении конкретной работы. Каждый чек-ин (занесение части кода в общую базу) может выполняться по прохождению теста. Это поможет определять проблемы до того, как они превратятся в большое бедствие.
  • Какие параметры производительности должны быть достигнуты? Определены ли параметры производительности, к достижению которых вы стремитесь? Время загрузки, сохранения, закачки?
 

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

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

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

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

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

 

Помните: вы всегда можете корректировать критерии выхода в течение проекта.

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

Уровень 4. Раннее планирование

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

 

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

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

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

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

Другой вариант: вы можете составить анкету для заказчика, которая поможет ему лучшим образом составлять отчеты об ошибках, что повысит качество описания ошибок, вводимых в систему. Подходящий способ обеспечить все это состоит в выделении человека для выполнения им задач по контролю качества. Если таковой человек в вашей команде уже есть, обеспечьте его большими возможностями (http://www.macdevcenter.com/pub/a/mac/2005/07/08/dev_team.html).

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

Если вы вырабатываете список частей проекта для улучшения, не забудьте ранжировать их. Расставьте их в порядке наибольшей значимости для вас и проекта, а затем начните решение первой задачи из этого списка. Не первых пяти или десяти, а именно самой первой. До тех пор, пока вы и каждый член вашей команды не будут способны добиться позитивных изменений, вы должны добиваться этих изменений. Помогите всем объединиться вокруг улучшения ситуации, позвольте каждому высказывать свои предложения и участвовать в их реализации. И не забывайте о критериях выхода, иначе как вы узнаете, что какой-либо процесс уже улучшен?

Исключения и примечания

Существует несколько исключительных ситуаций, когда необходимо пренебречь советами, данными в этом эссе.

Простая рекомендация: иногда программист может быстро превратить большую ошибку в ошибку малой важности. В такой ситуации нужно править ошибки вне порядка их приоритета. Позвольте программистам иногда действовать по их усмотрению. Соглашательство порой может быть полезным.

  • Мораль: правка ненавистных или очевидных ошибок, вне зависимости от их приоритета, может позволить программисту почувствовать гордость и повысить моральный дух. Это допустимо, если вы знаете, ради чего идете на это. Если такие вещи проделываются часто, то смените критерии для расстановки приоритетов 1, 2 и 3. Если вам приходится обходить правило, смените это правило.
  • Убедитесь, что программисты не путают свое время с рабочим временем. Низкоприоритетные ошибки и те ошибки, которые интересны лично им, они могут править только в свободное время. При этом убедитесь, что им известно, будут ли им начислены бонусы за работу над проектом в нерабочее время.
  • Качество: исправление ошибок схоже с любой другой работой - чем больше времени вы на это тратите, тем выше качество исправлений. При этом возьмите за правило, что время, затраченное на исправление, должно соответствовать весу ошибок. Вы ведь не будете навешивать пластмассовую дверь на золотые петли без веской причины?

Часто задаваемые вопросы

  • Кто должен быть вовлечен в сортировку ошибок (Уровень 1)?
    Тот, кто громче всех кричит. Не важно, разработчик ли это, тестер или менеджер проекта. Если один человек может взять на себя сортировку и фильтрацию базы ошибок, то не стоит поручать эту работу троим. Если у вас есть представитель заказчика, попросите его плотно поучаствовать в этом процессе (но будьте готовы переводить ошибки в его термины). Все специалисты, технические писатели, юзабилити-инженеры, маркетинг должны быть приглашены, но наилучший способ сэкономить время каждого из них — это договориться с ними о телефонных консультациях, когда их помощь будет нужна. Дайте им знать, какая из ошибок требует их внимания, и они подскажут вам, насколько серьезна данная ошибка.
  • Что мне делать, если я не могу добиться согласия босса на определение критерия выхода (окончания проекта)?
    Изучайте гипноз. Ну, хорошо, возьмите этот критерий для работы над пилотным проектом. Обратитесь к людям, которые уже участвовали в таких проектах и попробуйте выработать критерии вместе с ними. Затем, когда проект, по вашему мнению, подойдет к концу, совместно с боссом рассмотрите, насколько ваши критерии выхода приемлемы в данной ситуации. Если они приемлемы, босс все равно скажет нет. Если не приемлемы, то что вы еще ожидали от босса? Повторяйте эту процедуру, пока вы не найдете что-либо, позволяющее вам закончить проект.
  • Приведите пример самого неудачного случая в вашей практике управления ошибками.
    Что ж, это история одного менеджера по контролю качества, который сформулировал критерии выхода за два дня до срока окончания проекта. Он был счастлив своему прогрессу, но когда я взглянул на то, что он записал, я не был удивлен, что он просто задокументировал текущий билд. Вы можете догадаться о качестве этого релиза. Правда, это была не совсем ошибка менеджера. Вице-президент оставил критерии выхода только у себя в памяти и не сообщил о них менеджеру.
  • Почему управление ошибками не преподается как часть информатики в университетах? Возможно, их учебные планы сами полны ошибок?
    Если быть честным, то здесь достаточно и меньшего времени, чем учеба в университете. Я полагаю, что исправление ошибок — это узкая прикладная дисциплина, которая с академической точки зрения больше является прикладной, нежели относится к теории вычислительной техники. В большинстве училищ (в американской системе образования - trade scool, прим. переводчика), где учебный процесс сфокусирован на конкретных прикладных науках, можно встретить факультативные занятия по контролю качества и искусству отладки.

Полезные ссылки

1. Тестирование программного обеспечения. Это огромная тема. Начать можно отсюда:

2. Безболезненный учет ошибок: замечательное эссе от Джоеля о простом учете ошибок.

3. Примеры сортировки ошибок. Здесь есть примеры различной организации сортировки ошибок. Ссылки разнообразны:

Tags: