4.2. Critical Best Practices (CBP) – другой взгляд на проблему создания качественного программного обеспечения

«Компании, качество производимого ПО и эффективность работы в которых низки, вымрут как динозавры».

Эд Йордон

«Decline and Fall of the American Programmer»

Признанные мировые лидеры, создающие качественное ПО (их единицы во всем мире), активно используют понятие лучшего практического навыка (practice), ориентированное на улучшение деталей работы и быстрое достижение конечного результата, содержащее конкретные рекомендации, использующие числовые характеристики проекта.

Пентагоном было сформировано подразделение Software Program Managers Network (SPMN), которым был выработан подход, получивший название Critical Best Practices (CBP, критически важные практические навыки). Подразделение состояло из трех групп.

Группа оперативных советов (Airlie Software Council) определила важнейшие ключевые практические навыки – всего их насчиталось девять. В выявлении лучших навыков участвовали такие мировые общепризнанные эксперты, как Гради Буч, Эд Йордон и другие.

В дополнение к лучшим навыкам они разработали технологию Software Project Control Panel (панели управления ходом программного проекта), описывающую ключевые индикаторы состояния проекта, определили важнейшие цели типичного проекта, способы их количественной оценки и границы допустимых состояний, написали книгу Little Yellow Book, в которую вошли часто задаваемые вопросы руководителей проектов и ответы на них, а также выделили набор самых плохих практик.

Группа периодических обновлений (Issue Panels) (в нее вошло 180 специалистов по программной инженерии) обработала 163 методики 56 компаний и выделила 43 лучших практических навыка, расширивших и дополнивших 9 ключевых навыков.

Группа управления (Program Managers Panel) следила за работой двух предыдущих групп и определяла способы улучшения их работы.

CBP в самом общем виде предлагают:

· сфокусироваться на количественных параметрах завершения проекта (дате, бюджете, объеме);

· придумать быстро реализуемую стратегию выполнения проекта;

· измерять продвижение к цели;

· измерять активность разработки.

Результаты работы SPMN показали, что сложность крупных проектов обычно находится на грани хаоса, и существует ряд факторов, от которых зависит, перейдет ли система в неуправляемое состояние. Чтобы правильно управлять проектом, надо:

1) Выявлять ошибки и логические неувязки как можно раньше, а устранять их – сразу после обнаружения. Между моментом внесения ошибки разработчиком и моментом ее выявления должно пройти минимальное время. Образно говоря, когда создано бетонное основание дома, перестраивать его заново значительно сложнее.

Показательны следующие статистические данные – если ошибка фиксируется и устраняется на этапе формирования требований к проекту, организации это обходится в

139 долл. В процессе кодирования средняя стоимость ошибки достигает 1000 долл. На этапе тестирования устранение ошибки обходится уже в 7 тыс. долл., а на этапе внедрения – в 14 тыс. долл.

Конечно, без тестирования продукта обойтись нельзя – ошибки в программе есть всегда. Важно определить, когда закончить тестирование. Даже если на протяжении недели активного тестирования не выявлено ни одной ошибки, это не означает, что их нет. Эксперты рекомендуют придерживаться такого подхода – тестировать систему как можно раньше и как можно чаще (чем больше продукт тестируется, тем больше в нем находится дефектов), а обнаруживаемые ошибки надо устранять немедленно.

2) Планировать работу на основе правильных показателей.

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

3) Минимизировать неконтролируемые изменения проекта с учетом того, что неконтролируемые изменения вносятся разработчиками на всех этапах, начиная с требований к системе и заканчивая ее пользовательскими интерфейсами.

4) Эффективно использовать сотрудников.

Знания, опыт и мотивация сотрудников – важнейшие факторы успеха. Акцент в управлении проектами должен быть смещен на производительность труда, качество работы, выполнение планов и удовлетворение пользователя.

Рассмотрим  кратко 9 лучших навыков, рекомендованных SPMN.

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

Надо смягчать последствия рисков путем их раннего выявления и максимально ранней ликвидации, профилактической работы и изменения курса проекта «в обход» потенциальных неудач. Неустраненные риски надо отслеживать по параметрам «стоимость последствий риска» и «стоимость устранения риска». Желательно иметь резервные запасы ресурсов для устранения непредвиденных проблем.

