Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Содержание

• Введение
• 1. Что такое ХР?
• 3.1 Основные приёмы XP
• 4. Достоинства и недостатки
• 5. История использования
• Заключение

Введение

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

ХР часто представляется как набор методик, однако сама по себе ХР не является финишной линией. Не надо все лучше и лучше практиковать и развивать ХР для того, чтобы в конце этого процесса получить долгожданную золотую звезду. Напротив, ХР - это линия старта. ХР ставит вопрос: "Насколько минимальными могут быть наши усилия для того, чтобы мы могли продолжать производить качественное программное обеспечение?"

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

1. Что такое ХР?

Экстрема м льное программи м рование (англ. Extreme Programming , XP ) - одна из гибких методологий разработки программного обеспечения. Авторы методологии - Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

ХР - это упрощенный, эффективный, гибкий, предсказуемый, научно обоснованный и весьма приятный способ разработки программного обеспечения, предусматривающий низкий уровень риска. От других методик ХР отличается по следующим признакам:

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

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

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

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

ХР основана на оральном обмене информацией, тестах и исходном коде. Три этих инструмента используются для обмена сведениями о структуре системы и ее поведении.

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

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

ХР основывается на методиках, которые удовлетворяют как краткосрочным инстинктам отдельных программистов, так и долгосрочным интересам всего проекта в целом.

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

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

2. С чего начинается экстремальное программирование

С чего начинается экстремальное программирование? С понимания того, что типичное положение отечественного разработчика программного обеспечения обязывает максимально снижать стоимость разработки. А для этого необходимо интенсивно сотрудничать с заказчиком, понимать его интересы и, в конце концов, сделать именно то, чего он хочет: не больше и не меньше.

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

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

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

Что бы мы ни делали - вдевали нитку в иголку или собирались на вечеринку - мы всегда стремимся достичь какой-то цели. Если мы замечаем, что отклоняемся от нее, то корректируем свои действия соответствующим образом. А теперь представьте себе, насколько тяжелей попасть ниткой в иголку с закрытыми глазами или красиво одеться без зеркала! А ведь при разработке программ часто так и происходит: мы делаем нечто, результат чего нам не виден. Поэтому в экстремальном программировании принято за правило видеть результат своих действий настолько быстро, насколько это возможно. Или, говоря техническим языком, обеспечить максимально быструю обратную связь.

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

3. Техники XP

Экстремальное программирование (Extreme Programming, XP) возникло как эволюционный метод разработки ПО "снизу вверх". Этот подход является примером так называемого метода "живой" разработки (Agile Development Method). В группу "живых" методов входят, помимо экстремального программирования, методы SCRUM, DSDM (Dynamic Systems Development Method, метод разработки динамичных систем), Feature-Driven Development (разработка, управляемая функциями системы) и др.

Основные принципы "живой" разработки ПО зафиксированы в манифесте "живой" разработки, появившемся в 2000 году.

· Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты.

· Работающая программа более важна, чем исчерпывающая документация.

· Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта.

· Отработка изменений более важна, чем следование планам.

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

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

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

По утверждению авторов XP, эта методика представляет собой не столько следование каким-то общим схемам действий, сколько применение комбинации следующих техник. При этом каждая техника важна, и без ее использования разработка считается идущей не по XP, согласно утверждению Кента Бека (Kent Beck), одного из авторов этого подхода наряду с Уордом Каннингемом (Ward Cunningham) и Роном Джефрисом (Ron Jeffries).

· Живое планирование (planning game )

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

Рис .1 Схема потока работ в XP

· Частая смена в ерсий (small releases )

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

· Метафора (metaphor ) системы

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

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

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

· Простые проектные решения (simple design )

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

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

· Разработка на основе тестирования (test - driven development )

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

В XP особое внимание уделяется двум разновидностям тестирования:

ь тестирование модулей (unit testing);

ь приемочное тестирование (acceptance testing).

экстремальное программирование программное обеспечение

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

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

