×

Быстрая и точная оценка проекта

Быстрая оценка проекта — как фастфуд. Дешево, вредно, но порой необходимый атрибут профессиональной жизни.

Вам когда-то приходилось оценивать проект, о котором вы ничего не слышали, за 3 часа? Мне да. Было весело (саркастический, нервный смех).

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

В этой статье я не даю 100%-ный способ оценки любых проектов за пару минут. Я рассматриваю проекты средней длины — от полугода до года. И даю только первоначальную оценку проекта. Что-то, что вы можете предоставить вашему сейлз-менеджеру быстро, и не потерять при этом спокойный сон.

Требования к оценке проекта

Дядя Боб сделал замечательное видео об эффективных оценках. И он подчеркнул 3 главных качества хорошей оценки проекта:

  • честность;
  • прецизионность;
  • точность.

Честность

Как можно измерить честность оценки? Честность — что это вообще значит?

Честность в первую очередь перед самим собой.

Мое определение честной оценки: эта такая оценка проекта, за который ты бы сам взялся, если бы был слегка болен. Представь себе, что у тебя сезонная простуда, а тебе надо реализовать данный проект в оцененный тобой срок. Если возьмешься за это — оценка честная.

Прецизионность

Прецизионность — это значит, что если вы оценивали 3 похожих проекта, то вы должны получить 3 похожие оценки. Если одна CMS-ка средней руки займет 1 человеко-год имплементации, то разработка другой CMS-ки схожего функционала никак не может занять 3 собако-недели или 5 рабо-лет.

Убедитесь, что ваши цифры не противоречат друг другу и не вызывают сомнений в вашем профессионализме и здравом уме. Страничка с контактами не может занять дольше, чем главная страница вашего сайта. Простой RESTFull сервис не должен занять больше, чем самообучаемый AI сервис аналитики.

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

Точность и условия оценивания проекта

Оценка сроков выполнения проекта должна быть точной. Это значит, что разница между предсказанным и реальным сроком выполнения проекта должна быть минимальной. Если вы говорите, что проект займет 3 месяца, то крайне желательно, чтобы это было 3 месяца. А не полгода. Или год.

И точность оценки — это очень крепкий орешек. В основном это вызвано:

  • Временным ограничением. У вас обычно очень мало времени на оценку проекта. Особенно если вы работаете напрямую с сейлз-командой. Этим ребятам нужно все и сразу. Без исключений.
  • Недостатком информации. У вас нет полной информации о списке функционала, целевой аудитории и т. д. Иногда все, что у вас есть, — это полпараграфа текста. А временами и исписанная вашим боссом салфетка из бара напротив. GoogleIT© может помочь. Но в основном вам придется работать в условиях крайне ограниченной информации о проекте.

А чтобы получить больше информации, вам нужно больше времени. Которого у вас нет.

Добавьте к этому следующее:

  • Точность оценки в зависимости от трудозатрат растет логарифмически.
  • Трудозатраты на повышение точности оценки проекта растут экспоненциально.

Это значит, что даже при наличии относительно большого количества времени на оценку проекта, ваш результат все равно будет содержать в себе погрешность. И достаточно большую.

Вероятностная сущность оценки сроков проекта

Это приводит нас к вероятностной сущности оценки сроков проекта.

Едва ли вы можете выразить предполагаемый срок проекта в одной цифре и быть при этом честными, прецизионными и точными одновременно.

Оценка срока реализации проекта — величина вероятностная.

Честный, прецизионный и точный способ представления оценки проекта звучит примерно так: «Проект займет 6 недель с вероятностью успеха 95 %. Или он займет 4 недели с вероятностью уложиться в срок 65 %». Можно еще представлять оценку проекта в виде диапазона значений с учетом 95 % вероятности успеха: «Скорее всего, проект займет от 4 до 6 недель».

Единица измерений

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

Этот способ измерения всегда для меня был немного обманчив. Я представлял себе полный 8-часовой рабочий день, посвященный написанию кода. Что, конечно же, не соответствует реальности. Программисты не пишут код 8 часов в день. Планинги, митинги, кофе, паники — все это крадет драгоценное время.

Как следствие, в этой статье я буду использовать Average Working Day (AWD) как единицу измерения.

Считайте, что 1 AWD — это количество работы, которую 1 программист в среднем может сделать за день, состоящий из 5 часов написания кода и 3 часов, потраченных не у монитора.

