Профилактика дефектов: улучшаем качество, снижая затрат

Статья подготовлена специалистами Лаборатории Качества.

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

Читать статью

Маловато там про профилактику... Считай что и нет ничего. И, кстати, а где мой тезис про вред тестирования?!

Чуть чуть конструктивной критики:
>Применение методов профилактики дефектов приводит к следующим результатам:
>* Улучшение чек-листа оценки качества продукта
А причем тут чек-лист???
И еще момент. Качество продукта можно улучшить сотней разных способов. Почему нужно выбрать именно этот?

>Снижение трудозатрат на внесение изменений
Ни разу не приводит. Это совсем другая вещь.

>Значительное уменьшение числа дефектов и их критичности
Нет, не приводит. Уменшает цену исправления - это да. А число то остается неизменным, вне зависимости от того, когда вы его обнаружили. Правда?

>Улучшение взаимодействия между командой проекта и руководством
С какой рабости? это совсем из другой оперы.

>Оптимизация планирования ресурсов
Тоже совсем другая опера.
И еще.
1) Перестаньте называть людей "Ресурсами". У меня при этом выражении рука к кобуре тянется. Наслушаются сотрудников по борьбе с персоналом и начинается.
2) "Оптимизация планирования" это круто. Не так круто, как "интенсификация ускорения улучшения увеличения скорости прогресса", но тоже ничего.

Попридираюсь и я.
Меня учили начинать ревью с чего-нибудь положительного. Так вот, положительного в статье то, что автор ее написал (или перевёл, что не ясно).
Дальше будет критика.

"По информации Computer Finance Magazine (1998), в США до 60 % разработчиков работают в области исправления ошибок"
Ах, бедняжки. Прошло всего-то 12 лет и слова звучат дико, если не глупо.
Ситуация ухудшается, товарищи!
100% разработчиков, с которыми я работал (почти 10 лет в разных компаниях и странах) работают в области исправления ошибок.

"На рисунке 2 отражен механизм профилактики дефектов. Процесс профилактики начинается с анализа требований..."
Найти "анализы требований" на рисунке 2 я не смог.
Тот же рисунок пытается убедить меня в том, что дефекты приходят из тестирования ПО. Но я-то знаю, что это не так. Дефекты приходят из разных мест, и в первую очередь, от разработчиков. Не в том смысле, что они их "внедряют" в ПО, а в том, что они их тоже находят и заносят в трэкер. Особенно, если у них есть спеки.

Нет ссылок на статьи и даты. "По данным журнала..." - это все равно что - "Мне тут сказали, оказывается ..."

"Проверка автором одна из наиболее эффективных процедур ..." Ничего не понял. Автор чего, простите, и чего он проверяет: код или проектную документацию? Или это прикол? Мол, авторы кода - читайте свой код, после того как вы его написали? Круто!
Далее вот чего написано "По своей сути ревью (экспертная оценка) проектной документации похоже на Self-review (самолюбование?). Разница состоит в том, что код проверяет некий эксперт, отлично понимающий его функциональность, а не разработчик, благодаря чему появляется свежий взгляд."
Решил перефразировать мысль статьи - писатели статей, читайте то, что вы пишите!

Далее тратить время на чтение и критику считаю нецелесообразным.
...Нет, не удержался и решил дочитать.

"координатор профилактики дефектов", "Три ключевых принципа анализа первопричины: " ... профилакторий какой-то...

Далее: "Люди, которые понимают, что именно пошло не так, – это те, кто присутствовал при внесении этих дефектов (свечку держали?), то есть – члены команды разработки ПО. Они-то и могут дать наилучшие советы по предотвращению таких дефектов в будущем." Кому, ну кому, они советы должны давать? Себе? Сначала себя порецензировали, потом себе советов надавали...
От этого дефектов меньше не будет. Хотя нет, будет, т.к. будут тратить время не на внесение дефектов, а на выдачу советов.

Окей, картинку, на которой я чуть не свернул шею, мы пропустим (почему же, ее не развенуть-то на 90 градусов, а?).

Далее находим очередной перл. "Анализ первопричины – процесс выявления и устранения (неправда!!!) причины, что в свою очередь позволяет предотвратить повторное возникновение такой проблемы. Выявление причин настолько же важно, как и их устранение". Не может быть!

"После документирования причин необходимо провести отдельное собрание для поиска путей устранения дефектов". Зачем?
Я не верю в то, что постоянные собрания способствуют устранению дефектов.

