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

Методология разработки програмного обеспечения eXtreme Programming (изобретатель - Kent Beck) получает все большее признание благодаря максимальному упрощению процессов проектирования и непосредственной разработки програмных продуктов в среде с быстро изменяющимися требованиями.

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

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

Быстрый выпуск версий (small releases). Как бы красиво не был описан продукт, все прелести его использования можно понять только работая с ним. Методика быстрого выпуска версий позволяет понять, чего же хочет заказчик, обеспечивая ранний выпуск рабочих версий продукта.

Комментарий: Как показывает практика, первую раннюю версию можно сделать за 2-8 недель, не зависимо от ожидаемой сложности продукта. Желательно, чтобы первую версию продукта (хотя бы первые несколько итераций) делало 2 человека за одним компьютером. В этом случае очень быстро вырисовывается дизайн системы. Далее можно привлекать еще людей, перераспределив пары.

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

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

Простота реализации (simple design). XP предлагает делать код программы простым. Зачем усложнять себе жизнь, если простую программу легче понимать и поддерживать и она менее подвержена ошибкам.

Опережающее тестирование (test-driven development). Экстремальное программирование рекомендует проверять существующий код как можно чаще. Именно поэтому и практикуется данная методика. Тесты пишутся еще до того, как будет написан кусок кода. Это позволяет лучше понимать поставленные задачи и предоставляет возможность проверить код сразу, как только он будет написан.

Комментарий: У такого подхода есть масса плюсов.

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

Во-вторых, исключается нежелание тестировать некоторые "очевидные" ветки выполнения программы, хотя бы потому, что кода еще нет:). Ну и потом, при парном программировании тесты дейтвительно будут лаконичными и качественными.

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

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

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

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

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

Продолжающаяся интеграция (continuous integration). Команды XP-программистов создают новые билды продукта несколько раз в день. Это позволяет всем программистам быть в курсе происходящего и предотвратить проблемы интеграции с другими продуктами и частями кода.

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

Тем не менее эта практика актуальна до сих пор. Совместное владение кодом никто не отменял: не хочешь тратить время на огромный и сложный merge - потратить время на несколько маленьких мержиков:).

40-часовая неделя (forty hour week). Ради дела люди спопобны на многое, но экстремальное программирование категорически против самопожертвования разработчиков. Человек должен отдыхать, именно тогда он достигнет максимальной производительности в рабочее время.

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

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

Размещено на 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. Особенности технологии создания простейших приложений. Работа с компонентами среды разработки приложений. Ввод, редактирование, выбор и вывод информации. Аспекты использования структуры ветвления.

Экстремальное программирование или XP, eXtreme Programming — гибкая методология разработки программного обеспечения. Как и у других agile методологий, у нее есть особенные инструменты, процессы и роли. Хотя автор XP не придумал ничего нового, а взял лучшие практики гибкой разработки и усилил до максимума. Поэтому программирование и зовется экстремальным.

Автор методики — американский разработчик Кент Бек. В конце 90-х годов он руководил проектом Chrysler Comprehensive Compensation System и там впервые применил практики экстремального программирования. Свой опыт и созданную концепцию он описал в книге Extreme Programming Explained, опубликованной в 1999 году. За ней были выпущены другие книги, в которых подробно описывались практики XP. К становлению методологии причастны также Уорд Каннингем, Мартин Фаулер и другие.

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

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

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

1. Вся команда

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

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

Планирование в XP проводят в два этапа — планирование релиза и планирование итераций.

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

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

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

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

3. Частые релизы версий

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

4. Пользовательские тесты

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

5. Коллективное владение кодом

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

6. Непрерывная интеграция кода

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

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

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

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

Метафора системы — это ее сравнение с чем-то знакомым, чтобы сформировать у команды общее видение. Обычно метафору системы продумывает тот, кто разрабатывает архитектуру и представляет систему целиком.

9. Устойчивый темп

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

10. Разработка, основанная на тестировании

Одна из самых трудных практик методологии. В XP тесты пишутся самими программистами, причем ДО написания кода, который нужно протестировать. При таком подходе каждый кусок функционала будет покрыт тестами на 100%. Когда пара программистов заливают код в репозиторий, сразу запускаются модульные тесты. И ВСЕ они должны сработать. Тогда разработчики будут уверены, что движутся в правильном направлении.

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

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