Вдобавок мы обычно не работаем в одиночку. Мы работаем в команде. И существует вековая проблема масштабирования команды согласно ожидаемого/желаемого срока разработки проекта. См. «9 женщин не могут родить ребенка за 1 месяц» и закон Брукса.

Но для простоты мы опустим эти детали и будем считать, что 2 человека могут справиться с задачей на 2 AWD за 1 день, 4 — за полдня и т. д.

Расчет диапазона срока выполнения проекта

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

Трехкратный метод

Идея проста: чтобы оценить проект, разбиваете его на задачи и даете оценку каждой задаче с помощью 3 величин:

  • B — best case (оптимистическая) оценка срока, 95 % вероятности не уложиться в срок.
  • N — nominal (номинальная) оценка срока, 50 % вероятности уложиться в срок.
  • W — worst case (пессимистическая) оценка срока, 5 % вероятности не уложиться в срок.

Считайте, что уложиться в оптимистичный срок можно, только если сам Один сядет за лэптоп и всей своей мудростью и силой затянет проект прямо в Вальхаллу. Оптимистичная оценка — это минимально необходимое время для реализации проекта при наилучших обстоятельствах. Задача наверняка будет выполняться дольше, чем рассчитано по best case. Также можете считать это вашей Big-Omega оценки срока.

Номинальная оценка — наиболее реалистичный срок. Это самое важное значение, так как оно имеет наибольший вес в дальнейших расчетах. Эта оценка должна быть умеренно оптимистичной при ваших обычных условиях работы. Считайте, что у вас есть 50%-ная вероятность не уложиться в номинальный срок. Также можете считать это вашей Big-Theta оценки срока.

Пессимистическая оценка дается исходя из того, что все пойдет не так. Ваш ноут утащила в нору офисная крыса. Ваш дизайнер оказался мартышкой-наркоманом. Вас призвали в армию за день до релиза. Это наихудшая оценка, которую вы можете дать задаче. И у вас только 5%-ный шанс не уложиться в этот срок. Также можете считать это вашей Big-O оценки срока.

Очевидно, что

B < N < W

Ваша пессимистическая оценка не может быть меньше номинальной. Извините.

Давайте рассмотрим трехкратный метод на примере.

Пример требований к проекту


The web-service should allow a user to log in to an existing account.
Buy the product from the predefined list of commodities.
And review its purchase history.

Предположим мы разбили требования на 3 задачи:

Work Item Name
1User Login
2Purchase Commodity
3Purchase History

Пример трехкратной оценки задач

Work Item NameBNW
1User Login1030100
2Purchase Commodity1540150
3Purchase History21020
Все величины приведены в AWD


Расчет СКО и среднего арифметического взвешенного

Среднее значение срока выполнения задачи (mean) рассчитывается как:

M = (B + 4N + W)/6

Почему коэффициент 4 для номинальной оценки? Потому что она наиболее реалистичная. И мы хотим выделить ее по сравнению с другими оценками. Почему именно 4, а не 6 или 8? Потому что Rocket Science.

Для вычисления общей средней продолжительности проекта мы суммируем среднюю продолжительность каждой задачи.

И получаем:

Work Item NameBNWM
1User Login103010038
2Purchase Commodity154015054
3Purchase History2102010
Project Total Mean102
Все величины приведены в AWD, округлены до целых

Теперь давайте рассчитаем СКО (Standard Deviation) для каждой задачи:

S = (W — B)/6

И общее СКО для всего проекта:

Project Standard Deviation = SQRT(SUM(S^2))

Для нашего проекта имеем:

Work Item NameBNWM
1User Login103010038
2Purchase Commodity154015054
3Purchase History2102010
Project Total Mean102
Project Standard Deviation27.2

СКО показывает вариативность вашей оценки. Чем оно больше — тем больше будет диапазон вашей оценки. Не говорите об СКО проекта людям с гуманитарным образованием :)

Эти значения нам понадобятся для аппроксимации наших данных с помощью бета-распределения. Что в свою очередь даст возможность получить вероятностное значение сроков выполнения проекта.

Бета-распределение

Для получения вероятности успешного выполнения проекта в оцененный срок я использовал бета-распределение. Потому что его применяли в PERT.

Детальное описание использования бета-распределения с трехкратным методом приведено здесь.

