|
|
|
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
Однажды мне надо было сделать грубую оценку трудозатрат на один проект. Чтобы не вдаваться в подробности, на том этапе проект описывался в виде ервиновских файлов, в которых были расписаны процессы для каждой из подсистем. Нужно было дать клиенту ответ, примерно в какой диапазон она попадет.
Для каждого этапа жизненного цикла проекта существуют разные методики. Например, когда у вас есть набор юз-кейсов, описывающих проект, то можно воспользоваться Use Case Points (http://www.codeproject.com/gen/design/usecasepoints.asp). А что делать, когда информации мало? Для данного проекта я воспользовался следующим подходом. Я постарался более менее детально оценить сложную (по кол-ву процессов и взаимодействий) из подсистем, а потом просто на глаз прикинул отношение других по размеру файла Ну есессно потом коэффициенты всякие ввел (на ПМ, на тестинг, и т.п.), но в основе суть была именно такая. А какие методики используете вы? |
|||
|
||||
nornad |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1079 Регистрация: 16.2.2007 Где: в Караганде Репутация: нет Всего: 31 |
Лично я стараюсь следовать рекомендациям Джоэла Спольски: максимально детализированно описываешь проект и определяешь трудозатраты для каждой атомарной составляющей (атомарность вплоть до "добавить на форму кнопку"). Суммарную величину умножаем на некоторый коэффициент для учёта различных неблагоприятных ситуаций, вроде цунами в пустыне Гоби.
Если же с информацией совсем туго, то стараюсь описать, что могу и на глазок прикинуть трудозатраты оставшихся частей. Коэффициент в этом случае, естественно, беру выше. -------------------- Три достоинства программиста: Леность, Нетерпение и Гордость Ларри Уолл |
|||
|
||||
nornad |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1079 Регистрация: 16.2.2007 Где: в Караганде Репутация: нет Всего: 31 |
Неужто кроме нас двоих никто использует ничего более-менее систематического для определения трудозатрат? Или наоборот - все используют именно такие схемы? Что-то мало верится...
-------------------- Три достоинства программиста: Леность, Нетерпение и Гордость Ларри Уолл |
|||
|
||||
maddoc |
|
|||
Опытный Профиль Группа: Участник Сообщений: 364 Регистрация: 11.5.2005 Репутация: нет Всего: 1 |
а как оценить трудозатраты на работу, если есть только общее описание требуемого?
-------------------- "Безвыходных положений не бывает" (с) Камасутра |
|||
|
||||
it7ent |
|
|||
Новичок Профиль Группа: Участник Сообщений: 9 Регистрация: 24.4.2007 Репутация: нет Всего: нет |
Мы оценивали трудозатраты на наш текущий проект с помощью Use Case'ов (предварительно было составнено достаточно подробное их описание)
Расчетные значения получились примерно в 3-5 раз больше чем реальные трудозатраты на проект.
присоединяюсь к вопросу, особено когда не только описание требуемого расплывчато, но и к примеру - специалисты плохо знакомы со средой разработки и не знают смогут ли они это сделать вообще.. |
|||
|
||||
nornad |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1079 Регистрация: 16.2.2007 Где: в Караганде Репутация: нет Всего: 31 |
Ну, примерно то же самое и у Джоэла. Кстати, такая система мало подходит, если нужно выдать заказчику предварительную оценку трудозатрат. Но там, по идее, большая точность и не требуется. Главное слишком сильно не промазать в сторону занижения сроков. Да и "вверх" тоже - иначе не закажет. Были у меня подобные ситуации. В этом случае выбирается человек, который больше всех слышал о требуемой области и отправляется чуток разобраться, чтобы мог давать консультации вроде "можно/нельзя/возможно удастся сделать" и "легко/сложно/практически невозможно реализовать". Можно и самому - так даже лучше, но не всегда удаётся (часто проще найти или "сделать своего" эксперта). Имея хоть какие-то данные из предметной области, уже можно начинать рассчитывать трудозатраты. Главное - взять коэффициент повыше, иначе скорее всего вылетишь из сроков. -------------------- Три достоинства программиста: Леность, Нетерпение и Гордость Ларри Уолл |
|||
|
||||
it7ent |
|
|||
Новичок Профиль Группа: Участник Сообщений: 9 Регистрация: 24.4.2007 Репутация: нет Всего: нет |
упс, извините...
как раз этим методом мы и пользовались |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
Скорее всего, вы переоценили трудозатраты на юз-кейсы, или они перекрывались, или оценивали для новичков, а реально проект делали более опытные программеры. И, то что вы называете реальными трудозатратами, включает в себя время на management, testing, integration? На самом деле, есть несколько способов оценки на этапе pre-sale (когда о проекте известно, в лучшем случае, базовые требования) 1) Концептуальное проектирование. Строится концпетуальная архитектура системы (не путать с реальной!!!), оцениваются по отдельности ее составные части. Оценки суммируются. Главное - не проектировать глубоко, т.к. с глубиной проработки ухудшается оценка. 2) Крупномасштабная аналогия: обращаетесь к своему предыдущему опыты и ищете проекты: - Схожие по размерам - Схожие по типу - Схожие по размерам компонентов - Схожие по типам компонентов - Схожие по типу и объему требований Для этого метода требуется система хранения исторической информации 3) Wideband Delphi (типа "повышение шансов"). Это командный метод, суть которого сводится к раздаче требований участникам, они независимо оценивают, потом оценки и предположения собираются и консолидируются, потом все опять оценивают, и т.д. пока 4 итерации не пройдет, или оценки сойдутся к приемлемо узкому диапазону, или истечет время, выделенное на проведение оценки, или все решат, что больше оценки уточнять не стоит. 4) Метод Кларка - Разбить на модули - Сделать хорошие оценки для каждого модуля - Определить верхнюю и нижнюю границу оценки - Размер оценки = Сумма((Наибольшая оценка + 4*Среднее значение + Наименьшая оценка) / 6) При этом, есть повышающие коэффициенты: - X 5 для обеспечения безопасности ПО - X 5 для внедренных систем - X 1.5 для повторно используемого кода (reusable code) - X 2.5 для распределенных систем Имейте введу следующее: 1) Эти методы работают для этапа предпродажной работы (pre-sales), когда информации о проекте крайне мало, а клиент хочет получить цифры 2) На последующих этапах проект надо переоценивать заново, чтобы уточнять итог 3) Сколько будет стоить проект, будет известно только по его окончании 4) Обязательно нужно вести историю оценок |
|||
|
||||
maddoc |
|
|||
Опытный Профиль Группа: Участник Сообщений: 364 Регистрация: 11.5.2005 Репутация: нет Всего: 1 |
arilou, это все сдорово, но если ты(то есть я) и выполняеш сам заказ? или ты должен назвать цифры, а потом под эту сумму и время нанять людей и тд. -------------------- "Безвыходных положений не бывает" (с) Камасутра |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
Не понял вопроса... |
|||
|
||||
nornad |
|
|||
Эксперт Профиль Группа: Завсегдатай Сообщений: 1079 Регистрация: 16.2.2007 Где: в Караганде Репутация: нет Всего: 31 |
А какая разница, сам будешь выполнять заказ или найдёшь команду? Если ты изначально знаешь, кто будет выполнять заказ - рассчитываешь трудозатраты исходя из его (их) производительности. Если не знаешь (будет команда, но её ещё надо набрать и сплотить), то просто увеличиваешь расчётные трудозатраты при помощи коэффициента. -------------------- Три достоинства программиста: Леность, Нетерпение и Гордость Ларри Уолл |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
nornad, maddoc, ребята, не путайте - те методы, что я привел, нужны для того, чтобы сказать потенциальному кастомеру примерно сколько будет стоить его проект. На данном этапе побоку, кто будет его делать.
|
|||
|
||||
maddoc |
|
|||
Опытный Профиль Группа: Участник Сообщений: 364 Регистрация: 11.5.2005 Репутация: нет Всего: 1 |
я понял, что наверно тут все надо пощупать самому и на своей шкуре испытать. на форуме это не решить.
спасибо. -------------------- "Безвыходных положений не бывает" (с) Камасутра |
|||
|
||||
arilou |
|
|||
Великий МунаБудвин Профиль Группа: Экс. модератор Сообщений: 2646 Регистрация: 15.7.2004 Где: город-герой Минск Репутация: 3 Всего: 61 |
||||
|
||||
SpaceSpace |
|
|||
Опытный Профиль Группа: Участник Сообщений: 366 Регистрация: 10.4.2007 Где: Самара Репутация: нет Всего: 10 |
Прошу прощения, если скажу глупость.
Я встречал следующую методологию: речь идет о "внутренних проектах" корпоративных(имеющих много уровней, подразделений, отделений и тд.) оргаизаций с российской спецификой. В головном офисе сидят топ-манагеры(ПМы), долго и муторно разрабатывают(любым способом) сроки. Этот "план" уходитв отделы, там местные манагеры просто срезают 10%(или больше) от крайнего срока, чтобы как я понимаю подстраховаться, далее это продолжается ровно столько, сколько исполнительных уровней в организации, а непосредственным исполнителям приходится из шкуры лезть, чтобы успеть за 30-40 % реально разработанной схемы. вот такая российская специфика. Это сообщение отредактировал(а) SpaceSpace - 4.9.2007, 11:52 -------------------- Репутация - самое ценное, что есть у человека. Зарабатывают годы, теряют за мгновение. 70-565 MCPD Enterprise 3.5 |
|||
|
||||
|
НА ЗЛОБУ ДНЯ: Дорогие посетители, прошу обратить внимание на то, что новые темы, касающиеся новых вопросов, создаются кнопкой "Новая тема", а не "Ответить"! Любые оффтопиковые вопросы, заданные в текущих темах, будут удалены. Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, arilou. |
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | УП: Методологии | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |