| ||||||||||||||||
 | ||||||||||||||||
| ||||||||||||||||
 | ||||||||||||||||
| ||||||||||||||||
|
|
Экстремальное программирование? — В моем представлении, название «экстремальное программирование» было выбрано по аналогии с «экстремальными видами спорта»: воздушным серфингом, парашютированием с небоскребов и тому подобным. Другими словами — опасное, стоящее на грани, искусное. Проблема в том, что я представляю картину, где парень с ноутбуком программирует на Delphi, совершая прыжок в воду с пятидесятиметровой скалы! — И чем это отличается от обычного программирования? (Фрагмент обсуждения экстремального программирования в конференции borland.public.delphi.non-technical) |
История экстремального программирования (ЭП) началась в первой половине 90-х годов. Автор термина Кент Бек (Kent Beck) обдумывал новые подходы к созданию программ. Работая совместно с другим разработчиком над очередным проектом, Кент заметил несколько приемов, благодаря которым удавалось повысить эффективность труда. В марте 1996 года Кент попытался использовать накопленные наблюдения в работе над новым заданием, выполняемым по заказу фирмы «Даймлер-Крайслер». В результате он сформулировал положения, позднее ставшие известными как методика экстремального программирования (Extreme Programming).
Основной вывод, который сделал Кент, заключается в том, что разработку любого программного проекта можно сделать более эффективной, если приложить усилия в четырех основных направлениях: усовершенствовать взаимосвязь разработчиков, упростить проектные решения, усилить обратную связь с заказчиком и проявлять больше активности. Эти четыре направления и стали приоритетными в ЭП.
Возможно, для программистов со стажем «открытия» Кента могут показаться одновременно и очевидными, и надуманными. Поэтому попробуем разобраться, воспользовавшись материалами сайта http://www.extremeprogramming.org/.
Новый подходЭкстремальное программирование строится на том, что создавать простую и понятную программу выгоднее, чем сложную и запутанную. Типичный проект (помните, что речь идет о разработках, выполняемых по заказам западных компаний) предполагает приблизительно в 20 раз большие расходы на труд программистов, чем на аппаратное обеспечение. Что это значит? В проекте стоимостью 2 млн. Долл. около 100 тыс. расходуется на компьютеры. Допустим, вам удалось повысить эффективность работы программ, что привело к снижению требований к аппаратному обеспечению, и вы достигли экономии в 20% — 20 тыс. долл. Теперь представьте, что удалось каким-либо образом написать программы так, что на их поддержку и доработку расходуется на 10% меньше человеческих ресурсов. А это уже экономия в 200 тыс. долл.!
Следующий важный момент — ошибки в программах. В экстремальном программировании тестированию уделяется особое внимание. Тесты разрабатываются до того, как начнется написание программы, во время работы и после того, как кодирование завершено. По мере нахождения ошибок тесты дополняются, чтобы исключить повторное возникновение одной и той же ошибки.
Еще одна особенность, привлекательная для заказчика, — готовность программистов к постоянным изменениям в проекте. Часто заказчик имеет возможность корректировать работу только в тот момент, когда не самые подходящие решения в программе уже воплощены. За счет постоянной обратной связи с заказчиком ЭП позволяет вносить изменения именно на той стадии, когда это действительно эффективно.
Как видите, большая часть новаций, присущих ЭП, основана на переосмыслении того, как создается программный продукт.
Где и когда?Наиболее эффективным является применение ЭП для проектов с постоянно изменяющимися требованиями. Заказчик может не иметь точного представления о том, что должно быть сделано. Функциональность разрабатываемой системы может изменяться каждые несколько месяцев. Во многих случаях постоянные перемены в проекте — это единственное, в чем можно быть уверенным. Именно в этих случаях ЭП позволяет достичь успеха, в отличие от других методик.
ЭП также ориентировано на проекты с высокой степенью риска. Если заказчик должен получить новую систему в конкретный срок, риск очень высок. Если от вашей команды разработчиков требуется освоение новой области, — риск только увеличивается. Ну а если разработка является новинкой для всей программной индустрии, то это увеличивает риск многократно. В такой ситуации ЭП снижает риск и повышает шансы на успех.
Невозможно использовать ЭП на гигантских проектах — оно подходит для небольших групп программистов (от 2 до 10 человек). При постоянно меняющемся техническом задании такая группа может быть заметно эффективнее большого коллектива, использующего традиционные методики.
Однако ЭП требует расширения состава группы разработчиков. Помимо программистов туда должен входить менеджер и представитель заказчика, совместная работа которых заключается в постоянных консультациях, обсуждениях и тестирований.
Еще один критерий применимости ЭП — особенности предметной области. Должна существовать возможность создания автоматизированного теста. Хотя для многих областей это так, но есть и такие области, где данное требование невыполнимо. Для проверки необходимо провести предварительные тесты. Иногда нужно переформулировать задание или преобразовать систему, чтобы обеспечить автоматизированное тестирование.
Проекты ЭП свидетельствуют о большей производительности труда вовлеченных в них программистов по сравнению с аналогичными проектами, выполняемыми по привычным методикам. Однако рост производительности не был первоначальной целью ЭП. Главная цель — разработка программ в необходимые сроки. Если для вас это важно, то, возможно, пришло время попробовать ЭП.
ФормулировкиВместо термина «техническое задание» ЭП использует термин «формулировка пользователя». Формулировки позволяют оценить время, необходимое для разработки программы. Они записываются пользователями как описание действий, которые должна выполнять система. Формулировки похожи на сценарии использования, но не ограничиваются описанием пользовательского интерфейса. Каждая формулировка занимает три-четыре предложения в терминах заказчика (не программиста!).
Одна из наиболее распространенных ошибок состоит в том, что формулировки путают с традиционным техническим заданием. Наиболее заметное отличие — это уровень детализации. Формулировки обеспечивают только детали, необходимые для оценки времени и планирования с минимальным риском. Когда приходит время реализовать формулировку, разработчики получают от пользователя более детальное описание.
Каждая формулировка получает оценку — одну, две или три недели «идеального рабочего времени» (время, за которое задача может быть выполнена при отсутствии других задач). Если срок оказался более трех недель, следует разделить описание на несколько мелких. Срок менее одной недели указывает на излишнюю детализацию, в этом случае следует объединить несколько описаний.
Другое отличие — во главу угла ставится нужда пользователя. В формулировках следует избегать описаний технических подробностей, таких как устройство базы данных или алгоритмы.
ПланированиеДля бизнесменов очень важно принять деловые решения, столь же важно для разработчиков принять технические решения. Планирование устанавливает правила того, каким образом вовлеченные в проект стороны принимают соответствующие решения.
Главным итогом является план выпуска версий, охватывающий весь проект. Далее этот план используется для создания планов каждой итерации. Итерации детально планируются непосредственно перед началом каждой из них. Важнейшая задача — правильно оценить сроки выполнения работ по каждой из пользовательских формулировок.
Часто при составлении плана заказчик в первую очередь пытается сократить сроки. Этого делать не стоит, чтобы не вызвать проблем позднее. Основная философия планирования строится на том, что проект измеряется в четырех параметрах: объем, ресурсы, время и качество. Объем — сколько работы должно быть сделано, ресурсы — как много разработчиков находится в вашем распоряжении, время — когда проект будет закончен, качество — насколько хорошо будет реализована и протестирована программа. Можно, конечно, установить только три из четырех величин, но равновесие всегда будет достигнуто за счет оставшейся.
План релизовПлан релизов определяет даты релизов и формулировки пользователей, которые будут воплощены в каждом из них. Исходя из этого можно выбрать формулировки для очередной итерации. В течение итерации изготавливаются тесты приемки, которые выполняются в пределах этой итерации и всех последующих, чтобы обеспечить правильную работу программы. План может быть пересмотрен в случае значительного отставания или опережения по итогам одной из итераций.
ИтерацииИтерации придают процессу разработки динамичность. Не нужно планировать ваши программные задачи надолго вперед. Лучше вместо этого устраивать совещание для планирования в начале каждой итерации. Не стоит и пытаться реализовать то, что не было запланировано. У вас еще будет время, чтобы реализовать эти идеи, когда до них дойдет очередь согласно плану релизов.
Привыкнув не добавлять функциональность заранее и используя непосредственное планирование, вы сможете легко приспосабливаться к изменчивым требованиям заказчика.
Планирование итерацийПланирование итераций начинается со встречи в начале каждой итерации с целью выработки плана шагов для решения программных задач. Каждая итерация должна длиться от одной до трех недель. Формулировки внутри итерации сортируются в порядке их значимости для заказчика. Кроме того, добавляются задачи, которые не смогли пройти тесты приемки и требуют доработки. Формулировки и результаты тестов переводятся в программные задачи. Задачи записываются на карточках, которые образуют детальный план итерации. Для решения к каждой из задач требуется от одного до трех дней. Задачи, для которых нужно менее одного дня, можно сгруппировать вместе, а большие задачи разделить на несколько мелких. Разработчики оценивают задачи и сроки, для их выполнения. Для разработчика очень важно точно установить время выполнения задачи. Возможно, потребуется переоценить некоторые формулировки и пересмотреть план релиза после каждых трех или пяти итераций — это вполне допустимо. Если вы в первую очередь реализуете наиболее важные участки работы, то вы всегда будете успевать сделать максимум возможного для ваших клиентов. Стиль разработки, основанный на последовательности итераций, улучшает процесс разработки.
Ежедневные утренние совещания (планерки)Проводите по утрам планерки для обсуждения проблем, нахождения решений и определения точки приложения усилий всей команды. Расположите участников по кругу и проводите планерки стоя, чтобы избежать длинных дискуссий. Если вы проводите планерки, то большая часть других встреч будет проходить прямо на рабочих местах, напротив компьютера, где можно просматривать код и пробовать новые идеи.
Все гениальное — простоПростой дизайн всегда занимает меньше времени, чем сложный. Поэтому всегда делайте самые простые вещи, которые только смогут работать. Всегда быстрее и дешевле заменить сложный код сразу, прежде чем вы потратите много времени на работу с ним. Сохраняйте вещи такими простыми, как только возможно, не добавляя функциональность до того, как это запланировано. Имейте в виду: сохранять дизайн простым — это тяжелая работа.
Система метафорВыбор системы метафор нужен, чтобы удержать команду в одних и тех же рамках при именовании классов и методов. То, как вы называете свои объекты, очень важно для понимания общего дизайна системы и повторного использования кодов. Если разработчик в состоянии правильно предугадать, как может быть назван существующий объект, это ведет к экономии времени. Используйте такую систему имен для ваших объектов, которую каждый сможет понять без специфических знаний о системе.
Предварительные решенияПредварительные решения необходимы для трудных технических и дизайнерских проблем. Такое решение является простой программой, реализующей один из возможных вариантов решения. Разрабатывая предварительное решение, следует сконцентрироваться только на проблеме, которую надо решить, и игнорировать все остальные факторы. Многие предварительные решения приходится изменять, но таким образом удается уточнить оценку формулировок пользователя и уменьшить риск возникновения технических проблем в будущем.
Взаимодействие с пользователемОдно из требований ЭП — постоянное участие заказчика в разработке. Он не просто помогает разработчикам, но и является одним из них. Все фазы ЭП требуют взаимодействия с пользователем, предпочтительно лицом к лицу, на месте выполнения работ. Лучше всего пригласить одного или нескольких представителей заказчика участвовать в команде разработчиков. Может потребоваться время, чтобы вовлечь пользователя в работу. Не соглашайтесь, если заказчик даст вам новичка — вам нужен настоящий эксперт. Он будет разрабатывать формулировки, чтобы можно было оценить время и назначить приоритеты. Во время совещаний по планированию релизов пользователь может указать, какие формулировки должны быть включены в график релизов. На этих совещаниях следует определить минимальную последовательность шагов, чтобы пользователь скорее увидел программу в работе. Это позволяет как можно раньше испытать программу и дать разработчикам отзывы о ее работе. Поскольку при укрупненном планировании детали остаются в стороне, разработчикам постоянно нужно общаться с пользователями, чтобы получать как можно больше подробностей при выполнении программных задач. Пользователь также нужен и на этапе функционального тестирования. Словом, активное участие заказчика предотвращает появление некачественной программы.
Исходные текстыКачество исходных текстов играет гораздо большую роль, чем можно предположить. Хотя заказчик в большинстве случаев не имеет квалифицированного представления об исходных текстах или полного доступа к ним, однако это не может служить оправданием для создания запутанных, плохо изменяемых программ. Исходные тексты необходимо форматировать в соответствии с общими соглашениями. Такие соглашения позволяют сохранять целостность исходных текстов и облегчают их прочтение всей командой разработчиков в целом.
Коллективное владение исходными текстами позволяет каждому выдвигать новые идеи в любой части проекта. В случае достаточно больших систем один человек просто не в состоянии удержать в голове всю архитектуру проекта. Благодаря коллективному владению исходными текстами снижается риск принятия главным разработчиком неверного решения и устраняется нежелательная зависимость проекта от одного человека.
Парное программированиеВсе коды в проекте создаются парами программистов, работающими за одним компьютером. Парное программирование приводит к повышению качества без дополнительных затрат времени. Наши опыты показывают, что двое за одним компьютером сделают не меньше, чем каждый по отдельности, но качество кода будет выше. А это, в свою очередь, уменьшает расходы на сопровождение проекта в будущем.
Оптимальный вариант для парной работы — одновременно сидеть напротив монитора, передавая друг другу клавиатуру и мышь. Пока один человек сосредоточивает усилия на стратегическом представлении об объекте, второй реализует его свойства и методы.
Смена позицийВо время очередной итерации всех работников следует перемещать на новые участки работы. Подобные перемещения необходимы, чтобы избежать изоляции знаний и устранить «узкие места». Особенно плодотворной является замена одного из разработчиков при парном программировании.
ИнтеграцияБез последовательной и частой интеграции результатов разработки программисты не могут быть уверены, что они правильно разрабатывают проект. К тому же невозможно вовремя оценить качество выполненных фрагментов работы и внести необходимые коррективы.
Разработчики должны интегрировать и публиковать код для совместного использования каждые несколько часов, если это возможно. В любом случае не стоит откладывать публикацию более чем на один день. Интеграция позволяет избежать раздробления усилий отдельных пар и стимулировать повторное использование кода.
Не добавляйте функциональность слишком раноСледует удерживаться от соблазна добавить в систему возможности, которые, как вы думаете, будут востребованы позже. Только 10% из них будут когда либо использованы, а вы теряете 90% вашего времени. Даже если вам кажется, что система после этого станет только лучше, тем не менее постоянно твердите себе, что фактически это не так. Дополнительная функциональность только замедлит разработку и исчерпает ресурсы. Подавите свои порывы и сконцентрируйтесь на том, что было запланировано на сегодня.
Безжалостно перерабатывайтеМы, компьютерные программисты, держимся за свои разработки спустя долгое время после того, как они уже не нужны. Мы продолжаем использовать код, который становится трудно сопровождать, потому что он все еще работает в какой-то части, и боимся его модифицировать. Это совершенно не эффективно. Когда мы избавляемся от наследия прежнего кода, мы убираем ненужную функциональность и омолаживаем дизайн за счет удаления лишних частей. В ЭП этот процесс называется переработкой кода. Перерабатывайте безжалостно, чтобы сохранить дизайн простым. Сохраняйте ваш код прозрачным и целостным, чтобы его было легче понять, исправить и расширить. В конце концов на это уйдет меньше времени, чем на сопровождение устаревшего кода. Вы должны понимать, что программный модуль, который был когда-то хорош, сейчас может быть совершенно не нужен.
Оптимизируйте в последнюю очередьНе оптимизируйте до тех пор, пока не будет готово все. Никогда не пытайтесь предугадать, где в производительности системы будет «узкое место». Находите его при помощи измерений на готовой системе. Сначала заставьте систему работать, затем удостоверьтесь, что она работает правильно, и только после этого сделайте, чтобы она работала быстро.
Не работайте сверх графикаСверхурочная работа истощает дух и мотивацию команды. Проекты, которые для своего завершения требуют сверхурочной работы, все равно не будут закончены в срок, как бы вы ни старались. Вместо этого пытайтесь внести необходимые коррективы в график работы.
Ошибки и тестированиеТестирование — один из краеугольных камней ЭП. Вы должны обеспечить автоматическое тестирование как отдельных модулей, так и всех классов в системе. Не забывайте, что создание тестов должно предшествовать разработке программы. Тест необходимо помещать в библиотеку кодов вместе с кодом, который он тестирует. Главная причина недостаточного тестирования — приближающийся срок сдачи проекта. Однако тест экономит во много раз больше времени и денег, облегчая обнаружение ошибок. Чем сложнее написать тест, тем он более необходим, поскольку тем больше последующая отдача от него.
Тесты делают возможным коллективное создание исходных текстов и защищают их от неожиданных изменений. В случае обнаружения ошибки создавайте тест, чтобы предотвратить ее повторное появление.
Окончательные тесты основываются на формулировках пользователей. Эти тесты рассматривают вашу систему как «черный ящик» и рассчитаны на получение вполне определенного результата работы системы.
Тесты следует автоматизировать, чтобы их можно было выполнять часто. Основываясь на результатах тестов, разработчики включают в очередную итерацию работу над ошибками.
С чего начать?Попробуйте использовать ЭП в вашем следующем проекте. Начните со сбора формулировок и выработки предварительных решений. Затем соберите совещание и разработайте план выхода версий. Чтобы план был приемлем для всех, в совещании должны участвовать заказчики, разработчики и руководство. Приступайте к итеративной разработке с совещания по первой итерации.
Об ЭП вспоминают, когда все прочее уже не помогает. Найдите в своей работе слабое место и примените методы ЭП прежде всего там. Например, при недостаточно четком техническом задании используйте вместо него пользовательские формулировки. Если в системе много ошибок — больше тестируйте. При слабом повторном использовании кода — сделайте упор на парном программировании и общем доступе к исходным текстам.
КомментарийМнения о предлагаемой методике могут быть разными. Важно понимать, что экстремальное программирование не ставит перед собой цели заменить существующие технологии разработки (хотя уже сейчас многие программисты применяют ЭП — список проектов вы можете найти на сайте, ссылка на который приведена в начале материала). Наоборот, ЭП позволяет придать дополнительный импульс командам, использующим традиционные подходы. Не стоит искать здесь ответов на все возникающие вопросы. Это не технология программирования, а скорее технология организации работ, и именно в таком виде она имеет право на жизнь.
|
|
| ||||||||||||||||
| ||||||||||||||||
| ||||||||||||||||
|