Яку кількість часу потрібно витратити на помилки та оригінальну розробку? [зачинено]

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

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

Наприклад, якщо проект A потребує 40 годин, а додаткові 10 виправляючих помилок, цей проект матиме співвідношення 4: 1.

Якщо інший проект (B) потребує 10 годин для завершення, але ще 8 для помилок, то він матиме співвідношення 5: 4.

Це задокументована / досліджена концепція?

ОНОВЛЕННЯ

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

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

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

Враховуючи групу B, якщо вони створюють в середньому 8 одиниць переробки на кожні 10 одиниць роботи, яку вони виконують, то працюючи ці 8 одиниць, створять нові 6,4 одиниці переробки. Ми можемо оцінити загальні зусилля, які їм, зрештою, доведеться витратити, як суму геометричної прогресії:

10 + 8 + 6,4 + 5,12 + ...

Кількість помилок з часом буде експоненціально зменшуватися, але команда B має такий коефіцієнт у своєму експоненті, що він дуже повільно піде на нуль. Власне, сума перших трьох доданків у наведеному ряді становить лише 24,4; з першої п'ятірки, 33,6; з перших 10, 45; з усієї серії, 50. Отже, підсумок групи B: швидкість введення дефекту, 0,8; розвиток функції, 10/50 = 20%; виправлення дефектів, 80%. 20/80 - це їх стійкий розподіл потенціалу.

Навпаки, команда A знаходиться в набагато кращій формі. Їх прогресування виглядає приблизно так:

40 + 10 + 2,5 + 0,625 + ...

Сума цієї серії становить 53 1/3, тому розподіл особливостей розвитку команди А А становить 40 / (53 1/3) = 75%, а розподіл на виправлення дефектів - 25%, що відповідає їх швидкості введення дефекту 10/40 = 0,25 .

Насправді всі терміни в серії «Команда А» після перших трьох незначно малі. Що це означає на практиці, це те, що команда A, ймовірно, може видалити всі свої помилки за допомогою декількох випусків технічного обслуговування, другий випуск має досить малий обсяг. Це також створює ілюзію, що будь-яка команда може це зробити. Але не Команда B.

Я думав про цю еквівалентність, читаючи нову книгу Девіда Андерсона «Канбан» . (Книга на іншу тематику, але теж стосується проблем якості.) Андерсон, обговорюючи якість програмного забезпечення, цитує цю книгу Каперсом Джонсом, "Оцінки програмного забезпечення, орієнтири та найкращі практики" :

"... у 2000 р. ... виміряна якість програмного забезпечення для північноамериканських команд ... варіювалась від 6 дефектів на функціональну точку до менш ніж 3 на 100 точок функцій, діапазон від 200 до 1. Середня точка становить приблизно 1 дефект на 0,6 - 1,0 функціональних балів. Це означає, що командам зазвичай витрачати більше 90 відсотків своїх зусиль на виправлення дефектів ". Він наводить приклад одного з колег компанії, який витрачає 90% часу на виправлення помилок. .

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

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

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

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

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

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

Використовуйте матрицю на зразок наступної (горизонтальний - час, необхідний для виправлення помилки, вертикальний - тип помилки - вплив на користувачів)

              | Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix       | Fix

Приклад проблем:

              | Few hours                            | Many hours
--------------+--------------------------------------+---------------------------------
              | Window moves 1px every 10            | Windows is painted incorrectly 
Minor problem | times when you open the application. | every 100th time the app is open.
              | Fix is: handle window resize event   | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening     | Poor performance when >100 users 
              | SQL connection.                      | are connected (unusable app)
              | Fix: Fix invalid query + add nice    | Fix: change architecture + DB
              | message                              |

Матриця може бути більш складною з різним рівнем тяжкості, зусиль, ризиків тощо

Ви навіть можете створити рейтинг для кожної помилки та виправити їх на основі рейтингу. Щось на зразок:

Bug priority = Risk x Severity x Effort

* Може бути (1-х) для деяких операндів, залежно від того, який масштаб ви виберете :)

Отже, щоб відповісти на ваше запитання: залежить від типу помилок, наявного часу / бюджету тощо.

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

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

З досвіду я кажу, що це ЗАСЕГА недооцінене і дуже легко може витратити стільки ж годин, як "оригінальний проект".

Справді правильною відповіддю було б нульові години на виправлення помилок, оскільки ваш код ідеальний. :-)

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

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

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

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

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

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

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

Зауважте, що розробники повинні самостійно перевірити свій код. Їх відповідальність за доставку коду без помилок. Тому важко відокремити кодування від налагодження.

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

Тому замість того, щоб говорити про "час, витрачений на помилки", слід говорити про "час, витрачений на тести" (інтеграційні тести, тести прийняття користувача ...)

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

Якщо це допомагає, я можу вам сказати, над якими проектами я працюю (корпоративний простір, великі складні системи, багато інтеграції до інших систем) мають співвідношення приблизно 3: 2. Більшість з них не є помилками коду - частіше несправності з інтерфейсами. Наприклад, системи A і B розмовляють між собою через інтерфейс X. Розробники системи A інтерпретують інтерфейс X дещо інакше, ніж розробники системи B. Виходить комедія.

Одним із зауважень є те, що розробка коду та тестування / виправлення помилок коду не повинні бути двома різними фазами. Якщо ви тестуєте, як ви розвиваєте, "вартість" виправлення помилок менше.

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