Для XP более приоритетным является подход называемый TDD (Test Driven Development), сначала пишется тест, который не проходит, затем пишется код, чтобы тест прошел, а уже после делается рефакторинг кода.

· Постоянная переработка (refactoring )

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

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

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

· Программирование парами (pair programming )

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

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

· Коллективное владение кодом (collective ownership )

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

Давая каждому программисту право изменять код, мы получаем риск появления ошибок, вносимых программистами, которые считают что знают что делают, но не рассматривают некоторые зависимости. Хорошо определённые UNIT-тесты решают эту проблему: если нерассмотренные зависимости порождают ошибки, то следующий запуск UNIT-тестов будет неудачным.

· Постоянная интеграция (continuous integration )

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

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

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

· 40-часовая рабочая неделя

Сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд - это истощает программистов и делает их работу значительно менее продуктивной.

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

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

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

· Включение заказчика в команду (on - site customer )

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

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

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

· Использование кода как средства коммуникации

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

· Открытое рабочее пространство (open workspace )

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

· Изменение правил по необходимости (just rules )

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

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

3.1 Основные приёмы XP

Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained ) могут быть объединены в четыре группы:

· Короткий цикл обратной связи (Fine scale feedback)

o Разработка через тестирование (Test driven development)

o Игра в планирование (Planning game)

o Заказчик всегда рядом (Whole team, Onsite customer)

o Парное программирование (Pair programming)

· Непрерывный, а не пакетный процесс

o Непрерывная интеграция (Continuous Integration)

o Рефакторинг (Design Improvement, Refactor)

o Частые небольшие релизы (Small Releases)

· Понимание, разделяемое всеми

o Простота (Simple design)

o Метафора системы (System metaphor)

o Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)

o Стандарт кодирования (Coding standard or Coding conventions)

· Социальная защищенность программиста (Programmer welfare):

o 40-часовая рабочая неделя (Sustainable pace, Forty hour week)

Игра в планирование

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

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

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

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

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

4. Достоинства и недостатки

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

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

5. История использования

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 работников компании. Человек, игравший роль включенного в команду заказчика в проекте, уволился через несколько месяцев такой работы, не выдержав нагрузки, и так и не получил адекватной замены до конца проекта.

Заключение

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

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

Размещено на Allbest.ru

Подобные документы

Анализ этапов и особенностей разработки оптимальной и функциональной ARIS-модели - программного продукта компании IDS Scheer для моделирования бизнес-процессов компании. Изучение основных концепций, методологий и подходов экстремального программирования.

контрольная работа , добавлен 04.06.2011


Основные этапы разработки программного обеспечения (пакета программ), анализ требований к системе. Метод пошаговой детализации. Языки программирования низкого уровня и высокого уровня (императивные, объектно-ориентированные, функциональные, логические).

презентация , добавлен 13.10.2013


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

учебное пособие , добавлен 26.10.2013


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

презентация , добавлен 30.04.2014


Машинные коды и ассемблер. Первые языки программирования высокого уровня. Язык программирования FORTRAN. Достоинства и недостатки ALGOL. Научные и бухгалтерские программы. Основные принципы, которые соблюдались при создании языка программирования Basic.

курсовая работа , добавлен 21.06.2014


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

курсовая работа , добавлен 14.12.2012


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

презентация , добавлен 14.08.2013


Международный стандарт на язык программирования Паскаль. Приемы объектно-ориентированного программирования в Турбо Паскале. Символы языка, его алфавит. Этапы разработки программы. Понятие алгоритмов и алгоритмизации. Структура программ на Паскале.

курсовая работа , добавлен 28.02.2010


Современные инструменты разработки программного обеспечения для СУТП. Универсальные языки программирования и сравнение их со SCADA-системами. Разработка программного обеспечения с использованием многоканальных измерительных преобразователей Ш9327.

дипломная работа , добавлен 13.07.2011


Основные приемы работы в среде программирования Delphi. Особенности технологии создания простейших приложений. Работа с компонентами среды разработки приложений. Ввод, редактирование, выбор и вывод информации. Аспекты использования структуры ветвления.

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

