Как оценить времена при работе над новой технологией? [закрытый]
Я полагаю, что
См. эту ссылку на источник.
Вот выдержка из этого файла:
#if defined(__GNUC__)
typedef u64 uint64_t;
typedef u64 u_int64_t;
typedef s64 int64_t;
#endif
Итак, я думаю, вы могли бы просто добавить это в свой код, чтобы заставить его скомпилировать.
#include
typedef u64 uint64_t;
typedef s64 int64_t;
12 ответов
Я также рекомендую смотреть на этот поток: кто-либо работает с Единицами функциональности?
Единицы функциональности являются "промышленным стандартом" (независимо от того, что это означает) для оценки, сколько времени она берет, чтобы сделать что-то. Для большей части части они пытаются планировать то, что делает программа, и ЗАТЕМ Вы помещаете их в алгоритм как это:
long GetManHoursForProject()
{
long Count_of_Function_Points = GetFunctionPointCountFromAnalyticalPhaseOfSDLC();
double Average_Complexity = 1; // .8 for easy, 1 for normal, 1.2 for hard
long Programming_Language = 130; // for C++ (higher level languages have higher values)
double Man_Months = Count_of_Function_Points * Programming_Language * Average_Complexity;
long Man_Hours = Man_Months * 20 * 8; // 20 days per month, 8 hours per day
return Man_Hours;
}
Поток, с которым я связался от вышеупомянутых переговоров о Точках платы Истории, который является межпокоящимся разговором в и среди себя. Я изучил бы оба из этих предметов для нахождения, какой работает на Вас.
Хорошая вещь о единицах функциональности и точках платы истории состоит в том, что у них есть множитель языка. Тот же образ мыслей используется для всех языков.
Если бы Вы учите новый язык, то сложность была бы выше для Вашей определенной системы.
Вы не можете.
Необходимо рассмотреть это как исследование, и исследование не может быть оценено.
Я дал бы мне промежуток времени набора, чтобы экспериментировать с и изучить новую технологию прежде, чем обещать поставить что-либо в определенную дату.
После того первого периода сделайте некоторые грубые оценки и удостоверьтесь, что Ваши начальники знают, как грубо они действительно.
Я обычно оцениваю, что время потратило изучение, и время потратило реализацию отдельно. Т.е. Я оцениваю проект, как будто я знал то, на основе чего я делал, он - недоумение, но затем попытайтесь оценить время, это могло бы взять меня для изучения новой технологии.
То, когда я работал в проекте переключить группу разработчиков среднего размера на .NET единственный способ, которым могло быть оценено полное преобразование, должно было позволить начальную фазу исследования. Это позволило некоторым разработчикам знакомиться с технологией и реализацией, полностью, небольшой частью функциональности. Я нашел это очень важным, что часть системы, которая работалась на, была завершена к производственному стандарту.
Что-то, что было также обсуждено, нанимало консультанта, который был знаком с технологией. Это было отклонено из-за стоимости, но я думаю, что было бы чрезвычайно полезно иметь кого-то, у кого был опыт проектов.NET указать на нас в правильном направлении.
Единственная другая вещь добавить состоит в том, что, когда Вы работаете над проектом этой природы, важно также оценить, сколько времени это возьмет, чтобы принести другим разработчикам до скорости. Очевидно, это будет меньше, чем время, когда фаза исследования взяла. Хотя разработчики, которые работали над прототипом, должны быть рядом для помощи тем, кто теперь берет новую технологию.
Подводя итоги:
- Необходимо дать себе время для взятия нового tchnology, прежде чем можно будет дать реальные оценки.
- Вам нужно к оценкам baseyour на опыте полного проекта к производственному стандарту.
- Не бойтесь найма подрядчика с опытом для изучения лучших практик быстро.
- Не забывайте, что все должны изучить эту технологию, прежде чем они будут выпущены на коде procduction.
Не слишком долго назад, я должен был работать над проектом в Flex, и я никогда не использовал Flex (или Flash) прежде. Я был также вынужден пользоваться определенной сторонней библиотекой виджетов в этом приложении Flex. Я оценил, сколько времени я думал, что это возьмет в разумном языке как Java, затем приблизительно удвоил его для составления изучения нового языка. Проблема была, Flex не разумен, это не документируется, там много ошибок в стандартной библиотеке, и по-видимому наша сторонняя библиотека взяла все конструктивные особенности стандартной библиотеки к основе, потому что это также было очень повреждено. Мы закончили с плохо работающим продуктом с половиной функций и за выделенное время. К счастью управление позволило нам продолжать работать над ним в течение некоторого времени (они изменяли требования, таким образом, они были должны нам так очень), и мы получили его в действительно хорошую форму. Это все еще не делает всего, что мы хотели, но мы взломали наш путь вокруг большинства ошибок библиотеки, включая смягчение худшей из проблем производительности (а именно, инстанцирование UIComponent занимает много времени, таким образом, вместо того, чтобы делать их всех на запуске, мы делаем это по мере необходимости. Это не связано с нашим сторонним lib).
Так, короче говоря:
- Всегда оценивайте много времени вращения для изучения новой системы. Вне изучения языка необходимо изучить особенности. Это, вероятно, невозможно точно оценить
- Избегайте Flex если вообще возможный. Я не могу предположить, что прямой Flash немного лучше, так как они совместно используют значительную часть библиотеки.
Я предполагаю для проектов определенного размера, даю себе некоторое время для создания довольно простого и все же завершенным и не тривиальный прототип некоторой представительной части проекта. Затем у Вас будет некоторое время, чтобы играть с технологией и также заработать ценное понимание относительно времени, которое требуется для создания материала с ним.
Мое эмпирическое правило состоит в том, чтобы удвоить время, Вы думаете, что оно возьмет. Я нашел, что Вы будете всегда сталкиваться с некоторыми неожиданными проблемами, которые займут время для разрешения.
Когда я работал с новой технологией в прошлом (т.е. когда новая технология. было центральным к предоставлению проекта), у меня были хорошие результаты с оценкой его как:
New Project Time = Project Time * 1.5
... но это само собой разумеется, это - эмпирическое правило и YMMV.
Одна вещь, которую можно сделать - помимо найма кого-то или не оценки - состоит в том, чтобы оценить относительную сложность задач и затем сравнить время фактической реализации с уровнем сложности. Со временем отношение будет сходиться к стабильному значению.
Используйте Закон Хофштадтера:
Это всегда занимает больше времени, чем вы ожидайте, даже когда вы принимаете учтите Закон Хофштадтера.
Теперь я столкнулся с проблемой, подобной вашей. Прочитав эти комментарии здесь, Я думаю, что это тот уровень, на котором нужно глубоко понимать новые технологии. Во-первых, просто исследуйте в ближайшее время новую технологию в виде необработанных данных (эскизная фигура), после чего уже есть разбивка, так что теперь просто расставьте приоритеты и исследуйте более подробно по порядку.
Я надеюсь, что это полезно.