Вычисление программирования проекта [закрытых] времен

19
задан Curt 6 August 2010 в 11:57
поделиться

6 ответов

Оценка часто считается черным искусством, но на самом деле она намного более управляема, чем люди думают.

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

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

Приступая к работе

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

Много лет назад мой наставник сказал мне, что сработало для него. Это очень похоже на старый метод оценки Джоэла Спольски, о котором вы можете прочитать здесь: Джоэл об оценке . Это простой и низкотехнологичный подход, который отлично подходит для небольших команд. Он может выйти из строя или потребовать модификации для более крупных команд, где накладные расходы на общение и процессы начинают отнимать значительную часть времени каждого разработчика.

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

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

Обучение и совершенствование

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

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

Вот изображение типичной доски канбан, примерно на середине небольшого проекта.

2011-09-30 10.35.12

Возможно, вы не сможете прочитать заголовки столбцов, но там написано «Бэклог», «Брайан», «Кейт» и «Готово». Бэклог разбит по группам (область администрирования и т. Д.), И у разработчиков есть столбец, в котором показаны элементы, над которыми они работают.

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

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

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

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

19
ответ дан 30 November 2019 в 04:24
поделиться

Хорошая оценка приходит с опытом, а иногда и вовсе не приходит.

На моей нынешней работе двое моих коллег (которые, очевидно, имели гораздо больше опыта, чем я) обычно недооценивали время в 8 (да, ВОСЕМЬ) раз. Я, напротив, за последние 18 месяцев только один раз превысил первоначальную оценку.

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

Итог:

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

1
ответ дан 30 November 2019 в 04:24
поделиться

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

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

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

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

Вот хороший стартовая книга по оценке проектов:

http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

В ней есть хорошее описание нескольких методов оценки. Это поднимет вас за пару часов чтения.

3
ответ дан 30 November 2019 в 04:24
поделиться

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

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

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

0
ответ дан 30 November 2019 в 04:24
поделиться

Если вы используете FogBugz, то его Evidence Based Scheduling делает оценку даты завершения очень простой.

Возможно, это не так, но, возможно, вы сможете применить принципы EBS для составления оценки.

2
ответ дан 30 November 2019 в 04:24
поделиться

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

По сути, вы разбиваете свои этапы на небольшие задачи и прикидываете, сколько времени вам потребуется на их выполнение. Ни одна задача не должна быть длиннее 8 часов. Затем вы вводите все эти задачи как запланированные функции в Fogbugz. Выполняя задачи, вы отслеживаете свое время в FogBugz.

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

1
ответ дан 30 November 2019 в 04:24
поделиться
Другие вопросы по тегам:

Похожие вопросы: