Эмпирические правила для оценки веб-приложения [закрытые] часы

Перейти с вашим кишечником, а затем добавьте через 3 месяца

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

1. Время развертывания (включает несколько; dev, stage, production и т.д.)
2. Unit tests
3. DB modeling
4. Solution setup
5. Domain model pattern

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

[редактировать]

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

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

Сколько людей нанимать на стартап?

Вы не готовы нанять кого-либо, пока у вас нет партии (выберите свой словарный запас, пользовательские истории, точки функции, ...)

, так что, возможно, вам нужно Начать с помощью владельца проекта сделать этот уровень анализа.

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

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

ИМХО. Это потребуется около 500 +/- 100 часов, чтобы кодировать приложение и еще 300 для кодирования тестов и снова 500 для запуска тестов и приложения в дикой природе. Таким образом, для 3 квалифицированных и организованных разработчиков займет около 3 месяцев :) Но это только оценка.

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

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

Система была велика в теории. Трюк придумал правильный модификатор. На практике вы получите бы разумно хорошую оценку после того, как вы сделали 3 или 4 проекта, и затем могли затем рассчитать модификатор на основе прошлого опыта.

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

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

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

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

Также постарайтесь быть подробным при указании проекта и задач. Если у вас есть задачи типа "Сделайте что-нибудь, 30 часов", вы должны быть осторожны. Обычно я стараюсь разделить оценки, которые больше одного рабочего дня (5-7 часов).

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

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

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

Это в значительной степени психологическое. Мы знаем, что как программисты/дизайнеры/архитекторы мы оптимисты. Когда мы даем себе длинную, туманную мишень для удара, невероятно легко почувствовать, что мы опережаем игру, даже если на самом деле это не так. Еще 4 недели? И все, что мне нужно сделать, это исправить сломанную функцию поиска, которая работала на прошлой неделе? Это просто! Давайте отложим это в сторону и поработаем над забавными эффектами "Аякса".

Сказав это, есть особый эвристический подход, который я часто использую для оценки задней части проекта, и позвольте мне быть предельно ясным, что это , которые на самом деле никогда не использовались в планах проекта - это просто способы помочь ответить на вопрос, который всегда задают заказчики и менеджеры: "Скажем, мы хотим сделать <соме_vague_project>, как вы думаете, сколько времени это займёт? "

Сначала я определяю некоторые аспекты проекта, а именно:

• Ожидаемая продолжительность жизни - run-once, временная или постоянная?
• Оригинальность проекта - делали ли мы что-нибудь подобное раньше?
• Уровень требуемых доменных знаний в сравнении с известными - есть ли у спецификаций кривая обучения?
• Волатильность - насколько ясен объем/область собственности, насколько вероятно ее изменение?
• Влияние - будет ли она поддерживать/заменять критически важную бизнес-функцию?
• Сложность пользовательского интерфейса - менее 5 экранов, менее 20 или более?
• Облик с заказчиком? (Если так, то ей придется пройти через миллион ревизий)
• Нужно ли ей взаимодействовать с какими-нибудь другими системами?

Тогда я обычно присваиваю "очки" каждой из них (обратите внимание, что это не "система", все это происходит у меня в голове и обычно требует тонкой настройки). Суммируйте точки для приблизительного размера проекта:

• Нет точек: 1-2 дня (сценарий)
• 1 балл: 1-2 недели
• 2 балла: 2-4 недели
• 3 балла: 1-2 месяца
• 4 балла: 3-6 месяцев
• 5 баллов: 6-12 месяцев
• 6 или более баллов: Без понятия.

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

Хочу повторить для протокола, что это не имеет практического применения в реальном проектном плане, и я бы никогда не взял на себя обязательства по срокам проекта, не разбив всю спецификацию на задачи с максимальным размером 1-2 дня. Это только для того, чтобы отвечать на быстрые, нестандартные вопросы, когда заказчики/менеджеры эффективно просят меня подсчитать в моей голове и не желают принимать "я не знаю" за ответ.

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

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

1. нарушает проект в функции, где каждая функция является специфической, измеримой, достижимой и реализованной.
2. Дайте каждую функцию размера футболки: очень маленький, маленький, средний, большой, XL, XXL.
3. На данный момент, если вы можете, договоритесь с клиентом, чтобы уменьшить количество функций XL до минимума.
4. Создание дополнительных задач, разрушающих каждую функцию в подзадаченные задачи.
5. Размер футболки Каждая подзадача.
6. Повторите шаги 2-5 на этот раз, пытаясь уменьшить количество функций большого размера, сделайте это, пока у вас не будет голая минимальная сумма, необходимая для версии 1.
7. , пройдите через каждую функцию, давая каждую единую оценку.
8. Суммируйте ваши оценки.

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

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

