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

Ключевое слово «agile» в названии перспективного направления программной инженерии Agile Software Development (www.agilemanifesto.org) переводят по-разному: «скорое», «быстрое» [3], «гибкое» [5], «подвижное» [4], однако мне кажется, что прилагательное «ретивое» точнее подчеркивает целеустремленный характер разработок, выполняемых в соответствии с этой методологией.

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

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

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

Аgile-программы и agile-программирование

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

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

Как и современные программы, нынешние методы программной инженерии во многом интерактивны, что легко проследить на фазе кодирования. Диалоговый характер средств автоматизации программирования простирается не только на проектирование пользовательского интерфейса (look and feel), но и на участки текстов на языке программирования. Сегодняшние инструменты «на ходу», по мере набора текста, отслеживают корректность, выделяют и диагностируют ошибки, раскрашивают синтаксические конструкции, предлагают возможные варианты.

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

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

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

Ретивое потребление

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

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

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

Отражением возрастающей роли общения в потреблении программ являются изменения в пользовательском интерфейсе. Так, в основном меню новых версий продуктов Microsoft есть команда Community. Она обеспечивает стандартизированный выход на форум пользователей, где с большой вероятностью можно получить ответ на конкретный вопрос. Средства обратной связи (от автоматической посылки сообщения об аварийной ситуации до оперативного сбора информации о вариантах использования программы и конфигурациях окружения) буквально встраиваются в программу. И конечно, на уровне пользовательского интерфейса всячески поощряются отзывы и предложения. Размещение в сети справочного обеспечения (on-line help) и базы знаний, статьи которой помогают разрешать возникающие у потребителя трудности, позволяет оперативно корректировать и развивать программы.

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

Ретивое взаимодействие

Говоря о тесном оперативном взаимодействии заинтересованных лиц, необходимо, прежде всего, определиться с их «номенклатурой» — ролями, которые они играют непосредственно в проекте, а также косвенными связями, возникающими благодаря цепочкам «разработка-потребление». Под ролями в проекте, как правило, понимают ответственности лиц, создающих программу, например архитектор, разработчик, тестировщик, менеджер проекта [1]. К сожалению, ролям заказчика/пользователя уделяется значительно меньше внимания. Разве что в рамках стандартов программной инженерии сформулирован подход, представляющий поставщиков и потребителей программной продукции как равноправных партнеров [6]. Многообразие вариантов ролей в команде разработчиков и форм взаимодействия с потребителями невозможно даже кратко обозначить в рамках одной статьи, и мы остановимся лишь на некоторых современных тенденциях, влияющих на характер взаимодействия.

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

Расширение сферы применения (т.е. выход на глобальное потребление) связано с проблемами локализации. Причем требуются не только перевод пользовательского интерфейса и документации на другой язык, но и адаптация иных культурно зависимых элементов. Простейший пример: использовать плавающую точку или запятую? Более сложно понять, какой ряд пиктограмм уместен в местной традиции. Таким образом, к проекту подсоединяются переводчики и культурологи.

Выход программного продукта/услуги на рынок сопряжен со специфическими юридическими вопросами и требует привлечения специалистов.

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

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

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

Дисциплина agile-программирования

Как ни парадоксален этот заголовок, он не является противоречивым. Доказательством тому могут послужить методики Тома Гилба [7, 8], автора многочисленных работ на данную тему, пропагандиста эволюционной разработки и консультанта в ряде успешных крупных проектов. Интересно, что он не только не отказывается от планирования, но ставит этот процесс во главу угла agile-программной инженерии. Основой его методики служит способ формализованного представления элементов плана и спецификаций — язык Planguage (a quantified planning language). Базируясь на нем, Гилб предлагает процедуру эволюционного управления проектом — Evo.

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

Основной упор Гилб делает на явное количественное определение показателей качества. Цели каждого шага разработки задаются в терминах достижения конкретного уровня по шкале, например «Шкала: Число дефектов на страницу& Уровень: Не более одного дефекта на страницу». Выявление структуры показателей качества гораздо важнее конкретных числовых показателей, тем более что показатели эти, как правило, — условно числовые. Многие из них либо определяются бинарно («есть-нет»), либо по номинативной шкале оцениваются экспертами, либо представляют собой статистическую характеристику, которую трудно сделать представительной. Корректнее определять области с размытыми границами в пространствах, в которых часть размерностей номинативны. Однако постулируемая Гилбом определенность показателей позволяет осмысленно задавать векторы развития, которое считается постоянным. В ходе реализации проекта добавляются новые концепты и изменяются (при появлении новых версий) старые. После каждой итерации показатели измеряются и сопоставляются с плановыми.

Эволюционное управление проектом, согласно Evo, предполагает весьма жесткие временные рамки итерации — как правило, это неделя. Вот лишь один пример.

  1. Соберите от всех заинтересованных лиц информацию о 5-20 наиболее важных целях.
  2. Для каждой цели определите шкалу и уровень, который необходимо достичь (например, для цели Надежность: Шкала: Среднее время между отказами; Цель — больше одного месяца).
  3. Определите бюджет для основных ресурсов (время, люди, деньги, оборудование).
  4. Сформируйте план, фиксирующий цели и бюджет (желательно на одной странице).
  5. Согласуйте план с ключевыми заинтересованными лицами.
  6. Определите план очередного (недельного) шага в терминах целей-бюджета.
  7. Реализуйте шаг проекта и сообщите результаты по всем показателям бюджета ключевым заинтересованным лицам (на одной странице).
  8. Когда цели достигнуты, освободите ресурсы.

Конкретизацией этого плана служит расписание работы команды (по дням недели):

  • понедельник — тестирование версии N, передача ее пользователям, разработка версии N+1;
  • вторник-среда — реализация версии N+1;
  • среда — обсуждение с пользователями результатов использования версии N;
  • четверг — завершение версии N+1;
  • пятница — построение и тестирование версии N+1.

Какими бы парадоксальными ни казались эти планы людям, привыкшим к большим проектам, они обеспечили множество успешных внедрений. Среди них — и крупные оборонные проекты, в частности для US Army Personnel Information Systems Command (PERSINSCOM, www.result-planning.com/Download/PMMANUSAUG.pdf).

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

Рассуждая о целевых показателях качества для разработчиков, Гилб приводит отнюдь не численную шкалу, а «принципы да Винчи»:

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

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

Литература
  1. Ф. Брукс, Мифический человеко-месяц, или Как создаются программные системы. СПб.: Символ-Плюс, 2001.
  2. Э. Кармел, Р. Агарвал, Тактика глобальной разработки. «Открытые системы», 2001, № 11.
  3. А. Коберн, Быстрая разработка программного обеспечения. М.: Лори, 2002.
  4. С. Кузнецов, Как совместить подвижность с планом. «Открытые системы», 2003, № 9.
  5. Т. Литтл, Гибкость в борьбе со сложностью и неопределенностью. «Открытые системы», 2005, № 10.
  6. Н. Маркова, Нет так сложен SPICE, как его написали. «Открытые системы», 2001, № 12.
  7. T, Gilb, Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering and Software Engineering Using Planguage Butterworth-Heinemann, 2005.
  8. T. Gilb, Principles of Software Engineering Management. Addison Wesley Longman, 1989.

Наталья Маркова (Markova@amsd.com)— ведущий научный сотрудник ИПИ РАН (Москва).