Доклад на тему «Экстремальное программирование как метод создания

Доклад на тему «Экстремальное программирование как метод создания информационных систем» Подготовил Шамаев В. Ю. группа Пибд-21

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

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

Основные принципы XP • Итеративность. Разработка ведется короткими итерациями при наличии активной взаимосвязи с заказчиком. Итерации как таковые предлагается делать короткими, рекомендуемая длительность – 2 -3 недели и не более 1 месяца. За одну итерацию группа программистов обязана реализовать несколько свойств системы, каждое из которых описывается в пользовательской истории. Пользовательские истории (ПИ) в данном случае являются начальной информацией, на основании которой создается модуль. Они отличаются от вариантов использования (ВИ). Описание ПИ короткое – 1 -2 абзаца, тогда как ВИ обычно описываются достаточно подробно, с основным и альтернативными потоками, и дополняются моделью. ПИ пишутся самими пользователями, которые в XP являются частью команды, в отличие от ВИ, которые описывает системный аналитик. Отсутствие формализации описания входных данных проекта в XP стремятся компенсировать за счет активного включения в процесс разработки заказчика как полноправного члена команды.

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

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

Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы: • • Короткий цикл обратной связи • • Тестирование до начала разработки Игра в планирование Тесное взаимодействие с заказчиком Парное программирование Непрерывный, а не пакетный процесс • • • Непрерывная интеграция Рефакторинг Небольшие релизы Понимание, разделяемое всеми • • Простая архитектура Метафора системы Коллективное владение кодом Единые стандарты кодирования Социальная защищенность программиста • 40 -часовая рабочая неделя

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

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

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

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

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

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

Непрерывный, а не пакетный процесс 7. Небольшие релизы. • Версии продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой • • версией должна занимать как можно меньше времени. При этом каждая версия должна быть достаточно осмысленной с точки зрения полезности для бизнеса. Чем раньше выпускается первая рабочая версия продукта, тем раньше заказчик начнет получать за счёт неё дополнительную прибыль. Следует помнить, что деньги, заработанные сегодня, стоят дороже, чем деньги, заработанные завтра. Чем раньше заказчик приступит к эксплуатации продукта, тем раньше разработчики получат от него информацию о том, что соответствует требованиям заказчика. Эта информация может оказаться чрезвычайно полезной при планировании следующего выпуска. Минимальная итерация при разработке ПО – один день, максимальная – месяц; чем чаще осуществляются релизы, тем больше недостатков системы будет выявлено. Первые релизы помогают выявить недостатки на самых ранних стадиях, далее функциональность системы расширяется на основании пользовательских историй. Поскольку пользователь включается в процесс разработки начиная с первого релиза, то он оценивает систему и выдает пользовательскую историю и замечания. На основании этого определяется следующая итерация, то есть, каким будет новый релиз. В XP все направлено на обеспечение непрерывной обратной связи с пользователями.

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

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

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

Понимание, разделяемое всеми 11. Единые стандарты кодирования. • Стандарты кодирования нужны для обеспечения других практик: коллективного владения кодом, парного программирования и рефакторинга. Без единого стандарта выполнять эти практики как минимум сложнее, а в реальности вообще невозможно: группа будет работать в режиме постоянной нехватки времени. Команда работает над проектом продолжительное время. Люди приходят и уходят. Никто не кодирует в одиночку и код принадлежит всем. Всегда будут моменты, когда необходимо будет понять и скорректировать чужой код. Разработчики будут удалять дублирующий код, анализировать и улучшать чужие классы и т. п. Со временем нельзя будет сказать, кто автор конкретного класса. Следовательно, все должны подчиняться общим стандартам кодирования – форматирование кода, именование классов, переменных, констант, стиль комментариев. Вышесказанное означает, что все члены команды должны договориться об общих стандартах кодирования. Неважно каких, но все обязаны им подчиняются.

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

Предназначение XP Ключевые направления, на которые нацелена XP: • • • Работа с заказчиком. Выяснение того, что в действительности нужно заказчику. Как правило, это не то, что он себе представляет. Своевременное выяснение подробностей и планирование сбережет много сил, средств, времени и нервов. Гибкая разработка. Пресловутый простой дизайн, частые выпуски версий, регулярное планирование – все это служит тому, чтобы максимально быстро и безболезненно реагировать на меняющиеся требования заказчика и оперативно реализовывать функциональность, наиболее критичную прямо сейчас. Непрерывная работоспособность кода. Постоянные интеграции кода и большое количество тестов – это все дает уверенность, что код работоспособен и работает он правильно. Упрощение поддержки кода. Рефакторинги и стандарты кодирования облегчают дальнейшие изменения в коде и облегчают понимание кода всеми разработчиками. Повышение скорости и качества разработки. Парное программирование, коллективное владение кодом, заказчик в команде, 40 -часовая рабочая неделя и метафора системы – эти практики делают разработку более быстрой и качественной. Таким образом, XP как методология предназначена для уменьшения затрат на разработку и поддержку ПО. При этом она обеспечивает гибкость процесса разработки, качество продукта и его соответствие реальным потребностям заказчика.

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

Список использованной литературы • Кент, Б. Экстремальное программирование / Б Кент. - Санкт-Петербург : Питер, 2002. – 224 с. • Ауэр, К. Экстремальное программирование: постановка процесса с первых шагов и до победного конца / Ауэр К. , Миллер Р. - Санкт. Петербург : Питер, 2003. – 368 с. • Кент, Б. Экстремальное программирование: планирование / Кент Б. , Фаулер М. - Санкт-Петербург : Питер, 2003. – 144 с.