Дев'яносто дев'яносто правило на практиці

На перші 90 відсотків коду припадає перші 90 відсотків часу розробки. Решта 10 відсотків коду припадає на інші 90 відсотків часу розробки.

- Том Каргілл, Bell Labs

Що це саме означає на практиці? Що програмісти виконують значну кількість роботи і що вони дають 180% з себе чи?

Уявіть це так: Коли ви почнете працювати над програмним забезпеченням, ви можете написати величезну кількість коду за порівняно короткий час. Цей новий код може додати величезну кількість нового функціоналу. Проблема полягає в тому, що часто ця функціональність далеко не "зроблена", можуть виникнути помилки, невеликі зміни (невеликі в бізнесі, малі) тощо. Таким чином, програмне забезпечення може відчути, що воно майже зроблено (90% зроблено), оскільки воно підтримує більшість випадків використання. Але програмне забезпечення все ж потребує роботи. Суть цього правила полягає в тому, що, незважаючи на те, що програмне забезпечення відчувається, що воно майже зроблено, обсяг роботи над приведенням цього програмного забезпечення у належний робочий стан такий же великий, як і потрапляння до цього "майже зробленого" стану. Це тому, що виправлення помилок часто забирає багато часу, але не дає багато коду.

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

Це посилання на загальний сценарій, який, на жаль, має місце і сьогодні:

1. Команду пропонують оцінити (тобто здогадатися) обсяг роботи, необхідний для написання всього коду,
2. Проект триває з численними внутрішніми та зовнішніми тисками, щоб "залишатися на часі та бюджеті",
3. Так для значного відсотка проекту повідомляється "на ціль". Це часто ускладнюється вибором легких завдань, щоб забезпечити добрий прогрес.
4. Тоді на певному етапі досягається критична точка, коли реальність має бути прийнята: проект не буде завершений вчасно, а дата виходу буде відсунута назад (часто багато разів).

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

Я чув іншу версію цього (також називається "правило 90-90"), яка йде так:

Після того, як я реалізував 90% функціоналу, мені залишається реалізувати інші 90% .

Обидві версії стосуються складності правильної оцінки зусиль для розробки програмних продуктів та загальних підводних каменів, до яких люди, як правило, потрапляють:

• викидання статистики там, коли потрібні оцінки, і по суті здогадки ("я на 80% закінчую")
• зосередити увагу на алгоритмічній складності коду, який потрібно записати, на шкоду обсягу роботи (недооцінка необхідних зусиль для виконання загальних завдань)
• пропущені кроки ("поза увагою, поза розумом")
• недооцінка зусиль для підтримки та зміни існуючого коду
• заниження зусиль, необхідних для котла / коду «клею»

Це правило доповнює правило 80-20. Зараз існує багато різних інтерпретацій правила 80-20, але два, які мені найбільше подобаються:

1. Перша 80% розробка продукту вимагає 20% зусиль.
2. 80% помилок - у 20% коду.

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

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

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

Я вважаю пояснення Вікіпедії досить освічуючим:

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

Що це саме означає на практиці? Що програмісти виконують додаткову кількість роботи і що вони дають 180% від себе чи?

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

Це приблизно означає: "Це займе у вас вдвічі більше часу, ніж ви думаєте", і "Ви подумаєте, що ви справляєтеся добре, поки вже не пізно (термін наблизиться)".

Що це означає на практиці, це те, що люди брешуть собі.

Якщо програміст каже "ми готові на 90%", це означає, що витрачено 90% зусиль на створення функцій.

Якщо керівник проекту каже: «ми готові на 90%, мені просто потрібен хтось, щоб закінчити це», це означає, що вони 90% через бюджет (і, ймовірно, 50% зроблено). Це клієнт без грошей, великих очікувань та поганого ставлення.

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

Цими речами потрібно керувати в проекті, і це відповідальність керівника проекту. Це часто дивує нових прем'єр-міністрів, котрі узбережжя "на 90% мають повноцінність", лише розуміючи, що вони лише на півдорозі до "проекту зроблено".