МЕТОДОЛОГИИ
Сергей Бобровский
Ошибки, ошибки...
Сегодня создаются глобальные информационные проекты стоимостью в миллиарды долларов и объемом в десятки миллионов строк кода. Средства разработки становятся все более комфортабельными, а кодогенераторы берут на себя до 90% рутинной работы. Но можно ли считать ИТ-индустрию зрелой? Нет! Трудно себе представить любую другую область производства (например, строительство или автомобильную промышленность), где брак в работе в среднем равен 42%.
МО США ежегодно тратит на разработку и внедрение компьютерных систем десятки миллиардов долларов. Из этой суммы только 7 млрд. расходуется на оборудование. ПО используется практически во всех видах оружия и системах контроля и управления. На 1995 г. сумма незакрытых контрактов на создание ПО составляла 256 млрд. долл. Абсолютное большинство проектов в военной отрасли - крупные, а число ошибок в таких проектах увеличивается экспоненциально в зависимости от их объема (степень примерно равна 1,2).
Причина быстрого роста числа ошибок, как в течение 10 лет выясняли специалисты Пентагона, кроется в плохом управлении проектами. Плохое же управление - обусловлено тем, что руководители проектов не знают технологии и методики проектирования больших программных систем, критические проблемы, возникающие в процессе их создания, и не умеют (а нередко и не хотят) формировать план работ с учетом реальной производительности программистов.
При этом была выявлена одна важная вещь. Подавляющее большинство современных методологий разработки ПО основано на принципе улучшения процесса этой разработки, когда руководитель проекта имеет большую свободу действий в выборе способа реализации проекта. В то же время признанные мировые лидеры, создающие качественное ПО (в мире их единицы), активно используют понятие лучшего практического навыка (practice), ориентированное на улучшение деталей работы и быстрое достижение конечного результата, - в нем нет абстрактного “улучшения процесса”, а есть конкретные рекомендации, использующие числовые характеристики проекта. Другое преимущество подхода лучших практических навыков - возможность их немедленного применения в противовес разработанной МО США “тяжелой” методологии CMM (см. PC Week/RE, № 3/98, с. 50; № /98, с. 44), для сертификации по которой (как, кстати, и по ISO 9000) требуются годы труда. Хотя имеются случаи очень успешного внедрения CMM, более-менее массового признания эта методология не получила - из-за своей сложности и слишком больших усилий по ее воплощению. Продолжающиеся непрерывные неудачи в крупных программных проектах заставили Пентагон сформировать подразделение Software Program Managers Network (SPMN; www.spmn.com), которое призвано помочь военным быстро налаживать эффективные процессы управления проектами в организациях - разработчиках ПО.
В дело вступают эксперты
Эксперты МО США - Ноэл Лонгмэа и Эммит Пэйдж, проанализировав множество различных крупных проектов, представили руководству министерства заключение. В нем, в частности, говорилось: “Существующие в МО США методы разработки ПО не создают необходимых условий для управления крупномасштабными проектами по созданию ПО как неотъемлемой части комплексных боевых систем”.
На основании этого заключения были определены четыре главные цели работы SPMN:
- внедрить в Пентагоне лучшие практические навыки создания ПО;
- дать руководителям проектов возможность сфокусировать свои усилия на разработке качественного ПО вместо того, чтобы следовать должностным инструкциям и формальным методикам, которые только ухудшают состояние проекта;
- позволить руководителям проектов использовать лучшие мировые практические навыки с учетом локальной корпоративной культуры;
- дать возможность быстро изучить и внедрить эти навыки в свою работу с помощью соответствующих методик обучения и программных систем.
В SPMN были созданы три подразделения.
1. Группа оперативных советов (Airlie Software Council), определившая ключевые практические навыки, - всего их набралось девять. В выявлении лучших навыков участвовали такие мировые общепризнанные эксперты, как Гради Буч, Эд Йордон и другие.
В дополнение к лучшим навыкам они разработали технологию панели управления ходом программного проекта (Software Project Control Panel), описывающую ключевые индикаторы состояния проекта; определили важнейшие цели типичного проекта, способы их количественной оценки и границы допустимых состояний; написали “Малую желтую книгу”, в которую вошли вопросы, часто задаваемые руководителями проектов, и ответы на них; выделили набор самых плохих практик.
2. Группа периодических обновлений (Issue Panels). Вошедшие в нее 180 специалистов по программной инженерии обработали 163 методики, используемые в 56 компаниях, и выделили 43 лучших практических навыка, расширивших и дополнивших девять ключевых.
3. Группа управления (Program Ma- nagers Panel), следящая за работой двух предыдущих групп и определяющая способы улучшения их работы.
Подход, предложенный SPMN, - критически важные практические навыки (CBP, Critical Best Practices) - позволяет тактическими изменениями в работе организации очень быстро за (18 - 24 месяца) примерно на 80% достичь 3-го (из пяти) уровня (уровня мирового класса) по методологии CMM (что обычно требует около 10 лет). CBP-подход уже проверен на сотнях реальных крупных программных проектов.
Рекомендации по применению практических навыков достаточно очевидны, причем вкупе они дают очень сильный эффект. В самом общем виде CBP предлагают: сфокусироваться на количественных параметрах завершения проекта (дате, бюджете, объеме); придумать быстро реализуемую стратегию выполнения проекта; измерять продвижение к цели; измерять активность разработки.
Как избежать хаоса
Результаты работы SPMN показали, что сложность крупных проектов обычно находится на грани перерастания в хаос, и существует ряд факторов, от которых зависит, перейдет ли система в неуправляемое состояние. Чтобы правильно управлять проектом, надо выполнять ряд следующих условий:
1. Как можно раньше выявлять ошибки и логические неувязки, и сразу после обнаружения устранять их. Между тем моментом, когда разработчиком вносится ошибка, и моментом ее выявления должно пройти минимальное время (в военных проектах МО США оно в среднем составляло 9 мес.). Образно говоря, когда создано бетонное основание дома, перестраивать его заново значительно сложнее. Совершенно недопустима почасовая оплата программистов (обычная практика при выполнении госзаказов в США). Необходимо также совершенствовать механизмы выявления типичных причин ошибок и способы их устранения.
Показательны следующие статистические данные. Если ошибка фиксируется и устраняется на этапе формирования требований к проекту, организации это обходится в 139 долл. В процессе кодирования средняя стоимость ошибки достигает 1000 долл. На этапе тестирования, столь любимом многими компаниями, устранение стоит уже 7 тыс. долл., а на этапе внедрения - 14 тыс. долл.
Конечно, без тестирования продукта обойтись нельзя - ошибки в программе есть всегда. Важно определить, когда нужно закончить тестирование. Даже если на протяжении недели активного тестирования не выявлено ни одной ошибки, это не означает, что их нет. Эксперты рекомендуют придерживаться такого подхода: тестировать систему как можно раньше и как можно чаще (чем больше продукт тестируется, тем больше в нем находится дефектов), а обнаруживаемые ошибки устранять немедленно.
2. Планировать работу на основе правильных показателей.
Невозможно реализовать крупный проект, если не подготовлен максимально детальный план всех видов деятельности в его рамках с учетом производительности сотрудников, объема работ, бюджета и других ресурсов.
3. Свести к минимуму неконтролируемые изменения проекта с учетом того, что разработчики вносят на всех этапах, начиная с определения требований к системе и заканчивая ее пользовательскими интерфейсами.
4. Эффективно использовать умения сотрудников.
Знания, опыт и мотивация сотрудников - важнейшие факторы успеха.
Акцент в управлении проектами должен быть смещен на производительность труда, качество работы, выполнение планов и удовлетворение пользователя. Для этого требуются большие усилия по подготовке профессиональных руководителей проектов и изменению способов их подготовки. Как заметил Эд Йордон в своей работе “Decline and Fall of the American Programmer”, компании с низким качеством производимого ПО и малой эффективностью работы вымрут, как динозавры.
(Окончание следует)
Автору можно написать по адресу: sbo@pcweek.ru.
