Что пишут в блогах

Подписаться

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

Конференции

Что пишут в блогах (EN)

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

Про инструменты

Лучшие вакансии

.
Исправление ошибок: в нужное время и в нужном месте. Часть 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). Они могут инкапсулировать много различных критериев в один, зачастую автоматизированный, тест. Если вы будете их делать, то тесты помогут вам определить не только критерии выхода, но и просто помогут в завершении конкретной работы. Каждый чек-ин (занесени