Расчет времени программирования проекта
Как ведущий разработчик, я часто получаю спецификации для нового проекта, и меня спрашивают, сколько времени потребуется, чтобы завершить программирование с точки зрения количества часов.
Мне просто интересно, как другие разработчики рассчитывают эти времена точно?
Спасибо!
О, и я надеюсь, что это не считается спорным вопросом, мне просто интересно найти лучшую технику!
6 ответов
Оценка часто считается черным искусством, но на самом деле она гораздо более управляема, чем думают люди.
В Inntec мы занимаемся разработкой программного обеспечения по контракту, большинство из которых включает работу по фиксированной цене. Если бы наши оценки постоянно отклонялись, мы бы разорились.
Но мы занимаемся бизнесом уже 15 лет, и мы прибыльны, так что вся эта оценка вполне разрешима.
Начиная
Большинство людей, которые настаивают на том, что оценка невозможна, делают дикие догадки. Это может работать время от времени для самых маленьких проектов, но это определенно не масштабируется. Чтобы получить постоянную точность, вам нужен системный подход.
Несколько лет назад мой наставник рассказал мне, что сработало для него. Это очень похоже на старый метод оценки Джоэла Спольски, о котором вы можете прочитать здесь: Джоэл об оценке. Это простой, низкотехнологичный подход, и он отлично работает для небольших команд. Он может сломаться или потребовать модификации для более крупных команд, где затраты на общение и процессы начинают занимать значительный процент времени каждого разработчика.
В двух словах, я использую электронную таблицу, чтобы разбить проект на маленькие (менее 8 часов) куски, учитывая все, от тестирования до обмена информацией и документации. В конце я добавляю множитель 20% для непредвиденных предметов и ошибок (которые мы должны исправить бесплатно в течение 30 дней).
Очень сложно убедить кого-либо в том, что он не участвовал в разработке. Некоторым людям нравится, когда целая команда оценивает каждый предмет и идет с наибольшим количеством. Я бы сказал, что, по крайней мере, вы должны делать пессимистичные оценки и дать своей команде возможность высказаться, если они считают, что вас нет.
Обучение и улучшение
Вам нужна обратная связь для улучшения. Это означает отслеживание фактических часов, которые вы проводите, чтобы вы могли сравнить и настроить смысл оценки.
Прямо сейчас в Inntec, прежде чем мы начнем работу над большим проектом, позиции электронных таблиц становятся заметками на нашей доске канбан, и менеджер проекта отслеживает их выполнение каждый день. Каждый раз, когда мы переходим или имеем предмет, который не рассматривали, он выглядит как крошечная красная наклейка, и это также входит в наш отчет о сгорании. Эти два инструмента вместе обеспечивают бесценную обратную связь для всей команды.
Вот фотография типичной канбан-доски, примерно в середине небольшого проекта.
Возможно, вы не сможете прочитать заголовки столбцов, но они говорят "Бэклог", "Брайан", "Кит" и "Готово". Отставание разбито по группам (область администратора и т. Д.), И у разработчиков есть столбец, в котором показаны элементы, над которыми они работают.
Если бы вы могли присмотреться, на всех этих записях указано приблизительное количество часов, а те, что в моей колонке, если бы вы их сложили, должны были равняться примерно 8, поскольку это количество часов в моем рабочем дне. Это необычно иметь четыре в один день. Колонна Кейта пуста, поэтому он, вероятно, отсутствовал в этот день.
Если вы не понимаете, о чем я говорю: повторные встречи, разборки, отчеты об утомлении и т. Д., То взгляните на методологию разборки. Мы не следуем этому письму, но у него есть некоторые отличные идеи не только для выполнения оценок, но и для того, чтобы узнать, как предсказать, когда ваш проект будет отправлен, когда добавляется новая работа, а оценки пропускаются или встречаются или превышаются (это случается). Вы можете взглянуть на этот удивительный инструмент, который называется отчетом об истечении срока службы, и сказать: мы действительно можем отправить его за один месяц, а давайте посмотрим на наш отчет об истечении срока службы, чтобы решить, какие функции мы сокращаем.
В FogBugz есть что-то под названием "Планирование на основе фактических данных", которое может быть более простым, более автоматизированным способом получения преимуществ, которые я описал выше. Прямо сейчас я пробую это на небольшом проекте, который начнется через несколько недель. Он имеет встроенный отчет о сгорании и адаптируется к вашим неточностям в планировании, так что это может быть достаточно мощным.
Обновление: просто быстрая заметка. Прошло несколько лет, но до сих пор я думаю, что все в этом посте все еще сохраняется сегодня. Я обновил его, чтобы использовать слово канбан, так как изображение выше на самом деле является доской канбан.
Там нет общей техники. Вам придется полагаться на свой опыт (и опыт ваших разработчиков). Вам также нужно будет учесть все переменные среды и процесса разработки. И даже если вы справитесь с этим, есть большая вероятность, что вы что-то упустите.
Я не вижу смысла в оценке только времени программирования. Процесс разработки настолько взаимосвязан, что оценка одной его стороны не даст какого-либо ценного результата. Следует оценивать все это, включая программирование, тестирование, развертывание, разработку архитектуры, написание документации (технические документы и руководство пользователя), создание заявок и управление ими в системе отслеживания проблем, встречи, отпуска, больничные листы (иногда приходится ждать парень, затем назначение задачи другому), планирование сессий, кофе-брейки.
Вот пример: яйцо поджаривается всего за 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 Методологиях), чтобы определить нашу временную шкалу. Мы разбиваем проекты на компоненты и переоцениваем эти компоненты. Сумма этих оценок используется и добавляет дополнительное время для регрессионного тестирования и развертывания, и всю хорошую работу....
Я думаю, что вы должны вернуться к своим прошлым проектам и учиться на этих ошибках, чтобы увидеть, как вы можете оценить с умом.