В 90-х годах основным продуктом Iona Technologies было промежуточное программное обеспечение Orbix на базе CORBA. С того времени мы создали новую версию Orbix, но здесь мы поговорим о том, как мы поддерживаем более старую версию. Мы также рассмотрим внутренние проблемы энтропии кода, возникающие из-за нестабильности спецификации и напряжения, вызванного стремлением как можно быстрее выпустить продукт на рынок.

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

Проблемы

Когда к 1999 году Iona из небольшой фирмы превратилась в ведущего поставщика промежуточного программного обеспечения, она столкнулась с четырьмя основными группами проблем: процессами и приемами разработки, тестированием, энтропией кода и моральным состоянием команды разработки. Реорганизация, затеянная в 1997 году, потребовала огромных ресурсов на переработку программ, улучшенное тестирование и внесение изменений в кодовую базу, призванных удовлетворить требования последней версии CORBA, эффективно решить перечисленные проблемы в нем не удалось; мы лишь слегка коснулись того, что необходимо было сделать.

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

Тестирование. Качество не было сильной стороной Orbix. Мы не следили за тем, чтобы тщательно документировать проведение тестов, поэтому нам не удавалось получить хорошие параметры. Наши пакеты тестов были очень громоздкими, трудными для исполнения, и по ним нельзя было составить точный отчет. Пакет тестов, используемый для того, чтобы обеспечить и проверить интероперабельность с другими продуктами компании не был автоматизирован для всего множества платформ, для которых мы выпускали свой продукт.

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

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

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

Ранняя история изменений

В 1999 году, еще до появления книги Бека «Описание экстремального программирования» (Extreme Programming Explained) [1], компания Iona вела несколько проектов, направленных на решение выявленных проблем. Проанализировав эти проекты, мы пришли к выводу, что многие из реализуемых в них вещей являются элементами методологии XP.

Реинжиниринг. Вторая серия проектов реинжиниринга первоначально концентрировалась на решении проблем, о которых упоминали многие заказчики. Эти проблемы были, в первую очередь, связаны с некачественной реализацией программного обеспечения. Группы выявленных ошибок четко показали эти проблемные области. Сейчас эти работы продолжаются в рамках наших усилий по внедрению XP. Дополнительным следствием этих первоначальных усилий стало сокращение сложности кода за счет удаления неиспользуемого кода и внедрения нескольких подходов, которые упростили поддержку, тестирование и понимание кода. В итоге код был сокращен более чем на 40%.

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

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

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

Экстремальная поддержка

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

Несмотря на прогресс, нам еще предстояло решить вопросы тестирования, представления, морального климата и персонифицированных методов работы. С точки зрения управления, мы стремились достичь большего меньшими усилиями: более высокой производительности, параллельно улучшив качество, сократив размер группы и увеличив уровень удовлетворенности заказчиков. Инженеры хотели получить больше времени для того, чтобы хорошо сделать свою работу, а не находиться всегда в напряжении, будучи вынуждены исправлять одну ошибку за другой. Поэтому мы начали анализировать возможность использования XP и выяснили, что многие его элементы естественно вписываются в работу групп, занимающихся сопровождением. По словам Бека, «сопровождение — это естественное состояние проекта XP» [1].

В наших более ранних проектах мы создавали набор процессов обслуживания, которые описывали, как возникают ошибки, как их следует приоритезировать, анализировать, исправлять и в каком виде предлагать решения заказчику. Группа Generation 3 также работала с набором процессов, которые объясняют, как создавать запрос, описывать, классифицировать и реализовывать последовательные усовершенствования и предлагать их пользователям. Действительно, эти процессы уже включают в себя важные элементы XP; экстремальное сопровождение означает следование модели XP в течение всего цикла жизни продукта [2].

Совпадение оказалось настолько значительным, что мы начали применять термин XP для описания набора процессов и приемов, которые использовали участники группы Generation 3. Затем мы стали активно и целенаправленно опробовать XP. В таблице 1 представлены все приемы, описанные в [1], и рассказано, до какой степени мы их внедрили.

Метафора

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

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

Рис. 1. Оперативное совещание перед доской объявлений