12. Простой дизайн

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

13. Рефакторинг

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

Преимущества и недостатки XP

Методология XP вызывает много споров и критики со стороны тех, кто так и не смог ее внедрить в своей команде.

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

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

Несмотря на все плюсы, XP не всегда работает и имеет ряд слабых мест. Итак, экстремальное программирование — недостатки:

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

Принципы XP

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

1. Простота

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

2. Коммуникация

В XP коммуникация между разработчиками ведется не посредством документации, а вживую. Команда активно общается между собой и с заказчиком.

3. Обратная связь

Обратная связь в XP реализуется сразу в трех направлениях:

1. фидбек от системы при постоянном тестировании модулей
2. фидбек от заказчика, т.к. он входит в команду и участвует в написании приемочных тестов
3. фидбек от команды во время планирования касательно времени на разработку.

4. Смелость

Некоторые методики экстремального программирования настолько непривычны, что требует смелости и постоянного контроля над собой.

5. Уважение

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

Алгоритм внедрения методологии XP и процесс работы

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

Чтобы внедрить XP в существующий проект, нужно постепенно осваивать его методики в области:

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

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

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

Проектирование.

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

Планирование.

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

Менеджмент.

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

Разработка.

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

В проекте, который работает по методологии XP процесс построен таким образом:

Кто использует XP

По данным исследования Versionone за 2016 год всего 1% agile компаний используют экстремальное программирование в чистом виде. Еще 10% работают по гибридной методологии scrum и XP.

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

Не так просто найти информацию о командах, которые применяют XP, но есть и те, кто афиширует, что именно эта методология — причина их успеха. Пример экстремального программирования — компания Pivotal Software, Inc.

Pivotal Software, Inc.

Американская софтверная компания, которая разрабатывает ПО для бизнес-анализа на основе big data и оказывает консультационные услуги. Продуктами Pivotal пользуются корпорации Ford, Mercedes, BMW, GAP, Humana, крупные банки, государственные учреждения, страховые компании и т.д.

Pivotal — адвокат agile методологий, как единственно возможных в современной разработке. Из всех вариантов гибких методологий компания выбрала XP как win-win подход для заказчиков и команд программистов. Каждый рабочий день начинается с собрания на ходу, и заканчивается ровно в 18:00 — никаких переработок. Pivotal использует игру в планирование, парное программирование, постоянное тестирование, непрерывную интеграцию и другие практики XP. Для многих практик у них есть собственное ПО.

Экстремальное программирование,
Экстремальное программирование: планирование,
Экстремальное программирование: разработка через тестирование / Кент Бек

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

Рефакторинг: улучшение существующего кода / Мартин Фаулер

Экстремальное программирование: постановка процесса. С первых шагов и до победного конца / Кен Ауэр, Рой Миллер

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

Приложения для внедрения XP в команде

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

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

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

Jira

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

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

Вердикт

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

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

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

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

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

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

Права и роли

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

Заказчик

Человек или группа людей, заинтерисованных в создании конкретного программного продукта. Он имеет следуещие права и обязанности:

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

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

Разработчик

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

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

Роли внутри роли

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

Сторона заказчика

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

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

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

Сторона разработчика

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

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

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

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

Внешние роли

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

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

Соглашение о кодировании

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

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

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

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

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

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

CRC Сессия

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

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

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

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

Заказчик

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

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

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

Выбирайте самое простое решение

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

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

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

Функциональные тесты

Приемочные тесты (ранее их также называли Функциональные) пишутся на основе User Story . Они рассматривают систему как черный ящик. Заказчик ответственен за проверку корректности функциональных тестов. Эти тесты используются для проверки работоспособности системы перед выпуском ее в производство. Функциональные тесты автоматизируются так, чтобы имелась возможность их часто запускать. Результат сообщается команде и команда отвечает за планирование исправлений функциональных тестов.

Частая интеграция

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

