Презентация на тему: Экстремальное программирование (XP)

Экстремальное программирование (XP)
Extreme Programming
Экстремальное программирование (XP)
Вся команда
Игра в планирование
Частые релизы версий
Пользовательские тесты
Коллективное владение кодом
Непрерывная интеграция кода
Стандарты кодирования
Метафора системы
Устойчивый темп
Разработка, основанная на тестировании
Парное программирование
Простой дизайн
Рефакторинг
Принципы XP
Алгоритм внедрения XP
Преимущества XP
Недостатки XP
Выводы
1/21
Средняя оценка: 4.3/5 (всего оценок: 61)
Код скопирован в буфер обмена
Скачать (305 Кб)
1

Первый слайд презентации: Экстремальное программирование (XP)

Дорожинский Митина Якимов Черкасов Кхай

Изображение слайда
2

Слайд 2: Extreme Programming

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

Изображение слайда
3

Слайд 3

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

Изображение слайда
4

Слайд 4: Вся команда

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

Изображение слайда
5

Слайд 5: Игра в планирование

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

Изображение слайда
6

Слайд 6: Частые релизы версий

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

Изображение слайда
7

Слайд 7: Пользовательские тесты

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

Изображение слайда
8

Слайд 8: Коллективное владение кодом

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

Изображение слайда
9

Слайд 9: Непрерывная интеграция кода

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

Изображение слайда
10

Слайд 10: Стандарты кодирования

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

Изображение слайда
11

Слайд 11: Метафора системы

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

Изображение слайда
12

Слайд 12: Устойчивый темп

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

Изображение слайда
13

Слайд 13: Разработка, основанная на тестировании

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

Изображение слайда
14

Слайд 14: Парное программирование

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

Изображение слайда
15

Слайд 15: Простой дизайн

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

Изображение слайда
16

Слайд 16: Рефакторинг

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

Изображение слайда
17

Слайд 17: Принципы XP

Простота Коммуникация Обратная связь Смелость Уважение

Изображение слайда
18

Слайд 18: Алгоритм внедрения XP

Тестирование Проектирование Планирование Менеджмент Разработка

Изображение слайда
19

Слайд 19: Преимущества XP

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

Изображение слайда
20

Слайд 20: Недостатки XP

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

Изображение слайда
21

Последний слайд презентации: Экстремальное программирование (XP): Выводы

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

Изображение слайда