Тщательное экономическое обоснование всех действий - делается только то, что нужно заказчику и не приводит к невыгодности проекта.
Как можно более раннее формирование базовой архитектуры.
Использование компонентной архитектуры.
Прототипирование, инкрементная разработка и тестирование.
Регулярные оценки текущего состояния.
Управление изменениями, постоянная отработка изменений извне проекта.
Нацеленность на создание продукта, работоспособного в реальном окружении.
Нацеленность на качество.
Адаптация процесса под нужды проекта.
Экстремальное программирование (Extreme Programming, XP) возникло как эволюционный метод разработки ПО «снизу-вверх». Этот подход является примером так называемого метода «живой» разработки (Agile Development Method). В группу «живых» методов входят, помимо экстремального программирования, методы SCRUM, DSDM (Dynamic Systems Development Method, метод разработки динамичных систем), Feature-Driven Development (разработка, управляемая функциями системы) и др.
Основные принципы «живой» разработки ПО зафиксированы в манифесте «живой» разработки , появившемся в 2000 году.
Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты.
Работающая программа более важна, чем исчерпывающая документация.
Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта.
Отработка изменений более важна, чем следование планам.
«Живые» методы появились как протест против чрезмерной бюрократизации разработки ПО, обилия побочных, не являющихся необходимыми для получения конечного результата документов, которые приходится оформлять при проведении проекта в соответствии с большинством «тяжелых» процессов, дополнительной работы по поддержке фиксированного процесса организации, как это требуется в рамках, например, CMM. Большая часть таких работ и документов не имеет прямого отношения к разработке ПО и обеспечению его качества, а предназначена для соблюдения формальных пунктов контрактов на разработку, получения и подтверждения сертификатов на соответствие различным стандартам.
«Живые» методы позволяют большую часть усилий разработчиков сосредоточить собственно на задачах разработки и удовлетворения реальных потребностей пользователей. Отсутствие кипы документов и необходимости поддерживать их в связном состоянии позволяет более быстро и качественно реагировать на изменения в требованиях и в окружении, в котором придется работать будущей программе.
Тем не менее, XP имеет свою схему процесса разработки (хотя, вообще говоря, широко используемое понимание «процесса разработки» как достаточно жесткой схемы действий противоречит самой идее «живости» разработки), приведенную на Рис. 15.
По утверждению авторов XP, эта методика представляет собой не столько следование каким-то общим схемам действий, сколько применение комбинации следующих техник. При этом каждая техника важна, и без ее использования разработка считается идущей не по XP, согласно утверждению Кента Бека (Kent Beck) , одного из авторов этого подхода, наряду с Уордом Каннингемом (Ward Cunningham), и Роном Джефрисом (Ron Jeffries).
Живое планирование (planning game)
Его задача - как можно быстрее определить объем работ, которые нужно сделать до следующей версии ПО. Решение принимается, в первую очередь, на основе приоритетов заказчика (т.е. его потребностей, того, что нужно ему от системы для более успешного
ведения своего бизнеса) и, во вторую, на основе технических оценок (т.е. оценок трудоемкости разработки, совместимости с остальными элементами системы и пр.). Планы изменяются, как только они начинают расходиться с действительностью или пожеланиями заказчика.
Тестовые | ||||||
использования | сценарии | |||||
Новая история | ||||||
Требования | использования | |||||
Скорость проекта | ||||||
Метафора | План версии | |||||
Планирование | Итерация | Приемочные | Небольшие |
|||
архитектуры | Последняя | |||||
Одобрение |
||||||
пользователей |
||||||
Ненадежные | Уверенные | Новая итерация | ||||
«Вброс» решения
Рисунок 15. Схема потока работ в XP.
Частая смена версий (small releases)
Самая первая работающая версия должна появиться как можно быстрее и тут же должна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времени (от нескольких часов при небольших изменениях в небольшой программе, до месяца-двух при серьезной переработке крупной системы).
Метафора (metaphor) системы
Метафора в достаточно простом и понятном команде виде должна описывать основной механизм работы системы. Это понятие напоминает архитектуру, но должно гораздо проще, всего в виде одной-двух фраз описывать основную суть принятых технических решений.
Простые проектные решения (simple design)
В каждый момент времени система должна быть сконструирована настолько просто, насколько это возможно. Не надо добавлять функции заранее - только после явной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается.
Разработка на основе тестирования (test-driven development)
Разработчики сначала пишут тесты, потом пытаются реализовать свои модули так, чтобы тесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основные возможности системы, чтобы можно было увидеть, что система действительно заработала.
Постоянная переработка (refactoring)
Программисты постоянно перерабатывают систему для устранения излишней сложности, увеличения понятности кода, повышения его гибкости, но без изменений в его поведении, что проверяется прогоном после каждой переделки тестов. При этом предпочтение отдается более элегантным и гибким решениям, по сравнению с просто дающими нужный результат. Неудачно переработанные компоненты должны выявляться при выполнении тестов и откатываться к последнему целостному состоянию (вместе с зависимыми от них компонентами).
Программирование парами (pair programming)
Кодирование выполняется двумя программистами на одном компьютере. Объединение в пары произвольно и меняется от задачи к задаче. Тот, в чьих руках клавиатура, пытается наилучшим способом решить текущую задачу. Второй программист анализирует работу
первого и дает советы, обдумывает последствия тех или иных решений, новые тесты, менее прямые, но более гибкие решения.
Коллективное владение кодом (collective ownership)
В любой момент любой член команды может изменить любую часть кода. Никто не должен выделять свою собственную область ответственности, вся команда в целом отвечает за весь код.
Постоянная интеграция (continuous integration)
Система собирается и проходит интеграционное тестирование как можно чаще, по несколько раз в день, каждый раз, когда пара программистов оканчивает реализацию очередной функции.
40-часовая рабочая неделя
Сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд - это истощает программистов и делает их работу значительно менее продуктивной.
Включение заказчика в команду (on-site customer)
В составе команды разработчиков постоянно находится представитель заказчика, который доступен в течение всего рабочего дня и способен отвечать на все вопросы о системе. Его обязанностью являются достаточно оперативные ответы на вопросы любого типа, касающиеся функций системы, ее интерфейса, требуемой производительности, правильной работы системы в сложных ситуациях, необходимости поддерживать связь с другими приложениями и пр.
Использование кода как средства коммуникации
Код рассматривается как важнейшее средство общения внутри команды. Ясность кода - один из основных приоритетов. Следование стандартам кодирования, обеспечивающим такую ясность, обязательно. Такие стандарты, помимо ясности кода, должны обеспечивать минимальность выражений (запрет на дублирование кода и информации) и должны быть приняты всеми членами команды.
Открытое рабочее пространство (open workspace)
Команда размещается в одном, достаточно просторном помещении, для упрощения коммуникации и возможности проведения коллективных обсуждений при планировании и принятии важных технических решений.
Изменение правил по необходимости (just rules)
Каждый член команды должен принять перечисленные правила, но при возникновении необходимости команда может поменять их, если все ее члены пришли к согласию по поводу этого изменения.
Как видно из применяемых техник, XP рассчитано на использование в рамках небольших команд (не более 10 программистов), что подчеркивается и авторами этой методики. Больший размер команды разрушает необходимую для успеха простоту коммуникации и делает невозможным применение многих перечисленных приемов.
Достоинствами XP, если его удается применить, является большая гибкость, возможность быстро и аккуратно вносить изменения в ПО в ответ на изменения требований и отдельные пожелания заказчиков, высокое качество получающегося в результате кода и отсутствие необходимости убеждать заказчиков в том, что результат соответствует их ожиданиям.
Недостатками этого подхода являются невыполнимость в таком стиле достаточно больших и сложных проектов, невозможность планировать сроки и трудоемкость проекта на достаточно долгую перспективу и четко предсказать результаты длительного проекта в терминах соотношения качества результата и затрат времени и ресурсов. Также можно отметить неприспособленность XP для тех случаев, в которых возможные решения не находятся сразу на основе ранее полученного опыта, а требуют проведения предварительных исследований
XP как совокупность описанных техник впервые было использовано в ходе работы на проектом C3 (Chrysler Comprehensive Compensation System, разработка системы учета выплат
работникам компании Daimler Chrysler). Из 20-ти участников этого проекта 5 (в том числе упомянутые выше 3 основных автора XP) опубликовали еще во время самого проекта и в дальнейшем 3 книги и огромное количество статей, посвященных XP. Этот проект неоднократно упоминается в различных источниках как пример использования этой методики . Приведенные ниже данные собраны на основе упомянутых статей , за вычетом не подтверждающихся сведений, и иллюстрируют проблемы некоторых техник XP при их применении в достаточно сложных проектах.
Проект стартовал в январе 1995 года. С марта 1996 года, после включения в него Кента Бека, он проходил с использованием XP. К этому времени он уже вышел за рамки бюджета и планов поэтапной реализации функций. Команда разработчиков была сокращена, и в течение примерно полугода после этого проект развивался довольно успешно. В августе 1998 года появился прототип, который мог обслуживать около 10000 служащих. Первоначально предполагалось, что проект завершится в середине 1999 года и результирующее ПО будет использоваться для управления выплатами 87000 служащим компании. Он был остановлен в феврале 2000 года после 4-х лет работы по XP в связи с полным несоблюдением временных рамок и бюджета. Созданное ПО ни разу не использовалось для работы с данными о более чем 10000 служащих, хотя было показано, что оно справится с данными 30000 работников компании. Человек, игравший роль включенного в команду заказчика в проекте, уволился через несколько месяцев такой работы, не выдержав нагрузки, и так и не получил адекватной замены до конца проекта.
У. Ройс. Управление проектами по созданию программного обеспечения. М.: Лори, 2002.
А. Якобсон, Г. Буч, Дж. Рамбо. Унифицированный процесс разработки программного обеспечения. СПб.: Питер, 2002.
Kroll, The Spirit of the RUP. www-106.ibm.com/developerworks/rational/library/ content/RationalEdge/dec01/ TheSpiritoftheRUPDec01.pdf
К. Бек. Экстремальное программирование. СПб.: Питер, 2002.
http://www.agilemanifesto.org/
K. Beck, et. al. Chrysler goes to “Extremes”. Distributed Computing, 10/1998.
A. Cockburn. Selecting a Project’s Methodology. IEEE Software, 04/2000.
L. Williams, R. R. Kessler, W. Cunningham, R. Jeffries. Strengthening the Case for Pair Programming. IEEE Software 4/2000.
G. Keefer. Extreme Programming Considered Harmful for Reliable Software Development. AVOCA Technical Report, 2002.
Доступен как http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf .
Экстремальное программирование или XP, eXtreme Programming — гибкая методология разработки программного обеспечения. Как и у других agile методологий, у нее есть особенные инструменты, процессы и роли. Хотя автор XP не придумал ничего нового, а взял лучшие практики гибкой разработки и усилил до максимума. Поэтому программирование и зовется экстремальным.
Автор методики — американский разработчик Кент Бек. В конце 90-х годов он руководил проектом Chrysler Comprehensive Compensation System и там впервые применил практики экстремального программирования. Свой опыт и созданную концепцию он описал в книге Extreme Programming Explained, опубликованной в 1999 году. За ней были выпущены другие книги, в которых подробно описывались практики XP. К становлению методологии причастны также Уорд Каннингем, Мартин Фаулер и другие.
Цель методики XP — справиться с постоянно меняющимися требованиями к программному продукту и повысить качество разработки. Поэтому XP хорошо подходит для сложных и неопределенных проектов
Методология XP строится вокруг четырех процессов: кодирования, тестирования, дизайна и слушания. Кроме того, экстремальное программирование имеет ценности: простоту, коммуникацию, обратную связь, смелость и уважение.
Все участники проекта с применением XP работают как одна команда. В нее обязательно входит представитель заказчика, лучше, если это будет реальный конечный пользователь продукта, разбирающийся в бизнесе. Заказчик выдвигает требования к продукту и расставляет приоритеты в реализации функциональности. Ему могут помогать бизнес-аналитики. Со стороны исполнителей в команду входят разработчики и тестировщики, иногда коуч, направляющий команду, и менеджер, который обеспечивает команду ресурсами.
На планировании релиза команда программистов встречается с заказчиком, чтобы выяснить, какую функциональность он хочет получить к следующему релизу, то есть через 2-6 месяцев. Так как требования заказчика часто размытые, разработчики конкретизируют их и дробят на части, реализация которых занимает не более одного дня. Важно, чтобы заказчик разбирался в операционной среде, в которой будет работать продукт.
Задачи записываются на карточки, а заказчик определяет их приоритет. Дальше разработчики оценивают, сколько времени уйдет на каждую задачу. Когда задачи описаны и оценены, заказчик просматривает документацию и дает добро на начало работы. Для успеха проекта критично, чтобы заказчик и команда программистов играли на одном поле: заказчик выбирает действительно необходимую функциональность в рамках бюджета, а программисты адекватно сопоставляют требования заказчика со своими возможностями.
В XP если команда не успевает выполнить все задачи к дате релиза, то релиз не отодвигается, а режется часть функционала, наименее важная для заказчика.
В XP версии выпускаются часто, но с небольшим функционалом. Во-первых, маленький объем функциональности легко тестировать и сохранять работоспособность всей системы. Во-вторых, каждую итерацию заказчик получает часть функционала, несущую бизнес-ценность.
Заказчик сам определяет автоматизированные приемочные тесты, чтобы проверить работоспособность очередной функции продукта. Команда пишет эти тесты и использует их для тестирования готового кода.
В XP любой разработчик может править любой кусок кода, т.к. код не закреплен за своим автором. Кодом владеет вся команда.
Это значит, что новые части кода сразу же встраиваются в систему — команды XP заливают новый билд каждые несколько часов и чаще. Во-первых, сразу видно, как последние изменения влияют на систему. Если новый кусок кода что-то сломал, то ошибку найти и исправить в разы проще, чем спустя неделю. Во-вторых, команда всегда работает с последней версией системы.
Когда кодом владеют все, важно принять единые стандарты оформления, чтобы код выглядел так, как будто он написан одним профессионалом. Можно выработать свои стандарты или принять готовые.
Метафора системы — это ее сравнение с чем-то знакомым, чтобы сформировать у команды общее видение. Обычно метафору системы продумывает тот, кто разрабатывает архитектуру и представляет систему целиком.
XP команды работают на максимуме продуктивности, сохраняя устойчивый темп. При этом экстремальное программирование негативно относится к переработкам и пропагандирует 40-часовую рабочую неделю.
Одна из самых трудных практик методологии. В XP тесты пишутся самими программистами, причем ДО написания кода, который нужно протестировать. При таком подходе каждый кусок функционала будет покрыт тестами на 100%. Когда пара программистов заливают код в репозиторий, сразу запускаются модульные тесты. И ВСЕ они должны сработать. Тогда разработчики будут уверены, что движутся в правильном направлении.
Представьте двух разработчиков за одним компьютером, работающих над одним куском функциональности продукта. Это и есть парное программирование, самая спорная практика XP. Старая поговорка «одна голова хорошо, а две лучше» отлично иллюстрирует суть подхода. Из двух вариантов решения проблемы выбирается лучший, код оптимизируется сразу же, ошибки отлавливаются еще до их совершения. В итоге имеем чистый код, в котором хорошо разбираются сразу двое разработчиков.
Простой дизайн в XP означает делать только то, что нужно сейчас, не пытаясь угадать будущую функциональность. Простой дизайн и непрерывный рефакторинг дают синергетический эффект — когда код простой, его легко оптимизировать.
Рефакторинг — это процесс постоянного улучшения дизайна системы, чтобы привести его в соответствие новым требованиям. Рефакторинг включает удаление дублей кода, повышение связности и снижение сопряжения. XP предполагает постоянные рефакторинги, поэтому дизайн кода всегда остается простым.
Методология XP вызывает много споров и критики со стороны тех, кто так и не смог ее внедрить в своей команде.
В первой книге Кент Бек сформулировал такие принципы экстремального программирования: простота, коммуникация, обратная связь и смелость. В новом издании книги он добавил пятый принцип — уважение.
В XP разработка начинается с самого простого решения, которое удовлетворит текущую потребность в функциональности. Члены команды учитывают только то, что должно быть сделано сейчас, и не закладывают в код функциональность, которая понадобится завтра, через месяц или никогда.
В XP коммуникация между разработчиками ведется не посредством документации, а вживую. Команда активно общается между собой и с заказчиком.
Некоторые методики экстремального программирования настолько непривычны, что требует смелости и постоянного контроля над собой.
В экстремальном программировании уважение рассматривается с точки зрения уважения к команде и самоуважения. Члены команды не должны заливать изменения, которые поломают компиляцию, модульные тесты, или замедлят работу коллег. Каждый стремится к высшему качеству кода и дизайна.
Бек Кент рекомендует внедрять XP для решения проблем в проекте. Команда выбирает самую насущную проблему и решает ее с помощью одной из практик экстремального программирования. Затем переходит к следующей проблеме, используя еще одну практику. При таком подходе проблемы выступают мотивацией к применению XP и команда постепенно осваивает все инструменты методологии.
Команда создает тесты ПЕРЕД написанием нового кода и постепенно перерабатывает старый код. Для старого кода тесты пишутся по мере необходимости: когда нужно добавить новую функциональность, исправить ошибку или переработать часть старого кода.
Команда постепенно рефакторит старый код, обычно перед добавлением новой функциональности. Как и в случае с тестированием, рефакторинг старого кода проводят только по необходимости. При этом команде стоит сформулировать долгосрочные цели переработки кода и постепенно достигать их.
Команда должна перейти на тесное взаимодействие с заказчиком. На этом этапе важно донести до него преимущества работы в одной команде с разработчиками и интегрировать его в команду.
Роль менеджеров при переходе на XP — контролировать, чтобы все члены команды работали по новым правилам. Менеджер проекта принимает решение, когда расстаться с членом команды, который не справляется с работой в новых условиях, или найти нового и правильно интегрировать его в работу.
Преобразования в разработке начинаются с организации рабочих мест для программирования парами. Следующая задача — программировать парами большую часть рабочего времени, как бы тяжело это не давалось разработчикам.
По данным исследования Versionone за 2016 год всего 1% agile компаний используют экстремальное программирование в чистом виде. Еще 10% работают по гибридной методологии scrum и XP.
Интересно, что хотя XP далеко не самая распространенная методология в чистом виде, ее практики используются большинством компаний, работающих по гибким методологиям. Об этом говорят данные того же исследования:
Не так просто найти информацию о командах, которые применяют XP, но есть и те, кто афиширует, что именно эта методология — причина их успеха. Пример экстремального программирования — компания Pivotal Software, Inc.
Американская софтверная компания, которая разрабатывает ПО для бизнес-анализа на основе big data и оказывает консультационные услуги. Продуктами Pivotal пользуются корпорации Ford, Mercedes, BMW, GAP, Humana, крупные банки, государственные учреждения, страховые компании и т.д.
Pivotal — адвокат agile методологий, как единственно возможных в современной разработке. Из всех вариантов гибких методологий компания выбрала XP как win-win подход для заказчиков и команд программистов. Каждый рабочий день начинается с собрания на ходу, и заканчивается ровно в 18:00 — никаких переработок. Pivotal использует игру в планирование, парное программирование, постоянное тестирование, непрерывную интеграцию и другие практики XP. Для многих практик у них есть собственное ПО.
По экстремальному программированию от создателя методологии Кента Бека. Начните с первой, в ней с примерами описывается концепция XP и обосновываются ее преимущества. Позднее автор выпустил еще несколько книг, где подробно описал отдельные практики XP.
Так как экстремальное программирование стремится к чистому и легко поддерживаемому коду, к списку книг можно отнести все издания, которые учат программировать лучше.
Команды, работающие над проектами по методологии XP, применяют таск менеджеры и сервисы для agile проектов. На рынке много таких продуктов, мы рассмотрим несколько примеров.
Бесплатный менеджер задач с открытым кодом. Основные функции: работа сразу над несколькими проектами, гибкая система управления задачами, диаграмма Ганта, контроль времени, работа с документацией, создание задач через почту и др.
Простой удобный сервис для совместной работы над проектами. Включает таск менеджер, доску сообщений, встроенный чат, файлохранилище, календарь
Мощный сервис, разработанный специально для разработчиков agile проектов. Объединяет баг-трекер и сервис для управления проектами. Много функций плюс синхронизация с другими сервисами. Решения для команд разных размеров.
Для работы над проектами. Позволяет ставить задачи и контролировать процесс выполнения, вести переписку по задаче, настраивать фильтры, учитывать расход времени и финансов, работать с файлами.
Экстремальное программирование — гибкая методология, в центре которой качественный работоспособный код с простой архитектурой. Ее предназначение — снизить уровень неопределенности в проектах и по-настоящему гибко реагировать на изменения требований к продукту.
Немногие компании рискуют работать по чистому XP, но его практики разработки — самые популярные в agile проектах. И это весомый довод в пользу их эффективности.
Никто не обязывает внедрять XP по принципу «все или ничего». В конце концов, гибкие методологии должны быть гибкими и в плане применения — подстраиваться под нужды конкретной команды и проекта.
Экстремальное программирование
(англ. Extreme Programming, XP) - одна из гибких методологий разработки программного обеспечения. Авторы методологии - Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.Название методологии исходит из идеи применить полезные традиционные методы и практики разработки программного обеспечения, подняв их на новый «экстремальный» уровень. Так, например, практика выполнения ревизии кода, заключающая в проверке одним программистом кода,
написанного другим программистом, в «экстремальном» варианте представляет собой «парное программирование», когда один программист занимается кодированием, а его напарник в это же время непрерывно просматривает только что написанный кoд.
Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:
XP предполагает написание автоматических тестов (программный код, написанный специально для того, чтобы тестировать логику другого программного кода). Особое внимание уделяется двум разновидностям тестирования:
Разработчик не может быть уверен в правильности написанного им кода до тех пор, пока не сработают абсолютно все тесты модулей разрабатываемой им системы. Тесты модулей (юнит-тесты) позволяют разработчикам убедиться в том, что каждый из них по отдельности работает корректно. Они также помогают другим разработчикам понять, зачем нужен тот или иной фрагмент кода, и как он функционирует - в ходе изучения кода тестов логика работы тестируемого кода становится понятной, так как видно, как он
должен использоваться. Тесты модулей также позволяют разработчику без каких-либо опасений выполнять рефакторинг (refactoring).
Функциональные тесты предназначены для тестирования функционирования логики, образуемой взаимодействием нескольких (часто - довольно внушительного размера) частей. Они менее детальны, чем юнит-тесты, но покрывают гораздо больше - то есть, у тестов, которые при своём выполнении затрагивают больший объём кода, шанс обнаружить какое-либо некорректное поведение, очевидно, больше. По этой причине в промышленном программировании написание функциональных тестов
нередко имеет больший приоритет, чем написание юнит-тестов.
Для XP более приоритетным является подход, называемый TDD (от англ. test-driven development - разработка через тестирование). В соответствии с этим подходом сначала пишется тест, который изначально не проходит (так как логики, которую он должен проверять, ещё просто не существует), затем реализуется логика, необходимая для того, чтобы тест прошёл. TDD, в некотором смысле, позволяет писать код, более удобный в использовании - потому что при написании теста, когда логики ещё нет,
проще всего позаботиться об удобстве будущей системы.
Основная цель игры в планирование - быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими. Артефактами игры в планирование является набор бумажных карточек, на которых записаны пожелания заказчика (customer stories), и приблизительный план работы по выпуску следующих одной или нескольких небольших версий продукта.
Критическим фактором, благодаря которому такой стиль планирования оказывается эффективным, является то, что в данном случае заказчик отвечает за принятие бизнес-решений, а команда разработчиков отвечает за принятие технических решений. Если не выполняется это правило, весь процесс распадается на части.
В экстремальном программировании наблюдается отход от традиционного процесса создания программ - вместо единоразового планирования, анализа и проектирования системы с расчетом на долгосрочную перспективу программисты реализуют теперь все эти операции постепенно в ходе разработки.
Вначале была модель «водопада» (рис.1а): мы просим пользователей однозначно сформулировать свои требования; мы разрабатываем проект системы, которая сделает все, что хотят пользователи; мы пишем код; мы тестируем программу, дабы убедиться, что она действительно делает то, что требуется. Все получается замечательно.
На самом же деле, дела обстояли далеко не так радужно. Перед началом разработки пользователи еще не в состоянии однозначно сформулировать свои требования. Они не всегда знали, чего хотят, подчас противоречили сами себе и меняли свои взгляды на проблему. Но дело не только в пользователях. Мы, программисты, пройдя три четверти пути и обнаружив, что реально выполнили лишь одну треть работы, радовались этому как грандиозному успеху.
Итак, длинный цикл разработки плох, поскольку не способен приспосабливаться к изменениям. Тогда, возможно, надо сократить цикл, и все проблемы будут решены? На рис. 1b дана иллюстрация перерождения модели «водопада» в итеративную модель.
Напомним, что модель водопада появилась не на пустом месте - это была естественная реакция на те шокирующие оценки, которые показывали: цена внесения изменения в программу с течением времени очень сильно возрастает. Если это действительно так, то необходимо принимать важнейшие, далеко идущие решения на наиболее раннем этапе жизненного цикла программы чтобы не пришлось потом дорого заплатить за них.
Академическое сообщество разработчиков ПО взялось разрешить проблему высокой стоимости изменений и создало новые технологии - реляционные базы данных, модульное программирование, сокрытие информации. Но что если все эти труды уже исчерпали свой потенциал? И нам удастся найти новый способ снизить расходы на внесение изменений, не разрезая «водопад» на части, а просто смешав все его компоненты? То, что получилось в результате, показано на рисунке 1с. Мы назвали это «экстремальным программированием» (Extreme Programming, XP).
XP отходит от традиционного процесса создания программной системы и вместо единоразового планирования, анализа и проектирования с расчетом на долгосрочную перспективу при XP все эти операции реализуются постепенно в ходе разработки, добиваясь тем самым значительного сокращения стоимости изменений в программе. Методы XP разрабатывались с расчетом на совокупное использование, поэтому, разбираясь в одном из них, вы неизбежно придете к пониманию остальных (врезка ). Во врезке прослеживаются исторические предпосылки возникновения этого подхода).
На рис. 2 процесс XP соотносится с различными осями времени, где в качестве единицы измерения используются годы, месяцы, недели и дни. Заказчик определяет очередную версию (release) системы, выбирая наиболее ценные функции (в XP их называют историями - story) из всех возможных. Ценность функций определяется материальными и временными затратами на их реализацию командой разработчиков.
Заказчик определяет истории для следующей итерации, выбирая наиболее значимые истории из оставшихся в версии, вновь опираясь на оценку стоимости и скорости их разработки. Программисты разбивают истории на локальные задачи, и каждый берет на себя ответственность за одну из них. Затем программист преобразует свою задачу в набор тестовых примеров, успешное выполнение которых покажет, что задача решена полностью. Работая в паре с партнером, программист добивается нормальной работы тестов, одновременно развивая общий проект. Таким образом, удается реализовать максимально простую архитектуру системы в целом.
С точки зрения XP, период, предшествующий первому запуску системы в реальную эксплуатацию, является опасной аномалией в жизненном цикле проекта, и его надо преодолеть как можно быстрее. Однако работу над любым проектом надо как-то начать.
Прежде всего, необходимо решить, для чего вообще предназначена система и что она должна уметь делать в первую очередь. Как правило, для принятия таких решений нужен определенный анализ. Его символизирует узкий голубой прямоугольник на рис. 1с. Вы не можете начать программировать, пока не поймете, что, собственно, необходимо запрограммировать.
Результаты общего анализа оформляются как истории - индексы с перечислением возможных применений системы. Необходимо, чтобы каждая история была ориентирована на определенные задачи бизнеса, чтобы ее можно было протестировать и оценить с помощью количественных показателей. Месяц - вполне приемлемое время, чтобы сформулировать истории для проекта, рассчитанного на 10 человеко-лет. Понятно, что этого времени недостаточно для детального исследования всех возможных проблем. Но на анализ всех проблем никогда не хватит времени, если вы вообще намерены переходить к реализации системы.
Как видно из рис. 2, мы не реализуем сразу все истории. Заказчик вначале выбирает небольшое множество наиболее важных историй, логически связанных между собой. И мы программируем и запускаем в эксплуатацию прежде всего именно их. После этого реализуется все остальное.
Выбор историй для версии системы можно сравнить с покупками в супермаркете. Вы направляетесь в магазин с сотней долларов в кармане. Продумываете, что вам необходимо в первую очередь. Смотрите на ценники. И решаете, что купить. На этапе планирования (planning game) товары - это истории, а ценники - оценки историй. Ваш бюджет определяется числом оцененных историй, реализуемых командой разработчиков за выбранную единицу времени.
Покупатель (заказчик) может либо заполнить свою корзину (выбрать набор историй), после чего программисты вычислят окончательную дату их реализации, либо назначат дату, под которую программисты вычислят бюджет, а заказчик наберет нужное количество историй на полученную сумму.
Цель каждой итерации - запустить в эксплуатацию несколько новых протестированных и готовых к выполнению историй. Этот процесс начинается с составления плана, в котором определяется, какие истории будут реализованы и каким образом команда разработчиков будет выполнять эту задачу. Пока идет разработка, заказчик придумывает функциональные тесты. В конце итерации тесты должны работать, а разработчики должны быть готовы к следующей итерации.
Начиная планировать итерацию, разработчики вновь просят заказчика выбрать наиболее ценные истории, на этот раз из числа оставшихся для реализации в этой версии. Разработчики разбивают истории на задачи - модули, с реализацией которых один человек справится за несколько дней. Если есть несколько технических задач, таких, например, как переход к новой версии базы данных, их тоже включают в общий список.
Затем программисты берут на себя ответственность за реализацию определенных задач. После того как все задачи распределены, программист, ответственный за задачу, оценивает ее, на этот раз по числу идеальных дней программирования. Затем собираются оценки задач всех программистов команды, и если некоторые из них планируют затратить больше времени на реализацию, а другие меньше, нагрузка в команде перераспределяется соответствующим образом.
В ходе итерации программисты реализуют свои задачи. По мере завершения задач их код интегрируется в общую систему и тестируется вместе с ней. Либо все тесты успешно проходят, либо код нельзя интегрировать в систему. В ходе итерации в общую серию тестов добавляются предоставляемые заказчиком функциональные тесты. В конце итерации должны работать все тесты для отдельных модулей и все функциональные тесты.
Для того чтобы реализовать задачу, ответственный за нее программист прежде всего ищет себе партнера, поскольку окончательный код всегда пишется двумя людьми на одной машине. Если возникают вопросы о предмете или методах реализации, партнеры проводят короткую (15-минутную) встречу с заказчиком и/или программистами, осведомленными в вопросах кодирования задач, которые с наибольшей вероятностью будут связаны с кодом данной задачи в ходе реализации.
По результатам этой встречи программисты составляют список тестовых примеров, которые необходимо прогнать до завершения реализации задачи. Из списка выбирается такой тест, в реализации которого программисты полностью уверены, и с помощью которого они смогут лучше понять суть задачи. Пишется тестовая программа. Если она сразу нормально заработает, можно двигаться дальше. Однако как правило, без проблем не обходится. В случае если тест не работает, возможна одна из следующих ситуаций:
После того, как тест заработал, мы, возможно, снова поймем как усовершенствовать систему, что и сделаем.
Вполне вероятно, что в ходе реализации тестового примера мы найдем другой тестовый пример, который также должен работать. Мы заносим новый тест в свой список и продолжаем разработку. Возможно, мы обнаружим, что масштабы перестройки системы выходят за рамки требований текущего теста, тогда зафиксируем и этот факт и двинемся дальше. В конце концов, наша цель - сконцентрироваться на деталях и успешно справиться с конкретной проблемой, но одновременно не потерять общего представления о системе, которое формируется в процессе интенсивной работы над кодами.
Если говорить о ключевом методе ХР, то это, безусловно, тестирование модулей (unit testing). Как вы уже могли понять, тестирование модулей является неотъемлемой частью повседневной работы каждого программиста. Две особенности делают процесс тестирования в ХР гораздо эффективным по сравнению с традиционными методами: программисты сами пишут свои тесты и делают это до начала кодирования. Конечно, если подходить к программированию как к постепенному изучению проблемы, а изучение проблемы считать наиболее эффективным средством обратной связи с заказчиком, то больше всего пользы вам принесут тесты, написанные третьим лицом через несколько дней или недель после завершения кодирования. ХР учитывает общепринятое мнение, что программисты не могут правильно протестировать свой собственный код, поэтому и обязывает их работать парами.
Некоторые методологии, в частности, Cleanroom , запрещают программистам тестировать, а в ряде случаев даже компилировать свои программы. Обычно программист пишет код, компилирует его, убеждается в том, что он работает, а затем передает его некоторой тестирующей организации. Традиционные методы эталонного тестирования - это пошаговый анализ кода и переменных, интерпретация результатов работы операторов вывода на печать, проверка кнопок меню и т.д.
ХР не вносит никаких новых приемов тестирования по сравнению с обычными методами. Просто тестирование проводится в иной форме и вместо того чтобы делать нечто, от чего не останется и следа после завершения тестирования, вы создаете тесты на долгую перспективу. Эти тесты работают сегодня, будут работать в день завершения интеграции системы, и на следующий день, и через неделю, и в будущем году. Уверенность в нормальной работе каждого отдельного теста постепенно формирует у разработчиков уверенность в нормальной работе системы в целом.
Как уже отмечалось, заказчики также придумывают тесты. В начале итерации заказчик должен найти те факторы, которые убедят его в том, что истории для данной итерации реализованы полностью. Свои мысли на этот счет он формализует в тестах для системы в целом. Заказчик может самостоятельно написать тесты с помощью текстовых или графических сценарных языков, либо доверить их программисту, который воспользуется собственными инструментами тестирования. Такие тесты также формируют уверенность, на этот раз, уверенность заказчика в правильности работы системы.
Обсуждать тот или иной метод программирования в условиях, когда он работает прекрасно, нетрудно. Гораздо интереснее узнать, что вы будете делать, оказавшись в непредвиденной или нежелательной ситуации.
Переоценка собственных возможностей. Время от времени вы берете на себя больше, чем в состоянии выполнить. Необходимо по возможности свести к минимуму число подобных ситуаций, как можно чаще прибегая к количественным оценкам вашей работы. Если вы оказались перегружены, прежде всего поищите причину в себе. Проанализируйте: возможно, вы слишком отвлеклись от решения практических задач. С полной ли отдачей проводите тестирование, работаете в паре с партнером, занимаетесь переработкой системы и интеграцией? Не делаете ли больше, чем требуется заказчику в данный момент?
Если вы не в состоянии изыскать внутренние резервы для ускорения разработки, то стоит попросить заказчика помочь вам. Сохранять за собой ответственность за объем работ, выполнение которого вы не можете гарантировать - значит срывать план, вредить качеству системы и, наконец, полностью потерять работоспособность. Не позволяйте себе этого. Еще раз проанализируйте свои возможности, опираясь на приобретенный опыт, и затем обратитесь к заказчику с просьбой пересмотреть свои требования. Если вы в состоянии реализовать только две из трех историй - пусть он определит, за какие истории надо взяться в первую очередь, а какую оставить для следующей итерации или версии. Нет ли такой истории, некоторые части которой имеют более важное значение по сравнению с другими? Тогда вы сможете разбить ее реализацию на этапы, и запрограммировать более актуальные компоненты не откладывая, а менее важные - несколько позже.
Если заказчик не идет на сотрудничество. Представьте себе ситуацию, когда заказчик не принимает правила вашей игры. Не придумывает тесты, не определяет приоритеты, не формулирует истории. Прежде всего, попытайтесь установить доверительные отношения с заказчиком. Наращивая функциональность системы от итерации к итерации, предоставьте заказчику возможность контролировать процесс разработки. Если взаимного доверия не получается, проанализируйте, есть ли в этом ваша вина. Все ли вы делаете для эффективного взаимодействия с заказчиком?
Если вы не можете самостоятельно справиться с этой проблемой, обратитесь за помощью к заказчику. Принципы ХР просто не позволяют программистам вести разработку, строя догадки о потребностях своих заказчиков. Объясните или продемонстрируйте заказчику на примере последовательность работ в ХР. Если он не изменит своего отношения к вам, попробуйте сделать свои доводы более наглядными. Если же окажется, что, по существу, никому кроме вас нет дела до решения этой проблемы, возможно, данный проект имеет невысокий приоритет в деятельности заказчика, и не стоит вообще настаивать на его продолжении.
Текучесть кадров. Предположим, один из членов команды решил ее покинуть. Не окажетесь ли вы в тупиковой ситуации из-за отсутствия нужных документов ли отчетов? Прежде всего, заметим, что некоторая текучесть кадров полезна для команды разработчиков и отдельных ее членов. Хотелось бы, конечно, чтобы, уходя, люди руководствовались положительными мотивами. Если, отправляясь домой в конце очередной недели, программист видит конкретные положительные результаты своей деятельности, вероятность его разочарования в работе и возникновения желания уйти значительно снижается.
Если кто-нибудь уходит из ХР-проекта, это вовсе не означает, что он унесет с собой известные ему одному секреты. Каждая строчка в системе всегда контролируется двумя людьми. И какая бы информация не вышла за пределы рабочей комнаты, это не нанесет большого ущерба работе команды, поскольку разработчики смогут прогнать тесты и проверить, не произошло ли без их ведома что-нибудь непредвиденное.
Новые члены ХР-команды в ходе работы над первыми двумя итерациями ограничиваются посильной помощью более опытному партнеру в паре, изучением тестов и общением с заказчиком. Почувствовав большую уверенность в своих силах, они смогут взять на себя ответственность за определенную задачу. Во время разработки нескольких следующих итераций работоспособность новичков настолько повышается, что они в состоянии продемонстрировать всем реализацию конкретных задач в срок. По прошествии нескольких месяцев их уже не отличить от опытных членов команды.
Непростую проблему являют собой программисты, не привыкшие работать в команде. ХР - это напряженный совместный труд, и не каждый способен приспособиться к такому режиму работы. Возможно придется отказаться от старых привычек, а это совсем не просто, в особенности для программистов, которые высоко себя ценят. Но в конце концов многочисленные формы обратной связи, предусмотренные в ХР, позволяют точно определить, кто может работать в команде, а кто нет. Если один из вас постоянно не успевает довести задачу до конца, интеграция его модулей всегда вызывает проблемы для других членов команды, он никогда не пытается переработать систему, не работает в паре, не проводит тестирования и т.п. Каждый в команде поймет, что к чему. И всему коллективу будет только лучше, если такой человек уйдет, независимо от его умений и опыта.
Перемена требований. Проблема из проблем для большинства систем разработки вообще не является таковой для ХР. Созданный сегодня для решения конкретных задач, ХР-проект с той же эффективностью справится с любыми переменами функциональности в будущем. Сделать нечто похожее на то, что уже сделано, будет проще, поскольку ХР исповедует принцип «каждую мысль формулируй один и только один раз». Именно в таких переработках необходимость возникает чаще всего. Но и в том случае, когда появится совершенно новое требование к системе, вам не придется на скорую руку сооружать новые механизмы ее работы.
Вначале я не представлял себе достаточно четко степень адаптируемости ХР к изменениям. В первой версии ХР процесс выбора историй был частью планирования версии, и истории назначались для всех итераций в версии. Затем разработчики обнаружили, что затрачивая меньшие усилий на планирование, можно достичь лучших результатов. Поэтому теперь заказчика просят специфицировать только те истории, которые должны присутствовать в очередной итерации. Если появляется новая история, вы помещаете ее в резерв и не перетасовываете оставшуюся часть итерации. Через одну или две недели, если новая история еще не потеряла своей актуальности, заказчик выберет ее.
Планируя каждый раз по одной итерации, мы достигаем постепенного саморазвития и самоподобия системы. В масштабе месяцев и лет мы имеем дело с историями данной версии системы и затем с историями будущих версий. В масштабе недель и месяцев мы имеем дело с историями данной итерации и затем с историями, оставшимися в данной версии. В масштабе дней и недель мы имеем дело с задачей, над которой работаем в данный момент, а затем с задачами, оставшимися в итерации. Наконец, в масштабе минут и дней мы имеем дело с тестом, который прогоняем в данный момент, и затем с другими тестовыми примерами, которые, возможно, придут нам в голову.
Без всякого сомнения, ХР - элегантная, логически завершенная идея. Пределы ее применимости пока до конца не ясны. Взявшись реализовать этот подход сейчас, вы должны проявить определенную смелость, гибкость и готовность отказаться от проекта в случае неудачи. ХР стоит вначале испробовать в тех проектах, где польза от этого подхода очевидна: в заказной или собственной разработке небольших систем, требования к которым четко не определены и вполне могут измениться.
Если вы хотите испытать ХР не старайтесь сделать все сразу. Выберите самую неприятную для себя проблему и попробуйте решить ее с помощью ХР. Когда эта проблема перестанет быть самой неприятной, поищите следующую и повторите процесс. Продолжая в том же духе, вы, вероятно, обнаружите, что ни один из ваших старых методов уже не приносит пользы. Тогда можно больше к ним не обращаться. Такой процесс постепенной адаптации дает шанс выработать собственный стиль разработки - которым вы будете руководствоваться в любой ситуации - и тем самым снизить риск возникновения проблем с ХР.
Строгое разграничение между деловыми и техническими решениями, которое проводит ХР, восходит к работам архитектора Кристофера Александра. В его книге «The Timeless Way of Building» отмечается, что те, кто эксплуатирует здание, должны быть допущены к принятию важных решений в процессе его сооружения.
Принятые в ХР принципы быстрого развития плана в соответствии с вносимыми техническими и связанными с бизнесом изменениями, отражают принципы методологии Scrum и разработанного Уордом Кэнингхемом языка шаблонов Episodes .
Идея специфицирования и планирования проекта с точки зрения реализуемых возможностей восходит к работам Ивара Якобсона .
Том Гилб - гуру эволюционной разработки. В его последних трудах основное внимание уделяется вводу программного обеспечения в эксплуатацию в течение нескольких недель, с последующим его развитием.
«Спиральная модель» (Spiral Model) Барри Боэма была первой реакцией на устаревание модели водопада. Долгое время в освоении мощных технологий никто не мог превзойти Дейва Томаса и его коллег из Object Technology International, создавших метод JIT .
Корни принципа метафор, которые используются в ХР, можно найти в книгах Джорджа Лакоффа и Марка Джонсона, в частности, в их последней работе «Philoslphy in the Flesh» . Этот принцип предложен также Ричардом Койне, который связывал метафору и разработку программного обеспечения с точки зрения постмодернистской философии .
Наконец, то значительное внимание, которое ХР уделяет организации офисного пространства, проистекает из работ Джима Коплиена , Тома ДеМарко и Тима Листера , отмечавших влияние окружающих условий на работу программистов.
Джи Ханнула
Команда: менеджеры, бизнес-аналитики, разработчики, тестировщики, технические писатели
Приложение: база данных управления кампанией
Срок реализации: 3 года
В компании Acxiom на основе склада данных создали приложение управления бизнесом, использовав для этого инструментарий распределенной объектно-ориентированной разработки Forte. Небольшая команда разработчиков - всего 10 человек - при создании приложения твердо придерживалась принципов объектно-ориентированного программирования и коллективной разработки. Из трех лет, затраченных на разработку, в течение двух последних команда, включавшая в себя менеджеров, бизнес-аналитиков, разработчиков, тестировщиков и технических писателей, использовала методы экстремального программирования и именно благодаря этому достигла успеха.
До недавнего времени в Acxiom считали проект удавшимся, если он прост и некоторые из созданных ранее систем могли претендовать на то, чтобы стать частью нового приложения. Однако оказалось, что ничего хорошего из этого не выходит. Переработка системы стала важнейшим элементом разработки. Мы ясно осознали, что опасаясь изменять те части программы, функции которых нам пока не известны, мы не сможем считаться хорошими разработчиками. Мы позволили программе управлять нами. Если нам было неизвестно, что делает данный код, мы не боялись влезть в него и разобраться. Лучше самим реализовать определенную часть кода, чем сделать все приложение заложником отдельного его куска.
Много сил пришлось потратить на тестирование модулей, поскольку Forte не предлагает встроенных базовых средств для тестирования. Нам пришлось создать свои и с их помощью успешно провести тестирование. Недавно мы перешли на язык программирования Java и теперь как средство тестирования используем JUnit.
Когда мы только начинали работать по принципам ХР, среди нас нашлись программисты, не пожелавшие использовать его методы. Они считали, что эти методы не соответствуют выработанному ими стилю программирования и помешают им работать продуктивно. В результате больше всего проблем возникало с компонентами системы, написанными этими людьми. Эти разработчики игнорировали работу в паре, и по своим умениям стали уступать другим членам команды, которые воспользовались представленным им шансом поучиться друг у друга. Два опытных программиста, которые работают в тесной взаимосвязи друг с другом и остальной частью команды, всегда будут превосходить по мастерству «индивидуала», будь он даже семи пядей во лбу.
Мы поняли, что следовать принципам ХР должен каждый член команды, иначе этот подход не будет работать. Теперь мы сразу предупреждаем потенциального разработчика, что если его не устраивает принятый у нас стиль, ему лучше поискать работу в другом коллективе. Один человек, не заинтересованный в выбранном методе разработки, может свести к нулю усилия всей команды. Суть ХР - коллективная выработка новых идей в процессе создания системы.
Относительно ХР существует заблуждение, что данный подход подавляет творческую активность и развитие индивидуальных способностей разработчика. На самом деле, все обстоит как раз наоборот. ХР стимулирует творческий рост программиста и дает шанс отдельным членам команды проявить себя. Главное, определиться и твердо держаться выбранного направления.
«Экстремальное программирование» не поставило нашу команду в экстремальные условия. Этот метод использует хорошо известные и во многом привычные подходы к разработке. Все работают в тесной связке и совместно движутся к поставленной цели.
Чет Хендриксен
Команда: 15 человек, из них 10 программистов
Приложение: полномасштабная автоматизация расчета платежных ведомостей
Срок реализации: 4 года
Работа над проектом С3 была начата в январе 1995 года. Корпорация Chrysler заключила контракт с партнерской компанией, в соответствии с которым за реализацию проекта бралась объединенная команда разработчиков из обеих организаций. Наши партнеры придерживались методологии разработки, ориентированной на использование графического интерфейса и игнорировавшей автоматизацию тестирования. В результате мы получили систему, которая изобиловала невыразительной графикой и для большинства служащих вычисляла зарплату неправильно. Для создания месячной платежной ведомости такой системе понадобилось бы около 100 дней. Мы поняли, что написанная нами программа никогда не будет реально использоваться.
Мы обратились к Кенту Беку с просьбой помочь отрегулировать производительность системы. Он обнаружил у нас те же явления, с которыми сам постоянно сталкивается, берясь за задачу настройки производительности: плохо продуманный код, тесты, которые нельзя запустить повторно, руководство, потерявшее уверенность в своем проекте. Кент Бек порекомендовал выбросить весь написанный код и начать полномасштабный ХР-проект.
Прежний контракт был разорван, и Chrysler почти наполовину обновила свою команду разработчиков. Начиная с этого момента мы действовали по правилам ХР. Были распределены обязанности, спланированы итерации, установлены правила тестирования, опробовано и принято в качестве стандарта программирование в паре. К концу 33-й недели мы получили систему, в которой уже можно было начинать отлаживать производительность и проводить параллельное тестирование. Мы могли приступить к настройке производительности, поскольку система была хорошо продумана и подкреплена полным набором модульных тестов. Мы были готовы к параллельному тестированию, поскольку серия функциональных тестов наглядно продемонстрировала заказчику наличие в системе требуемых возможностей.
Этот этап реализации С3 был запущен в мае 1997 года, хотя мы рассчитывали на более ранние сроки. Срыв наших планов был обусловлен двумя факторами. Во-первых, мы решили заменить только внутренние компоненты платежной системы. Все внешние интерфейсы остались нетронутыми. Поставить в соответствие выходные данные новой системы компонентам старой оказалось гораздо более сложной задачей, чем мы предполагали. Во-вторых, мы решили в течение любого платежного периода не инициировать реализацию специальных требований, таких, например, как обработка W-2, участие в прибыли или общее повышение заработной платы. В результате то, что должно было быть сделано в ноябре, перенеслось на апрель.
После запуска системы расчета ежемесячной оплаты мы добавили несколько новых возможностей и автоматизировали расчет оплаты раз в две недели. Оплата для пилотной группы просчитывается с августа 1998 года, и мы надеемся запустить работающую систему для остальных служащих до ноября 1999.
Анализируя опыт, накопленный в ходе этой длительной разработки, могу сказать, что мы не оправдывали ожиданий нашего руководства и наших заказчиков только тогда, когда отступали от принципов ХР. Когда определяющим в ходе разработки становился процесс тестирования, когда мы писали код парами, когда реализовывались самые простые, наверняка работающие функции, мы превращались в лучшую команду, которая только может быть.
Дон Уэлс
Команда: 17 человек, из них 12 программистов
Приложение: система анализа затрат
Срок реализации: 6 лет
Отдел финансовых систем компании Ford Motor разрабатывает аналитическую систему Vehicle Costing and Profit System (VCAPS), которая создает отчеты по доходам от производства, расходам, чистому доходу и прибыли. Входными данными для системы являются инженерные спецификации продукции, фиксированные затраты и расходы и переменные затраты, например, рабочие часы. VCAPS аккумулирует все эти данные и подготавливает подробные отчеты с анализом затрат, которые обеспечивают эффективное прогнозирование и принятие корпоративных решений. Работа над проектом VCAPS была начата в 1993 году. При разработке использовались VisualWorks и GemStone Smalltalk. В данный момент поддержкой системы VCAPS занимается небольшая группа специалистов, и в скором времени она будет заменена более современным приложением.
При реализации проекта VCAPS нам пришлось решать две серьезные проблемы. Во-первых, аналитики хотели вносить изменения в систему и одновременно получать уже работающие новые функции. Требования постоянно менялись, и мы просто не успевали за ними. Во-вторых, существовали определенные ограничения на время работы системы. При этом система затрачивала много времени на обработку данных и требовала ручного ввода длинных последовательностей. Любая ошибка приводила к необходимости повторного запуска и потерям драгоценного времени.
С помощью ХР мы добились уникального сочетания возможностей: смогли оперативно реагировать на постоянно меняющиеся требования и достигли такого качества системы, которое позволило избежать опасных перезапусков.
Работа по методам ХР началась с этапа планирования. И это оказалось ошибкой. Заказчики и руководство не привыкли совместно улаживать график работ. То, что получилось в результате, страдало недостатком правдоподобия и практической применимости. Пришлось перейти на планы MS Project, которые можно было менять, не устраивая общих собраний, и с помощью которых мы получили планы в привычном для руководства виде.
Дальше мы сделали несколько модульных тестов и уже через год 40% системы было протестировано, а руководство отметило сокращение числа сообщений об ошибках на 40%. После этого на ХР обратили пристальное внимание.
Мы решали проблемы, реализуя все новые методы ХР. Тесты позволили нам перейти к непрерывной интеграции и частой смене версий. Это, в свою очередь, открыло дорогу к коллективному владению и переработке системы. Мы стремились создавать простой проект. Наконец наступил момент, когда мы решили попробовать программировать в парах. И нам пришлось немало потрудиться, чтобы добиться в этом успеха. Поначалу нашим разработчикам этот метод показался чрезвычайно неудобным; потребовалось время, чтобы привыкнуть и почувствовать себя в нем достаточно комфортно.
Через полтора года количество системных сбоев снизилось настолько, что наши заказчики и руководство смогли констатировать значительно более высокую стабильность системы. Для нас это символизировало успех принципов ХР.
Роб Ми
Команда: три разработчика
Приложение: система вычисления тарифов на перевозки
Срок реализации: 3 месяца
Tariff System - часть большого проекта, реализованного с помощью SmallTalk/GemStone в одной из крупных международных компаний, специализирующихся на контейнерных перевозках. Подход ХР позволил за три месяца силами трех человек пройти все этапы разработки этой подсистемы, от замысла до ввода в эксплуатацию. Результат оказался замечательно стабильным и простым в сопровождении.
Начиная работу над проектом, мы сразу решили твердо придерживаться нескольких базовых принципов ХР: всегда программировать в парах, использовать настолько простую архитектуру, насколько возможно, активно перерабатывать систему и писать много модульных тестов. Все эти принципы доказали свою эффективность. Одна идея ХР поначалу казалась нам несколько надуманной - писать тесты для кода, прежде чем написан сам код. Тем более мы были удивлены, обнаружив, что этот принцип позволяет выявить архитектурные проблемы и ускоряет процесс разработки.
С самого начала мы использовали еще один метод ХР - сбор пользовательских требований в виде историй. Результаты оказались не вполне однозначными. Мы - программисты и занимаемся прежде всего кодированием, поэтому поиск общего языка с пользователями стал для нас непростой задачей. Еще сильнее усложнял положение тот факт, что мы хотели получить от пользователей истории, одновременно релевантные и недвусмысленные, а для этого им надо было активно помогать. В конце концов, мы пришли к выводу, что в ХР недостает одной специальной роли. Нам нужен был человек, чьей основной задачей будет взаимодействие с пользователями. Очевидно, что он должен обладать соответствующими способностями.
Создавая и перерабатывая тестовые примеры, мы поняли, что для написания основных доменных объектов очень полезными будут специально придуманные для них небольшие языки, благодаря которым тестовый код становится гораздо более кратким и удобочитаемым. Кроме того, мы перестали тратить время на придумывание способов задания экземпляров объектов в процессе написания тестов, а определили грамматики для десяти доменных классов. По грамматике автоматически создается синтаксический анализатор, который используется конструктором для создания доменного объекта. Код для создания экземпляра объекта с помощью стандартных конструкторов будет очень длинным, почти не поддающимся прочтению и мало чем напоминающим сам тестовый пример.
Embracing Change with Extreme Programming, Kent Beck. Computer, October, 1999, pp. 70-77, Reprinted with permission, Copyright IEEE, 1999, All rights reserved.
Возможно, это прозвучит странно, но около 75% програмного обеспечения вообще не выходит в люди. С другой стороны, существует множество компаний, которые производят софт в огромном количестве. Все это и многое другое обязывает программистов снижать стоимость разработки. А для этого нужно понимать интересы заказчика, постоянно сотрудничать с ним, чтобы в итоге создать именно то, что ему необходимо.
Методология разработки програмного обеспечения eXtreme Programming (изобретатель - Kent Beck) получает все большее признание благодаря максимальному упрощению процессов проектирования и непосредственной разработки програмных продуктов в среде с быстро изменяющимися требованиями.
Существует всего лишь 5 ценностей экстремального программирования: простота, общение, обратная связь, смелость и уважение ("уважение" добавилось в последней редакции XP). На реализию этих основных ценностей и направлены 12 практических методик XP. Рассмотрим их в небольшом приближении. Кроме изветных многим истин, добавлю свои комментарии по поводу практик, основываясь на своем практическом опыте.
Процесс планирования (planning game). В XP планирование - это основная часть разработки. То, что планы могут внезапно поменяться, учитывается еще в самом начале. Аппетит заказчика приходит во время еды и нужно всегда держать ситуацию под контролем. Общение с заказчиком должно происходить как можно чаще. Это позволит точнее оценить сроки выполнения задач и внести необходимые коррективы в случае необходимости.
Быстрый выпуск версий (small releases). Как бы красиво не был описан продукт, все прелести его использования можно понять только работая с ним. Методика быстрого выпуска версий позволяет понять, чего же хочет заказчик, обеспечивая ранний выпуск рабочих версий продукта.
Комментарий: Как показывает практика, первую раннюю версию можно сделать за 2-8 недель, не зависимо от ожидаемой сложности продукта. Желательно, чтобы первую версию продукта (хотя бы первые несколько итераций) делало 2 человека за одним компьютером. В этом случае очень быстро вырисовывается дизайн системы. Далее можно привлекать еще людей, перераспределив пары.
Метафора (metaphor). Человеку намного легче запомнить отличия между двумя схожими предметами, чем знать строение предмета полностью. Методика метафора предлагает сравнивать систему (или один из ее модулей) с ее аналогами для удобства общения внутри команды и более глубокого понимания системы в целом.
Комментарий: Достаточно сложная практика, хотя на первый вгляд и кажется простой. Придумать метафоры для основных модулей системы - это не просто, но очень полезно. Многие программисты относят "метафору системы" к управленческим практикам, но мне кажется, что больше нужна она все-таки разработчикам. Правильный выбор метафор в конечном итоге поможет программистам придумать удачные названия классам и методам, что всегда положительно влияет на дизайн системы в целом.
Простота реализации (simple design). XP предлагает делать код программы простым. Зачем усложнять себе жизнь, если простую программу легче понимать и поддерживать и она менее подвержена ошибкам.
Опережающее тестирование (test-driven development). Экстремальное программирование рекомендует проверять существующий код как можно чаще. Именно поэтому и практикуется данная методика. Тесты пишутся еще до того, как будет написан кусок кода. Это позволяет лучше понимать поставленные задачи и предоставляет возможность проверить код сразу, как только он будет написан.
Комментарий: У такого подхода есть масса плюсов.
Во-первых, писать тесты перед написанием кода - один из лучших способов гарантировать наличие этих самых тестов.
Во-вторых, исключается нежелание тестировать некоторые "очевидные" ветки выполнения программы, хотя бы потому, что кода еще нет:). Ну и потом, при парном программировании тесты дейтвительно будут лаконичными и качественными.
В третьих, тесты усиливают уверенность программистов в себе, когда у них возникает желание произвести рефакторинг.
Рефакторинг (design improvement). Добавление новой функциональности и увеличение объема кода усложняет разработку и поиск ошибок. Решением этой проблемы является постоянная переработка (refactoring) кода. Рефакторинг - очень мощная и полезная вещь и заслуживает не то что отдельной статьи, а целых книг.
Комментарий: Не забывайте о ценности "смелость" и не бойтесь поламать систему во время рефакторинга. Тесты покажут, что сломалось и вы быстро исправите ошибки. Даже если тесты не покрывали некоторые аспекты, и вы не заметите какие-то потенциальные проблемы - ничего страшного, все всегда можно исправить. Главное, что дизайн системы стал проще и понятнее, а сложная система - это источник куда более ужасных ошибок, чем ошибки возникшие в результате рефакторинга.
Парное программирование (pair programming). Периодический просмотр чужого кода положительно влияет на его качество. Этот принцип лежит в основе парного программирования. Заключается оно в том, что два программиста одновременно работают за одним компьютером. Как ни странно, затраты на разработку не увеличиваются в два раза, а остаются приблизительно на том же уровне. С другой стороны при парном программировании повышается качество кода, осуществляется неявная и явная передача знаний, а также проиходит постоянное общение между разработчиками.
Совместное владение кодом (collective code ownership). Чаще всего при разработке програмных продуктов за определенную часть кода отвечает один человек. Отпуск, увольнение или же болезнь (прости, Господи) одного из программистов может сильно затормозить разработку продукта. Именно поэтому в XP за один кусок кода отвечает не менее двух человек и любой программист может внести изменения в любую часть програмного кода.
Продолжающаяся интеграция (continuous integration). Команды XP-программистов создают новые билды продукта несколько раз в день. Это позволяет всем программистам быть в курсе происходящего и предотвратить проблемы интеграции с другими продуктами и частями кода.
Комментарий: В наше время эта практика у молодых специалистов вызывает улыбку или даже непонимание, ведь есть svn, perforce, cvs и еще много чего. Это раньше двое дядек садилось возле главного компьютера и вручную мержились с основной веткой проекта.
Тем не менее эта практика актуальна до сих пор. Совместное владение кодом никто не отменял: не хочешь тратить время на огромный и сложный merge - потратить время на несколько маленьких мержиков:).
40-часовая неделя (forty hour week). Ради дела люди спопобны на многое, но экстремальное программирование категорически против самопожертвования разработчиков. Человек должен отдыхать, именно тогда он достигнет максимальной производительности в рабочее время.
