Как я должен знать, сколько дней что-то предпримет?

Ответ 1

Благодарим вас за все ваши ответы и отзывы.

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

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

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

До сих пор он работал хорошо.

Подробнее: http://www.scrumalliance.org/pages/what_is_scrum, http://www.goodagile.com/scrumprimer/.

Извините, что я отвечу своим ответом, но это то, что сработало для меня.

Ответ 2

Оценка времени сложна.

Но времена, когда я сделал это хорошо, у всех есть пара общих черт:

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

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

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

Ответ 3

Эта статья является хорошим описанием в значительной степени единственного способа узнать, сколько времени займет что-то: http://www.joelonsoftware.com/items/2007/10/26.html

Ответ 4

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

Ответ 5

Лучшие оценки исходят из опыта.

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

Ответ 6

Существует также разница между

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

Об оценке времени, необходимого для чего-то:

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

Через некоторое время, когда его спросят: "Сколько времени вам потребуется, вы это сделаете?", вы сможете подумать:

• ", что" очень похоже на другое, что я делал на проекте X, а также на то, что я сделал на проекте Y
• Я потратил 8 дней на это на проект X, а 6 дней - на проект Y; но было намного проще на Y, потому что у меня уже было некоторое представление о том, как это сделать (уже сделано на X)
• поэтому в этом новом проекте это не должно занимать больше времени, чем на проекте Y
• На самом деле, мне сейчас лучше, опытнее... Так что это займет около 5 дней.
• и не накладывать на себя слишком много давления и не допускать ошибок, вы говорите 6 дней или 6 дней и половину своему боссу.
• и в его голове он добавит еще один день ^^ (или, если он его парень, который сосчитал 4, когда он услышит 6, просто скажите ему 8, и он поймет 6 ^^)

С течением времени вы улучшаетесь и улучшаетесь; и, в конце концов, вы, вероятно, сможете:

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

Ho, и я забыл: я обычно добавляю около 15% "времени разработки" для тестов и исправлений ошибок, btw - это стандартная ставка, для проектов, над которыми я работал, и вообще довольно точный (конечно, для новичка, который, вероятно, создаст больше ошибок, вы добавите немного больше, для опытного разработчика, немного меньше).

Да, конечно, иногда вы будете совершенно неправы; случается, что это: каждый делает ошибки время от времени: -)

О задержке: хорошо, я вообще говорю моему боссу: "Мне нужно взять X дней, если мне не нужно что-то делать"; тогда, если мой босс попросит меня сделать что-то еще в течение 2 дней в середине моей задачи, это "его ошибка" ^^

Когда я работаю один в проекте или являюсь "моим собственным боссом", я обычно знаю, сколько времени мне приходится тратить на "другие вещи".
В проекте, над которым я работал некоторое время назад, я рассказывал клиенту: "Мне нужно 5 дней, чтобы сделать это, но, учитывая, что я обычно трачу половину своего времени на то, чтобы не планировать, подумайте, что мне понадобится 10 дней" - через некоторое время вы привыкли считать это ^^

Ответ 7

