Размер проекта. О совочках и экскаваторах.

Студент: Эта величина маленькая и ей можно пренебречь.
Преподаватель: Маленькая, по отношению к чему?

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

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

Шкала может быть разной. Можно сравнивать по трудозатратам, можно по стоимости, можно по функциональным точкам и тысячам строчек кода, можно вести оценку по методу COCOMO. Важно не это. Главное, чтобы на этой шкале уместились все проекты. Т.е если проект в 5 KLOC (Тысячи строк) “большой”, то куда отнести проект по переводу системы управления в 100 мегабайт исходного кода с мейнфрейма и COBOL на PC и C++ (с десяток лет назад был такой проект у нас в России)? А создание такой системы с нуля куда отнести?

Качественные значения, которыми мы оперируем при разговоре о величине проекта, как правило, составляют следующий список:

  • Маленький
  • Средний
  • Большой

Добавим к этому “крохотный” и “гигантский” для проектов, выходящих за эти рамки.

Для себя я составил следующее соответствие качественных и количественных показателей:

  • До 10 человекомесяцев - крохотный
  • 10 – 100 - Маленький
  • 100 – 1000 - Средний
  • 1000 – 10 000 – Большой (крупный)
  • Более 10 000 - Очень большой (гигантский)

Почему именно такие диапазоны? Существуют пики эффективности в зависимости от численности группы. Если не ошибаюсь, такие: 1 человек, 7, 22, 105, 600, 3000. Т.е как правило один разработчик работает значительно эффективней, чем два, но 22 эффективней, чем 15 или 30. И, по прежнему, один разработчик, как правило, будет эффективней 22. Однако при росте задачи, сильно возрастает время, что больно бьет по бизнесу. Если в одиночку разработчик решает задачу за год, то нет смысла давать эту задачу ему одному. Пусть лучше семеро решат эту задачу за три-шесть месяцев (компромисс время - трудозатраты). Конечно, нет смысла поручать эту задачу сотне людей. Все равно, за неделю они задачу не решат.
Моя оценка оптимального соотношения люди - время:
1 человек — неделя - квартал
5-9 человек — два месяца - полгода
21 - 25 человек — 0,5-2 года
100 - 110 человек — 1,5-3 года
600 человек — от трех лет
Отсюда я и выводил свои диапазоны.

Поставить в соответствие шкале трудозатрат строчки кода нетривиальная задача. Зависимость трудозатрат и бюджета от KLOC нелинейная, но чтобы хоть как-то соотнести одно другому:

Крупный проект это примерно:

  • от 1000 человеко месяцев
  • от миллиона строк кода
  • от 10 млн $ бюджет (для Москвы 2006 г)

PS. Охотно верю, что у других людей шкала другая. С удовольствием познакомлюсь с этими шкалами.

Эдвард йордан приводит следующую шкалу размеров проекта:

  • Небольшие проекты: менее 10 человек, 3-6 месяцев
  • Средние проекты: 20-30 человек, 1-2 года
  • Крупномасштабные проекты: 100-300 человек, 3-5 лет
  • Гигантские проекты: 1000-2000 человек, 7-10 лет

Макконнелл в книге “Остаться в жиых” определяет средний проект как проект с командой 3-25 человек и со сроком выполнения 3-18 месяцев
PSS. В частности, Алистер Коберн приводит другие численности эффективных команд.

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.