В общем мы рассчитываем вероятность успеть в срок исходя из среднего значения и СКО проекта.

Для нашего проекта получаем следующую функцию распределения:

Читается график так: «Проект будет завершен за 150 AWD с 95 % вероятностью».

Вот небольшая табличка шансов проекта на успех:

Chance of SuccessEffort (AWD)
95 %151
70 %116
50 %101

Если вы сравните со средним значением продолжительности проекта (102 AWD), то поймете, почему не следует просто использовать среднее.

Вот мы и получили вероятностную оценку срока выполнения проекта.

Диапазон оценки

Если вы не уверены во всей этой вероятностной кухне, можете просто давать диапазон значений для срока выполнения проекта, пользуясь следующим правилом:

The 95 % confidence interval for the true project work time is approximately:Project Total Mean ± 2 × Project Standard Deviation

Коэффициент 2 основан на правиле 68-95-99.7.

Для нашего проекта получаем: «Проект займет от 102 до 183 дней».

Можем опустить нижнюю границу диапазона и сказать: «Проект займет от 102 до 157 дней».

Конечно, можно использовать коэффициент 1, получая:

Project Work Time = Total Mean ± 1 × Project Standard Deviation

Но следует учитывать, что в этом случае мы говорим о вероятности окончания проекта в срок, равной 68 %.

Excel Workbook для проекта

Здесь находится Excel Workbook с примером расчетов для нашего проекта. Юзайте с миром :)

Дополнительные требования

Постарайтесь разбивать проект на максимально независимые задачи. Рекомендуется использовать около 20 и более задач для получения более точного результата.

Вывод

Оценка проектов в мире IT далека от точной науки. И так будет продолжаться еще долго. Методология использования трехкратного метода с бета-распределением не идеальна. Но она может дать вам больше уверенности в ваших оценках. Уверенность поможет добиться доверия к вашим словам, а на доверии и держится весь процесс оценки проектов.

P. S.

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

У меня есть подозрение, что это не совпадение. Разработка программных продуктов — крайне волатильный процес. Очень редко в конце мы получаем то, что планировали изначально. Это делает расчет точности оценки практически невозможным. Для отдельных задач это еще реально, но для проекта в целом — едва ли.

Так как же оценивать проекты, чтобы получить верифицируемый результат? Хороший вопрос. Выше я описал несколько вариантов. Также здесь есть пару идей. Но для меня это все еще открытый вопрос.


Благодарю за найденные ошибки Alex Blishun и Roman Kr

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному2
LinkedIn

Схожі статті




44 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

В оцінці потрібно ще врахувати такі фактори:
— наростання кодової бази і її вплив (архітектурний вплив)
— конфлікт змін в кодовій базі (архітектурний вплив)
— рефакторінг по-крупному (архітектурний вплив)
— білд-проекта (більше тестів — більше очикування)
— інтеграційне тестування
— до-задачі (близько 20%) що з"являться пізніше, але без яких не зробити нічого
— навчання як когось, так і себе (близько 5%)
— дуже великий вплив є від інтеграції з іншими сервісами, особливо з такими, про які навіть не чув
— кількість сторонніх залежностей
— популярність фреймворка в основі, його гнучкість, (щоб не шукати по 2 дня, як забрати той зайвий елемент, щоб ще все працювало і щоб не патчити в вендорах)
— на сільки стабільний код (тут взагалі може бути похибка в психіці, або вам прийде задача на маленькі правки, від яких на вас звалять ще пів нерабочої системи, яку замовник сам намагався поправити по FTP)

Ще би я відділив задача на інтелектальні, типові, ризикові і рутинні.
Інтелектальні — це ті, що починаються з *пошукайте самі* ... як розпізнати на фото всі обєкти, які в русі, парсери, криптографія, зберігання інформації, архітектура проекта, технологічні підходи. Тому такі задачі в оцінці будуть виглядати коротко, але з підозріло великим числом годин, через що часто на них концентрують увагу замовники і багато питають, але через брак часу на дослідження вони виглядають як чорний ящик.
Типові — формочки, таблички, crud (80% задач такі, їх багато і їх легко розписувати в оцінці, але через них нивелюється оцінка інтелектуальних задач)
Ризикові — це інтеграції з якимось сервісом, чи надія на бібілотеку, яка дуже популярна, міграція данних в нову структуру.
Рутинні — це наповнення данними.

