Релокейт-опрос 2017 (для тех, кто уже уехал). Собрано более 1500 анкет.
×Закрыть

Как оценить часы на разработку

Вероятнее всего, кто-то уже набил на этом руку, ну а для кого-то вопрос оценки продолжает оставаться pain in the ass. Процесс оценки — коллективный. Помимо того, что оценка включает не только разработку, еще и сама первичная оценка, полученная от разработчика, часто претерпевает изменения перед отправкой клиенту. Один мой знакомый товарищ даже искренне верил, что менеджмент набрасывает часы «чтобы сбить бабла с клиента». (Спойлер: он был неправ)

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

— How much would it take to create a WP website?
— 400-500 hours

— I need to fix this bug immediately!!!
— That would be 500USD

— Can we include this story?
— Yes, it’s 5 pts.

— When will you push update to the staging server?
— By the end of the week!

Однако, сложность заключается в абстрактности работы, часто в непредсказуемости объема, в размытости требований и, по сути, в том, что эту работу вы будете делать в первый раз, потому что каждый проект — уникален.

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

Кроме того, учитывая абстрактный характер работы и перфекционизм, присущий многим, программирование стремится занять всё отведенное на него время: всегда можно бесконечно что-то улучшать, рефакторить, переделывать. Вы оценили работу в «две недели», базово сделали за три дня, оставшееся время ушло на улучшения, в итоге заняло две недели.

Также любая оценка — субъективна. Она зависит от опыта, от уровня владения технологией, от того, в каких проектах девелопер участвовал.

Из последствий непопадания в оценку:

  • срыв планов релиза;
  • дефицит бюджета;
  • овертаймы;
  • убытки для компании (в случае заказов с фиксированной ценой);
  • недоверие и нелояльность клиента (если оплата почасовая);
  • стресс всем по цепочке.

Давайте рассмотрим, какими методами можно бороться с проблемой некорректной оценки.

I Классические приёмы

1) Poker estimate
Собирается группа девелоперов, озвучивается задача, все эстимейтят втихаря, потом сравнивают. Авторы самого большого и самого маленького значений обосновывают свою оценку. В конце нужно прийти к общему мнению.

2) Сравниваем с похожими уже сделанными задачами
Причем не с тем, что оценивали, а тем, сколько получилось фактически.:) Есть еще complexity factor, если делали что-то похожее, но легче/проще. На фактор умножаем.

3) Bottom up & top down
Первое — берем (или делаем) декомпозицию задачи и оцениваем каждую подзадачу, потом суммируем. Второе — пытаемся оценить задачу целиком. Если между двумя значениями большая разница, пытаемся понять, откуда эта разница.

4) Сторонняя экспертиза
Приглашаем Василия из соседнего отдела, просим прикинуть и сравниваем со своей оценкой.

II Лепта менеджмента

5) Риски
15-20% накидываются сверху на риски. Обычно, самые сложные или самые непонятные части системы и будут самыми рискованными, поэтому, если уже есть декомпозиция, можно накинуть только на эти части. Обычно риск постфактум звучит как «в процессе разработки выяснилось, что придется переделать структуру БД».

6) Не весь ресурс
Считаем, что есть только 80% ресурса. Т.е. у Василия в рабочей неделе 32 часа, а не 40. Но эти 80% применяем не к самому эстимейту, а к планированию дат. Т.е. оценку вы даёте в 40 часов, но готово будет через 6 рабочих дней. Подстраховка от больничных и прочих неожиданных моментов.

7) Out of scope
Требования имеют свойство обновляться и добавляться, это нормально. Ненормально считать, что первоначальный эстимейт их покроет. Проапдейтились требования? Ок, that’s great, here’s the updated estimation which includes this new feature.

8) Статистика
Авторы в Managing the Unmanageable ссылаются на то, что девелоперы, в среднем, кодят 55% от своего времени. Остальное уходит на коммуникацию с менеджментом, коллегами, тестировщиками, дизайнерами, клиентом; на code review и менторинг и на переключение между задачами. А в проекте, в целом, 1/6 времени уходит на первичное написание кода, а 1/2 на тестирование и багфиксинг.

III Выведено из практики

9) Честно вовремя признаться
Это нормально, что в процессе работы первоначальная оценка будет уточняться. Чем больше вам подробностей известно, тем точнее вы знаете, сколько времени понадобится. И чем раньше выясняется, что поменялся предполагаемый объем работ, тем лучше. Можно обсудить с клиентом, как урезать скоуп, поменять ожидаемую дату или добавить еще разработчика. В идеале, неуспевание на ранней стадии должен заметить PM, но на практике нужен еще и инпут от программиста. Особенно актуально, если процесс в компании прихрамывает или у лида/проджекта нет времени каждый день узнавать, как дела. На моей практике, самое безобидное «сейчас заканчиваю» длилось с восьми вечера до трех ночи. Может на неделю растягиваться, каждый день в стадии «сейчас, разворачиваю». Если станет известно на ранней стадии, очень много шансов выйти сухим из воды.

10) Индивидуальная скорость работы
Довольно редко проектом занимается только тот человек, который его оценивал. Были случаи, когда оценку давал один девелопер, а проект делал другой. Поэтому обычная практика — оценивать по средней мидловой скорости.

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

12) Коммуникация
Включайте в эстимейт время на общение с коллегами. Вспоминайте, сколько раз приходится что-то спрашивать и уточнять и сколько раз самому отвечать на вопросы. Запросто, что час в день.

13) Разрыв между значениями
Во-первых, дается два или даже три варианта оценки. Два — это от N и до M, три — оптимистический, реалистический и пессимистический. Во-вторых, не стоит делать разницу между нижней и верхней границами больше, чем 20%. Эстимейт 200-1000 часов испугает всех. Такой большой разрыв допустим, если всё очень плохо с требованиями или поведение какой-то сторонней библиотеки или сервиса непредсказуемо.

14) Ничего не забыли? Для клиента может быть очевидно, что включено:

  • аналитика,
  • тестирование,
  • менеджмент,
  • дизайн,
  • code review,
  • юнит тесты,
  • документация,
  • мануалы,
  • автоматизация,
  • саппорт IE6,

поэтому явно пишите, что эстимейт включает, а что — нет.

IV Пример

Оцениваем сайт на WP, где будет лежать несложный контент, а у юзеров будут свои аккаунты. Платежей нет, особых фич для залогиненных товарищей тоже нет. Нужно подготовить rough quote для клиента.

  • Обращаемся к профильному лиду, экспертное мнение 200-300 часов.
  • Добавляем 15% на риски: 230-345 часов.
  • Понимаем, что один лид проектом заниматься не будет, а у других ребят скорость отличается. Пусть на 1/4, получаем 288-431.
  • Плюс коммуникация, 20-30 часов: 308-461.
  • Делим на 6.4 часа в день и получаем 2-3 месяца разработки.


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

LinkedIn

Лучшие комментарии пропустить

Заложена ли ошибка планирования в человеческой природе? Исследователи провели эксперимент, предложив студентам назвать время, необходимое им для завершения диплома. В одном показательном тесте группа разделилась на оптимистов и пессимистов: оптимисты обещали закончить за двадцать шесть дней, пессимисты — за сорок семь. На самом деле на завершение работы потребовалось в среднем пятьдесят шесть дней.

Срок выполнения любого проекта по Бобуку-Бацек
pbs.twimg.com/...media/CNRsMteVEAAqy9j.png