• Просить процитировать в днях смешно, самое лучшее, что вы можете сделать, это оценить.
• Постарайтесь во что бы то ни стало, чтобы избежать принуждения к откровению, вы почти наверняка ошибаетесь. Покупка некоторого времени для лучшей оценки всегда является лучшей идеей.
• Если вы имеете дело с изменением или взаимодействием с каким-то кодом, с которым у вас нет предыдущего опыта, попробуйте дать оценку того, сколько времени потребуется, чтобы определить, как сделать то, что вам нужно, а затем вернуться к ним, когда вы точно знаете, что вам нужно делать с оценкой того, как долго.
• То же самое относится к тем, что вы никогда не делали раньше, скорее всего, скорее всего, скорее скажете, если вы сделаете некоторое исследование того, как другие проблемы были решены другими.
• Разделите свои задачи на меньшие куски (как можно меньше), чтобы более точно оценить. Таким образом, вы можете сказать что-то вроде "Я думаю, что A, B и C займут около 6 дней, но D - это то, что мне нужно будет смотреть". Это звучит намного лучше, чем "я понятия не имею" или "пока это требуется".
• Вы не можете оценить время, которое потребуется, чтобы найти ошибку. Вы можете оценить, сколько времени потребуется, чтобы исправить это. Жесткая ошибка может занять 2-3 дня, чтобы отследить и исправить. Ошибки в коде, который вы уже доставили, будут потреблять ваше время на последующих разработках.
• Всегда сообщайте им, когда вы сталкиваетесь с проблемой, которая заставит ваш срок проскочить задолго до вашего крайнего срока. Таким образом, ваш босс предупреждается, когда разговаривает со своим боссом/клиентом.
• Если вы оцениваете и достаточно повезло, чтобы иметь дополнительное время, либо проверьте его еще немного, либо используйте время для разработки чего-то еще, что будет полезно для вашей производительности в качестве разработчика.
• Если вы постоянно подвергаетесь издевательствам, соглашаетесь на суровые сроки, постоянно изводите или чувствуете, что ваши объяснения получаются так, как будто они были откровенной ложью, затем спокойно начинайте искать другую работу в фирме, которая понимает управление проектами программного обеспечения, прежде чем ваше здоровье неизбежно пострадает.

Ответ 8

Закон о тайм-менеджменте Мерфи:

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

Затем умножьте это на 2.

Затем перейдите к следующей более высокой единице времени.

Таким образом, если проект должен принять один день, он, вероятно, будет занял две недели.

Ответ 9

Лучший совет, который я могу дать, - это разбить задачу на более мелкие части, а затем оценить их. Возможно, приложите "доверительный" процент к каждой подзадаче, чтобы рассчитать оптимистичный и пессимистический диапазон. Таким образом, когда ваш босс говорит "5-8 дней? Это мне совсем не помогает, где вы придумываете эти цифры!?!?" вы просто покажите ему свою разбивку, и у вас есть оправдание. Компетентный менеджер должен положить ваш прикладом на линию за то, что вы совершаете, а не то, что вы отвлекаете, чтобы быть издевательством за совершение.

Ответ 10

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

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

С течением времени используйте их, чтобы помочь вам пересмотреть свои оценки. Например, последние несколько раз я оценил 5-дневную задачу, которая была средней сложности (скажем, 5 из 10), я был отключен в среднем на 5 дней.

С этим я собираюсь оценить 10 дней на этом и посмотреть, что произойдет.:)

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

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

Ответ 11

Некоторые мысли об оценке:

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

Ответ 12

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

Основные шаги:

• разбивайте куски на понятные/работоспособные куски (посмотрите на структуры рабочих прерываний)
• если есть элемент, который вам нужен для дополнительной информации, обратите внимание на него и убедитесь, что вы сообщаете своему менеджеру как можно скорее
• часть, которую у вас есть, должна включать элементы, которые, как и другие, которые вы делали раньше, - что должно облегчить представление об этих предметах, у вас есть некоторая "грубая" идея о том, как долго она ДОЛЖНА взять (добавить % на ваше время реакции на кишку, основанное на вашем уровне комфорта - скажем, где-то между 10% и 30%), и те предметы, которые вам просто нужно угадать (добавьте диапазон% к тем, которые могут быть от 30% до 500%)
• укажите список результатов вместе в электронной таблице, назовите каждый элемент, уровень комфорта завершения (от высокого до низкого), время вашего времени - это может быть диапазон (от 1 дня до 5 дней) и любые примечания которые могут включать вопросы и предположения.
• сообщите об этом своему менеджеру и обсудите

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

Ответ 13

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

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

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

Ответ 14

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

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

Ответ 15

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

Таким образом, если вы закончите намного ниже своего ожидаемого времени, вы будете похожи на героя!: P

Ответ 16

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

Ответ 17

Я бы сделал две вещи:

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