Уровень 5 модели зрелости процесса разработки ПО Software Engineering Institute (SEI CMM):
Точка зрения практика

^© Кимси М. Фоулер (Kimsey M. Fowler) младший,
лидер рабочей группы по процессам разработки ПО,
Boeing Defense and Space Group (D&SG)

Переведено БНТП по заказу Interface Ltd.

• Мечта об Уровне 5
• Заботы неразвитых процессов
• Начальная адаптация CMM
• Жизнь на Уровне 5
• Преимущества высокой зрелости
• Неожиданные привилегии
• Мнения членов команды

Вскоре после того, как наша организация была аттестована на соответствие Уровню 5, я был временно привлечен в другую программу, которая еще не прошла аттестацию. Меня в числе нескольких программистов попросили помочь, так как эта организация серьезно выбивалась из сроков и бюджета. Знакомая картина?

Однажды утром я пришел на совещание, на котором обсуждался файл данных, разработанный Группой А и поставленный Группе Б. Группа Б жаловалась: “Мы использовали этот файл в соответствии с условиями поставки, он содержит ошибки, и эти ошибки просочились в наш финальный продукт. Вы отвечаете за поставку файла без ошибок”. Люди из Группы А отвечали, что в их обязанности входит только разработать файл, что за ошибки отвечает группа контроля качества, и что Группа Б должна была проверить файл перед использованием.

Со стороны было очевидно, что вместо того чтобы пытаться искать виноватых, дискуссия немедленно должна была быть повернута в сторону выработки решения и мер по недопущению повторения подобных случаев. Еще более удивительно, что этот спор возник в условиях перерасхода бюджета и невыполнения сроков. Я сделал вывод, что раз я так привык работать в среде, где идет постоянное улучшение процессов, то решил, что и все остальные проекты нашей компании выполняются так же. Если эта история напоминает Вам условия разработки ПО, в которых работаете Вы, давайте минутку помечтаем о работе в организации, достигнувшей Уровня 5.

Представьте себе, на что похожа работа в среде, богатой хорошо скоординированными и выверенными процессами: каждый обучен, Вы можете точно оценить работу, закончить ее в срок, в рамках отведенного бюджета и с исключительно высоким качеством. Никто не спорит, чья ошибка вызвала проблему, и кто отвечает за конкретную задачу. Пока Вы мечтаете, обратите внимание на довольных менеджеров и множество работников, гордящихся своим трудом. Это не мечта – я описываю работу подразделения по разработке ПО в проекте Boeing Inertial Upper Stage (IUS). IUS – ракетоноситель для вывода спутников на орбиту, известный своей надежностью и точностью.

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

Когда моя программа отправлялась на приемочное тестирование, взгляд, брошенный тестировщиком в сторону моего рабочего места, вызывал у меня волну страха. Ничто не способно так быстро испортить день, как ошибка программы, найденная в ходе формального тестирования. Для меня это означало кучу дополнительной работы: написание отчета о проблеме в программе (SPR - software problem report), анализ проблемы, планирование работы над ней, разработка и тестирование заплатки, экспертная оценка заплатки, документирование новой редакции программы, получение разрешения на внесение изменения, участие в совещании комитета по рассмотрению изменений в программе (Software Review Change Committee), объяснение проблемы моему менеджеру так, чтобы он был способен объяснить ее руководству и заказчику. Время и деньги были потеряны, даже не беря в расчет мое самоуважение. Если ошибки случались слишком часто, доверие ко мне, так же как к моему подразделению, естественно, падало.

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

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

К счастью, наша организация обладала достаточной мудростью, чтобы начать внедрение процессов в начале 1980 годов. В 1985 году мы основали совет по рассмотрению проектов (DRB - design review board) для улучшения экспертной оценки кода. Широкий спектр инициатив по улучшению качества дал импульс для улучшения наших процессов, и в 1990 году мы превратились в хорошо отлаженную организацию по разработке ПО.

Когда несколько лет назад нам впервые представили модель CMM (модель зрелости процесса разработки ПО (CMM - Capability Maturity Model)) на однодневном семинаре, она была встречена без особого энтузиазма. Для многих из нас она показалась очередным академическим изысканием, которое временно стало модным в индустрии. Сложность модели и ее кажущийся бесконечным список требований вызвали неприятие даже у самых терпеливых инженеров в группе. Мы надеялись, что эта мода пройдет до того, как нам придется ей следовать. В конце концов, все мы были загружены “настоящей” работой и у нас не было времени на внедрение этой модели. Более десяти лет наш коллектив разработчиков с успехом применял традиционные, хорошо документированные процессы и подходы к улучшению процессов. Получим ли мы хоть какие-то преимущества от внедрения такой модели, если текущая практика уже покрывает многие из ее особенностей?