..уф... Ну почему слово "первопричина" в единственном числе всё время? "Использование знаний, приобретенных в результате анализа первопричины дефектов, в последующих проектах".
Может речь в статье о какой-то Первопричине-Всех-Багов?

"..увеличивают возможность разработчиков ПО учится на совершенных ошибках, и, что более важно, учится на ошибках других." http://tsya.ru/

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

Меня учили начинать ревью с чего-нибудь положительного. Так вот, положительного в статье то, что автор ее написал (или перевёл, что не ясно).

Судя по характерным ошибкам - все-таки перевел.

А ведь можно было просто реферат написать по "Practical Guide To Defect Prevention", например. Тема-то интересная.

Н-да.
Одно:

Судя по характерным ошибкам - все-таки перевел.

другому:

Для подготовки статьи использованы материалы Mukesh Soni*

явно не соответствует. Это уже не "использованы материалы", а перевод, причем не лучшей статьи.

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

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

PS. Статья не лучшая, чтобы мы первоисточник не нашли? Чтобы профессиональные искатели информации не нашли первоисточчник... Ну-ну.

Спасибо за указание на то, что это перевод и за ссылку первоисточник. Информацию о статусе публикации уточним.

Что касается её спорности и неоднозначности -- это, имхо, неплохо, а то и обсудить нечего было бы :)
Будем надеяться, что автор (переводчик) встанет на защиту.

Будем надеяться, что автор (переводчик) встанет на защиту.

Не будем. Есть пара хорошо подмеченных косяков перевода - попрошу исправить, за комменты спасибо :)
А на придирки про свечку, 100% багфиксеров (и откуда новое ПО берётся??) и использование устоявшегося в англоязычной литературе термина Self-review отвечать - время жалко :)

... 100% багфиксеров (и откуда новое ПО берётся??)...

Его пишут теже люди, ессно. Если вы думаете, что есть 40% программистов-аристократов, которые не снисходят до исправления ошибок, и 60% программистов-чернорабочих, копошащихся в чужих и своих исправлениях - то вас обманули. ПО делается не так.
Если считать программистов ресурсом и измерять этот ресурс в человеко-часах, то не видно разницы между
"в США до 60 % разработчиков работают в области исправления ошибок"
и
"в США разработчики, в среднем, тратят окло 60% времени на исправление ошибок"

...использование устоявшегося в англоязычной литературе термина Self-review...

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

.... время жалко :)

Не обижайтесь, но по статье заметно, что на неё тоже было жалко времени.

Если вы думаете, что есть 40% программистов-аристократов, которые не снисходят до исправления ошибок, и 60% программистов-чернорабочих, копошащихся в чужих и своих исправлениях - то вас обманули. ПО делается не так.

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

Если считать программистов ресурсом и измерять этот ресурс в человеко-часах, то не видно разницы между
"в США до 60 % разработчиков работают в области исправления ошибок"
и
"в США разработчики, в среднем, тратят около 60% времени на исправление ошибок"

+2

...использование устоявшегося в англоязычной литературе термина Self-review...

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

+1

.... время жалко :)

Не обижайтесь, но по статье заметно, что на неё тоже было жалко времени.

+1

Если вы думаете, что есть 40% программистов-аристократов, которые не снисходят до исправления ошибок, и 60% программистов-чернорабочих, копошащихся в чужих и своих исправлениях - то вас обманули. ПО делается не так.

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

Логично. Править чужой код - это занятие для профи. Те кто умеют - те правят. Те кто не умеют - ну куда ж их. Разве что на новый проект.

И очень рекомендую:

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

(с) http://gaperton.live....com/36790.html

Вы работали в крупных фирмах-разработчиках ПО? :)

Нечестный приём ведения дискуссии :)

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

Представляю, как у Алексея все забурлило внутри :) Наталья, а вы сами в крупных компаниях работали (действительно крупных)? Или вся эта бравада - Виттакер перец из Гугла, по-пацански, ресурсы и все остальное где вы ставите смайлики - напускная?

Я далек от мысли, что соотношение таких компаний/проектов 60 к 40.

Вы работали в крупных фирмах-разработчиках ПО? :)

А вы тыркните в моё имя в подписи, там все и написано :)

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

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

а во-вторых, я знаю как минимум пару компаний, вообще сдающих багфикс на аутсорс.

С таким не сталкивался, но вполне допускаю, что может так быть.

Представляю, как у Алексея все забурлило внутри :)

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

Представляю, как у Алексея все забурлило внутри :)

Sun Microsystems ~ 34.600 человек. Это не крупная, это монстр - поэтому не считается :)

