There are 999 reasons to become levi niner. Find yours at levi9.com/jobs
×Закрыть

Простой путь

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

Почему так происходит? Тут есть множество объяснений (включая «мир несправедлив и мы все умрем»). Я расскажу об одном из них. Оно не то чтобы полностью объясняет проблему, скорее, является одним из факторов. Этот фактор я для себя называю «простой путь».

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

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

Что же с этим поделать? Ну, вариантов получить более адекватную оценку — масса. На эту тему книги написаны, большие такие. Например, некоторые умножают в два (три, четыре) раза оценку программиста и записывают в план эти страшные цифры. А потом следующий менеджер снова умножит на два, ага. Некоторые детально прорабатывают задачу до начала работы над ней, строят все сценарии и когда все варианты ясны — дают оценку (некоторые потом ее умножают на, скажем, полтора — на всякий случай). Есть и другие способы, они приходят с опытом и посещенными тренингами. Лично мне на данный момент милее всего оценка в попугаях.

Этот способ обычно оценки используется в Agile, в частности в Scrum. Но можно и вне Agile, кто же вам помешает-то. Задачи при таком подходе оцениваются в так называемых идеальных часах или в feature point’ах. И новые задачи мы оцениваем по сути по отношению к старым — старая задача заняла три попугая, эта чуть сложнее, ага, пусть будет пять. И так как старую задачу мы оценивали тоже по «простому пути», то и новую так же оценим. Но посмотрим, что старая заняла 3 дня, значит, эта займет 5 дней, скорее всего. Естественно, чем дольше команда работает вместе, тем оценка становится точнее. Я плоховато объясняю, хорошие объяснения с примерами есть много где, в любой методичке по Scrum как минимум.

Я не хочу тут рекламировать Agile, знаю, у некоторых на него аллергия. Так что если у вас есть свой способ добиваться точных оценок и бороться с оптимизмом оценивающих, то замечательно. А если он еще и стабильно работает, то вообще просто чудесно. Поделитесь, что ли.

LinkedIn

74 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Вот отличная статья про почему оценки отличаются от реальности, рекомендую www.quora.com/...a-factor-of-2-3

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

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

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

Но не стоит забывать простого правила — срыв сроков происходит чаще не из-за неправильных прикидочных расчётов времени, а из-за непредвиденных в плане ситуаций. Метод Agile (упомянутый) смущает тем, что в нём нет анализа/приоритезации рисков. Вероятно, для коротких итераций менее актуальная проблема.

Нет, риски тут не исключаются. В принципе, при оценуе в попугаяъ их можно учитывать.

А подробная оценка с анализом — это хорошо. но слишком уж много энергии и сил требуют.

последние два года в сроках не ошибался. что я делаю не так?

Все так. Keep calm and carry on. Просто не нужно себя экстраполировать на всех.

просто в статье обобщение, вот я и озадачился :)

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

Избавиться от write lock-a в монгодб

мне кажется автор статьи имел в виду несколько другие задачи.

А какие такие задачи имел в виду автор?

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

PS. Ускорить пробовали?

оценки времени вредны всем. особенно «точные»
вот берем некую задачу, которую, ну по максимуму неделю делать, и требуем у качественных (это важно) программистов оценить — кто-то скажет 3 дня, кто-то 8 дней (1.5 недели)
допустим менеджмент не вмешивается (хотя реально может и потребовать за 2 (5) дней сделать)
дальше начинается работа — тот что сказал 3 дня будет пытаться попасть в эти 3 (а то и 2 дня) — дальше либо недостаточная проработка вопроса, либо выход за сроки, с комплексом студента и прочими плюшками
тот что сказал 8 дней — будет делать более спокойно и качественно ну и за 5 дней сделает, дальше, в зависимости от, может начать страдать излишними фичами и беспощадным рефакторингом

в обоих случаях результат будет не торт

а теперь возьмем модель построенную на доверии — никаких предварительных оценок, оба решают задачу за неделю с достойным качеством и все довольны

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

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