Наш руководитель разглядел потенциал модели для выверенного улучшения наших процессов и мечтал о получении преимуществ от освоения CMM. Он понимал, что для превращения мечты в реальность, ему нужен план по преодолению серьезного противодействия. Эти усилия требовали серьезных затрат времени со стороны и так уже перегруженных сотрудников. Необходимо было донести идею до руководства, которое распоряжалось финансовыми ресурсами, и до рядовых сотрудников. Наш руководитель использовал расхожие средства для своих целей: мотивацию и энтузиазм. Он использовал мотивацию, указав нам на множество моментов, в которых наши процессы удовлетворяли требованиям модели. Он помог нам увидеть какое чувство гордости за наш коллектив мы будем испытывать и какое уважение мы получим от нашего заказчика – военно-воздушных сил США, если сможем продемонстрировать процессы разработки ПО высокого уровня зрелости. Он знал, что энтузиазм заразителен и поэтому демонстрировал его в избытке.

Первоначальная самоаттестация убедила нас, что мы работаем на достаточно высоком уровне зрелости процессов, и что CMM является практической моделью. Мы уже применяли распределение требований сверху-вниз и хорошо регламентированные процессы для конфигурационного управления, проектирования ПО, экспертной оценки кода и тестирования. Мы уже практиковали большинство из процедур определенных для ключевых областей процессов Уровней 2 и 3, и нам нужно было только поставить уже существующие процессы в соответствие модели SEI (SEI - Software Engineering Institute) Для Уровней 4 и 5 мы имели лишь несколько документированных процессов, относящихся к управлению процессами на основе количественных характеристик, управлению изменениями процессов, управлению качеством ПО, предотвращению дефектов и управлению изменениями технологии, однако, все эти концепции практиковались у нас уже несколько лет. Архивная документация в форме меморандумов, протоколов совещаний и презентационных материалов служила доказательством реальности этих притязаний, но документированные процессы должны были формализовать эти процедуры. Мы назвали все это “структурированием наших процессов в соответствии с CMM”.

Возможно, наибольшим вызовом, брошенным нам нашим руководителем, было то, что он заставил нас осознать, что мы уже работаем по принципам, в большой степени совпадающим с положениями модели CMM. В каждом из подразделений разработчиков ПО проводились совещания по ознакомлению каждого из сотрудников с моделью и с тем, как наши уже существующие процессы укладываются в нее. Это придало нам больше энтузиазма относительно проекта. Результаты предварительной самоаттестации использовались при определении различий между текущим состоянием зрелости наших процессов и тем, как это должно быть в организации Уровня 5. Результаты были оформлены в виде списка задач, оценки работ, планов мероприятий и списка целей. Метрики, собранные в ходе предыдущих мероприятий по улучшению процессов, оказались достаточно полезными при планировании наступления на Уровень 5.

После напряженной двухнедельной проверки мы были аттестованы на Уровень 5. Это достижение вызвало глубокое чувство удовлетворения и гордости среди сотрудников. Мы не только руководствовались хорошими процессами, но еще и имели ряд процессов, определенных как “изобретенные здесь”. Это чувство собственника давало нам право судить, изменять и улучшать их при необходимости.

Мы отбросили устаревшие представления о том, что ошибки в программах – нормальная ситуация в процессе разработки. Теперь у нас была другая точка зрения на дефекты ПО: вместо того, чтобы ожидать небольшого количества ошибок, мы ожидаем их полного отсутствия. Работа в окружении, где используются документированные процессы, создает единую точку зрения среди сотрудников, что является результатом понимания этих процессов. В момент обнаружения проблемы все одновременно концентрируются на ее устранении, исправлении процесса, обновлении наших таблиц контрольных проверок, и поиске других ее проявлений. Наш процесс предотвращения дефектов систематически сокращает число дефектов, потому как каждый дефект служит уроком для предотвращения себе подобных в будущем. Как только члены команды осознали, что устранение дефектов является их функцией, поиски “козла отпущения” прекратились.

Наиболее выдающееся улучшение процесса, в котором я принимал участие, выросло из процедуры распознавания тенденций появления дефектов в программном обеспечении. За эту процедуру отвечал я. Причинно-следственный анализ был выполнен для всех SPR (SPR - software problem report), зафиксированных для программ, написанных за 10-летний период. Список специфических и общих типов дефектов был использован для обновления таблиц контрольных проверок у разработчиков. Это резко сократило количество дефектов в последующих версиях программ, которые разрабатывались с учетов обновленной таблицы контрольных проверок. Я считаю, что это снижение напрямую можно отнести на счет новой таблицы контрольных проверок.

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