Каждая пара разработчиков должна отдавать свой код как только для этого появляется разумная возможность. Это может быть когда все UnitTest-ы проходят на 100%. Отдавая изменения несколько раз в день, Вы сводите проблемы интеграции практически к нулю. Интеграция - это деятельность вида "заплати сейчас или заплати больше позднее". Поэтому интегрируя изменения ежедневно маленькими порциями вы не окажетесь перед необходимостью тратить неделю чтобы связать систему в одно целое непосредственно перед сдачей проекта. Всегда работайте над последней версией системы.

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

Планирование Итерации

Iteration Planning Meeting созывается перед началом каждой итерации для планирования задач которые будут сделаны в этой итерации. Для итерации выбираются User Stories, которые выбрал заказчик в плане релиза начиная с самых важных для заказчика и самых плохих (сопряженных с риском) для разработчиков. Также в итерацию включаются неработающие Функциональные тесты.

User Stories и невыполненные Функциональные тесты разбиваются на задачи. Задачи записываются на карточках. Эти карточки и есть детальный план на итерацию. Каждая задача должна быть продолжительностью от 1 до 3 идеальных дней.

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

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

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

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

Итерации

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

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

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

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

Меняйтесь задачами

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

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

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

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

Такая практика также стимулирует появление новых идей и улучшение кода.

Оставляйте оптимизацию на потом

Никогда не оптимизируйте ничего до окончания кодирования. Никогда не пытайтесь угадать где будут узкие места по производительности. Измеряйте!

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

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

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

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

Безжалостно Рефакторить!

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

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

План Релиза

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

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

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

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

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

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

Частые Релизы

Разработчики должны выпускать версии системы пользователям (или бета-тестерам) как можно чаще.

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

Пробное решение

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

Сделайте программу которая воспроизводит исследуемую проблему и игнорирует все остальное. Большинство пробных решений не предназначены для последующего использования так что ожидайте что они будут выброшены. Цель их создания - уменьшить риск принятия неправильного технического решения или более точная оценка времени на реализацию User Story.

Собрание стоя

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

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

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

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

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

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

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

Unit Test-ы

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

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

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

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

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

User Story

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

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

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

User Stories используются в XP вместо традиционных требований. Главное отличие User Story от требований (requirements) - уровень детализации. User Story содержит минимум информации, необходимой для обоснованной оценки того, сколько времени надо на ее реализацию.

Типичная User Story занимает 1-3 недели идеального времени. История требующая менее 1 недели слишком детализирована. История требующая более 3 недель может быть разбита на части - отдельные истории.

Скорость проекта

Скорость Проекта (или просто скорость) это мера того, как быстро выполняется работа в вашем проекте.

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

Во время планирования релиза скорость проекта используется для оценки того сколько User Stories может быть сделано.

Во время планирования итерации, скорость проекта в предыдущей итерации используется для определения того сколько User Stories надо планировать в текущую итерацию.

Этот простой механизм позволяет разработчикам восстановиться после трудной итерации. Если у вас после восстановления остается свободное время - идете к заказчику и просите еще User Story. В результате скорость опять возрастет.

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

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

Когда обнаружена ошибка

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

Невыполнившийся функциональный тест требует создания Unit Test . Это помогает сфокусировать усилия по отладке и четко показывает когда ошибка исправлена.

Вам это не понадобится

Воздержитесь от заполнения системы вещами, которые понадобятся вам в будущем. Только 10% от ожидаемого действительно понадобится вам в первоначальном виде, то есть 90% вашего времени будет потрачено впустую.

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

Экстремальное программирование (англ. Extreme Programming, XP) - одна из гибких методологий разработки программного обеспечения. Авторы методологии - Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.Название методологии исходит из идеи применить полезные традиционные методы и практики разработки программного обеспечения, подняв их на новый «экстремальный» уровень. Так, например, практика выполнения ревизии кода, заключающая в проверке одним программистом кода,
написанного другим программистом, в «экстремальном» варианте представляет собой «парное программирование», когда один программист занимается кодированием, а его напарник в это же время непрерывно просматривает только что написанный кoд.
Двенадцать основных приёмов экстремального программирования (по первому изданию книги 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)
  • Метафора системы (System metaphor)
  • Коллективное владение кодом (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), и приблизительный план работы по выпуску следующих одной или нескольких небольших версий продукта.

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