Являясь ведущим разработчиком, я часто получаю спецификации для нового проекта и спрашиваю, сколько времени потребуется для завершения части программирования, связанной с работой, с точки зрения количества часов.Расчет времени программирования Программирование
Мне просто интересно, как другие разработчики правильно вычисляют эти времена?
Спасибо!
О, и я надеюсь, что это не рассматривается как спорный вопрос, мне просто интересно найти лучшую технику!
Оценка часто считается черным искусством, но на самом деле она намного более управляема, чем люди думают.
В Inntec мы разрабатываем программное обеспечение для контрактов, большинство из которых связаны с фиксированной стоимостью. Если наши оценки будут постоянно удалены, мы не будем иметь дело в кратчайшие сроки.
Но мы были в бизнесе уже 15 лет, и мы выгодны, поэтому ясно, что вся эта оценочная вещь разрешима.
Начало работы
Большинство людей, которые настаивают, что оценка невозможно делают дикие предположения. Это может работать спорадически для самых маленьких проектов, но это определенно не масштабируется. Чтобы получить постоянную точность, вам нужен системный подход.
Несколько лет назад мой наставник рассказал мне, что с ним работало. Это очень похоже на старый метод оценки Джоэла Спольского, о котором вы можете прочитать здесь: Joel on Estimation. Это простой, низкотехнологичный подход, и он отлично подходит для небольших команд. Он может сломаться или потребовать модификации для более крупных команд, где накладные расходы на связь и процесс начинают занимать значительный процент времени каждого разработчика.
В двух словах я использую электронную таблицу, чтобы разбить проект на небольшие (менее 8 часов) куски, принимая во внимание все: от тестирования до связи с документацией. В конце я добавляю множитель на 20% для неожиданных элементов и ошибок (которые мы должны исправить бесплатно в течение 30 дней).
Очень сложно удержать кого-то в оценке, что они не участвовали в разработке. Некоторым людям нравится, что вся команда оценивает каждый предмет и идет с самым высоким номером. Я бы сказал, что, по крайней мере, вы должны сделать пессимистические оценки и дать вашей команде возможность высказаться, если они думают, что вы ушли.
Обучение и повышение
Вам нужна обратная связь, чтобы улучшить. Это означает отслеживание фактических часов, которые вы проводите, чтобы вы могли провести сравнение и настроить свой оценочный смысл.
Прямо сейчас, в Inntec, прежде чем мы начнем работу над крупным проектом, элементы электронной таблицы становятся заметками на нашей плате канбана, и менеджер проекта отслеживает прогресс на них каждый день. Каждый раз, когда мы переходим или имеем предмет, который мы не рассматривали, это поднимается как крошечный красный липкий, и он также попадает в наш отчет о выгорании. Эти два инструмента вместе дают бесценную обратную связь всей команде.
Вот фотография типичной доски канбана, примерно на полпути через небольшой проект.
Вы не могли бы быть в состоянии прочитать заголовки столбцов, но они говорят Отставание, Брайан, Кит, и Готово. Задержка разбивается на группы (область администратора и т. Д.), А разработчики имеют столбец, в котором отображаются элементы, над которыми они работают.
Если вы можете присмотреться, у всех этих заметок есть расчетное количество часов на них, а те, что в моей колонке, если вы их добавили, должны равняться примерно 8, так как это количество часов в моей рабочий день. Чрезвычайно необычно иметь четыре в один день. Колонка Кита пуста, поэтому он, вероятно, был в этот день.
Если вы не представляете, что я говорю о повторных встречах, встречах, схватках, отчетах о сжигании и т. Д., Тогда взгляните на scrum methodology. Мы не следуем этому письму, но у него есть отличные идеи не только для оценки, но и для того, чтобы узнать, как прогнозировать, когда ваш проект будет поставляться с добавлением новой работы, а оценки будут пропущены или выполнены или превышены (это происходит). Вы можете посмотреть на этот потрясающий инструмент, называемый отчет о выгорании, и сказать: мы действительно можем отправить его через месяц, и давайте посмотрим на наш отчет о выгорании, чтобы решить, какие функции мы режем.
У FogBugz есть что-то, называемое Планирование на основе фактических данных, которое может быть более простым и автоматизированным способом получения преимуществ, описанных выше. Сейчас я пробую это в небольшом проекте, который начинается через несколько недель. Он имеет встроенный отчет о сжигании и адаптируется к вашим неточностям планирования, поэтому это может быть довольно мощным.
Обновление: Простое примечание. Прошло несколько лет, но до сих пор я думаю, что все, что в этом посте все еще держится сегодня. Я обновил его, чтобы использовать слово kanban, так как изображение выше на самом деле является доской kanban.
Я знаю, что вам 3 года, но сможете ли вы вернуть изображение своей проектной доски, которое вы разместили на две трети вниз по своему посту? –
+1, чтобы дать нам хорошую ссылку, например, «Joel on Estimation» – kta
@WilliamGrand Я не мог найти это изображение, но я подключил к нему аналогичный и отредактировал его. –
Хорошая оценка приходит с опытом, а иногда и вовсе.
На моей нынешней работе мои 2 сотрудника (которые, очевидно, имели намного больше опыта, чем я) обычно недооценивали время на 8 (да, ВОСЕМЬ) раз. Я, OTOH, только один раз за последние 18 месяцев перешел по первоначальной оценке.
Почему это происходит? Ни один из них, по-видимому, не знал, что они делают, по коду, так что они буквально сосали.
Итог:
Никогда не стоит недооценивать, это намного безопаснее переоценить. Учитывая последнее, вы всегда можете «ускорить» разработку, если это необходимо. Если вы уже находитесь на жесткой временной линии, вы не можете многое сделать.
Это, вероятно, одно из крупных проблем в ИТ-бизнесе. Бесчисленные неудачные программные проекты показали, что пока нет идеального решения, но самое близкое к решению этого, которое я нашел до сих пор, - использовать механизм адаптивной оценки, встроенный в FogBugz.
В основном вы нарушаете свои вехи в небольшие задачи и догадываетесь, сколько времени вам понадобится, чтобы завершить их. Задача не должна превышать 8 часов. Затем вы вводите все эти задачи в виде запланированных функций в Fogbugz. При выполнении задач вы отслеживаете свое время с помощью FogBugz.
Fogbugz затем оценивает ваши прошлые оценки и фактическое потребление времени и использует эту информацию для прогнозирования окна (с вероятностями), в котором вы выполнили следующие несколько этапов.
Ах, у нас еще есть FogBugz! Раньше мы использовали это, но команда не очень хорошо адаптировалась к нему, поэтому аккаунт был отменен :( – Curt
Если вы используете FogBugz, то его Evidence Based Scheduling очень легко оценивает дату завершения.
Возможно, вы не можете быть, но, возможно, вы можете применить принципы EBS, чтобы придумать оценку.
Завышенная оценка скорее лучше, чем занижение. Это связано с тем, что мы не знаем «неизвестные» и (в большинстве случаев) спецификации меняются в течение жизненного цикла разработки программного обеспечения.
По моему опыту мы используем итеративные шаги (как и в Agile Methodologies), чтобы определить нашу временную шкалу. Мы разбиваем проекты на компоненты и переоцениваем эти компоненты. Сумма этих оценок используется и добавляет дополнительное время для регрессионного тестирования и развертывания, и вся хорошая работа.
Я думаю, что вам нужно вернуться из своих прошлых проектов и узнать из этих ошибок, чтобы узнать, как вы можете разумно оценить.
Нет общей техники. Вам придется полагаться на свой опыт (и ваших разработчиков). Вам также необходимо будет учитывать все переменные процесса окружающей среды и процесса разработки. И даже если вы справитесь с этим, есть большой шанс, что вы что-то пропустите.
Я не вижу смысла оценивать время программирования. Процесс разработки настолько взаимосвязан, что оценка одной его стороны не принесет никакого ценного результата. Все это должно быть оценено, в том числе программирование, тестирование, развертывание, разработка архитектуры, написание документа (технические документы и руководство пользователя), создание и управление билетами в трекер, встречи, каникулы, больничные листы (когда-нибудь это ждет парень, затем назначая задачу другому), планирование сеансов, кофе-брейки.
Вот пример: для того, чтобы яйцо стало жареном, требуется только 3 минуты, как только вы уронили его на жаровню. Но если вы скажете, что для жареного яйца требуется 3 минуты, вы ошибаетесь. Вы пропустили:
Вот хорошая стартовая книга по оценке проекта:?
http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
Он имеет хорошее описание по нескольким методам оценки. Это заставило вас за пару часов чтения.
Просто подумал, что я бы сказал, что у меня есть эта книга, и для моих целей это не очень практично. возможно, некоторые другие люди получили некоторую ценность из этого. –
Задать худший случай оценки и умножить на 5. – Oded
@Oded: По моему опыту, 8 - более безопасное число :) – leppie
@leppie - Я оптимист в глубине души ... – Oded