В залежності від проекта тут можна просто множити на якийсь відсоток, щоб було швидко (якщо легасі проект — можна сміливо просто збільшувати в 2-3 рази, бо це полюбому ні специфікації не знайдеш, або ще попадеш на апгрейд всіх залежностей з заміною на альтернативи).

Ще треба розуміти, що замовник хоче одне, пише друге, оцінку роблять для третього, домовляються за четверте, получається п"яте, тому сказати, що на проекта А ми витратитили N — годин, і на такий самий проект B ми витратимо теж N годин — буде не точно =)

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

Очень полезная статья. Но есть нюанс. Весь мрак кроется в деталях, а конкретнее в составлении требований, построении архитектуры продукта и тд. Если на этапе проектирования и планирования не учтено все до мелочей(до определенного адекватного порога естественно) то сколько времени в буфер не закладывай выйдет натягивание совы на глобус. Потому что не учтенные но важные мелочи собираются в один большой ад в самом конце и оттягивают сроки.
И еще надо понимать риски не только материальные такие штрафы по дедлайну, вылеты из бюджета и так далее, а еще и психологические. Потому как с каждым днем прошедшего дедлайна настроение в команде меняется не в лучшую сторону что сказывается на общей продуктивности. Ок, можно в экстренных ситуациях сидеть по ночам и разгребать это, но потом можно не удивляться почему сотрудники выгорают и сваливают. Прочувствовал это на своей шкуре с одной и с другой стороны «баррикад».

«B — best case (оптимистическая) оценка срока, 95 % вероятности не уложиться в срок.
N — nominal (номинальная) оценка срока, 50 % вероятности уложиться в срок.
W — worst case (пессимистическая) оценка срока, 5 % вероятности не уложиться в срок.»

Хіба тут не переплутані місцями в B та W «уложиться» і «не уложиться»? Має ж бути так: оптимістична оцінка — висока вірогідність «уложиться в срок», а не «не уложиться».

Ні. Під оптимістичною оцінкою вважається найменший можливий час на виконання задачі/проекту. Тому ця оцінка оптимістична. Але при цьому вірогідність вкластися в цей срок дуже мала.

Все хорошо написано. Только сложнее с зависимостями. Если просто задачи одна за другой, то можно просто складывать дисперсии, если считать длины задач независимыми переменными. (Если зависимые, то брать сумму ковариационной матрицы, откуда взять как коррелируют задачи — отдельная тема, если они функционально зависимые, то просто сумма стандартных отклонений). Но если чуть более сложные зависимости, то только Монте Карло спасет. Если иметь его под рукой, то можно и за 3 часа набросать. Хотя для такого плана вряд ли получится покопаться со сложными зависимостями.

Эх, если б это еще работало. А то честный план не нужен, а нужны на самом деле переговоры почти всегда ...

Спасибо за статью!

По неопытности интересует следующий вопрос. Совместима ли такая оценка с итеративной разработкой по Agile методологиям? Требуют ли клиенты оценки готовности проекта, если знают, что разработка будет вестись гибким методом, с внесением нужных изменений каждые 2-4 недели и постоянной интеграцией? И если да, что понимается под «готовым» проектом — его первый выход в свет с минимальным функционалом, какой-то перечень необходимых функций, или ещё что-то?

Совместима ли такая оценка с итеративной разработкой по Agile методологиям?

- в изложенном варианте нет

Требуют ли клиенты оценки готовности проекта, если знают, что разработка будет вестись гибким методом, с внесением нужных изменений каждые 2-4 недели и постоянной интеграцией? И если да, что понимается под «готовым» проектом — его первый выход в свет с минимальным функционалом, какой-то перечень необходимых функций, или ещё что-то?

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

Спасибо за этот обзор. Было интересно увидеть привязку оценки к вероятности успешности завершения проекта.

Уточнение по поводу расчета стандартного отклонения — вы берете квардратный корень от произведения двух сумм, что мне кажется неправильным, т.к. результатом этой операции будет сама сумма. Нас же на самом деле интересует корень из суммы квадратов отклонений по каждой задаче.

Вашу формулу (SQRT(SUM(F3:F36)*SUM(F3:F36))) можно исправить с помощью встроенного оператора Excel: (SQRT(SUMSQ(F3:F36)))

спасибо, ошибка исправлена

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

B < N < W

