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

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

a) изготовление другой 11К зонтики таже как 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 человек, сколько времени, по их мнению, это займет, и усредните их оценки. Майк Кон Планирование Покер - это, я думаю, очень подобно этому, хотя трудно планировать только с одним разработчиком.

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

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

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

Я использую определенную систему маркировки для своих оценок... класс А, класс В и класс С.--1-->

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

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

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

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

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

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

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

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

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

даже не пытайтесь оценить. Ваша оценка не может быть верной. Это ведь просто оценка.

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

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

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

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

EDIT: вы также можете увидеть,если вы можете получить более "итеративный" срок. В разделе " прагматическое мышление и Обучение", Энди Хант делает хороший момент, что люди являются экспертами проекта ближе к концу проекта и наименее осведомлены в самом начале. Не имеет смысла делать ВСЮ оценку вашего дизайна и времени в самом начале, когда все наименее осведомлены о проекте. Если вы "повторяете" сроки и решаете проблему кусками, у вас будет больше успеха.

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

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

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

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

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

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

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

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

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

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

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

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

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

Павел.

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

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

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

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

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

важная часть сообщает руководству, что оценка является Угадай, если они настаивают на более точной оценке или если они пытаются-Дорогой Бог -продать вы ограничение по времени (конечно, это только забрать вы 2 дня, чтобы построить звездолет Энтерпрайз, ты молодец) ДРЕЙФЬ, не компрометируйте свою оценку или тот факт, что она ненадежна.

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

запишите все это в письменном виде.