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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разбейте свою оценку на:

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

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

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

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

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

Класс А - плюс-минус 10%, финал и вперед или нет. Если это удача, и я слишком далеко отклоняюсь от оценки, я признаюсь часто и рано.

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

Если «Agile» чему-то нас научил, так это тому, что если руководство ожидает, что вы на постоянной основе будете так оценивать проекты, и вы будете «плохо выглядеть», если скажете, что это невозможно предоставить, потому что у вас нет достаточно информации, вы на пути к НЕУДАЧИ.

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

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

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

(Завышено, но незначительно.)

Даже не пытайтесь оценить. Ваша оценка не может быть верной. В конце концов, это всего лишь оценка.

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

Ознакомьтесь с гибкими практиками «Планирование релизов» и «Планирование итераций» для получения более подробной информации об этом подходе.

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

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

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

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

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

На протяжении всего этого вы должны иметь представление о таких вещах, как:

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

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

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

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

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

Большинство менеджеров должны понимать это - спрашивая даты окончания, они на самом деле говорят «дайте нам некоторое представление о том, как мы можем спланировать наш график» и «не просто занимать вечность».

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

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

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

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

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

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

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

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

Павел.

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

Важная часть является доведение до руководства , что оценка является предположением , если они нажмут для более точной оценки или если они пытаются - Боженька - продать вам лимит времени (конечно , это будет только принять вас 2 дней , чтобы построить Starship Enterprise, у вас все хорошо) ДЕРЖИТЕСЬ СВОИМ ОРУЖИЕМ , не ставьте под угрозу свою оценку или тот факт, что она ненадежна.

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

Запишите все это в письменной форме.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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