Наталья, а вы сами в крупных компаниях работали (действительно крупных)? Или вся эта бравада - Виттакер перец из Гугла, по-пацански, ресурсы и все остальное где вы ставите смайлики - напускная?

В таких крупных как Sun - нет, не работала - максимум ~1000 девелоперов включая азиатский аутсорс. Про браваду не поняла, я вообще смайлики люблю Так что разгадывайте дальше. ;)

LeshaL, а что, в Sun'е нет:
* поддерживаемых проектов, разработчики на которых только багфиксят?
* код фриза проектов, после которого разработчики месяцами только багфиксят?
Причём, заметьте, я ничего не говорю про их квалификацию. Речь же идёт про занятость.

Я далек от мысли, что соотношение таких компаний/проектов 60 к 40.

Я близка, но и мои и Ваши идеи - только субъективные ощущения, основанные на нашем конкретно опыте. Как будем считать? :)

Вы работали в крупных фирмах-разработчиках ПО? :)

Нечестный приём ведения дискуссии :)

Учитывая подпись Алексея, он нечестный вдвойне :)

LeshaL, а что, в Sun'е нет:
* поддерживаемых проектов, разработчики на которых только багфиксят?

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

LeshaL, а что, в Sun'е нет:
* код фриза проектов, после которого разработчики месяцами только багфиксят?

Это есть, не уверен что месяцами... Могу говорить только про то, что делают в нашей команде, а проекты наши длиной в несколько месяцев обычно и багфикс - неделя, максимум 2. Но это тоже не важно, т.к. люди начинают чинить баги, как только они появляются. А появляются они как только появляется первый официальный билд.

И вообще, мне кажется, что происходит подмена понятий. Наличие команд, которые только фиксят баги и наличие стадий разработки, когда только баги чинятся - никак не связано с изначальной, на мой взгляд неверной, формулировкой про "60% программистов работают в области багфикса". Наоборот, всё только подтверждает мои слова, что 100% разработчиков чинят свои и чужие баги.
Кто-то больше, кто-то меньше. В итоге, я допускаю, что такой ресурс как время может выйти на соотношение 60/40, но никак нельзя это утверждать про людей.

Я далек от мысли, что соотношение таких компаний/проектов 60 к 40.

Я близка, но и мои и Ваши идеи - только субъективные ощущения, основанные на нашем конкретно опыте. Как будем считать? :)

Тогда в этих 60% компаний\проектах, 100% разработчиков все свое время занимаются багфиксом, так? Ерунда какая-то получается.

Наличие команд, которые только фиксят баги и наличие стадий разработки, когда только баги чинятся - никак не связано с изначальной, на мой взгляд неверной, формулировкой про "60% программистов работают в области багфикса"

Тогда в этих 60% компаний\проектах, 100% разработчиков все свое время занимаются багфиксом, так? Ерунда какая-то получается.

В оригинале написано "60% are involved", и я не уверена в однозначности перевода :) Потому что для "иногда вовлечены в фикс багов" 60% это слишком мало :))
Наверное, можно выявить 3 варианта вовлечённости в багфикс:
1) "Фиксят баги" - я думаю, что здесь значение приближается к 100% - ВСЕ девелоперы фиксят баги :)
2) "Являются только багофиксерами на текущем месте работы" - это проекты поддержки и аутсораса, я не думаю что их больше 10-30%% (и врядли больше 10% если НЕ считать аутсорс), хотя не знаю как их посчитать - только ощущение по опыту.
3) "Являются только багофиксерами на текущих задачах" - вот здесь мне кажется реалистым как раз около 60%.
и тут я как раз говорила про крупные компании, потому что этот пункт явно зависит от крупности проекта. чем больше проект - тем дольше этап между код-фризом и релизом. В моём опыте был проект длительностью 1,5 года, где разработки длилась от силы месяца 2. Сейчас я в основном сталкиваюсь с проектами полугодовыми, где месяца 2-3 ведётся разработка и месяца 3-4 багфикс после заморозки функционала. Не знаю, показательно ли это - но я хорошо знаю внутренню кухню десятка крупных российских разработческих компаний, и у них соотношение приблизительно такое, а скорее - больше.
И да, как я понимаю значение - имеется в виду роль сотрудника в текущий момент. К примеру, я сейчас занимаюсь автоматизацией, и у меня есть сотрудники, которые на одном проекты выступают как девелоперы, в другом могут быть менеджером проекта, потом - опять девелопером. Т.е. в разные моменты у них разные роли.

Своё описание как смогла объяснила, и думаю, что непонимание было просто из-за недостаточно внятных терминов :)