Экстремальное программирование — практика

Существует четыре основных вида деятельности в экстремальном программировании. Они —

• кодирование

• тестирование

• прослушивание

• Проектирование

кодирование

тестирование

прослушивание

Проектирование

Эти четыре основных вида деятельности должны быть структурированы в свете принципов экстремального программирования. Для этого определены методы экстремального программирования.

Эти 12 практик экстремального программирования достигают цели экстремального программирования, и там, где одна из практик слаба, сильные стороны других практик восполняют ее.

Кент Бек, автор «Объяснения экстремального программирования», определил 12 практик экстремального программирования следующим образом:

• Планирование игры

• Короткие Релизы

• метафора

• Простой дизайн

• тестирование

• Рефакторинг

• Парное программирование

• Коллективная собственность

• Непрерывная интеграция

• 40 часовая неделя

• Клиент на месте

• Стандарты кодирования

Планирование игры

Короткие Релизы

метафора

Простой дизайн

тестирование

Рефакторинг

Парное программирование

Коллективная собственность

Непрерывная интеграция

40 часовая неделя

Клиент на месте

Стандарты кодирования

Четыре области экстремального программирования

Практики экстремального программирования можно разделить на четыре области:

• Быстрая, Прекрасная Обратная Связь —

  • тестирование

  • Клиент на месте

  • Парное программирование

Быстрая, Прекрасная Обратная Связь —

тестирование

Клиент на месте

Парное программирование

• Непрерывный процесс —

  • Непрерывная интеграция

  • Рефакторинг

  • Короткие Релизы

Непрерывный процесс —

Непрерывная интеграция

Рефакторинг

Короткие Релизы

• Общее понимание —

  • Планирование игры

  • Простой дизайн

  • метафора

  • Коллективная собственность

  • Стандарты кодирования

Общее понимание —

Планирование игры

Простой дизайн

метафора

Коллективная собственность

Стандарты кодирования

• Благосостояние разработчика —

  • Сорокчасовая неделя

Благосостояние разработчика —

Сорокчасовая неделя

В этой главе вы познакомитесь с методами экстремального программирования в деталях и преимуществами каждого из этих методов.

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

На следующей диаграмме показано, как экстремальное программирование сплетено с практиками экстремального программирования:

Планирование игры

Основной процесс планирования в рамках экстремального программирования называется «Игра в планирование». Игра — это встреча, которая происходит один раз за итерацию, обычно раз в неделю. Игра «Планирование» позволяет быстро определить объем следующего выпуска, объединив бизнес-приоритеты и технические оценки. Когда реальность настигнет план, обновите план.

Бизнес и развитие должны принимать решения в тандеме. Бизнес-решения и технические решения разработки должны согласовываться друг с другом.

Деловые люди должны решить о —

• Масштаб — Какую часть проблемы нужно решить, чтобы система была ценной в производстве? Бизнесмен в состоянии понять, сколько не достаточно, а что слишком много.

• Приоритет — если вам предоставляется вариант, какой из них вы хотите? Бизнесмен в состоянии определить это, больше, чем разработчик при участии клиента.

• Состав релизов — Сколько или как мало нужно сделать, чтобы бизнес стал лучше с программным обеспечением, чем без него? Интуиция разработчика по этому вопросу может быть совершенно неверной.

• Даты выпусков — Какие важные даты, в которые присутствие программного обеспечения (или часть программного обеспечения) будет иметь большое значение?

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

Приоритет — если вам предоставляется вариант, какой из них вы хотите? Бизнесмен в состоянии определить это, больше, чем разработчик при участии клиента.

Состав релизов — Сколько или как мало нужно сделать, чтобы бизнес стал лучше с программным обеспечением, чем без него? Интуиция разработчика по этому вопросу может быть совершенно неверной.

Даты выпусков — Какие важные даты, в которые присутствие программного обеспечения (или часть программного обеспечения) будет иметь большое значение?

Технические люди должны решить о —

• Оценки — Сколько времени займет реализация функции?

• Последствия — Есть стратегические бизнес-решения, которые должны приниматься только тогда, когда сообщается о технических последствиях. Развитие должно объяснить последствия.

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

• Подробное планирование — в каком выпуске какие истории должны быть написаны в первую очередь? Разработчикам нужна свобода в первую очередь планировать наиболее рискованные сегменты разработки, чтобы снизить общий риск проекта. В рамках этого ограничения они по-прежнему склонны перемещать бизнес-приоритеты на более ранних этапах разработки, снижая вероятность того, что важные истории придется отбросить к концу разработки релиза из-за нехватки времени.

Оценки — Сколько времени займет реализация функции?

Последствия — Есть стратегические бизнес-решения, которые должны приниматься только тогда, когда сообщается о технических последствиях. Развитие должно объяснить последствия.

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