Мы также ввели традицию проведения ежедневных совещаний в группе (см. рис. 1) — элемент XP. Каждая группа тратит по 15-30 минут на анализ своих результатов, и каждый член группы коротко рассказывает о том, чем он занимался в течение этого и предыдущего дня. Цель состояла не только в том, чтобы получить ясное представление о проводимой работе, но и о поддержке связей между членами группы. Качественные результаты были получены сразу же. Некоторые сотрудники пришли к выводу, что трудно объяснить, почему они потратили так много времени на вопросы, или почему они занимались вещами, которые отсутствовали в списке задач с самыми высокими приоритетами.

Тестирование

Автоматизация имеет существенное значение, и одна из первых инициатив была связана с автоматизацией тестовых пакетов и ускорением работы с ними. В 2000 году мы завершили связанный с этой инициативой расширенный проект, который позволяет разработчикам собирать и тестировать весь набор продуктов на любом сочетании платформ, которое мы поддерживаем. Это позволяет по ночам тестировать весь набор продуктов на соответствие спецификации CORBA и API-интерфейсу Orbix и проверять тестовые ситуации, предоставленные пользователям, а также по выбору инженера на любой из 17 поддерживаемых нами платформах. Инженер по тестированию требует, чтобы каждый из пользователей предоставил тестовую ситуацию для ошибки, и уже затем принимается за работу над ней. Эта тестовая ситуация автоматически включается в состав тестового пакета, выполняемого по ночам.

Любой инженер должен иметь возможность собирать весь продукт или систему и запускать тестовый пакет, чтобы сразу получить информацию об эффективности сделанных изменений. Еженощная сборка — разумный промежуточный шаг для тестирования по требованию. И опять-таки, процесс, которому мы решили следовать, хорошо соответствует представлению о тестировании, составляющем основу модели XP — «тестировать прежде, чем вы начнете реализовывать», и все тестировать как можно чаще.

Работа в паре

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

Наш эксперимент с парным программированием был проведен в конце 2000 года. Все произошло случайно. Группа Generation 3 работала над особо сложным набором вопросов. Один из инженеров компании-заказчика находился у нас в офисе. (Присутствие заказчиков — еще один принцип XP, хотя обычно мы считаем своим заказчиком наших менеджеров по продуктам и представителей службы поддержки). В разное время заказчик работал с разными членами группы Generation 3 в режиме парного программирования. Точно также члены группы стремятся работать вдвоем в соответствии с концепцией парного программирования по мере того, как они добиваются прогресса в работе над вопросами конкретного заказчика.

В итоге, отдача оказалась очень высокой. Наши инженеры осознали, что работают более эффективно и поддерживают более тесное взаимодействие, чем при независимом решении отдельных вопросов. Кроме того, руководство приветствует отношения «наставничества», которые естественным образом складываются между «ветеранами» и менее опытными членами группы. Общая производительность во время этого периода была также высока, а моральный климат в коллективе стал намного лучше. Инженеры получили большую позитивную поддержку друг от друга, и инженерные решения и качество улучшились по мере того, как мы стали активно поддерживать отношения «наставничества». Кроме того, мы не получили ни одного нарекания по заплаткам, которые были подготовлены в режиме парного программирования.

Небольшие версии

Одна из особенностей XP — постепенное наращивание функциональности, которую инженеры могут быстро объединить в комплекс. Интеграция исправлений выполняется достаточно быстро, и, благодаря еженощной сборке и тестированию, осуществляемым буквально по нажатию одной клавиши, они могут предоставить систему с заплаткой в течение одного дня. В проектах, где XP внедряется уже в процессе реализации, мы считаем необходимым сосредотачиваться на решении задачи автоматизации любыми силами. Оперативная обратная связь может только увеличить уровень удовлетворенности пользователей.

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

Разбиение на составляющие

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

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

Организация помещения

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

До начала проекта XP офис, где работали инженеры Iona, имел обычную для офисного помещения структуру — несколько комнат, в каждой из которых располагалось шесть отсеков. Инженеры и менеджеры инициировали проект по реструктуризации пространства, в котором они работали, чтобы улучшить связь внутри группы. Они создали большой центральный зал, сократив индивидуальные отсеки на 20% и создав единое групповое рабочее пространство. Кроме того, в каждом рабочем подразделении были установлены доски объявлений и штативы с информацией. Был приобретен диван, а служба доставки заботится об освежающих напитках и закусках.

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

Качественные улучшения

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