так тут просто — испрашивать\выдавать две цифры предварительного прогноза — оптимистическую и пессимистическую ну и пересматривать их с течением времени.

Да, это верно. Поэтому если оценка не необходима (например, это саппорт), нужно просто сидеть и работать. Для этих целей лучше подходит Канбан, а не Скрам, например.

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

Относитесь к неопределенности как к погрешности измерений. Да, можно дать очень конкретную дату, только погрешность до начала проекта — порядка 400% по некоторым оценкам. Ее нельзя уменьшить без дополнительной информации. Например, детального анализа, или прототипирования. То есть, фактически, начала разработки. Так ее можно уменьшить вплоть до полной определенности — в момент выпуска продукции.

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

Про творчество — очень спорное заявление. Другие инженеры, значит, ремесленники, а программисты — Творцы?

Что, обидно за инженеров? )

Любые инженеры испытывают ровно те же проблемы в сходных условиях — нетиповые проекты, меняющиеся технологии, меняющиеся требования, 23-летние синьоры.

Это все 5-10% работы. А в каком-нибудь аутстаффе хорошо если 1-2%. Остальное, увы, ремесло.

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

Программисты как раз ремесленники. И даже работают артелями. :-)
Как раз ремесло и есть творческое ручное производство (вольный пересказ википедии)
Ручное здесь — не конвейерное, не автоматическое.

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

Представьте, что вы ставите задачу поэту

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

Программисты тоже умеют писать программы в заданные сроки, представьте себе.

Я и не опровергаю. Поэты — неудачный пример творчества. 1% творит, 99% ремесленничает. «I am the 99%» ! :-)

Кроме того, есть огромная разница между «сделать что-то к заданному сроку» и «достаточно точно оценить, сколько времени займет разработка того-то».

Я иногда предлагал девелоперу оценить: сколько понадобиться времени, чтобы произвести более-менее внятную оценку по времени =)

Но что делать с тем, что заказчику нужно посчитать бюджет, хотя бы приблизительно?

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

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

Умножить эстимейт не так уж и глупо. Читал про проектирование мостов — после анализа, рассчета нагрузок и материалов, оценки умножались на коэффициент 5-6. Это коэффициент, в который заложена неполнота наших знаний об окружающем мире, природных явлениях, неясности в поведении людей и т.д. В бизнес-задачах, которые не то, чтобы решить, сформулировать зачастую невозможно, неясностей не меньше, чем в стоительстве мостов. Можно сначала взять «с запасом», потом уточнить оценку, ошибиться, снова уточнить, и такой «синусоидой» прийти к более-менее точным оценкам. А затем сменить проект или команду — и начать процесс заново :-)

Все равно, это та же интуиция. Если ее пока нет, можно пойти к опытному дэву(или к нескольким) и воспользоваться его(их) интуицией. Все остальное субъективно. Как определить сложнее задача или нет, в строчках кода?... как определить единицу измерения...

Единица измерения-то есть — functional point (плюс есть формальные правила подсчета поправочного коэффициента в зависимости от порядка 15ти параметров проекта). Только почему-то в родных пенатах я еще не видел никого, кто бы ей реально пользовался, хотя, покопавшись немного в теме и попробовав оценку в функциональных точках на практике, могу сказать, что в ней нет ничего экстра-сложного.

«Проблема в том, что в мире есть только человек 10-20, которые понимают как пользоваться function points» — не помню чья цитата, но примерно согласуется с моим опытом :)

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

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

С трудом представляю себе как можно было бы использовать function points, например, при создании игр первого эшелона.

«Проблема в том, что в мире есть только человек 10-20, которые понимают как пользоваться function points» — не помню чья цитата, но примерно согласуется с моим опытом :)