В рамках проекта рекомендуется постоянно вести и анализировать списки 10 важнейших рисков; списки неустраненных рисков в наиболее критических точках проекта; отчеты по устраненным, неустраненным и новым рискам; учитывать возможную стоимость последствий рисков в зависимости от имеющегося резерва. SPMN советует также использовать анонимные каналы для получения информации от персонала о неизвестных «подводных камнях» в проекте, чтобы в коллективе не создавалась атмосфера замалчивания ошибочных действий. Одновременно надо «декриминализировать» сам риск. У сотрудников не должно быть никаких иллюзий о допустимости рисков («выгодно затягивать проект», «не хочу критиковать коллегу»), при этом необходимо понять, что каждый выявленный риск – это предупрежденный риск.

Навык 2. Соглашения об интерфейсах – пользовательских, внутренних (межмодульных) и внешних (для стыковки с другими компонентами и приложениями).

Чем позже будут определены соглашения об интерфейсах, тем больше вероятность того, что систему придется заново проектировать, программировать и тестировать.

Пользовательский интерфейс (как и все остальные) надо полностью определить, согласовать с заказчиком и утвердить до начала этапов проектирования и разработки. Его описание должно быть включено в системную спецификацию на уровне

определения каждого экранного поля, элемента ввода/вывода и средств навигации между формами/окнами/экранами.

Правильность интерфейса проверяет и утверждает только реальный пользователь каждого рабочего места из организации – заказчика.

Для встраиваемой системы готовятся отдельные требования к ее внешнему интерфейсу.

Навык 3. Формальные проверки проекта.

Нередко устранение ошибок начинается, только когда проект переходит к так называемому этапу тестирования (такие этапы были придуманы 30 лет назад при создании небольших по сегодняшним меркам систем, и, хотя в тестировании нет ничего плохого, выделять его в отдельный этап методологически неверно), в результате стоимость такого этапа достигает 40 – 60 % стоимости всего проекта. Эти ненужные усилия могут быть сокращены на порядок.

Существует немало стандартных подходов раннего выявления ошибок – например, Fagan-проверки (M.E. Fagan, «Advances in Software Inspections»), позволяющие обнаруживать 80 % ошибок в момент их внесения, или многократные просмотры кода (выявляется 60 % ошибок). Но оперативное обнаружение 90 % и более ошибок требует использования нескольких подходов. Ведущие компании одновременно применяют 10 и более методик формальных проверок (анализ структуры проекта, проверки кода, редактирование документации, множественное тестирование и т. п.).

Не менее важны усилия по проверке корректности проекта на этапах формулирования требований, создания архитектуры системы и проектирования. Для выполнения формальных проверок надо использовать небольшие группы сотрудников с четко определенными ролями, привлекая при этом пользователей организации – заказчика. Персонал необходимо постоянно тренировать в умении анализировать код на наличие ошибок. Желательно отслеживать продолжительность усилий по проверкам проекта, число найденных ошибок по отношению к затраченным на их поиск усилиям и среднее время от внесения ошибки до ее устранения.

Навык 4. Управление проектом на основе метрик.

Этот навык нужен для раннего обнаружения потенциальных проблем. Как уже говорилось, стоимость устранения дефекта в проекте увеличивается в геометрической прогрессии по мере роста проекта.

С помощью метрик (числовых характеристик) планируются все задачи проекта. Ход их выполнения должен регулярно отслеживаться, как минимум по ключевым показателям (стоимость работы и производительность труда). Надо дополнительно контролировать время, затрачиваемое на устранение дефектов, и следить за важнейшими показателями, чтобы по их отклонениям (в любую сторону) выявлять потенциальные «подводные камни». Метрики основываются на эмпирических данных, например, на основе результатов схожих по размерам проектов.

Навык 5. Качество продукта должно контролироваться на детальном уровне.

Проблема реализации деталей программного проекта очень важна при разработке ПО. Иногда мелкое, на первый взгляд, требование заказчика выливается в глобальную переделку проекта. Если же проект спланирован недостаточно подробно, обсуждать реальное положение дел в ходе его выполнения бессмысленно.

В проекте надо выделить задачи объемом не более 5 % по продолжительности и усилиям, которые могут быть выполнены отдельной группой сотрудников, как минимум, на 95 %. Каждая подобная задача должна быть ориентирована на выполнение   однотипной работы. Результат выполнения каждой задачи оценивается группой приемки, при этом работа не может быть принята с оговорками – она должна