Как показано на рис. 2, в период реализации этого проекта была достигнута пиковая производительность по сравнению с предыдущими и последующими месяцами. Повышение производительности составило 67%, по сравнению со следующими наиболее продуктивными пятью неделями, даже, несмотря на то, что общее число человеко-недель, пропущенных из-за каникул во время двух наиболее производительных периодов, относительно эквивалентно. Принимая во внимание складывающуюся тенденцию, мы считаем, что рост производительности сохранится даже, несмотря на то, что число членов группы в марте 2001 года было сокращено с 36 до 25.

Рис. 2 отображает несколько параметров. Во-первых, связанные с новыми ошибками вопросы, которые необходимо решить группе. Во-вторых, число закрытых вопросов — это количество вопросов, которые уже решены, причем соответствующая заплатка передана заказчику. Этот цикл подготовки заплаток представляет нашу итерацию XP и составляет порядка двух-трех недель.

Каким образом XP помогает нам добиваться улучшений? Во-первых, внедрение парного программирования может компенсировать нехватку перекрестного обучения между многими модулями кодовой базы. Это решение не предназначалось для такого применения, но позволило решить реальную проблему, учитывая, что число членов группы сокращается. Инженеры, осознавая преимущества, внедряют решения, предлагаемые в рамках XP, но мы по-прежнему находимся в процессе реализации более общего подхода, который позволит гарантировать, что методы парного программирования становятся частью культуры Iona. В начале года было предложено подписывать отдельный договор по каждой новой ошибке, запросу на усовершенствования или ошибке разделения, формируя тем самым индивидуальную ответственность за выбор партнера и работу над вопросом. Наши технические руководители одобряют такой подход, и теперь они используют его как часть стандартного процесса.

Во-вторых, накопление данных имеет критически важное значение для перепланирования, но убедить участвовать в этом инженеров — сложно. Чтобы спланировать, сколько потребуется времени над завершением работы над комментарием, необходимо знать, сколько времени выполнялся аналогичный фрагмент работы на основе оценок инженера, выбранного для ее выполнения. «Другими словами, планирование строится на предположении о том, что на этой неделе вы будете делать столько же, сколько делали на прошлой» [3]. Кент Бек и Мартин Фоулер назвали это правилом «вчерашней погоды», и мы считаем такую аналогию вполне уместной.

Сейчас мы работаем над внутренним проектом, который расширит наши возможности вводить параметры работы в нашу систему контроля дефектов и автоматически создавать по ним отчеты. Из-за большого объема вопросов их трудно отслеживать с помощью простых электронных таблиц, но мы все равно это делаем. Наш руководитель, отвечающий за операции, беседует с каждым разработчиком и отмечает, какого прогресса он добивается в своей работе. Имеющиеся у нас данные показывают, что инженеру на исправление ошибок, в среднем, требуется две недели [3]. Это соответствует предполагаемому сроку на реализацию комментария в модели XP. Измеряя календарное время с помощью системы контроля дефектов, мы можем определить календарное время, которое потребовалось на решение вопроса и, в конечном итоге, темпы работы группы [3]. Эта информация поистине бесценна для планирования того, что мы будем делать при создании следующей заплатки или следующей итерации выпуска.

Благодарности

Авторы благодарны Кенту Беку за его работу с командой Orbix Generation 3 и ценные замечания, которые он привел, чтобы убедить нас использовать XP. Хотелось бы особо отметить влияние идей, высказанных в книгах «Разбиение: совершенствование проектирования существующего кода» (Refactoring: Improving the Design of Existing Code, M. Fowler, Addison-Wesley, 1999) и «Внедрение экстремального программирования» (Extreme Programming Installed, R. Jeffries, A. Anderson, and C. Hendrickson, Addison-Wesley, 2000). Первая версия данной статьи была представлена в XP Universe в июле 2001 года.

Литература

[1] K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, Reading, Mass., 1999

[2] G.A. Moore, Crossing the Chasm: Marketing and Selling High Tech Products to Mainstream Customers, Harper Collins, NY, 1999

[3] K. Beck and M. Fowler, Planning Extreme Programming, Addison-Wesley, Reading, Mass., 2000

Чарлз Пул (charles.poole@iona.com) — главный менеджер по разработке компании Iona Technologies. Яан Виллем Хьюсман (jan.willem.huisman@iona.com) работает в Iona Technologies в качестве менеджера по разработке, руководящего командой сопровождения продуктов Orbix Generation 3.

Charles Pooule and Jan Willem Huisman, Using Extreme Programming in Maintenance Environment. IEEE Software, November/December 2001. Copyright IEEE Computer Society, 2002. All rights reserved. Reprinted with permission.