Как исполнители оборонного контракта, разрабатывающие программное обеспечение для запуска спутников, которые могут стоить миллиарды долларов, мы имели достаточное основание принять CMM, только для того, чтобы удовлетворить нашего заказчика – военно-воздушные силы США. Однако наиболее выдающимся выигрышем от процессов высокого уровня зрелости стало доверие к нам со стороны военно-воздушных сил – не за счет высокого рейтинга CMM, а за счет высокого качества, предсказуемой стоимости и соблюдения сроков.

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

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

Аттестация на Уровень 5 принесла нам неожиданные привилегии. Нам внезапно доверили ведущие роли в разработке программного обеспечения. Это началось с немедленного внимания к нам со стороны руководства, которое всего несколько лет назад поставило целью для всех подразделений разработчиков ПО достигнуть Уровня 3. Они были приятно удивлены, узнав, что мы продемонстрировали гораздо более высокий уровень зрелости процессов разработки ПО. Джери Кинг (Jerry King), президент Boeing D&SG принял нас на специальном торжественном банкете в Музее Полетов (Museum of Flight) и вручил бронзовые медальоны в память об этом событии. Фотография и статья были опубликованы в Boeing News. Некоторые из нас даже получили приглашение воспользоваться шикарными корпоративными костюмами во время игры Seattle Seahawks прошлой осенью.

Что касается меня, это достижение дало мне возможность стать центром внимания группы по процессам программной инженерии (SEPG - software engineering process group) и обеспечило членство в новой группе SEPG в D&SG. Меня часто представляют сотрудникам из других проектов как “одного из тех парней, работающих в организации Уровня 5 SEI”. Время от времени мне приходится напоминать другим, что я не какой-нибудь вундеркинд от программирования, но что Уровень 5 значит просто, что я являюсь частью организации с большим опытом внедрения и использования процессов, повышающих качество программной продукции.

Более практичную неожиданную выгоду от достижения Уровня 5 мы получили, когда отвечали на квалификационный вопросник по разработке программному обеспечению (SDCE - Software Development Capability Evaluation) в составе предложений для военно-воздушных сил. Анкета SDCE имела много общего с CMM. Имея установленные на основе CMM процессы было гораздо легче отвечать на сложные квалификационные вопросы. Вдобавок документация, подтверждающая наши притязания, была уже готова для включения в состав наших ответов. Во время отборочного совещания по этим предложениям часть, посвященная программному обеспечению, получила исключительно высокую оценку.

Мы получили выдающиеся результаты с помощью наших процессов, и я всегда заинтересован в как можно более раннем их внедрения в новых проектах. Мои товарищи ощущают такие же положительные эмоции. Майк Янега (Mike Yanega), ведущий программист проекта IUS, говорит: “Я думаю, что признание как организации Уровня 5 придает мне дольше уверенности в наших решениях, так как многие хорошие вещи, которые мы делаем, мы делали за годы до того, как первый раз услышали про CMM. Аттестация на Уровень 5 служит стимулом идти в ногу со временем, так что мне легче убеждать людей стараться работать лучше и не лениться”.

Рич Де Анжело (Rich D'Angelo), руководитель группы программистов проекта, говорит: “В прошлом программному обеспечению была присуща высокая непредсказуемость. Процессы высокого уровня зрелости и управление процессами не только обеспечивают предсказуемость результатов, но и создают костяк, который улучшает даже ваши лучшие процессы”.

Роджер Уолтер (Roger Walter), ведущий авиаконструктор говорит: “Очень тяжело работать над проектом, когда организация такова, что ты никогда не знаешь, чего можно ждать от людей, с которыми взаимодействуешь. Наличие устоявшихся процессов, которые постоянно дают предсказуемые результаты, вызывает у других доверие, как к технической грамотности, так и к реальности сроков исполнения”.

Марк Олсок (Mark Olsoc), отвечающий за технологические изменения, говорит: “Я обнаружил, что одной из наиболее приятных особенностей работы в организации с высоким уровнем CMM является возможность быть в курсе новых технологий. Программная инженерия такая динамичная область, что очень интересно, захватывающе и важно идти в ногу с новыми технологиями”.

И Джон Харви (John Harvey), разработчик программного обеспечения полетов в проекте UIS говорит: “Мы ощущаем партнерство и кооперацию между программистами и контролерами (DRB - Data Review Board) в том, что мы вместе можем производить бездефектный код в отведенные сроки и в рамках бюджета. Мне приятно то, каким образом контролеры вовлечены в процесс, оценивая и корректируя самих себя, и помогая в общем процессе проектирования. Контролеры теперь так крепко связаны с нашим процессом разработки, что если они внезапно исчезнут, я потеряю дополнительное доверие и техническую поддержку, которую они оказывают”.

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

Курсы по управлению качеством на основе CMM

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Отправить ссылку на страницу по e-mail
Обсудить на форуме