Вирішення, які помилки даватимуть найбільшу користь [закрито]

Мені хотілося скласти уявлення про класифікацію помилок, виходячи з того, наскільки легко їх вирішити і скільки користі це дасть мені. наприклад, якщо є помилка, яка займе скажімо годину (подвійний закриття файлу тощо), щоб вирішити проти іншого, який займає день (помилка сегментації). Але якщо вирішити перший помилку не дуже важливо, я, мабуть, попрацюю над другою.

Чи є якісь наукові роботи, які класифікують помилки на основі показників витрат та вигод?

Скажімо, помилки можна класифікувати за характеристиками помилок, наприклад, вразливістю безпеки, помилкою пам’яті, помилкою логіки тощо. З іншого виміру можуть бути такі параметри, як складність (легкий, середній, жорсткий). Чи є інші виміри, які я повинен шукати. Щоб спростити речі, я можу припустити дві речі:

1. Кожен програміст в команді однаково здатний вирішити будь-яку помилку
2. Кінцевого строку немає

Типова система відстеження помилок має два, можливо три поля, що визначають співвідношення вартості та користі помилок:

1. Пріоритет (призначається власником бізнесу)
2. Тяжкість (класифікація помилок - критична до низької)
3. Приблизні години (здогадка про те, скільки часу знадобиться)

Як ви зазначаєте, це визначає, над якою помилкою важливо працювати.

Система, висунута в PEF / REV: Багатовимірний показник відстеження помилок додає більше інформації про бізнес та компоненти розробника для вигоди від помилок.

Усі значення знаходяться на шкалі 1 .. N (однакове верхнє значення для кожного).

PEF визначається бізнесом:

• П айн - Наскільки болюча помилка
• E ffort - скільки зусиль потрібно, щоб обійти клопа
• F вимога - як часто виникає помилка

REV походить від розробника:

• R isk - Наскільки ризиковано виправлення системи
• E ffort - скільки зусиль докладається, щоб виправити помилку
• V ерифікованість - як легко перевірити виправлення помилок

Якщо, наприклад, у вас трапляються аварії, які часто трапляються, з якими легко обійтись (увімкніть автоматичне збереження), це може бути коефіцієнт PEF 7,1,1 (оцінка 9). Під час виправлення це може включати зміну основного модуля і мати REV 9,3,2 (оцінка 14).

З іншого боку, у вас може виникнути роздратування, яке завжди є (3,3,9 - оцінка 15), що має тривіальну корекцію (1,1,3 - оцінка 5).

У цьому прикладі роздратування виглядає як краща справа з витратами / вигодами.

Проблема, яку ви описуєте, дуже поширена, і найкращою відповіддю може бути "використати почуття кишечника".

Зазвичай я поділяю помилки на три категорії: Збій, Дратівливий, Косметичний (їх можна назвати 1, 2, 3 - це насправді не має значення), а потім складаю загальну оцінку часу, необхідного для виправлення кожної помилки (усі помилки повинні мати приблизну оновлену оцінку в усі часи).

При вирішенні помилок Збиток> Дратівливий> Косметичний, а потім я просто виконую "найкоротшу роботу", щоб отримати якомога більше початкової пропускної здатності.

Мені ДУЖЕ важко підрахувати будь-яку пряму фінансову вигоду від вирішення будь-якої помилки - якщо тільки це не дуже чітко сплачена робота.

Одне зауваження, яке вам може знадобитися, - це те, що ви дійсно повинні дожити до п’ятої точки на тесті Джоела - на це може вплинути чисельність команди та розподіл між різними іншими «локальними» питаннями, - але це, як правило, ознака доброї практики.

Іншим моментом може бути тип тестування або організації тестування, яка розкриває помилку, намагаючись визначити вплив та вартість помилки та виправити. Елементне або функціональне тестування може вказувати на щось у дизайні, яке потрібно змінити, і таким чином виправити раннє було б простіше і дешевше, ніж пізніше. Тестування на систему чи інтеграцію може вказувати на те, що впливає на більшу кількість клієнтів. І тестування стандартів, хоча часто є некритичним для великої групи клієнтів, може призвести до втрати сертифікації, якщо її не виправити та мати негативний вплив на бізнес.

