Регистрация   E-Mail     Пароль   
  
Портал «Профессионал управления проектами»
!!!! Обращаем внимание регионов!
Первый курс по MS Project 2010 в он-лайн формате, 20-27 июля 2010 года.

Управление проектами: статьи » Управление проектами: статьи

О методологии создания крупного программного проекта

 
 
Эд Йордон
Дата публикации: 04.10.2002
Источник: Планета КИС
Версия для печати (доступна только зарегистрированным пользователям)Версия для печати
 

Известная шутка: на второй день работы над проектом программисты заявляют, что они сделали 90%, и эти 90% остаются до последнего дня перед сдачей проекта, после чего программисты обнаруживают, что для доделки оставшихся 10% требуется еще 6 месяцев. Как избежать этой ловушки? Правильным контролем за ходом проекта.

Удивительно, но многие компании в качестве критерия объема проделанных работ используют процент от выделенных на проект средств! Более корректные единицы измерения (например, число строк кода) тоже подходят далеко не всегда. Можно написать миллиарды строк кода, и при этом проект останется недоделанным.

Основной критерий - это качество работы. Классическое соотношение - необнаруженное число ошибок на стадии N выливается в десятикратное число ошибок на стадии N+1. Поэтому число обнаруживаемых на каждой стадии ошибок (соответственно, это число делится на 10 для каждой последующей стадии) может служить ключевым критерием качества проекта. Данный подход хорош еще и тем, что не позволяет откладывать тяжелые программистские (или даже постановочные) баги на потом, а заниматься устранением простых ошибок интерфейса.

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

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

Дополнение корпорации Cutter.

Как оценивается объем будущего проекта? Нередко это напоминает игру в числа.

  1. Руководитель проекта опрашивает подчиненных и формирует оптимистичную оценку объема (невысокие стоимость и продолжительность).
  2. Заказчик объявляет, что эта оценка слишком завышена, и кто угодно сделает этот проект быстрее и дешевле.
  3. Так как руководитель проекта на данном этапе не имеет адекватной информации о реальном объеме, он обычно соглашается с заказчиком, который практически всегда выигрывает такую 'игру в числа'.

Но в результате проект заканчивается неудачей.

предыдущая 1. 2. следующаяСледующая страница
Страница 1 из 2
Обсуждение Обсуждение
Путь Камикадзе в американских проектах. - 29.03.2003 (2), ВАкймин

Пожалуйста, авторизуйтесь или зарегистрируйтесь для участия в обсуждении.

Вызов консультанта