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

Ответ 1

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

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

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

Ответ 2

Я дам вам секрет. Даже если бы вы были экспертом в этой технологии, ваша оценка, скорее всего, будет весьма неточной. Это характер зверя при выполнении чего-то, что является неотъемлемой задачей R & D. К сожалению, руководство часто пытается применить модель производства и требует точных оценок. Чтобы проиллюстрировать мою точку зрения, рассмотрим трудность в точном оценивании следующих двух усилий:

A) Создайте еще 11K зонты, которые точно такие же, как 2K, которые вы выпустили в прошлом месяце. B) Создайте новый вид зонтика и постройте первый.

Разработка программного обеспечения - это B, но они запрашивают оценку, предполагающую A.

Лучшее, что вы можете сделать, это разбить задачу на наименьшие возможные предметы (не более 1/2 дня каждый), а затем утроить окончательный номер, который вы придумали. (Спольский метод)

В качестве альтернативы Стив Макконнелл имеет целую книгу (возможно, несколько) по этому аспекту разработки программного обеспечения. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

Ответ 3

Стив Макконнелл (и другие) рассказывает о конусе неопределенности. В основном вы предоставляете оценку, которая выглядит примерно так:

Работа займет от 3 до 9 недель, причем наиболее вероятно, что 4 недели.

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

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

Ответ 4

Возможно, вам стоит подумать о том, чтобы дать как оценку, так и уровень уверенности, то есть 50/50, что это займет 3-6 месяцев или 6-9 месяцев или 75% шанс сделать за 9 месяцев и 90%, что вы сделаете через год.

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

Ответ 5

Разделите свою оценку на:

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

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

Ответ 6

Я использую определенную систему маркировки для своих оценок... класс A, класс B и класс C.

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

Класс B - плюс или минус 25%. Иногда это достаточно хорошо, и они дают мне деньги на строительство. Если нет, меньше денег и больше исследований.

Класс A - плюс или минус 10%, окончательный и go или no go. Если это заход, и я слишком далеко от оценки, я признаюсь часто и рано.

Ответ 7

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

Если "Agile" научил нас чему-либо, это означает, что если руководство ожидает вас на постоянной основе, чтобы оценить проекты таким образом, и вы будете "выглядеть плохо", если вы скажете, что это невозможно, потому что вы У вас достаточно информации, вы на шоссе до FAIL.

Самая большая проблема - проблемы, которые у вас нет, и которые вы еще не определили. Как часто вы оглядывались назад и говорили себе: "Хорошо, я ударил свою оценку прямо на кнопку - с третьей попытки, после того, как я понял, что... и что мне нужна версия... и что dba будет включен каникулы на неделю и что Менеджер проекта понадобится мне... на неделю и что моя жена беременна и...".

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

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

(завышено, но только немного.)

Ответ 8

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

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

Взгляните на гибкие методы "Планирование выпуска" и "Планирование итерации" для получения более подробной информации об этом подходе.

Ответ 9

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

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

РЕДАКТИРОВАТЬ: Вы также можете увидеть, можете ли вы получить более "итеративный" крайний срок. В "Прагматическом мышлении и обучении" Энди Хант подчеркивает, что люди - эксперты проекта ближе к концу проекта и наименее осведомлены в самом начале. Не имеет смысла делать все ваши расчеты и оценки времени в самом начале, когда все наименее осведомлены о проекте. Если вы "повторите" сроки и решите проблему в кусках, у вас будет больше успеха.

Ответ 10

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

• Сколько времени мне требуется, чтобы изучить новый API?
• Сколько времени мне требуется, чтобы выучить новый язык?
• Сколько времени мне требуется, чтобы изучить новый набор инструментов (компилятор/компоновщик/IDE)?
• Сколько времени мне требуется для выполнения обычной задачи?
• Сколько времени мне требуется для проверки моей работы?
• Сколько времени мне требуется для развертывания моей работы?

Всюду в этом вы должны почувствовать такие вещи, как:

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