Ты знаешь, слегка подразобравшись с вопросом, хочу сказать, что сложность и непонятность function points сильно преувеличены. ИМХО единственный сложный момент — это определить, какие бизнес-сущности являются зависимыми, а какие-нет (от этого зависит количество ILF и RET). Да и то, на этот случай есть эвристика — сомневаешься, считай сущности независимыми.

Все остальное — вопрос «набивания руки» в правилах подсчета и подспорья в виде софта (тот же Function Point Modeler).

С трудом представляю себе как можно было бы использовать function points, например, при создании игр первого эшелона.

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

С трудом представляю себе как можно было бы использовать function points, например, при создании игр первого эшелона.

так же как и забивать гвозди микроскопом — легко.

FP не серебряная пуля, этот подход к оценке надо применять в подходящих случаях, а не где вздумается. Главное что он работает, если ТЗ не состоит из слов «сделать красиво» в том или ином выражении.

Вопрос — на сколько точно можно расчитать эстимейт пользуясь functional points? Какова допустимая погрешность в процентах? И стоит ли исходя из ответа применять эту методику?

Все остальное — вопрос «набивания руки» в правилах подсчета и подспорья в виде софта (тот же Function Point Modeler).
Опять вернулись к интуиции, опыту? Получается, что эти functional points — способ придать видимость строго математического подхода своей же интуиции и опыту... Чтобы было, что сказать заказчику умное?.. Зачем еще использовать формализированный метод, если расчет единицы измерения, все равно, субъективен?

на сколько точно можно расчитать эстимейт пользуясь functional points? Какова допустимая погрешность в процентах?

Зависит от трех факторов:

  1. Степень детализации требований (тот самый «конус неопределенности» МакКоннелла) — собственно, этот фактор от конкретной методики подсчета не зависит
  2. Опытности оценщика
  3. Достоверности статистических данных о производительности для данной компании и, желательно, данного типа проектов

Опять вернулись к интуиции, опыту? Получается, что эти functional points — способ придать видимость строго математического подхода своей же интуиции и опыту...

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

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

Как Вы думаете, ее стоит применять?

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

Потому что сложная — да. А вот насчет выгод, я бы все же не согласился. Метод функциональных точек дает четкий и однозначный ответ, почему фича A оценивается в X «попугаев», а фича B — в Y «попугаев», в то время как planning poker и иже с ним — это экспертная оценка, которая по определению менее точная.

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

Да и в fixed price контрактах, в идеале, можно фиксировать scope именно в функциональных точках.

необходимы серьезные навыки, критерии оценки которых, все равно, субъективны

Почему же субъективны — например, у IFPUG есть вполне себе формальный сертификационный экзамен. А функциональные точки в редакции IFPUG использовать разумнее всего, т.к. именно к ним чаще всего привязаны всякие полезные метрики в проф. литературе

Рецепт применения крайне прост:
1. Читаете что такое FP
2. Считаете/Накапливаете данные по завершенному продукту (время, человеко-месяцы, FP для продукта)
3. повторить п2 для двух-трех-десяти.
4. Считаете усредненные показатели (производительность например, при определенном желании можно даже график построить)
5. Считаете FP для завершенного продукта n+1
6. Оцениваете его по выбранной методике. (здесь та еще «магия» на первый взгляд)
7. Сравниваете временную затратную оценки с реальными данными. Это даст вам понять насколько точно калиброваны данные из пп. 2-3-4 и корректно выбран метод оценки в п. 6.
8. Корректируете пп. 2-3-4-6. (опционально)
9. Оцениваете будущий продукт в FP и считаете все временную и затратные оценки на основе данных из ранних пунктов.
10. ????

11. PROFIT

Это если вы не накапливали данные и метод не применяли. Следующие продукты стартуют с п. 8.

Субьективности здесь не так уж и много места. Так же можете воспользоваться софтом Construx Estimate — сильно поможет на шаге 6. И вообще читать Стива Макконнелла.

Из моего опыта данная методика позволила добиться 10% точности оценки от фактических затрат (как на шагах 5-6, так и на 9).

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

