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

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

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

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

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

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

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

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

кодирование

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

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

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

кодирование

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

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

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

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

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

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

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

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

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

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

• Реализация

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

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

Реализация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Планирование выпуска — фаза управления

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы понять —

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

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

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

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

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

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

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

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

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

Планирование итерации имеет три этапа —

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Планирование итерации — этап управления

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

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

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

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

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

Реализация

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

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

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

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

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

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

• оценки

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

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

• Карты задач

• дизайн

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

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

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

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

оценки

План выпуска

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

Карты задач

дизайн

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

План выпуска

План релиза содержит —

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

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

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

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

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

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

Карты задач

Карта задач —

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

дизайн

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

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

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

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

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