Чи є гранична вигода у виправленні помилок [закрито]

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

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

Чи є справді незначна користь у виправленні помилок? Чи є інший термін, який пояснює це поняття?

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

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

Усі ці фактори слід враховувати при визначенні пріоритетів.

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

Ось хороша довідка

http://www.joelonsoftware.com/articles/fog0000000043.html

Чи виправляєте помилки, перш ніж писати новий код? Перша версія Microsoft Word для Windows вважалася проектом «марш смерті». [...] тому що фаза виправлення помилок не була частиною формального розкладу [...]

Microsoft універсально прийняла щось [...], найвищий пріоритет - це усунення помилок перед написанням будь-якого нового коду [...] Загалом, чим довше ви чекаєте, перш ніж виправити помилку, тим дорожче (у часі та грошах) це виправити. .

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

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

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

Якщо припустити, що ви працюєте в комерційній організації, там неодмінно знайдеться хтось, хто знає аналіз витрат і вигод .

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

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

Якщо ви шукаєте тут більш структурований підхід, ви можете спробувати систему PEF / REV, яка призначає номери користувачам і програмістам перегляду помилки, як вихідну точку для вирішення того, що виправляється - а що ні.

Дивіться також ці дві публікації тут про програмування програмного забезпечення:

Вирішення яких помилок призведе до найбільшої користі

Майже кожна повідомляється про помилку є першочерговою помилкою

Не всі ненавмисні або небажані аспекти поведінки програмного забезпечення - це помилки. Важливо - гарантувати, що програмне забезпечення має корисний та задокументований діапазон умов, за яких можна покластись на корисну роботу. Розглянемо, наприклад, програму, яка повинна приймати два числа, помножувати їх і виводити результати, і яка виводить помилкове число, якщо результат становить більше 9,95, але менше 10,00, більше 99,95, але менше 100,00 і т.д. Якщо програма була написана для обробки чисел, продукт яких був між 3 і 7, і ніколи не буде закликаний обробляти будь-яких інших, фіксація його поведінки з 9,95 не зробить її кориснішою за призначенням. Однак це може зробити програму більш придатною для інших цілей.

У такій ситуації, як описано вище, існували два розумні дії:

1. Вирішіть проблему, якщо це зробити практично.

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

Підхід №1 усуне помилку. Підхід №2 може зробити прогрес менш придатним для певних цілей, ніж це було б інакше, але якщо немає необхідності в програмах для обробки проблемних значень, які можуть не бути проблемою.

Навіть якщо неможливість правильно обробити значення 99,95 до 100,0 є результатом помилки програмування [наприклад, вирішити вивести двозначний ліворуч від десяткової крапки перед округленням до одного місця після, таким чином, отримавши 00.00], це слід вважати лише a помилка, якщо в іншому випадку програма буде вказана як така, що дає значущий результат у таких випадках. [Між іншим, вищезазначена проблема сталася в коді Turbo C 2.00 printf; в цьому контексті це явно помилка, але код, який викликає несправний printf, був би помилковим, лише якщо він може отримати результати в проблемних діапазонах].

У вільному сенсі, так, не всі помилки потрібно виправляти. Вся справа в аналізі співвідношення ризик / вигода.

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

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

З іншого боку, у вас може виникнути помилка, яка здається важливою, але її важко виправити і впливає лише на незначну кількість користувачів. Наприклад, посилання на незначну кнопку перервано для користувачів, які використовують застарілу версію Google Chrome, а також вимкнено Javascript.

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

Сподіваюся, що це пояснює концепцію трохи краще! Я, безумовно, ухилявся б від думки про це в загальних рисах - кожен клоп унікальний і до нього слід ставитися.

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

Тож власне їх "аргумент"

Якщо ви будете ігнорувати помилку досить довго, Користувач забуде, в чому проблема, або знайде спосіб подолати її.

З помилками слід розставляти пріоритети та поводитися з ними "на порядок" так само, як нові запити на функції (але, мабуть, над останніми).