Как видно особо сложного ничего нет, ПМам и, возможно, БА надо всего лишь поднять свои задницы с удобного диванчика и начать выполнять свои прямые обязанности, ну и напрягать извилины конечно же.

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

PMBOK (например) описывает методики оценки (parametric, three-point-estimate, .... etc), поэтому можно не изобретать велосипед.

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

Быть абсолютным профессионалом в оценках не получится — тут и технологии разные, и проекты разные. Если у компании один продукт — например, Magento, и движок используется для интернет магазинов, то здесь проще. То есть если вы набили руку в оценках в веб-технологиях, это не означает, что сможете оценить embedded-проект.

Для этого и придуманы инструменты, помогающие снизить риск недо-, пере-оценки.

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

PMBOK (например) описывает методики оценки (parametric, three-point-estimate, .... etc), поэтому можно не изобретать велосипед.

PMBOK это как библия, читать полезно, но практики из него не почерпнешь.

Собственно выше была описана методика как пользоваться функциональными точками, не более и не менее. Как к этому относится PMBOK, исключая общетеоретические изыскания, — загадка.

Т.е. каждый оценивает СВОИ задачи в проекте.

т.е. каждый на год вперед знает что будет делать?

Быть абсолютным профессионалом в оценках не получится

Абсолютный профессионал — это кто? тот кто абсолютно зарабатывает деньги оценками?

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

я про микроскоп не зря писал.

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

ну этот опять же, выше описана методика использования метода оценки, его использование не запрещает и не регламентирует другие методики.

Если же затрагивать упомянутую вами тему нескольких источников оценок, то да, полезно привлекать и экспертную оценку. Как результат сравнивать несколько методов и в случае больших различий (пусть будет 20% и более) — искать кто, где и почему врет. Именно поэтому я упомянул «напряжение извилинами».

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

Тяжко сказати скільки мені часу потрібно, щоб заговорити на Хінді.
(Хінді!? Що це за мова така? Там є алфавіт? Ірогліфи? ...)
1) Оцінювати типові задачі(з якими ти вже стикався) простіше.
Інша справа німецька. На англійську я витратив 3 роки, тобто можна припусти, що стільки ж
потрібно і на німецьку. З іншої сторони я вже знаю іноземну мову з тієї ж групи, плюс мій досвід
навчання в принципі, тобто можна розраховувати на скорочення терміну до 2-х років. Але в той же час, англійська це баласт, дві мови можуть просто перемішатися в голові. Тоді +1 рік, а разом 4 роки.
2) 3-point estimate — коли задається три оцінки
* Оптимістична(Це займе не менше х часу)
* Реалістична(Це займе 1,5*х часу, якщо виникнуть підводні камені)
* Песимістична, він же дедлайн(Це буде виконано обовязко за 2*х)
Можна взагалі відмовитися від таких глобальних оцінок, а просто запланувати
оволодіти базовим рівнем за 6 місяців, а тоді на основі зворотнього звязку
планувати наступний рівень

3) Розбивка плану на послідовність кроків

І головне, девелопери не ворожки. Не очікуйте від них передбачень з точністю

до години.

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

а какие здесь есть нормальные варианты кроме отрезания фич через расстановку приоритетов? за счёт чего ещё можно уменьшать эстимейт?

отрезания вполне достаточно, это мощнейший инструмент

Я бы разделил задачи на «точно сделаем», «постараемся сделать» и «сделаем разве что чудом». И попытался бы объяснить такое вот разделение заказчику.

он бы все равно все понял как «сделаем»

Не ново, но полезно.

На ошибки с эстимированием как developer-ы так и QA-и (а в результате и Менеджеры) наступают годами. И так будет всегда, в той или иной степени.

От себя добавлю что описанный выше способ (попугаи в Agile/Scrum) — прекрасен, но может работать не всегда, а в некоторых случаях — даже «никогда», например когда контракта по сути еще нет и надо сделать предложение клиенту по сути до того как что-то было написано, протестировано и так далее.