Подробное планирование — в каком выпуске какие истории должны быть написаны в первую очередь? Разработчикам нужна свобода в первую очередь планировать наиболее рискованные сегменты разработки, чтобы снизить общий риск проекта. В рамках этого ограничения они по-прежнему склонны перемещать бизнес-приоритеты на более ранних этапах разработки, снижая вероятность того, что важные истории придется отбросить к концу разработки релиза из-за нехватки времени.

Таким образом, план является результатом сотрудничества между заказчиком, бизнесменом и разработчиками.

Игра в планирование — преимущества

Игра в планирование имеет следующие преимущества:

• Сокращение времени, потраченное впустую на бесполезные функции

• Большая оценка клиентов стоимости функции

• Меньше догадок при планировании

Сокращение времени, потраченное впустую на бесполезные функции

Большая оценка клиентов стоимости функции

Меньше догадок при планировании

Короткие Релизы

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

• Достижимо за короткий цикл

• Содержит самые ценные и актуальные бизнес-требования

• Рабочая система

Достижимо за короткий цикл

Содержит самые ценные и актуальные бизнес-требования

Рабочая система

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

Короткие Релизы — Преимущества

Преимущества коротких релизов —

• Частые отзывы

• отслеживание

• Уменьшить вероятность общего проскальзывания проекта

Частые отзывы

отслеживание

Уменьшить вероятность общего проскальзывания проекта

метафора

Согласно интернет-словарю Кембриджа, метафора — это выражение, часто встречающееся в литературе, которое описывает человека или объект, ссылаясь на то, что, как считается, имеет сходные характеристики с этим человеком или объектом. Например, «ум — это океан» и «город — джунгли» — это и есть метафоры.

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

Метафора состоит из специфичных для предметной области элементов и показывает их взаимосвязанность. Используемый язык является языком домена. Чтобы идентифицировать технические объекты, слова, используемые в метафоре, должны восприниматься последовательно.

По мере развития и развития метафоры вся команда обретет новое вдохновение от изучения метафоры.

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

Метафора — преимущества

Преимущества Метафоры —

• Поощряет общий набор терминов для системы

• Сокращение модных слов и жаргона

• Быстрый и простой способ объяснить систему

Поощряет общий набор терминов для системы

Сокращение модных слов и жаргона

Быстрый и простой способ объяснить систему

Простой дизайн

Система должна быть спроектирована максимально просто в любой момент. Дополнительная сложность удаляется, как только она обнаружена.

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

• Запускает все тесты

• Не имеет дублированной логики, такой как параллельные иерархии классов

• Излагает все намерения, важные для разработчиков

• Имеет как можно меньше классов и методов

Запускает все тесты

Не имеет дублированной логики, такой как параллельные иерархии классов

Излагает все намерения, важные для разработчиков

Имеет как можно меньше классов и методов

Чтобы получить простой дизайн, исключите любой элемент дизайна, который вы можете, не нарушая первые три правила. Это противоположно совету — внедряй на сегодня, проектируй на завтра. Если вы считаете, что будущее неясно, и вы можете быстро улучшить дизайн, то не ставьте никаких предположений.

Простой дизайн — преимущества

Преимущества простого дизайна —

• Время не теряется, добавляя лишнюю функциональность

• Проще понять, что происходит

• Рефакторинг и коллективная собственность стала возможной

• Помогает держать программистов на ходу

Время не теряется, добавляя лишнюю функциональность

Проще понять, что происходит

Рефакторинг и коллективная собственность стала возможной

Помогает держать программистов на ходу

тестирование

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

Тестирование — преимущества

Преимущества тестирования:

• Модульное тестирование способствует полноте тестирования

• Test-first дает разработчикам цель

• Автоматизация дает набор регрессионных тестов

Модульное тестирование способствует полноте тестирования

Test-first дает разработчикам цель

Автоматизация дает набор регрессионных тестов

Рефакторинг

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

Рефакторинг — преимущества

Преимущества рефакторинга —

• Предлагает разработчикам активно улучшать продукт в целом

• Увеличивает знания разработчиков системы

Предлагает разработчикам активно улучшать продукт в целом

Увеличивает знания разработчиков системы

Парное программирование

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

В каждой паре две роли —

• Первый разработчик (с клавиатурой и мышью) думает о том, как реализовать этот метод прямо здесь.

• Другой разработчик думает более стратегически

  • Весь этот подход будет работать?

  • Какие еще тестовые примеры могут еще не работать?

  • Есть ли способ упростить всю систему, чтобы текущая проблема просто исчезла?

Первый разработчик (с клавиатурой и мышью) думает о том, как реализовать этот метод прямо здесь.

Другой разработчик думает более стратегически

Весь этот подход будет работать?

Какие еще тестовые примеры могут еще не работать?