А это, батенька, уже рынок. «— Конкуренты? — You’re mostly welcome, good luck».
Лет 12 назад, по зеленой неопытности я рассуждал примерно так же как вы. Выкручивал квоуты как угодно, лишь бы попасть и получить клиента. Накинуть? Ой как бы клиент не отпал. Ничего хорошего не вышло — либо клиент оказывался редкостным муднем, либо просто откровенным кидалой, зачастую неимевший даже денег расплатиться по факту. Ретроспективно, выгоднее как раз браться за клиентов, готовых платить по адекватной оценке, и лезть из кожи, выдавая лучшее качество на которое только способна команда.

это еще хорошо поставлено дело в компании!
а так — 5.

чтобы 8 часов в день — это 10-11 часов в офисе.

Все советы сводятся к списку причин «накинуть» на оценку. Накинуть на риски, на неопределенность, на «миддла», на среднюю занятость, на коммуникации, на менеджмент, и так далее.

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

Поэтому все эти чудесные советы рассыпятся о «а почему так дорого, мне ваши конкуренты предлагают вдвое меньше». Не, «почему» — понятно, вон и список есть, почему. Но только это не про точность, а про прикрытие жопы. Так что клиента при продаже, увы, не впечатлит...

217 комментариев

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

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

сайт на WP, где будет лежать несложный контент

Несложный сайт на полном готовых решений Wordpress — за 2-3 месяца.
Это кричит о том, что методика оценки категорически ошибочная. Либо неверно построены процессы.

300-450 часов по $20 за час = $6000 — $9000 за сайт

Поделитесь, где вы находите заказчиков, готовых платить такие деньги за такой простой сайт? :)
Вы можете в методику впихивать сколько угодно параметров, но есть объективная реальность — рынок — заплатит ли кто-то за вашу работу со всем учитанным и просчитанным про запас.

В «несложный» сайт обычно добавится неделя-другая выяснений на дизайн, например. Потом какой-то готовый плагин не устроит, потому что не может делать так, как клиенту нужно. А потом у кого-нибудь из начальства клиента при демо разъедется лейаут, и ни у кого это больше не воспроизведется. И в случае, если вы «по-рыночному» пообещали за месяц всё сделать, придется еще два месяца потом клиента инвойсами расстраивать. Поэтому надо стремиться к равновесию, где и эстимейт укладывается в рамки разумного, но и не сильно оптимистичный.

Все что вы описали — относится к правильному составлению и согласованию ТЗ. И не относится к оценке «часов на разработку».

Все что вы описали — относится к правильному составлению и согласованию ТЗ
да, в идеальном мире — на проработку ТЗ выделяется до 20% всего времени, и ни одна строчечка в нем не меняется до полного запуска.
вам повезло, если живете в таком мире.

мне вот за 20+ лет не везло ни разу. ни на одном из проектов такого не было. а уж в «вебщине»...

так что в целом я согласен с подходом Julia Romanenkova

В утвержденном ТЗ ни одна строчка не меняется. Иначе потом не найдешь концов — кто прав, а кто виноват.

Если нужны изменения в ТЗ — а такое происходит в любом проекте — составляется дополнение к ТЗ. Фактически ТЗ на дополнительные задачи. Оно же и оценивается дополнительно.

а такое происходит в любом проекте
и в вашем идеальном мире тоже? мдя, сансара везде...
Фактически ТЗ на дополнительные задачи. Оно же и оценивается дополнительно.
а какая разница по сути — изменяется то ТЗ или не то :)

вобщем раз и в вашем мире все подвержено изменениям, то непонятно на что вы подразумевали под "

относится к правильному составлению и согласованию ТЗ.
"

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

Иначе потом не найдешь концов — кто прав, а кто виноват.
а вести надо проект — грамотно. а не надеяться на буковки в ТЗ.
если не отслеживать изменения — концов по правильно составленому и согласованному ТЗ тоже не найти.

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

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

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

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

Планирование и ТЗ — это создание карты местности проекта. Необходимое условие, но — не достаточное.

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

А вообще ТЗ как монолитный документ уже прошлый век. В эпохи вот этих всех ваших эджайлов и наличии овер 9к инструментов для красивого сторимаппинга, гонять с клиентом вордовский файлик с тысячью правками является тем еще моветоном.

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

Работа производится циклами — предварительная сдача проекта/этапа — получение пожеланий клиента — составление дополнения к ТЗ из этих пожеланий, потом их внедрение. Следующий цикл — получение пожеланий клиента после внедрения новых правок, если еще есть пожелания — составление дополнительного ТЗ.

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

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

P.S. И гонять вордовский файлик с клиентом не нужно — есть прекрасный Google Drive с совместной работой над документами и даже комментариями для любого абзаца или слова. Странно что вы до сих пор об этом не знаете :)

P.P.S.Причем ТЗ пишете вы, а клиент может только читать и комментировать. И тогда везде порядок и все довольны.

P.S. Уже даже это прошлый век =).

Отличная аргументация!!! Сразу чувствуется профи.

Oh come on, я пошутил =) Мы всё делали через Google Docs/Spreadsheets с 2008 года, хотя и до этого у нас была внутренняя тулза с комментариями для любого абзаца (2003-4 годы).

Сейчас эффективнее/легковеснее всего делать это через одно из перечисленного ниже, зависит от размера проекта.
storiesonboard.com
www.featuremap.co
trello.com — только требуются прямые руки и один екстеншн на кастомные поля.
marketplace.atlassian.com/...t-storymap/cloud/overview

У нас на начальном этапе лучше всего прижился Trello как ни странно и Storiesonboard.

Все что вы перечислили — это прежде всего инструменты реализации задачи, т.е. внутрикомандные.

Я же говорю о работе с заказчиком (т.е. постановке задачи). Составление документа, согласно которого заказчик будет принимать и оплачивать выполненные работы. ТЗ — это фактически детальный счет к оплате, как в ресторане.

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

Даже Google Docs для многих заказчиков это проблема. Для половины заказчиков наиболее удобный вариант общения — по телефону. Если вы им покажете Trello, они вас пошлют матюками.

Странно, но довольно часто так и бывает — мы общаемся, я делаю заметки и набрасываю предварительное ТЗ (ненавижу это слово, тк отдает совком) очень часто именно в Trello. Еще не было ни одного клиента пославшего — наоборот, они быстро въезжают, комментируют, создают свои карточки, атачат примеры. Довольно быстро это всё полируется, приводится в строгий вид user/job stories или use cases для более сложных фич, оценивается, утверждается и переносится уже непосредственно в среду ведения проекта, где еще раз утверждается.

ИМХО, для успешного выполнения задачи оценки проекта необходимо понимать, что такое проект, как происходят те или иные работы на проекте, что может случится или не случится и т.п. Дальше нужно стремится к тому, чтоб «считать», и уж если вариант «считать» не доступен, пытаться угадывать, сравнивать и все остальное.

5) Риски
15-20% накидываются сверху на риски.
Подобные фразы обычно показывают непонимание того, как происходят работы на проекте, или того, что такое риски. Накидывать 15-20% на любой проект — это сказать «добавим 15 минут, чтоб сотрудник добрался из дома до офиса» — фраза ни о чем (какой сотрудник, где он живет, на чем добирается.... все очень зависит).

