Правила большого пальца для оценки времени работы в Интернете

Ответ 1

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

Когда я говорю список задач, я имею в виду что-то вроде этого: (это пример, такой же многословный, как по-человечески, особенно на карте сайта)

• Database
  • Таблицы
  • представления
  • Сохраненные процедуры
• Карта сайта
  • Домашняя страница
  • О странице
  • Контактная форма
• Миграция от разработки к производству
  • Самотестирование
  • Клиент-тестирование
  • Ошибка фиксации

Я всегда оцениваю время по часам. (не 15-30-минутные блоки)

Ответ 2

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

Ответ 3

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

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

Это в значительной степени психологический. Мы знаем, что в качестве программистов/дизайнеров/архитекторов мы оптимисты. Когда мы даем себе длинную, туманную цель, чтобы попасть, невероятно легко чувствовать, что мы опережаем игру, хотя на самом деле мы этого не делаем. Еще 4 недели? И все, что мне нужно сделать, это исправить неисправную функцию поиска, которая работала на прошлой неделе? Это просто! Отложите это в сторону и поработайте над некоторыми эффектами Fade Ajax.

Сказав это, существует особая эвристика, которую я часто использую для оценок "назад-о-огибающей", и позвольте мне быть предельно ясными, что они никогда не были посвящены или использовались в проектных планах - это просто способы помочь ответить на вопрос, который всегда задают клиенты и менеджеры ", поэтому позвольте сказать, что мы хотим сделать <some_vague_project>, как долго вы думаете, что это займет?"

Сначала я определяю некоторые аспекты проекта, а именно:

• Ожидаемое время жизни - однократное, временное или постоянное?
• Оригинальность проекта - мы уже делали что-либо подобное раньше?
• Уровень знаний о домене, который требуется по сравнению с известными, - имеют ли характеристики спецификации кривая обучения?
• Волатильность - насколько прозрачна область действия/права собственности, насколько она может измениться?
• Impact - будет ли она поддерживать/заменять критическую бизнес-функцию?
• сложность интерфейса - менее 5 экранов, менее 20 и более?
• Это клиент? (Если это так, вам нужно будет пройти через миллион ревизий).
• Нужно ли взаимодействовать с другими системами?

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

• Нет баллов: 1-2 дня (a script)
• 1 балл: 1-2 недели
• 2 балла: 2-4 недели
• 3 балла: 1-2 месяца
• 4 балла: 3-6 месяцев
• 5 баллов: 6-12 месяцев
• 6 или более баллов: нет подсказки.

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

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

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

Ответ 4

Методы гибкой оценки предлагают следующие методы:

• Назначьте измерение относительного размера каждой из ваших идентифицированных "функций". Подумайте о функции (login), а не о слое/задаче (таблица для хранения учетных данных). Размеры T-Shirt хорошо работают - S, M, L, XL

• Возьмите функцию размера M и определите то, что команда уже поставила в желаемой технологии - используйте это как ожидаемую калибровочную меру. Итак, история вашей команды показывает, что она может доставить функцию M за 2 недели. Используя S = 1/2M, L = 2M, XL = 4M, вычислите ожидаемую длину проекта.

• Если ваша команда еще не сделала что-то сопоставимое; выберите функцию и реализуйте ее вместе.

• НИКОГДА не цитируйте ваш расчет как момент времени - всегда указывайте его как диапазон, с большим диапазоном, указывающим на меньшую уверенность. (обратите внимание, как MS только прогнозирует, в каком году что-то будет выпущено!)

Все, что было сказано, считали ли вы, что вы можете задавать неправильный вопрос? Сколько вы готовы рисковать?

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

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

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

Ответ 5

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

Также старайтесь быть подробными, когда указываете проект и задачи. Если у вас есть задачи типа "Сделайте что-нибудь, 30 часов", вы должны быть осторожны. Обычно я пытаюсь разделить оценки, которые превышают один рабочий день (5-7 часов).

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

Ответ 6

Что вы после звуков, несколько похожих на старый метод оценки, называемый Function Point Analysis. Каждое требование было идентифицировано и охарактеризовано как тип (например, экран ввода). Затем им был присвоен рейтинг сложности, высокий, средний или низкий. Каждому типу и сложности присвоено числовое значение, и вся партия была добавлена, чтобы дать вам общее количество очков для системы.