Вначале была модель «водопада» (рис.1а): мы просим пользователей однозначно сформулировать свои требования; мы разрабатываем проект системы, которая сделает все, что хотят пользователи; мы пишем код; мы тестируем программу, дабы убедиться, что она действительно делает то, что требуется. Все получается замечательно.

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

Итак, длинный цикл разработки плох, поскольку не способен приспосабливаться к изменениям. Тогда, возможно, надо сократить цикл, и все проблемы будут решены? На рис. 1b дана иллюстрация перерождения модели «водопада» в итеративную модель.

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

Академическое сообщество разработчиков ПО взялось разрешить проблему высокой стоимости изменений и создало новые технологии - реляционные базы данных, модульное программирование, сокрытие информации. Но что если все эти труды уже исчерпали свой потенциал? И нам удастся найти новый способ снизить расходы на внесение изменений, не разрезая «водопад» на части, а просто смешав все его компоненты? То, что получилось в результате, показано на рисунке 1с. Мы назвали это «экстремальным программированием» (Extreme Programming, XP).

Анатомия XP

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» . Этот принцип предложен также Ричардом Койне, который связывал метафору и разработку программного обеспечения с точки зрения постмодернистской философии .

Наконец, то значительное внимание, которое ХР уделяет организации офисного пространства, проистекает из работ Джима Коплиена , Тома ДеМарко и Тима Листера , отмечавших влияние окружающих условий на работу программистов.

Примеры выполнения проектов с использованием XP

Компания Acxiom: на пути к достижению общей цели

Джи Ханнула

Команда: менеджеры, бизнес-аналитики, разработчики, тестировщики, технические писатели

Приложение: база данных управления кампанией

Срок реализации: 3 года

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

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

Много сил пришлось потратить на тестирование модулей, поскольку Forte не предлагает встроенных базовых средств для тестирования. Нам пришлось создать свои и с их помощью успешно провести тестирование. Недавно мы перешли на язык программирования Java и теперь как средство тестирования используем JUnit.

Когда мы только начинали работать по принципам ХР, среди нас нашлись программисты, не пожелавшие использовать его методы. Они считали, что эти методы не соответствуют выработанному ими стилю программирования и помешают им работать продуктивно. В результате больше всего проблем возникало с компонентами системы, написанными этими людьми. Эти разработчики игнорировали работу в паре, и по своим умениям стали уступать другим членам команды, которые воспользовались представленным им шансом поучиться друг у друга. Два опытных программиста, которые работают в тесной взаимосвязи друг с другом и остальной частью команды, всегда будут превосходить по мастерству «индивидуала», будь он даже семи пядей во лбу.

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

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

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

DaimlerChrysler: лучшая в мире команда

Чет Хендриксен

Команда: 15 человек, из них 10 программистов

Приложение: полномасштабная автоматизация расчета платежных ведомостей

Срок реализации: 4 года

Работа над проектом С3 была начата в январе 1995 года. Корпорация Chrysler заключила контракт с партнерской компанией, в соответствии с которым за реализацию проекта бралась объединенная команда разработчиков из обеих организаций. Наши партнеры придерживались методологии разработки, ориентированной на использование графического интерфейса и игнорировавшей автоматизацию тестирования. В результате мы получили систему, которая изобиловала невыразительной графикой и для большинства служащих вычисляла зарплату неправильно. Для создания месячной платежной ведомости такой системе понадобилось бы около 100 дней. Мы поняли, что написанная нами программа никогда не будет реально использоваться.

Мы обратились к Кенту Беку с просьбой помочь отрегулировать производительность системы. Он обнаружил у нас те же явления, с которыми сам постоянно сталкивается, берясь за задачу настройки производительности: плохо продуманный код, тесты, которые нельзя запустить повторно, руководство, потерявшее уверенность в своем проекте. Кент Бек порекомендовал выбросить весь написанный код и начать полномасштабный ХР-проект.