. Все остальное — это выравнивание случайной выборки этих самых оценок относительного какого-то закона распределения вероятности для того, чтобы можно было дать ответ на вопрос «сколько времени надо приплюсовать к сумме оценок для того, чтобы проект уложился в срок с заданной вероятностью».

Подозреваю, что вы исходите из предположения, что входные цифры вам называют разработчики, т.е. используется так называемая экспертная оценка, однако для того чтобы они вам эти цифры назвали нужно, как минимум: сделать требования → сделать компонентное разбиение → слепить WBS с задачами, которые уже и будут оценивать разработчики в виде B, N и W. Это как-то не тянет на заявленные 3 часа времени :)

Для получения быстрых или т.н. индикативных оценок для проектов используются совсем другие инструменты, хотя бы те же Use-Case Points, которые в последствии можно точно так же выровнять используя PERT или что-то другое.

сделать требования → сделать компонентное разбиение → слепить WBS с задачами,

И получить те же самые оценки, только с чуть более узким stddev. На самом деле действительно точность растет логарифмически от увеличения предложенных усилий, и если надо за 3 часа ответить, то ок, просто надо диапазоны пошире брать.

Хорошая статья, спасибо.

Минорное замечание: Мне кажется в Excel-файле автора в разделе «Chance of Success» формулы в клетках R4 и R5 перепутаны местами (точнее коэффициенты в них перепутаны)

Большое спасибо — ошибка исправлена

не пробовали читать „Software Estimation: Demystifying the Black Art” ? помагает

Занимался оценками проектов несколько лет. Мы использовали следующий подход:

1. Получение базовых пожеланий о проекте от заказчика
2. Построение mind карты требований
3. Написание вопросов (общий, по дизайну, технических и других) заказчику, и получение от него дополнительных данных. Если нужно проведение скайпколов.
4. Систематизация полученных данных
5. Построение mindmap карты проекта
6. Установка взаимосвязей между задачами, и последовательность выполнения задач
7. Выставление сроков по каждой задаче (если нужно консультации с профильными спецами)
8. Учет рисков
9. Построение gantt чарта
10. Формирование Excel таблицы с конкретными часами
11. Выдача полного пакета сейлзам.

Сравнивали разные методы оценок, этот метод давал достаточно высокую точность, до 95%, в том числе и в сравнении, когда проект выполнялся с командой.

Этот метод хорошо работает когда клиент уже вот прям горячий.
А если клиент прохладный, а сроки и стоимость озвучить нужно, пусть приблизительные, но более-менее реальные?

— сколько стоит разработка?
— какая именно разработка?
— ну нормальная такая разработка.
— ну нормально так стоит.
(к)

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

используйте Use-Case Points, быстро, удобно, минимум телодвижений.

> B — best case (оптимистическая) оценка срока, 95 % вероятности не уложится в срок.
> N — nominal (номинальная) оценка срока, 50 % вероятности уложится в срок.
> W — worst case (пессимистическая) оценка срока, 5 % вероятности не уложится в срок.

Идея известная (я её использую давно и уже не помню, откуда взял). Но вот конкретные значения пределов вероятности выглядят странно. 95% это чуть меньше чем две сигмы в обе стороны. Почему именно так? Почему не, например, 25-50-75, или 10-50-90?

Я уточню вопрос.
1. Насколько есть уверенность, что описанная математика универсально годится для качественной аппроксимации времени исполнения с учётом иерархии задач? Все числа, похоже, рассчитаны из какой-то фиксированной модели, типа ровно 1 этапа деления на подзадачи.
2. Насколько можно доверять авторам оценок элементарных задач на настолько крайних уровнях вероятности (5, 95%)?

Насколько есть уверенность, что описанная математика универсально годится для качественной аппроксимации времени исполнения с учётом иерархии задач?

— уверенности никакой) Мат метод не универсальный — зависимые друг от друга задачи им нельзя расчитывать.

Все числа, похоже, рассчитаны из какой-то фиксированной модели, типа ровно 1 этапа деления на подзадачи.

— да, варианты разбития задач на подзадачи данный метод не рассматривает.

Насколько можно доверять авторам оценок элементарных задач на настолько крайних уровнях вероятности (5, 95%)?

— именно для компесации крайних занчений Номинальноме значение учитывается с весом в 4 раза больше крайних. ->
На сколько именно можно доверять крайним оценкам — в 4 раза меньше уровня доверия к номинальной оценке