Риск — это событие, которое может случится или не случится с определенной долей вероятности. Например, мы планируем использоваться готовую библиотеку X для решения нашей задачи. С этой библиотекой мы не работали, только читали документацию и думаем, что она работает так, как нужно нам для нашего проекта. НО: у нас есть риск, что на деле библиотека работает не так, как нужно нам. Если наш риск «стрельнет» и окажется, что наша библиотека работает не так, что мы будем делать? Например, мы решаем в этом случае реализовать нужный функционал самостоятельно без помощи готовых библиотек. Сколько в этом случае нам нужно будет времени на реализацию с нуля? Предположим 40 часов, а прикрутить готовую библиотеку 16 часов. Отсюда получаем, что на данную задачу наша оценка 16-40 часов, или же 16чч + 150% рисков.
Конечно не по всем задачам будут такие риски, по каким-то они будут меньше, по каким-то их вообще не будет. Это не полное описание оценки рисков в эстимейт, суть описания в том, что размер рисков на проект — это не какая-то абстрактная магическая величина, для каждого проекта это конкретная цифра, которая получается путем анализа и оценки отдельных рисковых ситуаций.

6) Не весь ресурс
Считаем, что есть только 80% ресурса. Т.е. у Василия в рабочей неделе 32 часа, а не 40. Но эти 80% применяем не к самому эстимейту, а к планированию дат. Т.е. оценку вы даёте в 40 часов, но готово будет через 6 рабочих дней. Подстраховка от больничных и прочих неожиданных моментов.
Наверное все слышали про реальные и идеальные часы, но многие не понимают как их правильно прикрутить к проекту, как в данном случае.

Идеальные часы — это часы, которые вы тратите исключительно на работу, т.е. не ходите в туалет, не пьете кофе и т.п.
Реальные часы — это идеальные часы + все остальные отвлечения, без которых человек просто не может работать, он же не робот.

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

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

1. согласна по поводу анализа рисков, чем больше времени есть на оценку, тем точнее можно их определить. абстрактные 15% — это на high level
2. тут мы имеем 40 реальных часов и 6 дней, за которых будет потрачено 40 (а не 48) часов. Это на случай внезапного отгула, больничного или необходимости Василию два раза по полдня отвлечься на другой проект

Например, мы решаем в этом случае реализовать нужный функционал самостоятельно без помощи готовых библиотек. Сколько в этом случае нам нужно будет времени на реализацию с нуля? Предположим 40 часов, а прикрутить готовую библиотеку 16 часов. Отсюда получаем, что на данную задачу наша оценка 16-40 часов, или же 16чч + 150% рисков.
Конечно не по всем задачам будут такие риски, по каким-то они будут меньше, по каким-то их вообще не будет. Это не полное описание оценки рисков в эстимейт, суть описания в том, что размер рисков на проект — это не какая-то абстрактная магическая величина, для каждого проекта это конкретная цифра, которая получается путем анализа и оценки отдельных рисковых ситуаций.
Смотрите как получается даже в вашем собственном примере вы «оценили» «риск» как +150% хотя на самом деле это +1 риск и именно это есть «размер риска на проект — абстрактная величина» потому как точный анализ риска в данном случае вы не проводили и точных значений сколько именно нужного функционала придётся реализовать самостоятельно у вас нет а появятся они только по факту попытки прикручивания библиотеки либо же ж экспертной оценки уже по запросу у эксперта по этой самой библиотеки риск 1 (один) оценка абстрактная типа «предположим» а «оценка» +150% рисков уже сделана неправильно потому как это уже не «риск» а чистый провтык простите при планировании и выборе инструментов для решения.

Потому как в данном случае «риск» отдельно а «оценка реализации риска» отдельно и вот она как раз должна быть более точной хотя бы на уровне тех самых +/-20%. Иначе это и не «оценка» никакая.

Конечно в данном случае речь идёт о конкретном примере чисто техническом в других вариантах уже больше организационных рисками выступают почти всегда «не вполне ясные требования» и тогда таки да действительно «оцениваем на глаз +/- 150% (это ещё и мало) и у нас есть библиотека может она подойдёт а может и нет но поскольку данных нет точнее дать оценку нельзя чисто технически» но это уже совсем другая история.

Мораль именно в том что в случае с «библиотекой» на самом деле никакая «оценка рисков» произведена не была и таки да так тоже очень часто бывает «как это в вашей системе нет половины нужного нам функционала!? но зачем же ж вы сразу не сказали ещё полгода назад!? как это вы сказали но выдали эту хрень простите за фичу!?» (к) (тм)

ЗЫ: «история за реальные часы» ерунда реального обсуждения не стоит...

Проблема в невозможности оценки реальных часов.
Можно только идеальные оценить.

Проблема как раз в существовании только реальных часов =)

Вам, как команде, нужно знать свой waste rate и использовать его при оценке. Это может происходить неявно (когда люди при оценке реально учитывают, когда та или иная фича может быть готова), либо явно (когда все понимают, что оценили идеальные условия), и оценка делится на какой-то baseline. Эмпирически, хороший baseline для несработанной средневзвешенной команды — 0.7, т.е. рассчитывайте, что люди смогут эффективно работать 5,6ч в день.

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

Ты неправильно понял, понимание waste rate никак не связано с рисками. Отдельно — считаем риски, отдельно — считаем эффективность работы команды.

В случае новой либы, в зависимости от масштаба «самому писать» (5,10,50,200% от остальной дистанции проекта), имеет смысл либо заложить это как риск (если мало), либо явно сказать, что риск сильно большой, и сначала нужно выполнить прототип (и его оценить).

Короче — оценка рисков != оценка с учетом потерь

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

Ты читаешь?) я же не говорю, что риски невозможно предсказывать, я говорю, что это ДРУГАЯ активность. Идеальные/реальные часы к рискам никакого отношения не имеют.

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

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

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

Именно так.
И вот вся неопределенность здесь:

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

Полность согласен, и, соответственно, разница в реальных часах и идеальных часах ПРИ ОЦЕНКЕ возникает из-за (темпа работы, перерывов на кофе, чесания за ухом или еще где) но не из-за нашего недостаточного понимания задачи. Посему их можно и нужно считать, явно или неявно — зависит от того, насколько команда понимает свой темп и waste rate (да и вообще, знает ли о нем)

Опытная и устоявшаяся команда это знает. Но что делать в рисками?

Риск — это событие, которое может случится или не случится с определенной долей вероятности. Например, мы планируем использоваться готовую библиотеку X для решения нашей задачи. С этой библиотекой мы не работали, только читали документацию и думаем, что она работает так, как нужно нам для нашего проекта. НО: у нас есть риск, что на деле библиотека работает не так, как нужно нам. Если наш риск «стрельнет» и окажется, что наша библиотека работает не так, что мы будем делать? Например, мы решаем в этом случае реализовать нужный функционал самостоятельно без помощи готовых библиотек. Сколько в этом случае нам нужно будет времени на реализацию с нуля? Предположим 40 часов, а прикрутить готовую библиотеку 16 часов. Отсюда получаем, что на данную задачу наша оценка 16-40 часов, или же 16чч + 150% рисков.

Предвосхищая вопрос, следующая цитата

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

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

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

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

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

З.Ы. А так я с тобой согласен.

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

Дурачок — ваш архитект. Но с другой стороны тебе же платят за жопочасы, да еще и учат бесплатно.

я бы не сказал что учат, я бы сказал, что у него очень субъективное мнение — но да, мне в целом пофиг

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

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

Это не сказка, 99% проектов которые разрабатывают в украине элементарные, а все сложности и проблемы только от говнокода, вот чем раньше начать его разгребать, тем проще поддержка кода, при удачном раскладе багофикса практически не будет

Это потому, что проекты в большом количестве пишут монолитными со связностью всех со всеми.

