Как вы даете правильную оценку времени для чего-то, что вы никогда не делали? [закрыто]

Вы можете скомпилировать C и / или (древний диалект) C ++ в 16-разрядный файл MS-DOS .com. Компилятор / компоновщик, который у вас есть с Code :: Blocks, почти наверняка не может делать это.

В частности, по крайней мере, насколько мне известно, gcc даже не пыталась генерировать код для 16-разрядной среды с сегментированной памятью. Был хотя бы один порт gcc для расширителя DOS ( DJGPP , но он создает файлы .exe, а не .com, и он использует собственный расширитель DOS вместе с древним версия gcc).

Если вам действительно нужно сгенерировать файл .com, существует довольно много опций, но все компиляторы довольно старые, поэтому особенно в отношении C ++ язык, который они принимают, довольно Ограниченный.

Цепочки инструментов, которые нацелены (ed) MS-DOS.

Предостережение. Как уже отмечалось, все это very old. Вообще говоря, C, которые они принимают, являются разумно совместимыми C89, но только для довольно небольших программ (как с точки зрения кода, так и размера данных - по необходимости: .com-файлы в основном ограничены суммарной суммой 64 Кбайт данных и кода). Различия между C ++, которые они принимают, и что-то даже близкое к современному, гораздо более глубокое (например, некоторые не поддерживали шаблоны вообще ). Все упоминание о соответствии здесь относительно других компиляторов того времени; по современным стандартам, их соответствие равномерно ужасно.

  1. Microsoft: только продал компиляторы C ++ для MS-DOS в течение довольно короткого времени - они несколько опоздали на рынок и вышли из него для компиляторов, которые выпустили только 32-разрядные исполняемые файлы Windows довольно рано. Известно больше для оптимизации, чем соответствия языков.
  2. Borland: Зеркальное изображение Microsoft. Лучшее соответствие, более низкая оптимизация, возможно, последняя, ​​чтобы отказаться от рынка MS-DOS. Их последние несколько компиляторов для MS-DOS даже поддерживали шаблоны C ++ (довольно новые в то время).
  3. Watcom: один из немногих, который по-прежнему доступен , как бесплатная загрузка, но без коммерческая поддержка. Когда это было новым, это, как правило, считалось одним из лучших доступных как для соответствия, так и для оптимизации.
  4. Metaware: Довольно дорогостоящий вариант в то время. Я никогда не использовал его, но некоторые люди, которых я уважал, считали его лучшим компилятором, которого вы могли бы получить. В основном предназначенные встроенные системы.
  5. Datalight / Zortech / Symantec / Digital Mars: еще один официально доступен . Был небольшой, но чрезвычайно преданный. Некоторое время я это пробовал, но никогда не нашел веских оснований предпочитать его другим.

Тогда было еще немало, но они, вероятно, составляют более 90% рынка в то время.

30
задан Refracted Paladin 8 April 2009 в 16:27
поделиться

13 ответов

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

Если вы очень ясно даете понять, что:

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

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

30
ответ дан Jon Skeet 27 November 2019 в 23:58
поделиться

Вы можете сказать: «Я не знаю, у меня недостаточно доказательств»

Тогда сделайте несколько прототипов, чтобы получить некоторые доказательства.

Затем ответьте на вопрос.

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

6
ответ дан DanSingerman 27 November 2019 в 23:58
поделиться

IMO Joel is way, way off in his article, and his conclusions and recommendations are not based on any reality. (Sorry, Joel) Fundamentally he says that you should be able to schedule your work down to units of time of hours or less before you even begin. But the reality is you don't know what those units of work are all going to be (in non-trivial systems) before you get in to the code. So you can't come up with an hour-by-hour breakdown of what you're going to do before you even pop the hood and have that breakdown reflect what actually happens with any accuracy.

Giving a project estimate is very difficult if you want that estimate to be of any value. Coming up with accurate estimates is difficult for programmers because very often you don't discover all the complexities of the project until you get under the hood.

So the solution to this is to get under the hood when coming up with estimates. For smaller projects & bug fixes this is fairly straightforward:

  • Replicate the bug on your machine.
  • Find the code that is causing the bug.
  • Figure out how to write the code that will fix the bug.
  • Estimate how long it will take you to write that code.

In finding the code you have to write you necessarily must discover most or all the complexities that would have thrown off your estimate.

The interesting thing about this method is that the time it takes to generate the estimate is very often 90% of the total time to actually do the work. You practically have to do the work in order to come up with an estimate. With bug fixes especially, the solution is often on the order of one line of code, so your estimate will end up being 5 minutes. That's fine because deadlines can be set around estimates like that.

As you get practice with this you will get better and better at "just knowing" how long things will take. At first you'll only be able to "just know" how long the smallest projects will take. But over time you will be able to estimate larger & larger projects.

5
ответ дан John Dibling 27 November 2019 в 23:58
поделиться