Я настоятельно рекомендую принимать эту информацию и поместить ее что-то вроде (Fogbugz) [www.fogbugz.com]. Затем вы можете пометить ваше фактическое время против вашего предполагаемого времени, чтобы получить лучшее представление о том, когда дата вашего корабля будет реально.

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

Удачи в проекте, я надеюсь, что это отправляется вовремя!

Методы Agile Оценка Предлагают следующие методы:

• Назначьте относительную размерность размера для каждой из ваших идентифицированных «функций». Думайте функцию (вход в систему), не Слой / задача (таблица для хранения учетных данных). Размеры футболки работают хорошо - S, M, L, XL

• Возьмите функцию M размеров и идентифицируют то, что команда уже доставлена ​​в нужную технологию - используйте это как ваша ожидаемая калибровка. Итак, история вашей команды показывает, что она может доставить функцию M через 2 недели. Используя S = 1/2M, L = 2M, XL = 4M, рассчитайте ожидаемую длину проекта.

• Если ваша команда еще не сделала что-то сопоставимое; Выберите функцию и внесите ее вместе.

• Никогда не процитируйте свой расчет как точку времени - всегда цитируйте его как диапазон, с большим диапазоном, указывающим на менее уверенностью. (Обратите внимание, как MS только предсказывает только в каком году что-то будет выпущено!)

Все, что говорится, вы считаете, что вы можете задавать неправильный вопрос? Сколько вы готовы рисковать?

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

Если это хорошо, у вас будет многое другое реальная информация, на которой можно оценить будущие функции с большей командой.

Надеюсь, что поможет!

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

Не тратьте навсегда на оценку.

• Постарайтесь разделить все на задачи, где самая длинная не более длинная неделя
• , ни одна особенность не составляет менее 1/2 в день
• , добавьте случайное количество неизвестных задач для вещей, которые никто не думал ( Известные неизвестные)
• Add все вверх и Умножно результат 3 .

Кроме того, всегда помните Mythical Man Manage и / или код Code Complete, что чем больше людей на проекте, тем менее эффективен любой один человек.

Уже лучше, иди цыган.

Учитывая, что у вас есть

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

Тогда вы можете сломать проект в меньших проектах, а лыжным способом? Определите аванс на график доставки (каждые 3 недели?), Приоритет приоритеты к случаям использования, время первой доставки, чтобы вы могли ее сделать, и иметь свободную оценку / план на последующих итерациях - и повторно обсудить приоритеты при каждой итерации. Скорее всего, ваш клиент в любом случае изменит свой разум, чтобы вы могли бы построить обычную обратную связь / обсуждение в процессе. Легче получить время прямо на меньших частях.
Если вы не можете этого сделать, затем отправляйтесь на опцию SAM - найдите время, чтобы построить хорошие оценки.

Еще одним хорошим способом продемонстрировать взаимоблокировку является SQL Server.

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

Плюсом здесь является то, что вы можете продемонстрировать это с помощью SQL Management Studio. Я использовал это в прошлом, чтобы объяснить людям взаимоблокировки во время обучения на уровне «Введение в SQL Server».

Большинство участников имеют проблемы с теорией, но все (обычно) становится ясно, когда они видят это в действии.

Короче говоря, транзакция A (которая не завершена) принимает явную блокировку таблицы. Вторая транзакция B пытается считать из таблицы, заблокированной транзакцией A. Транзакция B блокируется до тех пор, пока транзакция A не будет зафиксирована или не будет откатлена.

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

Не вводите в заблуждение с помощью обозначения. Скорее раздражает то, что С использует прототип f (void) для обозначения « f ожидает отсутствие параметров», а не « f ожидает единственный параметр типа void ». Обозначение f () было сохранено для обозначения «количество параметров, которое ожидает f , неизвестно, поэтому вы можете называть его с любым количеством параметров, которые вам нравятся, и удачи вам». До ANSI Standard C (он же C89) не было такой вещи, как прототип функции, и вам нужен был инструмент, такой как lint , чтобы защитить вас от даже самых обыденных видов ошибок с параметрами, таких как передача неверного количества параметров или передача параметра с дико несовместимым типом.

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

Наймите одного умного человека, который делает все, чтобы начать, а затем через некоторое время спросите их, сколько еще людей нужно, чтобы закончить к заданной дате. Если вы когда-нибудь не уверены, сколько/сколько взять на работу, err на стороне none/one.