это не сказка. просто формулировка должна быть такой:

в долгосрочной перспективе код будет добавлять немногим(<50%) сложней чем в начале разработки.

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

Сказка. Любой проект со временем будет так или иначе накапливать технический долг. Это как в ДНК мусора накоплено море.
И это разумно принять как данность. да, мы можем рефакторингом и т.п. замедлить накопление тех долга, но не остановить. Такова наша вселенная.
Лично я для себя нашел такой метод борьбы с энтропией в проектах. Проект должен быть разделен на модули максимально независимые и общающиеся по четко определенным протоколам. Интерфейс модулей должен быть обязательно покрыт набором тестов.
Внутри самого модуля может быть любой мусор, главное, чтобы он делал то, что от него нужно.

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

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

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

а так да, согласен — «все, что рождено, умрет» — © Будда Шакьямуни.

И это разумно принять как данность.
что именно — прогерию как данность?
так ведь это не данность. легаси проекты которым за десять лет — существуют, и сапортяться.
даже на древнем(до 5.3) пыхе, не говоря об энтерпрайзных на джаве версии 6.
Лично я для себя нашел такой метод борьбы с энтропией в проектах.
не нашли, исходя из вашей уверенности что эти способы — сказка.
не нашли, исходя из вашей уверенности что эти способы — сказка.
Просто то, что состарилось и накопило кучу мусора просто выкидывается и заменяется новым и молодым.

неправда. вы прямо как юноша какой-то неопытный :)

ругаемый всеми за внутренний уё-ищный(по современным стандартам проектирования ПО) дизайн Wordpress — живет себе вполне.

вам как неопытному привести списочек подобных исключений? ;)

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

я о том, как делать разумно без усложнения себе жизни.
Сколько можно верить в эту сказку?

Я так делал и всё было хорошо. Проект вон уже хер знает сколько лет без меня живет. Просто меняют модули на более новые, если нужно.
Там можно просто dll заменить на новую и всё будет работать.

Проект вон уже хер знает сколько лет без меня живет.
не рассказывайте сказок :)

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

в долгосрочной перспективе код будет добавлять немногим(<50%) сложней чем в начале разработки.

rssradio.ru. Там наконец-то последний модуль привели в порядок.

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

как вот недавно меня один обучал как гуглом пользоваться:
Select -> right click -> Search Google for <selected>
dou.ua/...rums/topic/20029/#1075729

вы уверены что все такие тупые сказочники?

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

понятно.

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

А еще многим советую прочитать хотя бы библию.

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

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

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

2 или 3ья глава Книги Эклессиаста.

затасканная правда цитатка :)

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

честно говоря я не верю ничему от людей который априорно считают других полными кретинами.

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

вы считаете что Vadim Kopanev и я сказочники о техническом долге?
нет проблем.

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

С верой к богу, а не к людям.
Но я заметил, что мысли писателей библии более чем 2000-х тысячелетней давности для многих до сих пор откровения.

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

Но я заметил
мое старое, с христианских времен

— Библия говорит...
— Но разве она генерирует звуковые волны которые ты слышишь ушами?
— Хорошо, в Библии написано...
— Стоп, в какой именно, на каком языке, и главное — а точно там кроме черных карлючек на белом что-то есть?
— Хорошо, умеющий читать, в Библии прочтет что ....
— извини что опять перебиваю, это то что прочтет, обязательно совпадет с тем что имелось ввиду тем который писал? Какие гарантии
— Ммм... Нужно просить у Господа правильного разумения

skynin.blogspot.com/...2013/08/blog-post_18.html

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

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

Отчего собака бывает кусачей? ©

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

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

Ну я по жизни стараюсь пользоваться банальностями.

Первая глава, Сергей, первая. Это самое начало книги.

какой ужас! как же я страшно ошибся. надо было таки открыть ее в инете и номер стиха указать, да.
это очень важно!

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

согласен.

интереснее другое — какой смысл в подобном умничании с вашей стороны? это такой вид граманаци?
вот из всего что относится к «в интернете кто-то не прав» — вы выбираете подобные неточности? ;)

Haдо было отметить своё сообщение тегом «сарказм». Смысл — в привлечении внимания к неуместности указания в этом контексте источника цитаты глубже, чем название произведения и его автора. «Лев Толстой, 17-я или 18-я глава 2-го тома Войны и Мира» или «Александр Пушкин, 22-я или 23-я строфа 3-й главы Евгения Онегина» звучит точно также.

Haдо было отметить своё сообщение тегом «сарказм»
КОМУ — надо?
мне — не надо.

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

Знаете: может и есть у меня такая болезнь. ;)
И то, что я нужу на этот пост, косвенно это подтверждает :)

значит не болезнь. просто — тараканчик :)
мало у меня их что-ли.

А можно сделать так, чтобы архитектор выражал свои пожелания до того, как девелоперы начали имплементировать?

И зачем такой архитект нужен тогда, если он архитектурой занимается уже после реализации. Это получается уже не архитект, а менеджер по рефакторингу какой-то.

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

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

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

а писать чтобы было открыто к расширению и закрыто к изменению сразу никак? в таком же случае в будущем всегда можно будет расширить и его аргумент перестанет работать, ведь доказать что будущее учтено будет можно

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

К примеру, я сделал записывание double в mongo (весь бекенд на джава) на что он сказал что это плохо, ибо если мы будем проводить вычисление с этими значениями (а мы их не будем, сервер для этой сущности должен реализовать только функцию персистентности ну и небольшой валидации), и мы добавим php и там это будем делать, то могут быть проблемы. Если честно я не знаю что на такое отвечать человеку выше меня по рангу...

К примеру, я сделал записывание double в mongo (весь бекенд на джава) на что он сказал что это плохо, ибо если мы будем проводить вычисление с этими значениями (а мы их не будем, сервер для этой сущности должен реализовать только функцию персистентности ну и небольшой валидации), и мы добавим php и там это будем делать, то могут быть проблемы.
если в этом дабле хранятся данные, которые не должны содержать никакой погрешности, деньги например, то ты сильно накосячил, и тебе в достаточно мягкой форме объяснили что ты не прав, зачем-то со странным примером, который потенциально будет, когда требования поменяются
Если честно я не знаю что на такое отвечать человеку выше меня по рангу...
тоже что и человеку ниже по рангу и с таким же рангом, и случайному прохожему, зачем ото разделять на какие-то неведомые уровни
если в этом дабле хранятся данные, которые не должны содержать никакой погрешности, деньги например, то ты сильно накосячил
это кастомизация UI в double проценты для задания высоты элемента — там всегда будет погрешность и это ок.
тоже что и человеку ниже по рангу и с таким же рангом, и случайному прохожему, зачем ото разделять на какие-то неведомые уровни
есть такой глагол — уволить
это кастомизация UI в double проценты для задания высоты элемента — там всегда будет погрешность и это ок.
ибо если мы будем проводить вычисление с этими значениями (а мы их не будем, сервер для этой сущности должен реализовать только функцию персистентности ну и небольшой валидации), и мы добавим php и там это будем делать, то могут быть проблемы.
вот эти два предложения как-то не вяжутся, в одном погрешность — нельзя, в другом можно
есть такой глагол — уволить
ну не знаю, я всегда долго спорил с дебильными решениями тех кто выше по рангу, ну логично что часто спор заканчивался тем что «хватит спорить, делай как я сказал», через пару месяцев появлялся баг в таком кривом решении, после этого я никогда не упускал возможность потроллить, потом баг фиксил как предлагал сделать изначально, в общем это заканчивается не увольнением, а тем что через какое-то время больше не лезут с глупостями

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

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

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

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

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

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

