Lecture03 (1133560), страница 4
Текст из файла (страница 4)
При этом предпочтениеотдается более элегантным и гибким решениям, по сравнению с просто дающими нужныйрезультат. Неудачно переработанные компоненты должны выявляться при выполнениитестов и откатываться к последнему целостному состоянию (вместе с зависимыми от нихкомпонентами).Программирование парами (pair programming)Кодирование выполняется двумя программистами на одном компьютере. Объединение впары произвольно и меняется от задачи к задаче. Тот, в чьих руках клавиатура, пытаетсянаилучшим способом решить текущую задачу.
Второй программист анализирует работупервого и дает советы, обдумывает последствия тех или иных решений, новые тесты, менеепрямые, но более гибкие решения.• Коллективное владение кодом (collective ownership)В любой момент любой член команды может изменить любую часть кода.
Никто не долженвыделять свою собственную область ответственности, вся команда в целом отвечает за веськод.• Постоянная интеграция (continuous integration)Система собирается и проходит интеграционное тестирование как можно чаще, понесколько раз в день, каждый раз, когда пара программистов оканчивает реализациюочередной функции.• 40-часовая рабочая неделяСверхурочная работа рассматривается как признак больших проблем в проекте. Недопускается сверхурочная работа 2 недели подряд — это истощает программистов и делаетих работу значительно менее продуктивной.• Включение заказчика в команду (on-site customer)В составе команды разработчиков постоянно находится представитель заказчика, которыйдоступен в течение всего рабочего дня и способен отвечать на все вопросы о системе.
Егообязанностью являются достаточно оперативные ответы на вопросы любого типа,касающиеся функций системы, ее интерфейса, требуемой производительности, правильнойработы системы в сложных ситуациях, необходимости поддерживать связь с другимиприложениями и пр.• Использование кода как средства коммуникацииКод рассматривается как важнейшее средство общения внутри команды. Ясность кода —один из основных приоритетов. Следование стандартам кодирования, обеспечивающимтакую ясность, обязательно.
Такие стандарты, помимо ясности кода, должны обеспечиватьминимальность выражений (запрет на дублирование кода и информации) и должны бытьприняты всеми членами команды.• Открытое рабочее пространство (open workspace)Команда размещается в одном, достаточно просторном помещении, для упрощениякоммуникации и возможности проведения коллективных обсуждений при планировании ипринятии важных технических решений.• Изменение правил по необходимости (just rules)Каждый член команды должен принять перечисленные правила, но при возникновениинеобходимости команда может поменять их, если все ее члены пришли к согласию поповоду этого изменения.Как видно из применяемых техник, XP рассчитано на использование в рамках небольшихкоманд (не более 10 программистов), что подчеркивается и авторами этой методики. Большийразмер команды разрушает необходимую для успеха простоту коммуникации и делаетневозможным применение многих перечисленных приемов.Достоинствами XP, если его удается применить, является большая гибкость, возможностьбыстро и аккуратно вносить изменения в ПО в ответ на изменения требований и отдельныепожелания заказчиков, высокое качество получающегося в результате кода и отсутствиенеобходимости убеждать заказчиков в том, что результат соответствует их ожиданиям.Недостатками этого подхода являются невыполнимость в таком стиле достаточно больших исложных проектов, невозможность планировать сроки и трудоемкость проекта на достаточнодолгую перспективу и четко предсказать результаты длительного проекта в терминахсоотношения качества результата и затрат времени и ресурсов.
Также можно отметитьнеприспособленность XP для тех случаев, в которых возможные решения не находятся сразу наоснове ранее полученного опыта, а требуют проведения предварительных исследованийXP как совокупность описанных техник впервые было использовано в ходе работы напроектом C3 (Chrysler Comprehensive Compensation System, разработка системы учета выплатработникам компании Daimler Chrysler). Из 20-ти участников этого проекта 5 (в том числеупомянутые выше 3 основных автора XP) опубликовали еще во время самого проекта и вдальнейшем 3 книги и огромное количество статей, посвященных XP.
Этот проект неоднократноупоминается в различных источниках как пример использования этой методики [6,7,8].Приведенные ниже данные собраны на основе упомянутых статей [9], за вычетом неподтверждающихся сведений, и иллюстрируют проблемы некоторых техник XP при ихприменении в достаточно сложных проектах.Проект стартовал в январе 1995 года. С марта 1996 года, после включения в него Кента Бека,он проходил с использованием XP. К этому времени он уже вышел за рамки бюджета и плановпоэтапной реализации функций.
Команда разработчиков была сокращена, и в течение примернополугода после этого проект развивался довольно успешно. В августе 1998 года появилсяпрототип, который мог обслуживать около 10000 служащих. Первоначально предполагалось, чтопроект завершится в середине 1999 года и результирующее ПО будет использоваться дляуправления выплатами 87000 служащим компании. Он был остановлен в феврале 2000 года после4-х лет работы по XP в связи с полным несоблюдением временных рамок и бюджета. СозданноеПО ни разу не использовалось для работы с данными о более чем 10000 служащих, хотя былопоказано, что оно справится с данными 30000 работников компании. Человек, игравший рольвключенного в команду заказчика в проекте, уволился через несколько месяцев такой работы, невыдержав нагрузки, и так и не получил адекватной замены до конца проекта.Литература к Лекции 3[1] У. Ройс.
Управление проектами по созданию программного обеспечения. М.: Лори, 2002.[2] А. Якобсон, Г. Буч, Дж. Рамбо. Унифицированный процесс разработки программногообеспечения. СПб.: Питер, 2002.[3] Kroll, The Spirit of the RUP. www-106.ibm.com/developerworks/rational/library/content/RationalEdge/dec01/ TheSpiritoftheRUPDec01.pdf[4] К.
Бек. Экстремальное программирование. СПб.: Питер, 2002.[5] http://www.agilemanifesto.org/[6] K. Beck, et. al. Chrysler goes to “Extremes”. Distributed Computing, 10/1998.[7] A. Cockburn. Selecting a Project’s Methodology. IEEE Software, 04/2000.[8] L. Williams, R. R. Kessler, W. Cunningham, R. Jeffries. Strengthening the Case for PairProgramming. IEEE Software 4/2000.[9] G. Keefer.
Extreme Programming Considered Harmful for Reliable Software Development.AVOCA Technical Report, 2002.Доступен как http://www.avoca-vsm.com/Dateien-Download/ExtremeProgramming.pdf..
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