Прежний контракт был разорван, и Chrysler почти наполовину обновила свою команду разработчиков. Начиная с этого момента мы действовали по правилам ХР. Были распределены обязанности, спланированы итерации, установлены правила тестирования, опробовано и принято в качестве стандарта программирование в паре. К концу 33-й недели мы получили систему, в которой уже можно было начинать отлаживать производительность и проводить параллельное тестирование. Мы могли приступить к настройке производительности, поскольку система была хорошо продумана и подкреплена полным набором модульных тестов. Мы были готовы к параллельному тестированию, поскольку серия функциональных тестов наглядно продемонстрировала заказчику наличие в системе требуемых возможностей.

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

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

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

Ford Motor: уникальное сочетание оперативности и качества

Дон Уэлс

Команда: 17 человек, из них 12 программистов

Приложение: система анализа затрат

Срок реализации: 6 лет

Отдел финансовых систем компании Ford Motor разрабатывает аналитическую систему Vehicle Costing and Profit System (VCAPS), которая создает отчеты по доходам от производства, расходам, чистому доходу и прибыли. Входными данными для системы являются инженерные спецификации продукции, фиксированные затраты и расходы и переменные затраты, например, рабочие часы. VCAPS аккумулирует все эти данные и подготавливает подробные отчеты с анализом затрат, которые обеспечивают эффективное прогнозирование и принятие корпоративных решений. Работа над проектом VCAPS была начата в 1993 году. При разработке использовались VisualWorks и GemStone Smalltalk. В данный момент поддержкой системы VCAPS занимается небольшая группа специалистов, и в скором времени она будет заменена более современным приложением.

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

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

Работа по методам ХР началась с этапа планирования. И это оказалось ошибкой. Заказчики и руководство не привыкли совместно улаживать график работ. То, что получилось в результате, страдало недостатком правдоподобия и практической применимости. Пришлось перейти на планы MS Project, которые можно было менять, не устраивая общих собраний, и с помощью которых мы получили планы в привычном для руководства виде.

Дальше мы сделали несколько модульных тестов и уже через год 40% системы было протестировано, а руководство отметило сокращение числа сообщений об ошибках на 40%. После этого на ХР обратили пристальное внимание.

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

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

Tariff System: тесты, которые можно читать

Роб Ми

Команда: три разработчика

Приложение: система вычисления тарифов на перевозки

Срок реализации: 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.

Экстремальное программирование - или, сокращенно, XP (eXtreme Programming) - является ответом сообщества программистов на наступление формальных подходов к созданию программных продуктов и призвано вернуть в среду разработчиков дух творчества.

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

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

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

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

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

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

Экстремальный цикл

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

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

Как следствие постоянно изменяющихся требований следует другой принцип - позднее принятие решений.

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

Ускоренная и совместная разработка приложений

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

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

На практике подобный подход к разработке приложений сопряжен с проблемами, перечисленными ниже:

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

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

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

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

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

Способы обработки исключительных ситуаций оказываются различными для разных модулей.

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

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

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

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

Принципы XP и используемые методы ускорения разработки

Отцом-идеологом экстремального программирования считают Кента Бека (Kent Beck). XP является достаточно молодой методологией, оценки которой весьма противоречивы - от восторженных до резко негативных. Основными принципами являются:

Простота решений (simplicity).

Интенсивная разработка малыми группами (не больше 10 человек), активное общение в группе и между группами (communication).

Обратная связь с клиентом (feedback), который фактически вовлечен в процесс разработки.

Достаточная степень смелости (courage) и желание идти на риск.