В том то и прикол что его поймать заранее очень сложно, а еще он изначально может сказать одно потом совершенно другое, и такое каждый раз, и это не только у меня, у других та же беда, пробовали как то порешать но без успеха.
а откуда время потом берется? ну наверняка можно объяснить что поговорить один раз до лучше, чем 3-4 раза после
преобразовывать их вручную в интегер и обратно убивает прозрачность
в ждаве все настолько плохо что нет типов с фиксированной точкой?
ну наверняка можно объяснить что поговорить один раз до лучше, чем 3-4 раза после
я тоже так раньше думал — сейчас понимаю,что случаи бывают разные
в ждаве все настолько плохо что нет типов с фиксированной точкой?
есть класс BigDecimal — но это не тип. если че C# мне больше нравится чем джава

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

Это просто до*бки на пустом месте.

если мы будем проводить вычисление с этими значениями (а мы их не будем
Если в тз нигде не видно что будем, значит не будем. Продумать наперед случай что будем конечно можно, но нужно смотреть на вероятность такого изменения и на сложность переписывания. Переписать нафиг ради призрачной вероятности что это понадобится в будущем — ну бред. Как бы на этот бред смотрел тот кто платит деньги, мне интересно.
и мы добавим php и там это будем делать
Это вообще за гранью. Я даже не знаю. Нахрена это вдруг в проект на java мы добавим php? Ещё и будем проводить в нём вычисления? Я понимаю там в проект на php добавить сервис на java (и то, должны быть весомые причины) для расчетов, с которыми php хуже справляется, но уж никак не наоборот.

Мне это видится как самоутверждение архитекта за счет подчиненных и на деньги заказчика.

И зачем такой архитект нужен тогда,
Элементарно.
Он вступает в игру, когда программист просит прибавки к зарплате.
Он то и помогает её сбить. Самым что ни есть очевидным способом.

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

там даже не рефакторинг, а переписывание ради переписывания

Ну верить на слово выслушав одну сторону... может там все по делу говорит? есть еще разница — продуктовая компания или аутсорс какой-нить с гребцами. Я работал в продуктовой компании 1 раз — для меня это наверное была лучшая работа. Там реально мы заморачивались над качеством продукта, по 3 раза могли переписывать любой модуль, т.к. это наш продукт, и нам с ним еще очень долго работать (если не «всегда»). Если проект клиенту — все совершенно наоборот, и там нужно закрыть задачу в сроки, так как сроки оплачены и месяц переписывать 1 модуль 3 раза — это уже из кошелька компании а не заказчика. А вообще — наверное стоит радоваться, все таки это обучение.... надеюсь ))

Там реально мы заморачивались над качеством продукта, по 3 раза могли переписывать любой модуль, т.к. это наш продукт, и нам с ним еще очень долго работать
А продукт-то «выстрелил», или загнулся на этапе MVP?

Я когда пришел в компанию — продукт уже 6 лет как успешно работал и развивался. На этапе MVP никто бы и не заморачивался над качеством кода

Это продукт, но еще на этапе активного создания МВП, но не в классическом понимании, вообщем сложно объяснить. Я не говорю что он не дельные комменты дает, его точка зрение имеет право на жизнь, и возможно я чегото там незнаю о планах на проект. проблема в том что он не делает этого заранее — изза чего спринт делается в течении 2-3 спринтов.

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

это новый продукт (а точнее говоря даже переписывание с нуля существующего) весьма успешной конторы на своем рынке, но у нашей конторы есть аналогичный продукт который по факту является нашем конкурентом, и бигбоссы сча решают какой им убить а какой оставить, хотя реально уверенности что продукт будет успешен нет, так как это Б2С, вообщем как и говорил все сложно )))

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

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

Второй момент — это то, что объем работы по переделкам зависит от того, насколько рано-поздно вы получили фидбек, чем раньше вы его получаете, тем меньше переделывать.

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

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

P.S. Смотреть на код и говорить, что не нравится подход — это как смотреть на построенный дом и говорить, что хотел другое расположение комнат :). Вопрос расположения комнат (подхода) решается на стадии ревью планировки будущего дома.

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

Работал один раз в паре с таким сениором (java: spring, hibernate). Но я был джуном тогда и мой лид всегда переписывал что-то после моих коммитов.

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

Как оценить часы на разработку

Никак. Одно из следствий закона Мэрфи это: «Всякая работа требует больше времени, чем вы думаете».

Смиритесь)

Обычно для таких целей подписывается договор гранул.

А почему делим на 6.4 часа в день?

А ти реально кодиш усі 8 годин на протязі вісьми годинного робочого дня?! :)

это еще хорошо поставлено дело в компании!
а так — 5.

чтобы 8 часов в день — это 10-11 часов в офисе.

Я всегда считаю рабочую неделю как 3 дня:
3 дня производство конечно результата
1 день на всякие митинги, email, кофе, и так далее
1 день само развлечение — дурака валяние, повышение квалификации, катание на велосипеде и так далее. короче кто на что учился.

У нас так и есть — 5.
Рабочая неделя — 4 дня. Пятый день — резервный.
Клиенту никогда не продается эффективная велосити больше 20-25 часов в неделю.

да, вполне здраво.

5 дней в неделю можно ставить, в продуктовых компаниях, т.е когда ТЗ формализовано до занудства. и команда сработалась за годы. и клиентом является сотрудник компании в должности продакт овнера :)

тогда даже на 6 часов в день можно выйти!

чтобы 8 часов в день
Крыша долго не выдержит такого темпа. Причем его еще и стимуляторами придется поддерживать.
Правда, чем ты моложе, тем легче долго такой темп держать, правда негативные последствия настигнут потом. В молодости это не осознается.
чем ты моложе, тем легче долго такой темп держать
— Что Вы умеете делать?
— Я умею быстро печатать!
— Сколько знаков в минуту печатаете?
— Ну, примерно, 1500 знаков в минуту...
— ООО!
— Но, вот, только в результате, такая фигня получается...
(к)
саппорт IE6
🤦🏻‍♂️

Осталось впечатление, что автор немного так путает effort и duration очень сильно. А еще — не вполне понимает, что такое критический путь и итеративно-инкреметные подходы, например, здесь:

Предсказали 700 часов, сделали за 700 часов.

Це все дуже класно і правильно, але як пояснити клієнту, що простий сайт на вордпресику буде робитись командою професіоналів 3 місяці? І з відповідною оплатою

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

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

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

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

Я всегда мог обосновать любые временные и финансовые затраты для фиксед прайс.
Т.е. запросто можно обосновать реальный объем работы в 2 часа в 2000 часов.
Посему я знаю только одну оценку — оптимистичную. Реальная может оказаться любой больше отптимистичной.
Посему только этапы и продолжение работы по их результатам с перепланированием очередного этапа. В предельном случае «Срам».

Если ваша оценка меньше недели, добавьте к ней неделю минимум. Если ваша оценка меньше месяца, добавьте две недели. Потому как ВСЕГДА возникает какойто вопрос к клиенту, и КРАЙНЕ маловероятно, что клиент ответит меньше чем за сутки.

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

— 10 минут.... и неделю.... и.... и это минимум....
— :О

а так и есть. Вот из недавней практики, был проект на 2 часа. В середине возник вопрос. Клиент ответил через 10 дней.

