Как реагировать, когда вас просят оценить?

Мы, как программисты, постоянно спрашиваем: «Сколько времени это займет»?

И вы знаете, ситуация почти всегда такая:

  • Требования неясны. Никто не сделал глубокого анализа всех последствий.
  • Новая функция, вероятно, нарушит некоторые предположения, сделанные вами в вашем коде, и вы сразу начнете думать обо всех вещах, которые могут возникнуть для рефакторинга.
  • У вас есть другие вещи, которые можно сделать из прошлых заданий, и вам придется придумать оценку, которая учитывает эту другую работу.
  • Определение «done», вероятно, неясно: когда это будет сделано? «Готово», как только что закончил его кодирование, или «сделано», как в «пользователи используют его»?
  • Независимо от того, насколько вы сознательны во всех этих вещах, иногда ваша «гордость программиста» заставляет вас давать /принимать более короткие времена, чем вы изначально предполагали, что это может произойти. Специально, когда вы чувствуете давление сроков и ожиданий руководства.

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

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

Каков ваш личный процесс для принятия и оценки? Какие методы вы нашли полезными?

606 голосов | спросил Sergio Acosta 3 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 03 Sep 2010 10:41:26 +0400 2010, 10:41:26

17 ответов


358

Из Прагматический программист: от Journeyman to Master :

  

Что сказать, если спросить об оценке

     

Вы говорите: «Я вернусь к вам».

     

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

В этом разделе авторы рекомендуют следующий процесс:

  • Определите требуемую точность. Основываясь на продолжительности, вы можете процитировать оценку с разной точностью. Высказывание «от 5 до 6 месяцев» отличается от «150 дней». Если вы немного проскользните в 7-й месяц, вы все еще довольно точны. Но если вы проскользните на 180-й или 210-й день, не так много.
  • Убедитесь, что вы понимаете, что задают. Определите объем проблемы.
  • Модель системы. Модель может быть ментальной моделью, диаграммами или существующими записями данных. Разложите эту модель и постройте оценки из компонентов. Назначьте значения и диапазоны ошибок (+/-) для каждого значения.
  • Рассчитать оценку, основанную на вашей модели.
  • Отслеживайте свои оценки. Записывайте информацию о проблеме, которую вы оцениваете, о вашей оценке и фактических значениях.
  • Другие вещи, которые следует включить в вашу оценку, разрабатывают и документируют требования или изменения в спецификациях требований, создают или обновляют проектные документы и спецификации, тестируют (единицу, интеграцию и принятие), создавая или обновляя руководства пользователя или README с изменениями. Если два или более человека работают вместе, есть накладные расходы на связь (телефонные звонки, электронные письма, встречи) и слияние исходного кода. Если это длинная задача, учитывайте такие вещи, как другая работа, время отпуска (праздники, отпуск, время болезни), встречи и другие накладные задачи при выборе даты доставки.
ответил Thomas Owens 3 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 03 Sep 2010 18:15:39 +0400 2010, 18:15:39
160

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

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

  1. Взгляните на требования, которые у вас есть.
  2. Сделайте предположения, чтобы заполнить пробелы, основываясь на ваших лучших предположениях о том, что они хотят.
  3. Запишите все ваши предположения
  4. Заставьте их сесть, прочитать и согласиться с вашими предположениями (или, если вам повезет, заставить их сдаться и дать вам реальные требования).
  5. Теперь у вас есть подробные требования, которые вы можете оценить.

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

ответил Fishtoaster 3 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 03 Sep 2010 18:22:02 +0400 2010, 18:22:02
130

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

  • Я выставил счет за все время, которое я потратил на оценку. Он составил около 20-25% от того, что я выставил.
  • Я очень подробно изучил задачи. Нет стрельбы из бедра. Я вошел в код, выяснил, какие строки нужно изменить, какие другие части программы он затронет, сколько тестов мне нужно будет сделать, чтобы все еще работало. Я бы оценил каждую часть в единицах .1 часа (6 минут).
  • Я отправил ему свою оценку для каждой задачи вместе с этой подробной разбивкой.

20-25% биллинга звучит как много.

Но он попросил меня сделать изменения XYZ, думая, что это займет около 2 часов. Через 1 час детальной оценки я бы определил, что это займет 8,5 часа. Поэтому он решил, стоит ли платить 8,5 часов. Если нет, то он спас 7,5 часа за то, что бы это стоило ему, если бы я сделал это без оценки.

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

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

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

ответил Kyralessa 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 29 Sep 2010 08:29:22 +0400 2010, 08:29:22
54

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

Они почти всегда получают смысл.

ответил Walter 4 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 04 Sep 2010 01:25:04 +0400 2010, 01:25:04
51

Это зависит от того, для чего предназначена оценка.

Для начальной оценки высокого уровня для бизнес-кейса ключевые моменты:

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

Я нахожу лучший метод для выбора сопоставимого проекта, который «чувствует» то же самое. «Чувство» полностью субъективно - но с такой оценкой мой опыт говорит мне, что вы не найдете объективных измерений. Затем обеспечивайте широкий диапазон. Я прочитал несколько книг, которые говорят, что диапазон от -50% до + 100% хорош, но зависит от многих факторов.

Для детальной оценки низкого уровня:

  1. Вам нужна базовая линия. Если базовая линия нестабильна, оценка не имеет смысла.
  2. Внизу лучше. Получите подробную разбивку работы, оцените каждый компонент, а затем сверните его на большее число. Я считаю, что планирование покера - отличная техника здесь.
  3. Непредвиденность документа. Выясните, где добавляется какая-либо непредвиденная ситуация (если таковая имеется). Он добавляется к каждой позиции? Или на всю оценку? Или к конкретным рискам? Или нет?
  4. Укажите свои предположения. Подтвердите как можно больше времени.
  5. Укажите явно, что включено и исключено в оценке. Например, включен ли обзор? Включены ли технические задержки?