Есть ли способ упростить всю систему, чтобы текущая проблема просто исчезла?

Спаривание динамическое. Это означает, что две роли A и B могут поменяться местами или объединиться с другими членами команды. Чаще кто-либо в команде будет выступать в качестве партнера. Например, если вы несете ответственность за выполнение задачи в незнакомой вам области, вы можете попросить кого-то с недавним опытом объединиться с вами.

Парное программирование — преимущества

Преимущества парного программирования —

• Две головы лучше одной

• фокус

• Два человека с большей вероятностью ответят на следующие вопросы —

  • Весь этот подход будет работать?

  • Какие тестовые случаи могут еще не работать?

  • Есть ли способ упростить это?

Две головы лучше одной

фокус

Два человека с большей вероятностью ответят на следующие вопросы —

Весь этот подход будет работать?

Какие тестовые случаи могут еще не работать?

Есть ли способ упростить это?

Коллективная собственность

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

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

Коллективная собственность — преимущества

Преимущества коллективной собственности —

• Помогает смягчить потерю члена команды, который уходит.

• Предлагает разработчикам взять на себя ответственность за систему в целом, а не за ее части.

Помогает смягчить потерю члена команды, который уходит.

Предлагает разработчикам взять на себя ответственность за систему в целом, а не за ее части.

Непрерывная интеграция

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

• Сидит, когда машина свободна.

• Загружает текущий выпуск.

• Загружает их изменения (проверка и устранение любых коллизий).

• Запускает тесты до тех пор, пока они не пройдут (100% правильно).

Сидит, когда машина свободна.

Загружает текущий выпуск.

Загружает их изменения (проверка и устранение любых коллизий).

Запускает тесты до тех пор, пока они не пройдут (100% правильно).

Интеграция одного набора изменений за один раз помогает понять, кто должен исправить неудачный тест. Ответ — это настоящая пара, так как последняя пара вышла из теста на 100%. Возможно, им придется выбросить то, что они сделали, и начать все сначала, поскольку они, возможно, не знали достаточно, чтобы закодировать эту функцию.

Непрерывная интеграция — преимущества

Преимущества непрерывной интеграции:

• Уменьшает продолжительность, которая в противном случае является длительной.

• Включает практику коротких выпусков, так как время, необходимое для выпуска, минимально.

Уменьшает продолжительность, которая в противном случае является длительной.

Включает практику коротких выпусков, так как время, необходимое для выпуска, минимально.

40-часовая неделя

Экстремальное программирование подчеркивает ограниченное количество часов работы в неделю для каждого члена команды, исходя из их устойчивости, максимум до 45 часов в неделю. Если кто-то работает больше времени, это считается сверхурочной работой. Сверхурочные работы допускаются не более одной недели. Эта практика должна гарантировать, что каждый член команды будет свежим, творческим, осторожным и уверенным.

40-часовая неделя — преимущества

Преимущества 40-часовой недели —

• Большинство разработчиков теряют эффективность за последние 40 часов.

• Ценность придается благосостоянию разработчиков.

• Менеджмент вынужден находить реальные решения.

Большинство разработчиков теряют эффективность за последние 40 часов.

Ценность придается благосостоянию разработчиков.

Менеджмент вынужден находить реальные решения.

Клиент на месте

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

Клиент на месте — преимущества

Преимущества наличия местного клиента —

• Может дать быстрые и знающие ответы на реальные вопросы развития.

• Уверен, что то, что разработано, — то, что нужно.

• Функциональность расставлена ​​по приоритетам правильно.

Может дать быстрые и знающие ответы на реальные вопросы развития.

Уверен, что то, что разработано, — то, что нужно.

Функциональность расставлена ​​по приоритетам правильно.

Стандарты кодирования

Разработчики пишут весь код в соответствии с правилами, подчеркивающими

• Общение через код.

• Наименьшее количество работы возможно.

• В соответствии с правилом «один раз и только один раз» (без дублирующего кода).

• Добровольное усыновление всей командой.

Общение через код.

Наименьшее количество работы возможно.

В соответствии с правилом «один раз и только один раз» (без дублирующего кода).

Добровольное усыновление всей командой.

Эти правила необходимы в экстремальном программировании, потому что все разработчики —

• Может переключаться с одной части системы на другую часть системы.

• Меняйте партнеров пару раз в день.

• Рефакторинг кода друг друга постоянно.

Может переключаться с одной части системы на другую часть системы.

Меняйте партнеров пару раз в день.

Рефакторинг кода друг друга постоянно.

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

Стандарты кодирования — Преимущества

Преимущества стандартов кодирования —

Сокращает время, которое разработчики тратят на переформатирование кода других людей.

Уменьшает необходимость внутреннего комментирования.

Призывает к ясному, однозначному коду.