да, но вы же не будете биллить клиента за 10 дней простоя :) конечная дата изменилась, а эстимейт — нет

Буду. При следующем обращении. Причина очень проста. Проект, который решается за день требует гараздо меньше усилий, чем проект, который решается по 15 минут в течении 6 месяцев(и такой у меня был).

Угу, когда к моменту ответа ты уже и забыл на чем остановился.

Записывать надо очень рекомендую очень помогает как в «воспоминаниях» так и в «разборках по случаю чего» а также в обоснованиях «смотрите у меня все ходы записаны и вот применена методика оценки по собранной статистике в результате чего можно вывести более точные цифры» (в большую сторону или наоборот в меньшую отдельный вопрос)

ЗЫ: в конце концов биг-дата наступает стыдно не применять её «на передних фронтах». ))

Вот вроде бы да, но у меня такая ситуация: есть проект на фрилансе, я там занимаюсь фронтом. Заказчиком (тем, который общается со мной и платит) выступает бекендщик. Он же занимается общением с инвесторами/потенциальными клиентами. Работать с ним мне очень нравится, но есть проблема простоев. И меня эта проблема начинает напрягать, так как простои никогда не определены заранее и я не знаю, ответит он мне завтра или через неделю. В результате я не могу искать другие проекты (потому что люди хотят девелопера на фултайм или хотя бы с предсказуемой доступностью), имею много свободного времени (ну это не проблема, спускаю на игры и DOU) и не очень много денег. И вот, я же не буду биллить за простои (тем более, работаю с апворковским трекером), хотя на вторую-третью неделю без работы очень даже хочется.

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

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

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

у Василия в рабочей неделе 32 часа, а не 40.
Даже это оптимистично как по мне ). А еще в вашем примере и расчёте календарной длительности вы не учитываете время клиентов на ревью и ответы на вопросы и уточнения. Особенно весело когда кто-то из отвечающих внезапно уходит в отпуск.

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

1) Poker estimate
Собирается группа девелоперов, озвучивается задача, все эстимейтят втихаря, потом сравнивают. Авторы самого большого и самого маленького значений обосновывают свою оценку. В конце нужно прийти к общему мнению.

Это какое-то извращение на базе Planning Poker www.mountaingoatsoftware.com/tools/planning-poker

Почему извращение?

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

Если будет только «группа девелоперов втихаря», то это будет очень неточно и неэффективно.

Под «втихаря» имелось в виду «не раскрывая сразу свою оценку»

«не раскрывая сразу свою оценку»
А зачем? Чтобы не влиять на оценки других? А зачем всем эстимейтить одно и то же? Разбить на задачи каждого никак нельзя? Если каждый предполагается профессионалом достаточным для выполнения задачи независимо от (всё равно ведь кому-то выполнение будет поручаться) то разве его собственный эстимейт не внушает доверия раз уж ему будет поручена реализация?

Или с реализациями тоже «не раскрывая сразу свою потом сравнивают»?

Для минимизации ошибки. Василий решил, что импорт csv сделать можно за 8 часов, а Иннокентий решил, что за 16. Раскрываем. «Кеша, шо так много?», — «Васёк, там очень дурной запрос будет, и импортилку всю надо переписать», — «Точно, про запрос не подумал. А импортилку возьмем из другого модуля, она там ок». В резудьтате сходятся на 12 часах.

То есть Иннокентий знал как работает имеющийся модуль импорта, а Василий не знал. Так и зачем Василию оценивать эту часть?

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

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

В резудьтате сходятся на 12 часах.
На что условно (и в реальности безусловно тоже) потрачено гораздо более «условных 4-х часов разницы конкретной задачи» только на то чтобы её «правильно заэстимейтить».

Т.е. если бы б они сели рядом сразу 2 и эстимейтили просто вдвоём то варианты «не подумал» также решались бы сразу чисто технически по ходу равно как и

возьмем из другого модуля, она там ок

А ну ок. (к) (тм)

А зачем? Чтобы не влиять на оценки других?

Именно. По сути, planning poker — это геймифицированный и подогнанный под Scrum старый добрый метод Wideband Delphi

Да вот только «в оригинале» речь идёт за «экспертов» а скрум обычный обыкновенный почти 146% имеет в наборе кого попало включая скрум-кучеров и адептов подлизывания но чисто технически таки «кого попало» в результате какого-либо особо специального смысла «играть в продвижение реальной оценки» нет от слова вообще и таки да реальный эксперт без кавычек легко всё это планирует и может давать «оценки ближе к среднему» таким образом избегая личных участий в «specifically focusing on».

Тут таки фокус именно в том «вам игрушки или ехать?» и в скрум обыкновенный почти 146% будет сказано «ну у нас же ж был покер все ритуалы скрума соблюдены значит должно работать». А по сути все «ритаулы» направлены исключительно на одно создание видимости для стороннего обычно для продакт-овнера.

Потому как в «методике оценки» речь идёт исключительно об «геймификации» но не о том как реально практические методы применить. Особенно с учётом п.п. «имеет в наборе кого попало».

Если позволите, я расширю уже данные ответы:

А зачем всем эстимейтить одно и то же?

1. В общем случае, задача может быть сформулирована как угодно и может предполагать работу нескольких людей над её реализацией.
2. Заранее может быть неизвестно кто именно будет заниматься задачей. И если условный Петя оценит её, условно, в 8 часов, а потом заболеет, то условный Вася, которому придётся пилить эту задачу, может иметь другую производительность и экспертизу. И у Васи задача уже получится не в 8 часов.
3. Как правило, оценки при помощи покера делаются не в абсолютных, а в относительных величинах.
4. Чем больше людей вовлечено в оценивание, тем более полно можно рассмотреть задачу и учесть детали. (Я лично не раз был свидетелем того, как оценка задачи серьёзно менялась, когда своё слово говорили тестировщики. Т.к. разработчики думают по-другому, и чаще фокусируются на алгоритме, а тестировщики — на сценариях использования. В итоге оценка менялась из-за того, что тестировщики озвучивали какие-то условия, из-за чего способ имплементации нужно было менять.)

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

Этот то самый неловкий момент когда таки в скруме таки:

может предполагать работу нескольких людей над её реализацией
нет не может
может иметь другую производительность и экспертизу
нет не может
не в абсолютных, а в относительных величинах
справедливости ради таки они «неабсолютные» только потому что реальные их значения предполагается определить по мере накопления статистики и тогда они таки реально станут абсолютными пусть даже «с условно нелинейной шкалой» другое дело что они _должны_ такими стать но вот в реальных реализациях исходя уже даже из п.п. 1-2 которые «нет не может» но вот почему-то #внезапно так есть то в реальной реальности это только называется скрум чтобы его можно было продать клиенту либо самим себе сказать «у нас есть (хоть какой-то) процесс» (к) (тм)
Можно, но долго.
А ну ок.
Все люди разные и подходы к выполнению одной и той же задачи разные.
Ну это совсем классика:
«Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему.» (Часть I, Гл. I)

И таки да в этом суть вы (здесь обобщение) пытаетесь «натянуть скрум» на несчастных неспециалистов для которых он таки _не_ предназначен причём сами же ж про это же ж и пишете а ну ок.