Первый фактор ускорения разработки - итеративность: разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. XP - это итеративный процесс разработки, который сам по себе не является революционным. Итерации как таковые предлагается делать короткими, рекомендуемая длительность - 2-3 недели и не более 1 месяца. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории (user story). Пользовательские истории в данном случае являются начальной информацией, на основании которой создается модуль. Пользовательские истории отличаются от прецедентов (use case): пользовательская история коротка - 1-2 абзаца, тогда как прецеденты обычно пишут достаточно подробными, с основным и альтернативными потоками - таким образом, получается примерно страница плюс схема (наиболее распространенная формализация в настоящее время предложена в UML); истории пользователей пишутся самими пользователями (которые в XP являются частью команды) в отличие от прецедентов, которые обычно пишет системный аналитик. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать посредством активного включения в процесс разработки заказчика как полноправного члена команды и за счет наличия постоянного контакта с заказчиком (активное общение и непрерывная поддержка обратной связи). В данном случае extreme - это степень привлечения заказчика к программистской кухне, что обусловлено стремлением сжать сроки разработки за счет коммуникации и обратной связи.

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

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

Практики

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

Планирование процесса (planning game). Вся команда собирается вместе, принимается коллективное решение о том, какие свойства системы будут реализованы в ближайшей итерации. Набор свойств определяется пользовательскими историями. XP-трудоемкость каждого свойства определяется самими программистами.

Тесное взаимодействие с заказчиком (feed-back, on-site customer). Заказчик должен быть членом XP-команды (on-site customer). Он пишет пользовательские истории, выбирает истории, которые будут реализованы в конкретной итерации, и отвечает на вопросы, касающиеся бизнеса. Заказчик должен быть экспертом в автоматизируемой предметной области. Необходимо постоянное наличие обратной связи с заказчиком (feed-back).

Метафора системы (system metaphor). Хорошая метафора системы означает простоту именования классов и переменных. В реальной жизни поиск метафоры - крайне сложное занятие; найти хорошую метафору непросто. В любом случае команда должна иметь единые правила именования.

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

Стандарты кодирования (coding conventions). Стандарты кодирования нужны для обеспечения других практик: коллективного владения кодом, парного программирования и рефакторинга. Без единого стандарта выполнять эти практики как минимум сложнее, а в реальности вообще невозможно: группа будет работать в режиме постоянной нехватки времени. Детальные стандарты не требуются, необходимо стандартизировать только важные вещи. Определение наиболее важных объектов стандартизации в XP субъективно.

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

Парное программирование (pair programming) - одна из самых известных XP-практик. Все программисты должны работать в парах: один пишет код, другой смотрит. Таким образом, необходимо размещать группу программистов в одном месте, что легче всего сделать на территории заказчика (все необходимые члены команды географически находятся в одном месте); XP наиболее успешно работает в нераспределенных коллективах программистов и пользователей.

40-часовая рабочая неделя. Программист не должен работать более 8 часов в день. Необходимость сверхурочной работы (overtime) - это четкий индикатор проблемы на данном конкретном направлении разработки; к тому же заказчик не платит за сверхурочную работу в XP. Поиск причин сверхурочной работы и их скорейшее устранение - одно из основных правил.

Коллективное владение кодом (collective code ownership). Каждый программист в коллективе XP должен иметь доступ к коду любой части системы и вносить изменения в любой код. Обязательное правило: если программист внес изменения и система после этого работает некорректно, то именно этот программист должен исправить ошибки. В противном случае работа системы уподобится тотальному хаосу.

Частая смена версий (small releases). Минимальная итерация - один день, максимальная - месяц; чем чаще осуществляются релизы, тем больше недостатков системы будет выявлено. Первые релизы помогают выявить недостатки на самых ранних стадиях, далее функциональность системы расширяется (на основании тех же пользовательских историй). Поскольку пользователь включается в процесс разработки начиная с первого релиза, то он оценивает систему и выдает пользовательскую историю плюс feedback. На основании этого определяется следующая итерация: каким будет новый релиз. В XP все направлено на обеспечение непрерывной обратной связи с пользователями.

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