Основываясь на всех этих вещах, вы сможете развить чувство того, как долго что-то придет и сможет изложить ваши предположения ( "Предполагая, что API - это разумно..." ) даже перед лицом ужасно неполного Информация.

Ответ 11

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

Ответ 12

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

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

В вашем случае вы, безусловно, захотите получить хотя бы НЕКОТОРНОЕ понимание того, что вы ныряете, прежде чем давать оценку. Возможно, вам даже нужно предоставить оценку того, сколько времени потребуется, чтобы дать оценку. Умножение на 3 помогает счастливым клиентам.

Ответ 13

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

Как только куски достаточно малы, чтобы их можно было рассматривать как отдельные заданные задачи, некоторые из них будут полностью необоснованными. Для тех, кто сначала прототип, или просто оставьте себе некоторое разумное количество времени, в зависимости от размера куска. Если вы обнаружите, что у вас есть неудобные куски, большие, чем за 2-4 недели работы, верните их сначала на измельчение.

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

Если вы не можете сломать задачи, вам нужно нанять кого-то с достаточным опытом, который может (поскольку ваш недостаток опыта будет преследовать вас и другими способами). Если вы не можете нанять кого-то, тогда вам следует просто торговаться в течение случайного периода (от 6 месяцев до 2 лет) и идти прямо в грязный прототип (пока вам не удастся дать себе достаточно опыта, чтобы узнать, что правильно и что неправильно). Но, если вы в конечном итоге сталкиваетесь с этим, важно не позаботиться о себе и подумать, что вы делаете это правильно ". Прототипы должны были быть выброшены. Надеемся, что как только отсчет прототипа завершится, вы готовы построить его для реального.

Павел.

Ответ 14

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

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

Большинство менеджеров должны понимать, что - прося даты окончания, они действительно говорят: "Дайте нам представление о том, как мы можем планировать наш график" и "не просто навсегда".

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

Ответ 15

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

Важная часть заключается в том, чтобы сообщить руководству, что оценка является угадать, если они нажимают для более точной оценки или стараются - дорогой Бог - продать вас (наверняка вам понадобится 2 дня для создания Starship Enterprise, вы хороши, что вы есть) STICK TO YOUR GUNS, не компрометируйте свой оценки или того факта, что она ненадежна.

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

Получите все это в письменном виде.

Ответ 16

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

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

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

Также признайте, что будут некоторые задачи, где все, что вы можете предоставить, - это Wild Ass Guess (WAG). Для этого вы должны установить минимальное время для своей оценки и дать понять, что вы не знаете, что такое max. Часто такая оценка является достаточной причиной для того, чтобы некоторые функции /req были отключены руководством.

Ответ 17

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

Ответ 18

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

Когда вы находитесь в ситуации, подобной этому, проект внезапно становится проектом R & D и более длительным временем, чем обычно, не заставит вас выглядеть плохо, поскольку вы изучаете и выпускаете программы. Я не знаю, как быстро вы учитесь или какие ресурсы у вас есть для решения любых проблем, которые вы можете найти (Qaru - это один из вариантов, который у вас есть).

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

Надеюсь, это поможет!

Ответ 19

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

Одна вещь, которую я хотел бы подчеркнуть, - отслеживать ваши оценки (небольшая электронная таблица Excel a la Joel или даже документ Notepad, если это очень просто), и в конце каждого дня обновлять это до самых точных цифр теперь могут обеспечить. Даже если вам не нужно передавать это обратно своим начальникам, чтобы это было актуально, вы получите лучшее представление о том, как все развивается, и, что более важно, вы получите хорошее представление о том, почему ваша оценка изменяется по мере продвижения работы.

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

Ответ 20

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

Ответ 21

Можете ли вы дать диапазон? 40-60 часов, что-то в этом роде?

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

Посмотрите на любую область, с которой у вас есть опыт, и используйте ее в качестве руководства. "В прошлый раз необходимо создать функцию, которая изменила базу данных, в которой мне понадобился X". Удачи.

Ответ 22

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

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