Затем вы применили модификатор к итогу функции, чтобы преобразовать его в часы работы. Модификатор учитывал бы используемые инструменты, а также (потенциально) навыки разработчиков.

Система была велика в теории. Трюк придумал правильный модификатор. На практике вы получили бы достаточно хорошую оценку после того, как сделали бы 3 или 4 проекта, и затем могли бы рассчитать модификатор, основанный на прошлом опыте.

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

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

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

Ответ 7

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

• Разбить проект на функции, где каждая функция является конкретной, измеримой, достижимой и реалистичной.
• Дайте каждой функции размер футболки: очень маленький, маленький, средний, большой, xl, xxl.
• В этот момент, если можно, договоритесь с клиентом, чтобы уменьшить количество функций XL до минимума.
• Создайте подпрограммы, разбивая каждую функцию на подзадачи.
• Размер футболки каждой подзадачи.
• Повторите шаги 2-5 на этот раз, пытаясь уменьшить количество функций большого размера, сделайте это, пока не получите минимальную минимальную сумму, необходимую для версии 1.
• Пройдите через каждую функцию, дающую каждому оценку времени.
• Суммируйте свои оценки.

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

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

Я настоятельно рекомендую взять эту информацию и поместить ее в нечто вроде (fogbugz) [www.fogbugz.com]. Затем вы можете пометить свое фактическое время по сравнению с расчетным временем, чтобы получить представление о том, когда будет реальна дата вашего корабля.

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

Удачи вам в проекте, я надеюсь, что он отправится вовремя!

Ответ 8

Не тратьте время на оценку.

• Попробуйте разбить все на задачи, где самый длинный не более недели
• Никакая функция не принимает меньше 1/2 в день.
• добавить случайное число неизвестных задач для вещей, о которых никто не думал (известные неизвестные)
• добавить все и умножить результат на 3.

Кроме того, всегда помните Месяц Мифического Человека и/или Код Завершен, что чем больше людей в проекте, тем менее эффективен любой отдельный человек.

Еще лучше, перейдите на Agile.

Ответ 9

Мои эмпирические правила:

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

• Умножение общего оценочного времени на 2 , по крайней мере, и даже на самый простой проект, а на 3 или 4 для более крупных проектов или более сложных, или вещей, которые я новый для.

• Использование "Punchclock" с функцией паузы - не куплено, всего лишь js script - если я работаю над 3 проектами, у меня есть 3 часа пробивки, поэтому я измеряю потраченное время. Это может привести к неожиданным результатам, поскольку, как я думаю, большинство из нас не имеет понятия, сколько времени нам нужно для чего-то... да, мы думаем, что знаем, но попытаемся измерить - вы можете также обнаружить, что вы быстрее, чем вы думаю

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

Ответ 10

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

Ответ 11

IMHO потребуется около 500 +/- 100 часов, чтобы закодировать приложение, а еще 300 - для тестирования тестов, а затем 500 для запуска тестов и приложений в дикой природе. поэтому для 3 опытных и организованных разработчиков это займет около 3 месяцев:), но это только оценивает.

Ответ 12

Учитывая, что у вас есть

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

то можете ли вы сломать проект в небольших проектах в гибкой манере? Решите заранее по графику доставки (каждые 3 недели?), Назначьте приоритеты для использования, время первой доставки, чтобы вы могли это сделать, и иметь свободную оценку/план на последующих итерациях - и повторно обсуждать приоритеты на каждой итерации. Скорее всего, ваш клиент все равно изменит свое мнение по пути, так что вы могли бы также создать регулярную обратную связь/дискуссию в этом процессе. Легче получить правильное время на небольших кусках.
Если вы не можете этого сделать, перейдите на вариант Сэма - найдите время, чтобы построить хорошие оценки.

Ответ 13

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

• Время развертывания (включая несколько, dev, stage, production и т.д.)
• Модульные тесты
• Моделирование БД
• Настройка решения
• Модель модели домена

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

[edit]

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

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

Ответ 14

Сколько людей нанимают для запуска?

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

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

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

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

Ответ 15

Пойдите со своей кишкой, а затем добавьте к ней 3 месяца