отнюдь. Если уже есть команда, то она может давать оценки на основе своего опыта с предыдущих проектов. Если непонятно что делать, то сначала делается прототип или proof-of-concept проект, который показывается заказчику (отдельный контракт, таймбоксед), после чего уже можно планировать основной проект.

Если уже есть команда
А если команды нет? — Читай — она формируется каждый раз по новому исходя из свободных человеко-ресурсов — тогда как?

«Гиви, я не пойму: ты за меня, или за медведя?» © анекдот

Ну эти люди они как, до этого были дворниками? Не делали никогда типовые задачи? Абсолютно новый проект? Вообще-вообще? Точно? А если подумать? :-))

Да ладно Вам, не поясничайте :)

Прекрасно же поняли о чем я говорю.

Если бы схема так работала всегда то человек что сделал и сдал 2-3-4 проекта в комбинации с другими такими же «человеками» которые формируют новую команду делали бы сверх точные эстимейшены постоянно — но это почему-то до сих пор не происходит ни в одной из компаний! ;)

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

сверх точные эстимейшены постоянно

10% — это сверхточно, по вашему мнению?

уточню:

10% отклонение оценки от фактических трудозатрат — это «сверхточно»?

Зависит от ситуации конечно: величины проекта, типа контракта, позиции клиента, сроков, отношения клиента к «additional» работе и многих других условий!

Но в общих чертах, ИМХО, 10% погрешности в Estimation-е проекта (если это делается до физического старта проекта, — по спецификации и другим документам) — это более чем прекрасный результат!

вы не путаете «точность» и «достоверность»?

до физического старта проекта, — по спецификации и другим документам) — это более чем прекрасный результат!

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

Так вот возвращаясь в контекст — 10% от фактических трудозатрат по оценкам разработчиков (для любых масштабов задач (пусть от 2 часов до 2 лет) — это «сверхточно»?

Так вы оцениваете в попугаях или все же в идеальных днях? «Старая заняла 3 дня..» — это ж Вы явно не идеальные дни имели ввиду, а фактически). «.. эта займет 5 дней, скорее всего. ...» а это уже идеальные дни? Мне кажется у вас там не такой уж простой путь ))
Вообщем что я хочу сказать своим придирством: Простой путь это мерять именно попугаями, где один попугай это тот ОБЪЕМ работы , который нужно сделать чтобы выпустить всем понятную в команде фичу, например. ВРеменнными единицами лучше не мерять , т.к. даже этот один и тот же попугай — один дэв сделает за день, например , а более опытный в команде сделает за полдня. Вот и пошел кривой путь )) .
Я часто люблю проводить аналогию с кучей зерна (в отличии от попугая и удава , мне кажется она более понятна) : представим что новая фича, которую нам нужно оценить — это куча зерна, у нас есть ведро , с помощью которого нам нужно перекинуть эту кучу в амбар, ведро — это один стори пойнт, и вот нам нужно прикинуть сколько примерно ведер в этой куче ? Понятно что один программер одно ведро наберет и отнесет за x времени. а другой это же ведро за 2x. Но это не важно, главное в среднем знать сколько ведер команда перелопачивает за 2 недели , всмысле за спринт.

ВОт это простой путь.

Хенрик писал в своей первой книге Скрам с передовой а то что меряем в идеальных днях. Но при этом в оценку он надо вводит понятие фокусфактора , который собсвтенно и показывает степень неидеальности вашего дня ))

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

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

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

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

Оце і є суть аджайла?

Нет, в Agile про оценки вообще ничего нет.

Вы пошутить хотите или действительно разобраться?

Дякую, уже розібрався. А шутить я не вмію, це ви (?) правильно зауважили.

На самом деле, в Скраме есть много интересных идей, не только про оценки.

аджайл вообще малоэффективен по поводу оценок

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

Другой вопрос, что можно это понять, и научиться с этим жить.

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