Опыт показывает, что сработавшиеся команды
Опыт показывает что реальным специалистам не нужно «с 1-2 раза» и что практические реализации #внезапно приходят к настолько одинаковым вещам что для этого придумали даже патенты «кто первый успел» а вот всем остальным приходится довольствоваться... лично я крайне слабо себе представляю что именно могут «обсуждать» «сработавшиеся команды» состоящие скажем их джунов мидлов и синьоров не считая каких-нибудь + лидов-архитекторов и насколько именно здесь речь идёт про «обсуждать» и тем более «к общей оценке» и что такое вообще «обсуждать» и «общая оценка» в случае когда на старт проекта мощностью 40 условных человек требуются условных 4 человека которые к тому же ж в дальнейшем прямо участия в проекте принимать не будут кроме разве что т.н. «архитектурный надзор» но вот даже «скрум скрумов» предполагает уже разделение на уровни и «необщие обсуждения» но в целом общее состояние таки да вы всем этим подтвердили и лично я с фактическим состоянием дел совершенно полностью согласен.
нет не может
Может.
нет не может
Может.
вы (здесь обобщение) пытаетесь «натянуть скрум»
При чём здесь скрам?
реальным специалистам не нужно «с 1-2 раза» и что практические реализации #внезапно приходят к настолько одинаковым
Это в идеальных проектах в вакууме?
для этого придумали даже патенты «кто первый успел»
У вас очень специфическое представление о патентах.
Также хотелось бы узнать статистику — часто ли приходилось патентовать наработки проектов либо использовать чужие патентованные решения, за исключением случаев, когда заплатить за лицензию или использовать готовое и бесплатное дешевле, чем сделать своё.
лично я крайне слабо себе представляю что именно могут «обсуждать» «сработавшиеся команды»
С этого, наверное, нужно было начинать.
в случае когда на старт проекта мощностью 40 условных человек требуются условных 4 человека которые к тому же ж в дальнейшем прямо участия в проекте принимать не будут кроме разве что т.н. «архитектурный надзор»
Это какая-то личная боль?
Не пытаюсь уколоть. Но очень странно, что дискуссия переходит в бросание словами и пространные рассуждения о каких-то странных абстрактных ситуациях.

Хорошо, если так.

Все советы сводятся к списку причин «накинуть» на оценку. Накинуть на риски, на неопределенность, на «миддла», на среднюю занятость, на коммуникации, на менеджмент, и так далее.

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

Поэтому все эти чудесные советы рассыпятся о «а почему так дорого, мне ваши конкуренты предлагают вдвое меньше». Не, «почему» — понятно, вон и список есть, почему. Но только это не про точность, а про прикрытие жопы. Так что клиента при продаже, увы, не впечатлит...

Все накидывания следуют из анализа «сколько пообещали» против «сколько получилось». С накидываниями (многие из которых следуют из того, что какие-то вещи хронически забывают включить в эстимейт) получается как раз точнее. Предсказали 700 часов, сделали за 700 часов. А вариант предложить клиенту самый оптимизм(чтобы продать) и потом в него не вложиться, потому что забыли коммуникацию, васин отпуск и то, что API может оказаться дырявым, проигрывает тем, что он не точный, и еще и очень стрессовый для всех, включая клиента.

Попасть в переоцененный проект несложно. Причем, чем сильнее переоценить — тем проще попасть. Это не точность.
Просто в статье я вижу список причин увеличить оценку, и ни одного способа уменьшить. И мотива уменьшить тоже ни одного. Как из этого может получиться точная оценка? Только безопасная для исполнителя.

Есть много способов уменьшить оценку, но все они относятся больше к конфигурации проекта и работе с требованиями — повод для отдельной статтьи.

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

Работа заполняет время, отпущенное на неё
То есть, даже если вы сильно переоценили — все равно, все это время найдется, чем занять.

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

Я правильно понял — менеджер должен не допустить рефакторинга?

менеджер вместе с командой должен понимать, где есть польза от перфекционизма, а где он уже идет во вред

Какой мудрый и всепонимающий менеджер!

Конечно, тот же рефакторинг и отладка.

Работа заполняет время, отпущенное на неё
Это ж шутка как бы, так можно и Карлина цитировать начать =).
То есть, даже если вы сильно переоценили — все равно, все это время найдется, чем занять.
Если проект фиксед прайс то у вас нет мотивации его затягивать, а в почасовке клиент всегда может сказать good enough, thanks!

Ну, в каждой шутке если доля шутки.

А Клиент вообще всегда может сказать что угодно, он вообще всегда прав, if you know what I mean.

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

А это, батенька, уже рынок. «— Конкуренты? — You’re mostly welcome, good luck».
Лет 12 назад, по зеленой неопытности я рассуждал примерно так же как вы. Выкручивал квоуты как угодно, лишь бы попасть и получить клиента. Накинуть? Ой как бы клиент не отпал. Ничего хорошего не вышло — либо клиент оказывался редкостным муднем, либо просто откровенным кидалой, зачастую неимевший даже денег расплатиться по факту. Ретроспективно, выгоднее как раз браться за клиентов, готовых платить по адекватной оценке, и лезть из кожи, выдавая лучшее качество на которое только способна команда.

Еще выгоднее браться за клиентов, готовых платить по завышенной оценке.

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

Все советы сводятся к списку причин «накинуть» на оценку.
конечно. всегда.
потому что:
Только все это не делает оценку более точной.
точную оценку сроков не дают даже пророки которым Бог на ухо шепчет о будущем.

у меня был один шеф, который твердо утверждал — чем точнее оценка, тем план туфтовей.

Те что дают, либо шарлатаны, либо дают для типичных, повторяемых без вариаций проектов.

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

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

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

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

если ему стало скучно вникать в этапы путы к успеху собственного(!) проекта — то пусть идет к конкурентам.
(примерно как с наемом работников — если вы сомневаетесь брать или не брать этого работника — прочувствуйте ситуацию — его возьмет ваш конкурент)

в тому ж і вся сіль — хто знайшов золоту середину і зміг продати клієнту, той і є крутий сео/сейлз/фрилансер/etc.

Ну так и как же? В статье только как увеличивать оценку. Так золотую середину не найти...

Спасибо, интересная и полезная статья. От себя бы еще добавил, что разработчики довольно часто указывают эстимейт задачи не учитывая то, что задача к ним вернется (а может и не раз) на доработку / исправление. Не все, конечно, но довольно многие

Когда-то видел проект, в котором команда в явном виде закладывала задачи на багфиксинг. Т.е. есть фича, под ней список задач, которые нужно выполнить, чтобы она считалась правильно имплементированной, и, среди этих задач, задача «bugs fixing». Иногда она по размеру составляла около 100% от других задач.
Мне было интересно узнать, как к этому относится заказчик. :)

на моей практике нормально относились (правда не 100% добавляли), надо было лишь объяснить, что софта без багов в принципе не бывает

Мне кажется, что все зависит от отношений с заказчиком. Если у Вас мелкий проект, заказчик будет / может трястись над каждым часом, тогда такие вещи лучше предварительно согласовывать. Есть даже очень большая вероятность, что большая часть багов просто останется, потому что «сойдет». Если же проект большой и серьезный — все участники должны понимать, что от багов никуда не денешься. Если заказчик этого не понимает, тогда я не завидую успеху всего проекта :)

Если месяцами в задачи закладывается хороший кусок на фиксинг багов, то возникает масса вопросов:
1. А почему так много?
2. А почему это число со временем не сокращается?
3. А почему вы пишите с дефектами?
4. Разве нет возможности как-то с этим бороться?
5. Блин, ребята, я тут посчитал, мы 40% бюджета на багфиксинг тратим. Вы точно профессионалы?

