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

24

Первые 90 процентов кода составляют первые 90 процентов времени разработки. Оставшиеся 10 процентов кода составляют остальные 90 процентов времени разработки.

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

Что это означает на практике? Что программисты делают значительный объем работы и что они дают 180% от себя или?

Иосип Ивич
источник
2
Все мы знаем, что либо 100% переопределяется путем его превышения, либо что оно в 1,8 раза больше известного значения. В этом случае, однако, я бы сказал, что это, вероятно, гипербола. Вторые девяносто процентов должны сделать его запоминающимся и добавить изюминку в конец цитаты.
AJFaraday
1
Оценка времени разработки меняется в середине предложения.
Milleniumbug
180% - это количество времени и бюджета, которые затрачивает проект.
Agent_L
1
Я думаю, что совершенно ясно, что этот вопрос задает, несмотря на неловкое последнее предложение.
Мэтью Джеймс Бриггс
2
Эта цитата должна быть прочитана как шутка, в этом контексте она имеет смысл. Говорят, что последние 10% займут гораздо больше времени, чем вы предполагали
Ричард Тингл

Ответы:

40

Представьте себе это так: когда вы начинаете работать над программным обеспечением, вы можете написать огромное количество кода за относительно короткое время. Этот новый код может добавить огромное количество новых функций. Проблема заключается в том, что зачастую эта функциональность далека от «выполненной», могут быть ошибки, небольшие изменения (небольшие в малом бизнесе) и так далее. Таким образом, программное обеспечение может показаться, что оно почти готово (90% сделано), потому что оно поддерживает большинство вариантов использования. Но программное обеспечение все еще нуждается в работе. Смысл этого правила заключается в том, что, несмотря на ощущение, что программное обеспечение почти готово, объем работы по приведению этого программного обеспечения в надлежащее рабочее состояние столь же велик, как и переход в это «почти готовое» состояние. Это потому, что исправление ошибок часто отнимает много времени, но не выдает много кода.

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

Euphoric
источник
3
Большая часть причины иллюзии 90-90 состоит в том, что разработчики программного обеспечения часто визуализируют путь успеха - обработка случаев ошибок и исключений является запоздалой мыслью. Если исходный проект не учитывает случаи ошибок с низкой вероятностью, вероятно, потребуется пересмотр, прежде чем программное обеспечение можно будет назвать завершенным.
Rumbleweed
1
+1, но я чувствую, что второй абзац нуждается в смелом тексте, потому что это действительно важная часть урока :)
Боб Твей
20

Это ссылка на общий сценарий, который, к сожалению, все еще происходит сегодня:

  1. Команду просят оценить (т.е. угадать) объем работы, необходимый для написания всего кода,
  2. Проект продвигается с многочисленными внутренними и внешними давлениями, чтобы «остаться вовремя и в бюджете»,
  3. Таким образом, для значительного процента проекта, «на цели» сообщается. Это часто усугубляется выбором простых задач, чтобы обеспечить хороший прогресс.
  4. Затем на каком-то этапе достигается критическая точка, где реальность должна быть принята: проект не будет завершен вовремя, а дата релиза будет перенесена (часто много раз).

«90%» - это произвольная цифра, но она хорошо показывает суть: оценки являются догадками и, скорее всего, будут ошибочными (часто очень ошибочными), а человеческая природа гарантирует, что мы почти всегда оцениваем, так что вещи перерасходят.

Дэвид Арно
источник
14
То, что называют «гибким», ничего не решает; он просто распределяет его по более мелким предметам, где точно такое же соотношение происходит в меньшем абсолютном масштабе, даже если Каргилл был шутливым. Суть в том, что в каждом проекте есть пара небольших вещей, которые занимают много времени на разработку.
Blrfl
3
@Blrfl Ответ не подразумевает, что agile решает проблему трудностей с оценками, но он смягчает свои последствия, делая меньшие оценки.
Эрик
Я думаю, это не только проблема управления ресурсами. Быстро и грязно прототипировать 90% проекта очень просто, но оставшиеся 10% занимают ОЧЕНЬ много времени, потому что именно здесь мы заботимся о том, чтобы полностью соответствовать начальным требованиям. Я нахожусь во встроенных системах, и я могу дать демонстрацию продукта продавцу за месяцы до выпуска продукта, и он почти не увидит разницы между демонстрацией и конечным продуктом, но наверняка демонстрация не будет отправлена. Ошибки, оптимизация, расширенные функции, энергопотребление, вот и всеother 90%
Тим
Поверьте мне, даже когда Agile дерьмо попадает в вентилятор и взрывается!
JonH
2
Убрал запоздалую мысль о гибкости, так как это явно отвлекает людей от основного пункта ответа.
Дэвид Арно
7

Я слышал другую версию этого (также называемую «правилом 90-90»), которая выглядит следующим образом:

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

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

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

Это правило дополняет правило 80-20. Есть много разных интерпретаций правила 80-20, но мне больше всего нравятся две:

  1. Первые 80% разработки продукта занимают 20% усилий.
  2. 80% ошибок в 20% кода.

На практике это означает следующее: разработка начнется и будет продолжаться до определенного момента, когда будут замечены первые задержки. Задержки могут быть различного характера:

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

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

Владимир Стокич
источник
1
Правило 80-20 также известно как en.wikipedia.org/wiki/Pareto_principle
Питер М. - означает Моника
4

Я нахожу объяснение Википедии довольно поучительным:

Это добавляет до 180% ошибочного намека на известность проектов по разработке программного обеспечения, значительно превышающих их графики (см. Оценку усилий по разработке программного обеспечения). Он выражает как грубое распределение времени между простыми и сложными частями проекта программирования, так и причину запоздалости многих проектов как неспособность предвидеть сложные части. Другими словами, для выполнения проекта требуется больше времени и больше кода, чем ожидалось.

Надир Сампаоли
источник
1

Что это означает на практике? Что программисты выполняют незначительный объем работы и что они отдают на 180% себя или?

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

Это примерно означает «это займет у вас вдвое больше времени, чем вы думаете» и «вы будете думать, что у вас все хорошо, пока не станет слишком поздно (крайний срок близок)».

Agent_L
источник
1

На практике это означает, что люди лгут самим себе.

Если программист говорит: «Мы на 90% сделали», это означает, что 90% усилий по созданию функций были израсходованы.

Если руководитель проекта говорит: «Мы на 90% закончили, мне просто нужен кто-то, чтобы закончить», это означает, что они на 90% закончили бюджет (и, вероятно, 50% сделали). Это клиент без денег, больших ожиданий и плохого отношения.

Разница в том, что для завершения проекта требуется больше усилий, чем для написания кода: исправление ошибок, копирование, редактирование, развертывание.

Этими вещами нужно управлять в проекте, и они находятся в ведении менеджера проекта. Это часто удивляет новых PM, которые соглашаются на «90% возможностей завершено» только для того, чтобы понять, что они только на полпути к «проекту выполнено».

Майкл Коул
источник