Сначала я основываю свою оценку на моя осознанная сложность проблемы. Насколько велика проблема. Сколько штук это может коснуться или потребовать. Это дает мне общее руководство. Затем я всегда убеждаюсь, что добавляю коэффициент выдумки 15-25%, потому что вы что-то пропустите.

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

Также не давайте грубых оценок с очень точными приращениями. 4,5 часа не является грубой оценкой. Полдня - приблизительная оценка.

3
ответ дан JoshBerke 27 November 2019 в 23:58
поделиться

Although it is very rough, I estimate on Lines of Code. This parameter, whose meaning for productivity is close to zero, still gives you an idea of the complexity of a project.

Measure the fact that on average, a developer can write circa 200, max 300 lines of code per day. Keep into account that just for coding of a single man army:

  • A small project of 1000 lines of (logic) code can be done in one or two weeks
  • An average complexity project of 10.000 lines of (logic) code could be completed in two or three months.
  • A large project of 100.000 lines of (logic) code requires at least a couple of years

To the logic code, you have to add the testing, which is already included in the previous estimates. To have a clue of the complexity, the Gimp is 600.000 lines of code, a kernel ranges in the million or more.

To this, add the fact that if you are working waterfall, the time you need to develop the code is actually a small part of the time needed to develop specifications and design. I would estimate a 2/3 time is for specs+design, and the remaining 1/3 goes in coding, maybe even more on the specs+design part. It is really time consuming.

So, track your estimate from the complexity, to the lines of code, consider the manpower you have and how much they can work in parallel, and add the overhead of specs+design, you will get a very rough estimate.

I suggest you the mythical man month. It is a fantastic book on this regard.

3
ответ дан Stefano Borini 27 November 2019 в 23:58
поделиться

Лично я представляю оценку как статистическое распределение - и пытаюсь донести до нее идею стандартного отклонения:

10 - «вероятность того, что он будет между 8 и 12, составляет 50%»

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

(Кроме того, оценка НЕ ​​должна быть вовлечена в результаты - в противном случае она получает дополняется до смерти и становится бесполезным)

1
ответ дан ptyx 27 November 2019 в 23:58
поделиться

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

1
ответ дан MissT 27 November 2019 в 23:58
поделиться

Для опытного программиста, который хотя бы знает систему и имеет перед собой ряд разумных требований ", я не знаю "не является правильным ответом. Если вы говорите, что не знаете, что ваш PHB уйдет и применит их 1337 h4x0r sk1lz и сделает оценку в следующем порядке: «Это звучит как кусок пирога, как насчет 1 часа».

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

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

1
ответ дан Adam Hawes 27 November 2019 в 23:58
поделиться

I do this all the time. ALmost everything I do is the first time. How do I estimate ? I guess! And then I guess again. And I keep doing that each delta-time interval that a schedule is reworked, because project plans are iterative and you only what you know when you are doing it. My guesses are pretty good tho because I have, after many many years, figured out what 'looks' easy and what 'looks hard'

0
ответ дан Scott Evernden 27 November 2019 в 23:58
поделиться

Предоставьте приблизительную оценку и четко определитесь с этим.

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

Используйте короткие итерации. Рассмотрите / проанализируйте, как промежуточные выпуски соответствуют 2-6-недельным итерациям. Примите во внимание полученные уроки и скорректируйте общую оценку.

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

0
ответ дан eglasius 27 November 2019 в 23:58
поделиться

Попробуйте Анализ функциональных точек . Для вещей CRUD это дает хорошие приблизительные цифры. Главное его преимущество в том, что оно основано не на том, что вы собираетесь реализовать, а на том, о чем просил пользователь. Вам нужно будет выяснить, какова ваша производительность FP. Для этого вы можете использовать прошлые проекты на одном языке.

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

Теперь учтите, что FPA плохо работает с алгоритмически тяжелым программным обеспечением и полагается на AVERAGES, что означает, что вы, вероятно, переоценивать или недооценивать каждый проект.

0
ответ дан Daniel C. Sobral 27 November 2019 в 23:58
поделиться

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

0
ответ дан 27 November 2019 в 23:58
поделиться

Любая неизвестная задача или работа всегда имеет что-то, что известно в определенной степени и легко оценить. Я разделяю и сразу оцениваю то, что знаю, и то, что чувствую, что знаю. Остальное честно объявляется тонким пятном, и тогда мы начинаем «торговаться». Если даритель труда доверяет моей компетенции, он будет, кроме моих грубых оценок и рисков - мы работаем вместе. Это никогда не было неудачей, просто потому, что я никогда бы не взялся за задачу, которую не могу поднять или врезаться в землю (чувство кишки?). Если дающий работу не доверяет мне, я всегда рекомендую, кого спросить, и где искать лучший вариант. Тогда мы либо работаем вместе, либо нет. Большую часть времени мы делаем, но все в безопасности. Я делаю свою работу, «специалист по тонким точкам» получает свою работу, менеджеры довольны, а клиенты довольны. Возможно, это немного наивно, но у меня это работает :)

0
ответ дан 27 November 2019 в 23:58
поделиться
Другие вопросы по тегам:

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