ответил darreljnz 18 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 18 Sep 2010 02:50:49 +0400 2010, 02:50:49
18

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

Я сам не пробовал, но хотел бы посмотреть, насколько точны мои оценки.

ответил Richard 4 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 04 Sep 2010 00:42:53 +0400 2010, 00:42:53
17

«Две недели!»

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

Я пытаюсь обойти это, попытаюсь на самом деле подумать о том, как долго я думаю, что что-то предпримет, пытаясь определить все потенциальные пятна и биты, которые выглядят слишком черными для меня для точной оценки. И попытайтесь признать, что если мой ответ «Две недели!», Я, вероятно, не смог этого сделать.

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

ответил BlairHippo 3 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 03 Sep 2010 18:20:10 +0400 2010, 18:20:10
17

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

  

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

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

  

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

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

  

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

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

  

Определение «done», вероятно, неясно: когда это будет сделано?   «Готово», как только что закончил его кодирование, или «сделано», как в «   используя его??

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

  

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

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

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

Между тем, Джо оценивает 5 месяцев. Вы думаете, что это смешно, вы думаете, что можете снять это через неделю. Сколько Джо работает? 10 часов в неделю? ... за исключением того, что он заканчивается вовремя ровно через 5 месяцев.

Угадай, кто воспринимается как осел? Правильно, ты. Джо кажется отличным рабочим, теперь ты казался ненадежным. Это не имеет значения, так что вы могли бы достичь еще лучшего результата в ~ 7% случаев, когда Джо взял. Важно то, что у вас было 3 выходных дня с одной недели.

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

ответил 11 FriEurope/Moscow2015-12-11T08:04:21+03:00Europe/Moscow12bEurope/MoscowFri, 11 Dec 2015 08:04:21 +0300 2015, 08:04:21
10

Это зависит от организации и того, как используются оценки.

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

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

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

ответил g . 3 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 03 Sep 2010 11:17:38 +0400 2010, 11:17:38
8

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

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

ответил Paddyslacker 4 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 04 Sep 2010 01:01:34 +0400 2010, 01:01:34
8

Оценки для чего? Небольшие задачи или комплексные решения.

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

Небольшие задачи - Планирование покера Я нашел работу очень хорошо (не идеально, некоторые задачи 1pt заняли много дольше, а некоторые 5pt заданий занимали минуты, но в итоге все это заканчивается).

ответил mlk 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowWed, 29 Sep 2010 19:50:04 +0400 2010, 19:50:04
7

Уверенно. Я не могу сказать вам, сколько раз я устраивал первоначальную встречу с клиентом, не ставя профессионализм при оценке. Даже если вы продуваете номера из воздуха - убедитесь, что вы всегда держите оценку. Тем не менее, будьте осторожны, чтобы не оценить себя в яме. Различные вещи берут разное количество времени, усилий и ресурсов для объединения. Вот хороший способ сделать это:

  

Им: Сколько это будет стоить?

     

Я: Это зависит от того, что вы хотите от меня. Как правило, я запускаю этот проект примерно в $ X.

ответил Moshe 3 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 03 Sep 2010 18:04:57 +0400 2010, 18:04:57
6

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

Как только мы решили поделиться нашим опытом и знаниями о процессе оценки программного обеспечения и определили четыре различных типа оценок :

  • цифра шара
  • оценка обслуживания
  • оценка функции
  • компонентная оценка

Конечно, эти типы отличаются. Бейсбол - это то, что часто называют â € œguesstimateâ €. . Это приблизительное число или диапазон, который дает общее представление о и это может помочь перспективе решить, хотят ли они продолжить дискуссию.

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

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

Вы можете прочитать больше в нашем блоге!

http://blog.lemberg.co.uk/project-management/software- оценка-процесс /

Надеюсь, эта информация поможет вам!

ответил Olha 13 MarpmTue, 13 Mar 2012 19:46:52 +04002012-03-13T19:46:52+04:0007 2012, 19:46:52
4

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

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

ответил Gopi 3 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 03 Sep 2010 11:32:15 +0400 2010, 11:32:15
4
  

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

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

Некоторые советы, основанные на моем 10-летнем опыте:

  • Всегда предоставлять диапазон (т. е. нижнюю и верхнюю границы). Это сообщит о вашем уровне неопределенности.
  • Если у вас очень большая неопределенность, попросите отсрочку (например, 1 день, чтобы провести анализ, а затем предоставить более жесткий диапазон).
  • Если задача слишком велика, разбейте ее и укажите диапазон для каждой части
ответил jamesfmackenzie 8 22016vEurope/Moscow11bEurope/MoscowTue, 08 Nov 2016 23:52:03 +0300 2016, 23:52:03
1

Если вы делаете много проектов для одного и того же босса или клиента, вы можете попытаться оценить в общих чертах сложности вместо недель или месяцев, возможно, в размерах футболки. Определите несколько прошлых проектов и присвойте им размеры S, M, L, XL.

И тогда спросите себя: какой проект похож на объем? А затем вместо ответа на «2 месяца» вы можете ответить «звучит как L для меня» (или независимо от того, какая ваша калибровка для проекта окажется).

Это довольно легко понять, и также ясно, что в этих догадках есть много неопределенности.

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

ответил moritz 3 SunEurope/Moscow2017-12-03T22:05:34+03:00Europe/Moscow12bEurope/MoscowSun, 03 Dec 2017 22:05:34 +0300 2017, 22:05:34
0

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

ответил xtreampb 14 J000000Thursday16 2016, 18:48:57

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132