Тестирование (testing). В отличие от большинства остальных методологий тестирование в XP - одно из важнейших составляющих. Экстремальный подход заключается в том, что тесты пишутся до написания кода. Каждый модуль обязан иметь unit test - тест данного модуля; таким образом, в XP осуществляется regression testing (возвратное тестирование, «неухудшение качества» при добавлении функциональности). Большинство ошибок исправляются на стадии кодирования. Тесты пишут сами программисты; любой программист имеет право написать тест для любого модуля. Еще один важный принцип: тест определяет код, а не наоборот (такой подход носит название test-driven development), то есть кусок кода кладется в хранилище тогда и только тогда, когда все тесты прошли успешно, в противном случае данное изменение кода отвергается.

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

Существующие риски применения методологии

Следует выделить риски XP, способные завалить проект, если не учитывать и не предотвращать их.

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

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

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

Простая архитектура (simple design). В каждый момент времени разрабатываемая система выполняет все тесты и поддерживает все взаимосвязи, определяемые программистом, не имеет дубликатов кода и содержит минимально возможное количество классов и методов. Это правило кратко можно выразить так: «Каждую мысль формулируй один и только один раз». Данный принцип вступает в противоречие с быстротой написания кода. Без наличия высокой самодисциплины и жестких стандартов кода система немедленно попадает в группу риска.

Частая смена версий (small releases). Систему запускают в эксплуатацию уже через несколько месяцев после начала реализации, не дожидаясь окончательного разрешения всех поставленных проблем. Периодичность выпуска новых версий может варьироваться от ежедневной до ежемесячной. Протестировать за такой срок более-менее сложный компонент невозможно; заказчик фактически выступает в роли бета-тестера. Системы, к которым предъявляется требование непрерывной надежной работы (так называемое требование 24Ѕ7), входят в группу риска.

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

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

Программирование в паре (pair programming). Весь код проекта пишут группы по два человека, использующих одно рабочее место. Человеческий фактор в данном случае играет определяющую роль: пара или работает или нет, третьего не дано.

40-часовая неделя (40-hour weeks). Объем сверхурочных работ не может превышать по длительности одну рабочую неделю. Даже отдельные случаи сверхурочных работ, повторяющиеся слишком часто, служат признаком серьезных проблем, которые требуют безотлагательного решения. Как показывает практика применения экстремального программирования (несмотря на целый ряд положительных примеров, приводимых сторонниками данного метода), сверхурочная работа при таком подходе - это правило, а не исключение, и борьба с проблемами в данном случае - явление постоянное. Усиливается она в период замены текущей сырой версии продукта очередной - менее сырой. Если заказчик не получает постоянных доказательств улучшения системы, значит, у вас возникли серьезные проблемы.

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

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

Тесты (tests). Программисты постоянно пишут тесты для модулей (unit tests). Собранные вместе, эти тесты должны работать корректно. Для этапов итерации заказчики пишут функциональные тесты (functional tests), от которых также требуется правильная работа. Однако на практике это не всегда достижимо. Чтобы принять верное решение, необходимо понять, во что обойдется сдача системы с заранее известным дефектом, и сравнить это с ценой задержки на его устранение. Тесты, написанные самими программистами (особенно в условиях сверхурочных работ), не являются полнофункциональными и уж тем более не учитывают особенностей многопользовательской работы. На более продвинутые тесты у разработчиков обычно не хватает времени. Решается данная проблема путем привлечения на определенный срок контакторов, что связано с большой ролью человеческого фактора: поскольку техническая документация изначально отсутствует, то информация передается посредством общения программистов. Хотя, конечно, можно построить систему разработки таким образом, что от начала до конца всем будут заниматься одни и те же люди. К сказанному необходимо добавить, что тестирование системы вовсе не исчерпывается тестами компонентов (units); не менее важны тесты взаимодействия между ними, это же относится и к тестам надежности работы. И тем не менее метод экстремального программирования не предусматривает создания тестов данного класса. Это объясняется тем, что сами подобные тесты могут представлять достаточно сложный код (особенно это касается тестов - имитаторов реальной работы системы). В данной технологии также никак не учитывается еще один важный класс тестов - тесты поведения системы при росте объемов обрабатываемой информации. При высокой частоте изменения версий выполнить такой тест технологически невозможно, поскольку его проведение требует стабильного и неизменного кода проекта, например в течение недели. В таком случае придется или приостанавливать разработку компонентов, или создавать на время проведения теста параллельную версию проекта, которая будет сохраняться неизменной, тогда как другая при этом будет изменяться. Затем нужно будет выполнить процесс слияния кода. Но в этом случае тест придется создавать заново, так как методы экстремального программирования просто не предусматривают разработку средств, позволяющих прогнозировать поведение системы при тех или иных изменениях. Решать данные проблемы в XP предлагается посредством все того же человеческого фактора и самодисциплины.

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

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

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