Потому это дело лучше закладывать в неопределённость, и там, где это возможно использовать способы минимизации количества дефектов (такие, как TDD, парное программирование), так и техники, которые позволяют сократить время жизни дефекта (peer review, smoke testing, unit testing, CI).

способы минимизации количества дефектов (такие, как TDD, парное программирование)
А эти способы не сильно увеличивают время на разработку? Как бы не вышло, что вместо 40% на багфиксинг получится 40% бюджета на тесты, а потом еще 20% на багфиксинг

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

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

Не всё можно проверить автоматическим тестами, точнее очень немногое.

е2е тесты, с использованием browserstack — всё решаемо и упирается исключительно в цену вопроса.

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

дешевле, быстрее — хороший QA отдел :)

Во фронте обыдена фигня, когда в одном браузере работает, а в другом — нет.
это да, вот, вчерась — кружочек вокруг пиктограммы рисовал.
и опа — в Хроме и IE кружочек, а в ФФ — овал!
хотя, по идее тоже можно, автоматический тест на такие штуки должен делать скриншоты, а потом сверять с скриншотами дизайна...

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

А каких размеров проекты и сколько человеко-часов занимает регрессионное тестирование?

А каких размеров проекты
В данный момент довольно большой проект (документооборот для международной торговли), в стадии разработки (релиза не было). Фронтенд — ember.js
сколько человеко-часов занимает регрессионное тестирование?
Не замерял

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

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

Именно это я и имел в виду, менеджеру стоит учитывать данный факт

В п. 13 было бы здорово упомянуть про PERT :)

Нужно умножить средний эстимейт на 2 и будет все гуд с выполнением запланированных задач ))

Почему не на 3? Будет не все гуд с выполнением задач?

По целому проекту не скажу, но по отдельным фичам это работает. Можно и на 3, если разработчик заметил за собой такую большую погрешность в оценках. Можно на 1.5, если обычно угадываешь и задача знакомая. Коэффициент должен зависеть от разработчика и насколько задача типовая/знакомая.

Может, тогда уже 5? Для надежности?

Что непонятного в этой фразе?

Коэффициент должен зависеть от разработчика и насколько задача типовая/знакомая.
Если кто-то три раза подряд ошибся в эстимейте в 5 раз, то логично на 4й раз свой эстимейт в 5 раз умножить. А если так получилось что эстимейтишь всегда в 2 раза больше чем требуется — то никто не мешает поделить, но я о таких девелоперах не слышал.

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

Да, я и не утверждаю что это дает точность. Но в случае, когда билятся реальные часы (я фрилансер, у меня так и есть), лучше я скажу клиенту что фича будет готова через 8 часов и выкачу её через 4, чем скажу что фича будет готова через 4, а выкачу через 8. В первом случае клиент получит что хотел раньше обещанного и за меньшую сумму. А во втором мало того что с задержкой, так еще и в два раза дороже. В каком случае он будет более довольным и желающим продолжать сотрудничество?

Полагаю, Алексей намекает на fixed bid сценарии, где излишнее перезакладывание приводит к проигрышу конкурентам по цене (если нет очень сильного, по сравнению с ними, конкурентного преимущества по другим пунктам)

— берем оценку разработчиков 500ч
— накидываем свои 40% на риски и недооценку разработчиками
— показываем клиенту 700ч
— делаем скидку до 580ч
— разработчикам говорим, что есть только 400ч и надо вписаться
......
PROFIT :)
.....
ретроспектива, где сравниваем оценку разработчиком, оценку менеджером (+риски) и actual time

а по факту получается 900ч и атата

зависит от того на сколько вы знаете своих девелоперов

У нас шутка ходит, что некоторым надо умножать на число Пи, некоторым на е. А бывают и такие, которым и на то, и на другое и еще делить на постоянную Планка.

В институте учили брать самые пессимистичные оценки, умножать на 1.3, и потом ещё 3 месяца сверху добавлять.

На пи... умножать. Почему? Ну просто число нравиться.

Там где-то была картинка с кругом на ней видно «почему на пи...»

ЗЫ: кстати тему с «вариантов № 2» как-то не знал и таки да очень иллюстративное описание того как есть на самом деле #внезапно.

ЗЫ: а вот же ж она:

dou.ua/...ign=reply-comment#1073293
Alex Troush -_-
yesterday

Срок выполнения любого проекта по Бобуку-Бацек
pbs.twimg.com/...media/CNRsMteVEAAqy9j.png

Срок выполнения любого проекта по Бобуку-Бацек
pbs.twimg.com/...media/CNRsMteVEAAqy9j.png

Заложена ли ошибка планирования в человеческой природе? Исследователи провели эксперимент, предложив студентам назвать время, необходимое им для завершения диплома. В одном показательном тесте группа разделилась на оптимистов и пессимистов: оптимисты обещали закончить за двадцать шесть дней, пессимисты — за сорок семь. На самом деле на завершение работы потребовалось в среднем пятьдесят шесть дней.

откуда цитата? :)
упд. уже нашла, спасибо.

Прочитал очень бегло. Если я правильно понял, вы предлагает оценивать скоуп работ в целом по релизу сходу в часах. Говорите про покер(Scrum), хотя описывает типичную оценку Waterflow проекта. Вы как минимум мешаете методологии разработки. Так лучше не делать. Оценка в часах больших задач, без предварительно оценки производительности конкретной команды заведомо плохая идея и ни к чему хорошему она не приведет.

Я предлагаю несколько методов оценки. Для каждой методологии и для каждой команды набор этих методов и каких-то своих хаков будет различаться. Оценка в часах больших задач часто необходима для sales, pre-sales и для ориентирования клиента. Невозможно начать проект, хотя бы примерно не спланировав бюджет. То же самое и с новыми большими и маленькими фичами. И, в реальности, далеко не всегда, к сожалению, у PM будет хорошо знакомая сработанная команда с предсказуемой скоростью и качеством :)

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

Покер в типичном аутсорсе? Srsly?

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

То ли дело сядет менеджер, проставит опытной рукой в экселе часы...

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

Только если будет опираться на довольно серьезную аналитику и будет готов платить со своего кошелька за собственные ошибки.

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

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

Ну и че там у вас в LiveArt за процесс выстроен, поделитесь? Полагаю, это эффективная, незатратная по времени, подчеркнуто объективная, невероятно полезная и имеющая кучу достоинств методика. Все будут рады поучиться.

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

Дам подсказку — за 15+ лет в индустрии, ни один метод оценки с коробки не работает даже в 20% случаях и проектах. То есть да, в отдельных случаях вы можете чинно раздать карточки и поиграть, но пройдет 1-2-5 заданий, спринтов или целых проектов и вы быстро поймете, что это лишь шелуха, а полученные оценки все равно надо пересматривать другим методом и не раз коррелировать.

В личном общении могу рассказать.

А можно вопросы, а не консультацию? Для чего вы использовали Planning Poker, что оценивали и как? Что не устраивало в результатах?

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

Второе, затратность по времени. Для этого необходимо всех собрать, раздать, обсудить етц.

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

Четвертое, это оценка одного и того же задания несколькими людьми. Это как вообще? Например сколько займет по времени прикрутить доску (актуальная для нас задача после небольшого офисного ремонта) — я оценю в 2 часа, мой лид в 30 мин, еще кто-то из ребят минут в 20. Сойдёмся на часе времени, но прикручивать то надо будет лишь кому-то одному. Улавливаете фейл в подходе? На кого-то из нас будет «спущен» этот эстимейт и если не успеешь, можно будет всегда отмазаться в стиле классического SEP синдрома.

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

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