Являясь ведущим разработчиком, я часто получаю спецификации для нового проекта и спрашиваю, сколько времени потребуется для завершения части программирования, связанной с работой, с точки зрения количества часов.
Мне просто интересно, как другие разработчики правильно вычисляют это время?
Спасибо!
О, и я надеюсь, что это не рассматривается как спорный вопрос, мне просто интересно найти лучшую технику!
Оценка часто считается черным искусством, но на самом деле она намного более управляема, чем люди думают.
В Inntec мы разрабатываем контрактную разработку программного обеспечения, большинство из которых связаны с постоянной фиксированной стоимостью. Если наши оценки будут постоянно удалены, мы не будем в состоянии работать в кратчайшие сроки.
Но мы занимаемся бизнесом уже 15 лет, и мы выгодны, поэтому ясно, что вся эта оценочная вещь разрешима.
Начало работы
Большинство людей, которые настаивают на том, что оценка невозможна, делают дикие догадки. Это может работать спорадически для самых маленьких проектов, но это определенно не масштабируется. Чтобы получить постоянную точность, вам нужен системный подход.
Несколько лет назад мой наставник рассказал мне, что с ним работало. Это очень похоже на старый метод оценки Джоэла Спольского, о котором вы можете прочитать здесь: Joel on Estimation. Это простой, низкотехнологичный подход, и он отлично подходит для небольших команд. Он может разрушаться или требовать модификации для более крупных команд, где накладные расходы на связь и процесс начинают занимать значительный процент от времени каждого разработчика.
Вкратце, я использую электронную таблицу, чтобы разбить проект на небольшие (менее 8 часов) куски, принимая во внимание все: от тестирования до связи с документацией. В конце я добавляю множитель на 20% для неожиданных элементов и ошибок (которые мы должны исправить бесплатно в течение 30 дней).
Очень сложно подвести кого-то к оценке, что они не участвовали в разработке. Некоторым людям нравится, что вся команда оценивает каждый предмет и идет с самым высоким номером. Я бы сказал, что, по крайней мере, вы должны сделать пессимистические оценки и дать вашей команде возможность высказаться, если они думают, что вы ушли.
Обучение и улучшение
Вам нужна обратная связь для улучшения. Это означает отслеживание текущих часов, которые вы проводите, чтобы вы могли сравнить и настроить свой оценочный смысл.
Прямо сейчас, в Inntec, прежде чем мы начнем работу над крупным проектом, позиции электронных таблиц становятся заметными заметками на нашей плате канбана, и руководитель проекта отслеживает прогресс на них каждый день. Каждый раз, когда мы переходим или имеем предмет, который мы не рассматривали, это поднимается как крошечный красный липкий, и он также попадает в наш отчет о выгорании. Эти два инструмента вместе дают бесценную обратную связь всей команде.
Здесь изображена типичная доска для канбанов, примерно на полпути через небольшой проект.
Возможно, вы не сможете прочитать заголовки столбцов, но они говорят, что Backlog, Brian, Keith и Done. Задержка разбивается на группы (область администратора и т.д.), А разработчики имеют столбец, в котором отображаются элементы, над которыми они работают.
Если вы можете присмотреться, у всех этих заметок есть определенное количество часов на них, а те, что в моей колонке, если вы их добавили, должны равняться примерно 8, поскольку это количество часов в моей работе день. Необычно было четыре раза в день. Колонка Кита пуста, поэтому он, вероятно, был в этот день.
Если вы не представляете, что я говорю о повторных встречах, схватках, отчетах о сжигании и т.д., тогда взгляните на методология схватки. Мы не следуем этому письму, но у него есть отличные идеи не только для оценки, но и для того, чтобы узнать, как прогнозировать, когда ваш проект будет поставляться с добавлением новой работы, а оценки будут пропущены или выполнены или превышены (это происходит). Вы можете посмотреть на этот потрясающий инструмент, называемый выгорающим отчетом, и сказать: мы действительно можем отправить его через месяц, и посмотрим на наш отчет о выгорании, чтобы решить, какие функции мы режем.
В FogBugz есть что-то, называемое "Планирование на основе фактических данных", которое может быть более простым и автоматизированным способом получения преимуществ, описанных выше. Сейчас я пробую это в небольшом проекте, который начинается через несколько недель. Он имеет встроенный отчет о сжигании и адаптируется к вашим неточностям планирования, поэтому может быть достаточно мощным.
Обновление: Простое примечание. Прошло несколько лет, но до сих пор я думаю, что все, что в этом посте все еще держится сегодня. Я обновил его, чтобы использовать слово kanban, так как изображение выше на самом деле является доской kanban.
Нет общей техники. Вам придется полагаться на свой опыт (и ваших разработчиков). Вам также необходимо будет учитывать все переменные процесса окружающей среды и процесса разработки. И даже если вы справитесь с этим, есть большой шанс, что вы что-то пропустите.
Я не вижу смысла оценивать время программирования. Процесс разработки настолько взаимосвязан, что оценка одной его стороны не принесет никакого ценного результата. Все это должно быть оценено, в том числе программирование, тестирование, развертывание, разработка архитектуры, написание документа (технические документы и руководство пользователя), создание и управление билетами в трекер, встречи, каникулы, больничные листы (когда-нибудь это ждет парень, затем назначая задачу другому), планирование сеансов, кофе-брейки.
Вот пример: для яйца требуется только 3 минуты, чтобы обжарить, как только вы уронили его на жаровню. Но если вы говорите, что для жареного яйца требуется 3 минуты, вы ошибаетесь. Вы пропустили:
Вот хорошая стартовая книга по оценке проекта:
http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
У этого есть хорошее описание нескольких методов оценки. Это заставило вас за пару часов чтения.
Если вы используете FogBugz, то его На основе фактических данных очень легко оценить дату завершения.
Возможно, вы не можете, но, возможно, вы могли бы применить принципы EBS, чтобы придумать оценку.
Хорошая оценка приходит с опытом, а иногда и вовсе.
На моей нынешней работе мои 2 сотрудника (которые, очевидно, имели намного больше опыта, чем я), обычно недооценивали время на 8 (да, ВОСЬМО) раз. Я, OTOH, только один раз за последние 18 месяцев перешел по первоначальной оценке.
Почему это происходит? Ни один из них, по-видимому, не знал, что они делают, по коду, так что они буквально сосали друг другу.
Нижняя строка:
Не стоит недооценивать, гораздо более безопасно переоценивать. Учитывая последнее, вы всегда можете "ускорить" разработку, если это необходимо. Если вы уже находитесь на жесткой временной линии, вы не можете многое сделать.
Это, вероятно, одна из больших проблем в ИТ-бизнесе. Бесчисленные неудачные программные проекты показали, что пока нет идеального решения, но самое близкое к решению этого, которое я нашел до сих пор, заключается в использовании механизма адаптивной оценки, встроенного в FogBugz.
В основном вы нарушаете свои вехи в небольшие задачи и догадываетесь, сколько времени вам потребуется, чтобы завершить их. Задача не должна превышать примерно 8 часов. Затем вы вводите все эти задачи в виде запланированных функций в Fogbugz. При выполнении задач вы отслеживаете свое время с помощью FogBugz.
Затем Fogbugz оценивает ваши прошлые оценки и фактическое потребление времени и использует эту информацию для прогнозирования окна (с вероятностями), в котором вы выполнили следующие несколько этапов.
Переоценка лучше, чем занижение. Это потому, что мы не знаем "неизвестные" и (в большинстве случаев) спецификации меняются в течение жизненного цикла разработки программного обеспечения.
По моему опыту мы используем итеративные шаги (как и в Agile Methodologies), чтобы определить нашу временную шкалу. Мы разбиваем проекты на компоненты и переоцениваем эти компоненты. Сумма этих оценок используется и добавляет дополнительное время для регрессионного тестирования и развертывания, и вся хорошая работа....
Я думаю, что вам нужно вернуться из своих прошлых проектов и узнать из этих ошибок, чтобы узнать, как вы можете разумно оценить.