И другие.

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

Энциклопедичный YouTube

1 / 5

Экстремальное программирование (XP) - основные приемы

Hexlet Webinar #6: экстремальное программирование

Life Tips. Зачем участвовать в соревнованиях по программированию?

032. Парное программирование - Сергей Бережной

Канал экстремального программирования v. 2.0

Субтитры

Основные приёмы XP

Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained ) могут быть объединены в четыре группы:

• Короткий цикл обратной связи (Fine-scale feedback)
  • Разработка через тестирование (Test-driven development)
  • Игра в планирование (Planning game)
  • Заказчик всегда рядом (Whole team, Onsite customer)
  • Парное программирование (Pair programming)
• Непрерывный, а не пакетный процесс
  • Непрерывная интеграция (Continuous integration)
  • Рефакторинг (Design improvement, Refactoring)
  • Частые небольшие релизы (Small releases)
• Понимание, разделяемое всеми
  • Простота (Simple design)
  • Метафора системы
  • Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
  • Стандарт кодирования (Coding standard or Coding conventions)
• Социальная защищённость программиста (Programmer welfare):
  • 40-часовая рабочая неделя (Sustainable pace, Forty-hour week)

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

XP предполагает написание автоматических тестов (программный код, написанный специально для того, чтобы тестировать логику другого программного кода). Особое внимание уделяется двум разновидностям тестирования:

• юнит-тестирование модулей;

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

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

Для XP более приоритетным является подход, называемый TDD (от англ. test-driven development - разработка через тестирование). В соответствии с этим подходом сначала пишется тест, который изначально не проходит (так как логики, которую он должен проверять, ещё просто не существует), затем реализуется логика, необходимая для того, чтобы тест прошёл. TDD, в некотором смысле, позволяет писать код, более удобный в использовании - потому что при написании теста, когда логики ещё нет, проще всего позаботиться об удобстве будущей системы.

Игра в планирование

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

Заказчик всегда рядом

«Заказчик» в XP - это не тот, кто оплачивает счета, а конечный пользователь программного продукта. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.

Парное программирование

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

Непрерывная интеграция

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

Рефакторинг

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

Частые небольшие релизы

Версии (releases) продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени. При этом каждая версия должна быть достаточно осмысленной с точки зрения полезности для бизнеса.

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

Простота проектирования

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

Метафора системы

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

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

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

Стандарты кодирования

Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому:

• члены команды не тратят время на споры о вещах, которые фактически никак не влияют на скорость работы над проектом;
• обеспечивается эффективное выполнение остальных практик.

Если в команде не используются единые стандарты кодирования, разработчикам становится сложнее выполнять рефакторинг; при смене партнёров в парах возникает больше затруднений; в общем и целом, продвижение проекта затрудняется. В рамках XP необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, - вся команда работает унифицированно, как один человек. Команда должна сформировать набор правил, а затем каждый член команды должен следовать этим правилам в процессе кодирования. Перечень правил не должен быть исчерпывающим или слишком объёмным. Задача состоит в том, чтобы сформулировать общие указания, благодаря которым код станет понятным для каждого из членов команды. Стандарт кодирования поначалу должен быть простым, затем он может постепенно усложняться по мере наработки опыта группой разработчиков. Не нужно тратить слишком много времени на предварительную разработку стандарта.

Коллективное владение

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