быть выполнена полностью и без ошибок (двоичная система оценки качества «готово – нет»).

Навык 6. Информация о ходе проекта должна быть общедоступной. Чем больше сотрудников вовлечено в процесс контроля за ходом проекта, тем проще идентифицировать потенциальные проблемы и риски. Надо сделать показатели хода проекта доступными всем сотрудникам и заказчику и организовать канал приема анонимных сообщений о возникающих проблемах. Такой канал может быть использован для сведения личных счетов, но лучше получить ложный сигнал, чем не узнать о реальной проблеме. К тому же открытость проекта будет залогом снижения числа ложных сообщений.

Навык 7. Чтобы добиться высокого качества, надо отслеживать причины возникновения ошибок.

Ошибки должны быть формально отслеживаемы на каждой фазе проекта. Для этого желательно использовать средства конфигурационного управления. Каждый случай обнаружения и устранения ошибки обязательно надо документировать.

Устранять ошибки необходимо по мере их возникновения. При этом учет ошибок удобнее всего вести в нормализованном виде (в расчете на единицу объема, например, тысячу строк кода) – согласно принципу «снежного кома», с ростом проекта норма ошибок в нем увеличивается. Контролировать также надо среднее и максимальное время устранения ошибки и время от внесения до устранения ошибок в течение каждого этапа проекта и на протяжении первого года эксплуатации системы.

Навык 8. Конфигурационное управление.

Неконтролируемые изменения в проекте могут быстро ввергнуть его в хаос.

Поэтому на практике надо руководствоваться двумя простыми правилами:

1) Любая часть информации, которая используется более чем одним сотрудником, должна контролироваться с помощью системы конфигурационного управления.

2) Любая часть информации, учитываемая системой качества, должна контролироваться с помощью системы конфигурационного управления.

Надо отслеживать все изменения в состоянии создаваемой системы, бюджете и сроках, интерфейсах, контрольных отчетах и т. п. Без систем конфигурационного управления при этом не обойтись, потому что в крупном проекте большие объемы информации меняются очень быстро. Каждый учитываемый объект должен определяться его версией, при этом надо вести архив всех версий всех таких объектов.

Навык 9. Управление персоналом.

Главный фактор успеха проекта – качество, опыт и мотивация сотрудников.

Выявлена высокая корреляция между суммами, вкладываемыми в обучение персонала, и общим успехом проекта, поэтому надо постоянно выполнять обучение и переподготовку сотрудников. Любые авралы необходимо минимизировать – а к авралам (как ни парадоксально на первый взгляд) обычно приводит работа более 40 часов в неделю, что говорит о неверной организации труда и скрытых ошибках в организационной структуре.

Ключ к эффективному использованию персонала – открытая доверительная атмосфера, основанная на правдивых отношениях.

Каждый из описанных навыков полезен сам по себе, но совместное их использование значительно повышает суммарную эффективность.

Достоинства изложенного подхода (мнение его сторонников):

· в нем нет абстрактного «улучшения процесса», а есть конкретные рекомендации, использующие числовые характеристики проекта;

· может быть внедрен без дополнительных расходов на оборудование, технологии и персонал;

· возможность немедленного применения в противовес к «тяжелой» методологии СММ, для сертификации по которой требуются годы труда;

· позволяет тактическими изменениями в работе организации очень быстро    (18 – 24 месяца) примерно на 80 % достичь третьего уровня по методологии CMM.

Тесты для самоконтроля

1. Зрелость организации является главным понятием стандарта:

а) ISO 9001;

б) ISO/IES 12207;

в) СММ.

2. Оценка процесса в стандарте SPICE:

а) позволяет оценить возможности улучшения данного процесса;

б) происходит путем сравнения существующего процесса разработки ПО с описанной в стандарте моделью;

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

3. Стандарт ISO/IES 12207:

а) не может быть использован, когда разработчик и пользователь ПО из одной организации;

б) ориентирован на организацию действий поставщика (разработчика) ПО;

в) ориентирован на организацию действий как разработчика, так и пользователя ПО.

4. Стандартом, определяющим стратегию и общий порядок в создании и эксплуатации ПО является:

а) ISO/IES 12207;

б) CMM;

в) ISO/IES 15504.

5. CBP предлагают для правильного управления проектом:

а) планировать работу на основе правильных показателей;

б) документировать положительную практику;

в) создавать внутрифирменные стандарты ПСПО.