Однак, тому, що певна тестова організація має тест, не повинно автоматично робити помилку "критичною". Наприклад, може виникнути спокуса сказати щось на кшталт "всі тести системи повинні пройти перед відправкою, таким чином, будь-який тест системи, який виходить з ладу, автоматично призводить до помилки критичної / високої тяжкості". Сподіваємось, жодна організація не зробить це твердженням (хороші критерії виходу з тесту - це інша дискусія), але справа в тому, що про "серйозність" помилки слід судити про її вплив на клієнта, продукту чи іміджу компанії, а не де або коли розкрито.

Один з можливих способів вирішити це - розрізнити "тяжкість" та "терміновість". Наприклад, оскільки дата випуску наближається, може бути тиск часу, щоб визначити, чи може помилка з низьким ступенем тяжкості впливати на велику підгрупу клієнтів, надаючи помилкою більшу "нагальність" і підвищивши роботу над цією помилкою вище (деяких) інших на принаймні, поки це визначення не може бути зроблено. Правильний баланс між ними, разом із досвідом та хорошим судженням, допоможе спрямувати, куди витрачаються час та сили.

На додаток до того, що інші сказали про класифікацію помилок тощо, також розглянемо перегляд Afferent Coupling (Ca) для визначення рівня критичності, яку може представляти конкретна помилка. Якщо у вас є помилка в модулі з високим числом Са, я, можливо, сподіваюся виправити цей перший, оскільки це може принести користь іншим компонентам системи. Ca допомагає визначити рівень відповідальності, а відповідальні модулі із помилками в них завдають шкоди всій програмі (докладніше про Ca читайте тут: http://www.ibm.com/developerworks/java/library/j-cq04256/index.html ).

Зважаючи на це, ми схильні класифікувати помилки та розміщувати їх у пріоритеті на основі їх впливу на клієнта. Ваш клієнт буде різним, але залучення їх до дискусії в кінцевому рахунку призведе до того, які помилки слід виправити над іншими. Це не реально науково, але ми, як ціла команда, схиляємось до консенсусу щодо пріоритетності та категоризації помилок, кожен має внесок у «великих» (усі зацікавлені сторони можуть дати вклад), і ми збираємось та зберігаємо звідти.

Ви не можете визначити фактичну вартість усіх помилок. Деякі ви можете, для багатьох це важко оцінити. Наприклад, скажіть, що у вас є помилка, в результаті якої весь текст на кнопках трохи не вирівняний. Це робить ваш продукт 1,0 виглядає трохи неохайним. Це не спричиняє збій вашої програми або втрату даних вашими користувачами. Напевно, досить дешева помилка, правда?

А що робити, якщо кожен ваш клієнт помічає цю проблему, і кожен рецензент згадує про це у відгуках про ваш продукт. А що робити, якщо ця помилка переноситься від версії 1.0 до 1.1 та 1.2. Зараз ваша компанія може мати репутацію трохи неохайного контролю якості. Наскільки дорогим може бути цей простий помилка з точки зору потенційних втрачених продажів вашої компанії для майбутніх продуктів? Або, як це може вплинути на відгук, який отримує ваш продукт - ваш продукт може повністю відповідати потребам ваших клієнтів, але отримує лише 9 з 10, оскільки він виглядає трохи неохайним.

Отже, вам потрібно не тільки дивитися на вартість конкретної помилки з точки зору того, що її варто виправити, і це безпосередньо впливає на користувача, але ви повинні розглядати це в більш широкому контексті того, як це впливає на сприйняття вашого продукту. на ринку, і як це сприйняття впливає на майбутні продажі.

Це може здатися надуманим, але це не так. У той час, коли я це пишу, ви можете перейти на інший веб-сайт, у якому є стаття про те, як Apple перемістила «1» на їх піктограмі календаря на піксель або два. Якщо ви здійснюєте пошук, ви побачите кілька негативних статей про цю крихітну помилку. Звичайно, це не вплинуло безпосередньо на підсумки Apple, але вони рекламують себе як вершину хорошого дизайну, тому помилка дизайну впливає на таке сприйняття, хоч і незначно.