Экстремальное программирование развивается с момента его возникновения, и практика экстремального программирования оказывается эффективной и в других гибких методологиях.
Следующая таблица показывает, как развиваются практики экстремального программирования.
| Практика экстремального программирования | эволюция |
|---|---|
| Клиент на месте | Вся команда |
| Планирование игры |
Планирование релиза Планирование итерации |
| тестирование |
Приемочное тестирование Модульное тестирование Разработка через тестирование |
| Рефакторинг | Улучшение дизайна |
| 40-часовая неделя | Устойчивый темп |
Планирование релиза
Планирование итерации
Приемочное тестирование
Модульное тестирование
Разработка через тестирование
Клиент на месте — вся команда
Экстремальное программирование опирается на проектное сообщество с упором на командно-ориентированный подход. Все участники проекта Extreme Programming, включая клиента, являются одной командой.
Заказчик устанавливает требования, устанавливает приоритеты и руководит проектом. Это позволяет клиенту понять практические детали разработки и соответственно расставить приоритеты и ожидания. Это меняется с «Когда заказчик запрашивает разработку» на «Когда заказчик понимает и сотрудничает с разработкой».
Цели проекта — общая ответственность, а развитие — это постоянный разговор всей команды. Это совместная игра изобретения и общения. Установлено, что личное общение является наиболее эффективным и наиболее эффективным методом на пути развития и устраняет время ожидания и задержки.
Планирование игры — Планирование выпуска и итерации
Инкрементное планирование проекта оказалось эффективным, поскольку оно способствует точным планам. Все больше и больше информации изучается по мере развития разработки на основе фактической производительности. Сначала разработайте приблизительный план и постепенно улучшайте его.
Планирование выпуска ставит долгосрочные цели с общей общей картиной под рукой. Заказчик представляет необходимые функции, оценки разработчиков и даты выпуска взаимно согласованы и зафиксированы. Поскольку план выпуска пересматривается после каждого выпуска, он становится более точным по мере продвижения проекта.
Планирование итераций устанавливает краткосрочные временные рамки с итерациями, обычно в диапазоне от 1 недели до 1 месяца. Основная цель итерационного планирования — это работающее программное обеспечение в конце каждой итерации. Разработчики выбирают функции / истории для итерации, разбивают их на задачи, оценивают задачи и фиксируют выделенные задачи. Устойчивый темп обеспечивается балансировкой коэффициента нагрузки по команде с учетом 40-часовой рабочей недели.
Приемочное тестирование
Заказчик пишет один или несколько автоматических приемочных тестов для функции, чтобы убедиться, что система правильно реализует нужные функции. Приемочные тесты написаны вместе с историями и предоставлены до реализации.
Команда автоматизирует эти тесты, чтобы убедиться, что функция реализована правильно. После того, как тест запущен, команда гарантирует, что он продолжает работать правильно после этого, во время регрессии, выполняя все приемочные тесты, реализованные до этого момента.
Приемочные испытания обеспечивают недвусмысленные спецификации функциональных требований. Кроме того, процент прохождения приемочных испытаний измеряет завершение выпуска, без сюрпризов в последнюю минуту.
Система всегда улучшается и никогда не отступает.
Модульное тестирование
Разработчик пишет модульные тесты с достаточным охватом, включающие намерение и использование модулей и методов кода. Модульные тесты автоматизированы, с четким прохождением / провалом. Большинство языков имеют платформу xUnit (например, nUnit, jUnit).
Все модульные тесты выполняются очень часто, и код не может быть зарегистрирован, пока не пройдут все модульные тесты. Результаты модульного теста также помогают в рефакторинге.
Разработка через тестирование
Разработка через тестирование считается самой инновационной практикой экстремального программирования.
В Test Driven Development разработчик пишет модульный тест перед написанием кода. Цель состоит в том, чтобы заставить модульный тест не пройти Поскольку код еще не реализован, модульный тест не пройден. Разработчик пишет достаточно кода, чтобы выполнить модульное тестирование, а затем разработчик рефакторинг, чтобы гарантировать, что код прост и чист (без дублирования и сложности).
Разработчик выполняет итерации, пока кодирование не будет завершено и приемочный тест не пройден.
Юнит-тесты собраны воедино, и каждый раз, когда пара интегрирует и выпускает код в хранилище, пара должна убедиться, что каждый тест выполняется правильно. Если какой-либо тест не пройден, пара знает, что это их код, который необходимо исправить, поскольку предыдущие интеграции прошли без каких-либо дефектов.
Разработка через тестирование приводит к 100% охвату модульных тестов и гарантирует, что код будет простым и минимальным.
Рефакторинг — Улучшение дизайна
Рефакторинг позволяет дизайну постепенно развиваться, сохраняя его простым, устраняя дублирование и сложность, как вы заметили. Это улучшает дизайн существующего кода без изменения его функциональности путем рефакторинга.
Рефакторинг должен быть основан на изучении новых реализаций. Рекомендуется выполнять рефакторинг сразу после написания нового кода. Рефакторинг направляет код к шаблонам проектирования более высокого уровня и поддерживается тестированием.
40-часовая неделя — устойчивый темп
Работайте в темпе, который можно поддерживать бесконечно. Sustainable Pace обеспечивает человеческий вклад в успех проекта, учитывая факты, которые —
Усталость и стресс снижают производительность, а также качество продукта. Это может привести к текучести кадров.
Развитие не останавливается на спринте, и оно должно быть направлено на достижение долгосрочных целей
Если команда не согласится с ожиданиями, не будет обязательств и ответственности.
Точные часы не так важны, как умение выступать.
Следует избегать микроуправления, обеспечивая при этом доступность по мере необходимости