Затем переходит к следующей проблеме, используя еще одну практику. При таком подходе проблемы выступают мотивацией к применению XP и команда постепенно осваивает все инструменты методологии. Он пишет ПИ, выбирает истории, которые будут реализованы в конкретной итерации, и отвечает на вопросы, касающиеся бизнеса. Представитель заказчика должен быть экспертом в автоматизируемой предметной области. Необходимо наличие постоянное обратной связи с представителем заказчика.
Ускорить процессы разработки, а также исключить вероятность недопонимания и задержек при длительном перерыве в работе над тем или иным модулем. Особенности экстремального программирования и менеджментаГлавная особенность XP — методология применима только в сфере разработки программного обеспечения. Ее не использовать там, где нет никакого digital-продукта.
Экстремальное программирование (Extreme Programming, XP) 💥 — методология, цели и практики
В этой главе вы познакомитесь с методами экстремального программирования в деталях и преимуществами каждого из этих методов. Эти четыре основных вида деятельности должны быть структурированы в свете принципов экстремального программирования. С хорошими модульными тестами вы можете легко реорганизовать свой код для проведения дополнительных тестов.
Возможно, им придется выбросить то, что они сделали, и начать все сначала, поскольку они, возможно, не знали достаточно, чтобы закодировать эту функцию. Интеграция одного набора изменений за один раз помогает понять, кто должен исправить неудачный тест. Код интегрируется и тестируется много раз в день, по одному набору экстремальное программирование изменений за раз. Не все знают каждую часть одинаково хорошо, хотя каждый знает что-то о каждой части. Например, если вы несете ответственность за выполнение задачи в незнакомой вам области, вы можете попросить кого-то с недавним опытом объединиться с вами. Чаще кто-либо в команде будет выступать в качестве партнера.
И какие практики предлагают?
Итерации облегчают адаптационные изменения по мере развития программного обеспечения в соответствии с меняющимися требованиями. Ключевое допущение экстремального программирования заключается в том, что стоимость изменения программы может оставаться в основном постоянной с течением времени. Существует требование строгого процесса изменений, который включает в себя плату управления изменениями, которая может даже выдвигать изменения в более поздние выпуски. Частые и постоянные поставки обеспечивают быструю обратную связь, что, в свою очередь, позволяет команде соответствовать требованиям. В экстремальном подходе нужно выпускать код в продакшен каждый день, а лучше даже несколько раз в день.
Требования часто меняются, поэтому процесс делят на короткие этапы с частыми релизами, как и в Scrum. Задачи записывают на карточки, выясняют у заказчика последовательность, в которой он хочет получать функционал продукта. Термин «экстремальное управление проектами» придумал эксперт по менеджменту Дуг ДеКарло в 2004 году. На самом деле он просто собрал опыт разных компаний, проанализировал, выделил самое лучшее и получил авторский метод менеджмента. Весь процесс управления по ДеКарло основан на принципах экстремального программирования .
Простой дизайн
Разработчик не может сказать кому-либо еще о критических изменениях в дизайне. В 1999 году Кент опубликовал свою книгу «Объяснение экстремального программирования». Кент Бек, Уорд Каннингем и Рон Джеффрис сформулировали экстремальное программирование в 1999 году.
XP – это легкий, эффективный, с низким уровнем риска, гибкий, предсказуемый, научный и интересный способ разработки программного обеспечения. Мы раскрываем лучшие способы разработки программного обеспечения, делая это и помогая другим делать это. В экстремальном программировании заказчик всегда доступен для вопросов, с ним обсуждают код, возможности алгоритмов и функции программы.
· Непрерывный, а не пакетный процесс
В разработке программного обеспечения термин «гибкий» адаптирован для обозначения «способности реагировать на изменения – изменения в требованиях, технологиях и людях». В бизнесе «гибкая» используется для описания способов планирования и выполнения работы, при которой понимается, что внесение изменений по мере необходимости является важной частью работы. Начать можно как “снизу” (новые практики, такие как парное программирование), так и “сверху” (внедрение ценностей XP иAgile).
- Программное обеспечение доставляется клиенту заблаговременно, а также принимаются отзывы, чтобы при необходимости можно было внести необходимые изменения.
- Обратная связь с заказчиком, представитель которого фактически вовлечен в процесс разработки.
- Не бояться рисковать и использовать новые непроверенные практики.
- С Metaphor, чтобы внести ясность для разработчиков в области.
В экстремальном программировании планирование — неотъемлемая часть разработки и то, что планы могут поменяться, учитывается с самого начала. Экстремальное программирование — гибкая методология, в центре которой качественный работоспособный код с простой архитектурой. Ее предназначение — снизить уровень неопределенности в проектах и по-настоящему гибко реагировать на изменения требований к продукту. Бек Кент рекомендует внедрять XP для решения проблем в проекте. Команда выбирает самую насущную проблему и решает ее с помощью одной из практик экстремального программирования.
Рефакторинг
Некоторые методики экстремального программирования настолько непривычны, что требует смелости и постоянного контроля над собой. В XP коммуникация между разработчиками ведется не посредством документации, а вживую. Простой дизайн в XP означает делать только то, что нужно сейчас, не пытаясь угадать будущую функциональность. Простой дизайн и непрерывный рефакторинг дают синергетический эффект — когда код простой, его легко оптимизировать. XP команды работают на максимуме продуктивности, сохраняя устойчивый темп. При этом экстремальное программирование негативно относится к переработкам и пропагандирует 40-часовую рабочую неделю.
После того, как они добавили функцию, разработчики спрашивают, могут ли они теперь увидеть, как сделать код проще, при этом все еще выполняя все тесты. При реализации функции разработчики всегда спрашивают, есть ли способ изменить существующий код, чтобы сделать добавление функции простым. Разработчики постоянно пишут юнит-тесты, которые необходимо пройти для продолжения разработки. Чтобы получить простой дизайн, исключите любой элемент дизайна, который вы можете, не нарушая первые три правила. Вы можете думать о метафоре как об архитектуре системы, которая будет построена таким образом, чтобы ее легко могли понять все, кто участвует в разработке.