Программная инженерия развивается экстремальными методами

В мире разработано несколько десятков методологий и подходов к организации процессов создания программного продукта. Условно их можно поделить на тяжелые (например, RUP компании Rational или CMM-SE института программной инженерии при университете Карнеги - Меллона) и легкие (называемые также экстремальными, гибкими или проворными).

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

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

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

Модель "Водопад" предусматривает последовательный переход от фазы к фазе - поочередно выполняются определение системных требований, анализ требований к продукту, предварительное и детальное проектирование, кодирование, тестирование, объединение модулей, проверка работы всей системы, комплексное и системное тестирование и внедрение.

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

Главная проблема подобных подходов - экспоненциальный рост времени на устранение выявляемых на последних этапах ошибок (особенно если они связаны с неверно спроектированной архитектурой системы или с плохо сформулированными требованиями).

На основе последовательной модели была разработана эволюционная (или спиральная) методология. Она ориентирована на использование в условиях, когда все требования не удается сформулировать заранее. При этом происходит многократное повторение цикла "анализ - проектирование - кодирование - тестирование".

Экстремальные методологии

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

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

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

ЭМ будут работать только при наличии высокопроизводительной команды, в которой отлажен механизм взаимодействия, а каждый сотрудник способен переключаться на разные виды работ. Разработка ПО - это прежде всего организация сотрудничества между людьми и только потом - применение Java или Си++, считает Пауль Аллен, эксперт консорциума Cutter, возглавляемого Эдом Йордоном.

Экстремальное программирование

Познакомимся с одной из наиболее популярных ЭМ - экстремальным программированием (ЭП, Extreme Programming; http://www.xprogramming.com). Эта легкая методология была придумана Кентом Бэком (Kent Beck), одним из активных участников проекта по развитию языка SmallTalk, и изложена им в книге "Extreme Programming Explained". Бэк использовал для создания ЭП достаточно простой подход - брал различные методологические элементы и, если они выглядели (по его мнению) простыми и полезными, обобщал на весь проект или применял в рамках очень коротких циклов.

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

В основе ЭП лежат 12 принципов.

Взаимодействие. От каждого сотрудника требуется умение синхронизировать свою работу с деятельностью других людей и соответственно понимать структуру всего продукта.

Выбор приоритетов (по Эду Йордону). На основе стоимостных оценок решается, какая функциональность должна быть реализована обязательно, а что можно отсрочить.

Небольшие релизы. Разработчики выпускают работоспособную версию очень рано и расширяют ее возможности очень часто.

Система имен. В процессе разработки и общения используется единая терминология.

Простота проектирования. Создаваемая программа будет простым продуктом, отвечающим текущим требованиям заказчика. В нее не закладываются возможности "на будущее".

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

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

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

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

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

40-часовая рабочая неделя. Усталые программисты делают больше ошибок.

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

Особенности применения ЭМ

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

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

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

В статье использованы материалы журнала CrossTalk и консорциума Cutter