Описанный метод — это одна ступень эволюции от оценки типа «Ну где-то за месяц справимся». И применение его для иерархических или зависимых задач требует серейзной доработки

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

Хорошее начало для цикла статей. Пишите еще)

К гадалке не пробовали сходить?)

Гадал на кофейной гуще. Не оценили)

Вам когда-то приходилось оценивать проект, о котором вы ничего не слышали, за 3 часа? Мне да.
Что-то, что вы можете предоставить вашему сейлз-менеджеру быстро
Для нашего проекта получаем: «Проект займет от 21 до 183 дней».

Так много написано о паре простых вещей. Оценивать должен человек с опытом. Оценивать стоит оптимистичный ход событий и пессимистичный, а клиенту называть стоит средний прогноз, чуть ближе к пессимистичному. В статье не написано об очень важной штуке — оценку нужно сопровождать предположениями assumptions — и чем их больше, тем ближе вы к написанию полного ТЗ, но защититься себя хотя бы простыми штуками нужно. Например, оценка User Login не включает себя 2-factor, sms и SSO авторизацию, только работа с логинами и паролями в БД самого приложения.

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

В статье не написано об очень важной штуке

 — работв с рисками/assumptions это тема для отдельной статьи)

Однажды одна коллега-пилот, еще только обучаясь, задала вопрос — на каком расстоянии надо задержать штурвал, чтобы создать посадочное положение для самолёта и сесть? Вопрос поставил всех инструкторов и опытных в ступор, потому что нет простого ответа: всё зависит от mass & balance самолёта, скорости, направления и силы ветра, плотности воздуха, превышения аэродрома ....

Это я к тому, что в условиях неполной информации вывести какую-то систему оценки практически невозможно. Все методы и вычисления распределений разобьются о первый же проявленный риск или багу в сторонней библиотеке. И так или иначе как разработчик, автор скорее всего полачается на свой опыт, чутьё и пятую точку, чтобы как можно точнее постараться дать оценку. А все системы и диаграмы — всего лишь красивая, но зачастую бесполезная обёртка.

Да, но в пределах этого чутья такие оценки всё равно позволяют получить результат, приемлемый для администрирования.

Плюс, как известно, plan is nothing, planning is everything.

Все методы и вычисления распределений разобьются о первый же проявленный риск или багу в сторонней библиотеке.

- мой метод по опыту разбивается не о первый, а где-то о третий риск/багу

А все системы и диаграмы — всего лишь красивая, но зачастую бесполезная обёртка.

— бесполезная для непосредственного жтапа разработки — возможно. Но красивые графики и диаграмы могут быть полезны на этапе продаж, рекламы и т.д.

Дядя Боб сделал замечательное видео об эффективных оценках.

Оно настолько же замечательное, как замечательны его знания булей?

Cм. func isWin(_ board: BoardState,_ player: Player) -> Bool в github.com/...​/Gomoku/GomokuRules.swift

Более приближенные к реальности примеры есть? User Login от 10 до 100 дней — это выглядит как-то странно.

почему? или вы не видели систем окроме стандартной form authentication, сколько по вашему займет разработка к примеру SSO

Отсюда и начинаются самые интересные истории «в проекте записано user login а на самом деле там sso».

Есть, не покажу — NDA )

Расчет времени конечно потрясает — разработка страницы контактов не может занимать больше чем главной страницы. Отвечаю — может, если там и интерактивная карта и контактная форма и возможно даже какой нить чат. Нельзя оценивать разработку трех разных проектов по срокам — один пишет быдлокод, второй пытается углубится в абстракции а третий навешивает тесты. Оценка должна зависеть от комплектность/на время... Вообще он(д. Боб) часто путается сам в себе и действует не последовательно и не логично — сугубо личное мнение после прочтения пары его книг...

Расчет времни приведен как пример. Не более.
В статье прикреплена экселька, куда вы можете подставить адекватные по ващему мнению данные

Нельзя оценивать разработку трех разных проектов по срокам

 — при условии, что вы знакомы со стилем вашего написания и стилем ваших коллег — можно

Оценка должна зависеть от комплектность/на время...

— Простите, немного не понял, что имеется в виду под комплектностью

Вообще он(д. Боб) часто путается сам в себе и действует не последовательно и не логично

- никто не идеален)

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

Підписатись на коментарі