Comments 24
Выбор джедаев — оценка на месте. Здесь и сейчас.
Описано подробно и понятно. Впечатление такое, что такая оценка "на месте" займет не меньше часа. И это при условии, что основные детали реализации сразу ясны, что странно для идеи, которую только презентовали.
тут предполагается, что вы обладаете достаточным IT-бекграундом и сумели бы сделать эту задачу в одиночку, при достаточном запасе времени
"Сумели бы сделать в одиночку", это не всегда подразумевает, что не требуется исследование. Адекватный план работ -- видится наиболее сложной частью оценки. А продуманные (или рожденные опытным путем) коэффициенты -- это здорово! Если это первая оценка, и после уточнения требований и деталей реализации, перед тем как задача попадет в спринт, -- будет вторая оценка, тогда совсем хорошо.
Могу сказать, что на практике такая методика позволяет более-менее комфортно попадать в сроки.
Это замечательно!
Отличная статья.
Помнится в книге Р. Мартина "Идеальный программист" автор открыл глаза на вероятностное распределение в оценке. Если считаешь что выполнишь за 3 дня, то это значит что наиболее вероятно 3 дня, чуть меньше вероятности что 4, и так далее. Наименьшая вероятность была на цифре 11.
Он предлагает вдохновится программой PERT от ВМС для проектирования подводных лодок в части вычисления оценок. При оценки задачи предоставляются три числа:
оптимистичная оценка
номинальная оценка
пессимистичная оценка
Так же приводятся формулы для суммирования этих оценок по группе задач и вычисления среднеквадратичного отклонения
Можно ли это как то применить при подходе, описанном Вами?
Мы рассчитанную цифру еще умножаем на коэфф. 3,14 - и, по итогам разработки, очень часто как раз столько и получается. Потому что еще есть очень много неучтенных факторов, которые невозможно учесть в начале пути. А если сделали быстрее - то молодцы!)
Такой подход может оставить бизнес инициатора с неоправданными ожиданиями — «Почему именно 3,14? Откуда такая цифра? Опыт? Так в этот раз будет все по другому!»
Хорошо, в этот раз умножаем на e
Полагаю, коллега опирался на труд великого Бобука
Довольно часто так бывает, что инициатор фичи, услышав озвученные сроки реализации и понимая, что за пять минут она не сделается (как он думал ранее), отказывается от нее, т.к. на самом деле она была не очень-то и нужна)
Основная ошибка автора состоит в том, что он забыл все сроки умножить на два и прибавить две недели!
Вы недооцениваете хитрость ситуации. Ключевой момент здесь:
Инициатор вместе с вами участвует в процессе оценки. Это уже не только «ваша» оценка, но и его! И он ее будет гораздо ревностнее защищать перед другими коллегами.
Соответственно, даже хорошо, если сроки будут сорваны - инициатор тоже окажется виноватым, а следовательно, в следующий раз у него будет меньше желания просить оценить сроки на ходу, без ТЗ.
Еще в универе мне препод говорил, что если хочешь оценить сроки разработки, то спроси у программиста за сколько он сделает описанный в ТЗ продукт. Затем названные сроки надо умножить на три, прибавить три дня и одну ночь. Тогда сроки будут максимально близки к реальности.
У вас в пункте про козффициент мути что-то не сходится (по таблице КМ присваивается либо +0%, либо +5%, либо +10% (зачем указывать знак плюс при присвоении, если он плюс и так по умолчанию?), однако ниже пишете, что "КМ по умолчанию равен 10 %, и в зависимости от ответов на поставленные вами вопросы может так и остаться 10 %, либо вырасти до 70 %.").
Поправьте либо таблицу (чтобы был инкремент, типа КМ += 10%), либо вывод))
Кажется понял, что Вы имели в виду. Спасибо за обратную связь, поправил - надеюсь будет понятнее.
Там, где у вас в табличке КМ +10%, это на самом деле не проценты, а процентные пункты.
Было бы проще для понимания, как мне кажется, использовать для КМ не проценты, а просто число от 0 до 1 (или больше, если табличка разрастется). Даже само слово "коэффициент" на это намекает, ведь коэффициенты в процентах обычно не исчисляются.
Я хотел бы поделиться с читателем ходом своих рассуждений, которые позволяют мне довольно точно оценивать сроки реализации даже в самых запущенных случаях.
Это же невозможно, подумал я. Без ТЗ оценивать сроки не только невозможно, но и глупо!
Инициатор вместе с вами участвует в процессе оценки. Это уже не только «ваша» оценка, но и его! И он ее будет гораздо ревностнее защищать перед другими коллегами.
А, ну все понятно. На одну разводку (когда программиста просят оценить сроки без ТЗ - это именно разводка) вы делаете встречную. С точки зрения «бей врага его же оружием» неплохо :)
У меня довольно часто работает правило - первая оценка которая всплывает в подсознании X 2.
Если в ходе работ требуется интеграция со смежным сервисом, то накидывайте 30 % календарного срока на длительность интеграционных работ
Это работает в случае готового сервиса, разработанного в той же организации и который будет использоваться "как есть".
Иногда бывает что надо интегрироваться с внешним сервисом, который ещё и допиливается под нужды твоего проекта - вот тут я бы говорил об условной оценке собственных трудозатрат (учитывая каналы связи с внешней командой, возможные рычаги управления и т.п.)
Да, формально мы можем просто взять оценку доработки от внешней команды и приплюсовать к нашей оценке для нашего проекта + добавить какой-то процент сверху "на издержки коммуникации". Однако любой внешний исполнитель привносит нехилый элемент рандома. Если есть цель предоставить более-менее объективную, а не формальную оценку - то на подобные вещи лучше указывать отдельно, подразумевая, что точную оценку именно данного аспекта (интеграции) в такой ситуации предоставить нереально.
В целом - да, Вы правы.
Беда в том, что все "отдельно выделенные" проблемные места тут же сотрутся в памяти инициатора. Там умещается только одна цифра.
Я бы предпочел накинуть в "гору" побольше времени на внешний сервис. А если это госорган (ПФР, ФНС, Минсельхоз и т.д.) - то гора должна быть размером с Эверест.
Для вопрошающего ваша оценка будет звучать как магическая непонятная заповедь. И если он сам не понимает, откуда взялась оценка, то может возникнуть желание «почеленджить» её
Вот это — самое страшное. Причем аргументы для обоснования уменьшения сроков обычно берутся из серии «Товарищ Иванов! Вы же — коммунист! И пулемет застрочил снова.»
Часто сталкиваюсь с такой ситуацией. Всегда есть важный внешний фактор, ограничивающий сроки на задачу - "KPI руководства", "изменения в законах", "конкуренты уже вышли на рынок с таким же продуктом" и прочее.
По сути - это способы о стороны инициатора повлиять на срок (хотя их особо то и нет), перекладывая последствия в виде поддержки говнокода на разработку. Это естественная реакция каждого человека - "надо же что-то делать, чтобы ситуацию улучшить". Я пытаюсь показать, как с помощью прозрачности направить вектор этого "надо же что-то делать" с прессинга разработки на управление ожиданиями топ менеджмента.
Меня беспокоит идея оценки на коленке. Аналитика, которая позволит как-то более-менее оценить время разработки -- это сама по себе работа, на которую должно быть выделено время.
Каждая оценка имеет некую точность (ну или "погрешность"). ПОдробный разбор задачи аналитиком позволяет снизить такую погрешность (но кстати не убрать ее, а именно снизить).
В тепличных условиях - конечно нужно отрисовать схемы процессов, макеты интерфейсов, отрисовать алгоритмы работы, спроектировать модель данных и т.д.
Беда в том, что периодически ситуация такова, что на оценку времени особо нет. По разным причинам (об этом можно отдельную статью написать), но нет.
В этом случае оценку можно сделать самому в условиях дефицита информации, взяв "в гору" и объяснив, почему так (как собственно я и предлагаю) - либо можно подставить аналитика, и попросить его сделать такую оценку, выделив минимум времени - тогда он по сути сделает то же самое, но ответственность вроде как будет на нем. Я за первый варик.
Когда сделаете доработку?