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

В этой главе мы поймем действия и артефакты экстремального программирования.

XP - Деятельность

В экстремальном программировании четыре основных вида деятельности:

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

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

  • Listening

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

кодирование

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

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

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

Listening

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

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

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

Эти действия выполняются во время -

  • Планирование релиза

  • Планирование итерации

  • Реализация

Планирование релиза

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

Планирование релиза имеет три этапа -

  • Этап разведки

  • Фаза обязательств

  • Фаза управления

Планирование релиза - фаза исследования

На этапе разведки -

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

  • Разработчики собирают требования и оценивают влияние работы каждого из этих требований.

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

Активное прослушивание важно на этом этапе, так как

  • Разработчики должны понимать, «что заказчик просит» и «какие требования имеют большую ценность».

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

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

  • Получить ясность

  • Избегайте двусмысленности

  • Выразите себя, если есть возможные пробелы в понимании

Это возможно только при устном общении.

Планирование релиза - Фаза обязательств

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

Этот этап включает определение затрат, выгод и графика воздействия. На этом этапе

  • Клиент сортирует пользовательские истории по стоимости бизнеса.

  • Разработчики сортируют истории по риску.

  • Разработчики определяют усилия и продолжительность (оценки), необходимые для реализации историй.

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

  • На основе пользовательских историй и оценок определяется дата выпуска.

Активное слушание важно на этом этапе, так как -

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

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

Планирование релиза - Фаза управления

На этапе рулевого управления заказчик и разработчики «рулят» -

  • Вносить изменения в отдельные пользовательские истории и относительные приоритеты различных пользовательских историй.

  • Чтобы скорректировать план.

  • Если оценки оказались неверными.

  • Для размещения изменений.

Активное слушание важно на этом этапе,

  • Чтобы понять -

    • Новые требования будут добавлены.

    • Какие изменения необходимо внести в существующие требования.

    • Влияние на существующую систему, если какое-либо из существующих требований будет удалено.

  • Получите оценки, необходимые для корректировки плана, учитывая

    • Работа проделана до сих пор.

    • Новые требования будут добавлены.

    • Существующие требования, которые должны быть изменены или удалены.

Планирование итерации

В Планировании итерации разработчики участвуют в планировании действий и задач для итерации. В этом заказчик не участвует.

Планирование итерации состоит из трех этапов:

  • Этап разведки.

  • Фаза обязательств.

  • Фаза рулевого управления.

Планирование итерации - фаза исследования

На этапе разведки,

  • Требования будут переведены на разные задачи.

  • Задачи записаны на карточках задач.

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

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

Планирование итерации - Фаза обязательств

На этапе принятия обязательств,

  • Задачи возлагаются на разработчиков.

  • Разработчик принимает задачи, за которые он или она берет на себя ответственность.

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

  • Балансировка нагрузки выполняется после того, как всем разработчикам в команде были назначены задачи.

  • Проводится сравнение между расчетным временем выполнения задач и коэффициентом загрузки.

  • Коэффициент загрузки представляет собой идеальное количество практического времени разработки на одного разработчика в течение одной итерации, предполагающего 40-часовую неделю.

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

Планирование итерации - фаза управления

На этапе управления,

  • Разработчик получает карточку задачи для одной из задач, которые он или она совершили.

  • Разработчик выполнит эту задачу вместе с другим разработчиком, следуя практике парного программирования.

Реализация

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

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

Экстремальное программирование не является антидокументированием, но поощряет делать наименьшее количество, которое действительно необходимо. Документ при необходимости для распределенного обмена, исторических потребностей, подведения итогов и т. Д.

Основные артефакты экстремального программирования -

  • Пользовательские истории

  • Приемочные испытания

  • оценки

  • План выпуска

  • План итерации

  • Карты задач

  • дизайн

  • Модульные тесты

  • Записи общения с клиентами и разработчиками

Карты истории пользователя

Карты истории пользователя имеют следующие особенности:

  • Карта истории пользователя -

    • Содержит краткое описание поведения системы с точки зрения заказчика.

    • Должно быть написано заказчиком, а не разработчиками.

    • Использует терминологию заказчика без технических терминов.

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

  • Один для каждой основной функции в системе.

  • Используются для создания оценок времени для планирования выпуска.

  • Диск создания приемочных испытаний.

Приемочные испытания

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

Оценки - Планирование выпуска

Оценки усилий и продолжительности для историй, которые будут использоваться при планировании релизов -

  • Прибытие к целевой дате выпуска на этапе разведки.

  • План корректировки на этапе рулевого управления.

План выпуска

План выпуска содержит -

  • Пользовательские истории, выбранные для релиза.

  • Оценка усилий и продолжительности.

  • Целевая дата выпуска, которая зафиксирована.

Карты задач

Карта задач -

  • Содержит необходимые задачи для реализации пользовательской истории.

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

  • Формы основы для оценки задач и задач.

Оценки - планирование итераций

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

План итерации

План итерации содержит -

  • Пользовательские истории, выбранные для итерации

  • Назначение задач

  • Оценка заданий

дизайн

Дизайн содержит простой дизайн, достаточный для реализации пользовательской истории.

Модульные тесты

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

Отчеты о взаимодействии с клиентами и разработчиками

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