Из Википедии, бесплатной энциклопедии
  (Перенаправлено из игры "Планирование" )
Перейти к навигации Перейти к поиску

Экстремальное программирование ( XP ) - это гибкая методология разработки программного обеспечения, используемая для реализации программных проектов. В этой статье подробно описаны практики, используемые в этой методологии. Экстремальное программирование включает 12 практик, сгруппированных в четыре области, основанных на лучших практиках разработки программного обеспечения . [1]

Обратная связь с мелким масштабом [ править ]

Парное программирование [ править ]

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

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

Планирование игры [ править ]

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

  • Планирование релизов : это сосредоточено на определении того, какие требования включены в какие краткосрочные релизы и когда они должны быть выполнены. И заказчики, и разработчики являются частью этого. Планирование выпуска состоит из трех этапов:
    • Этап исследования: на этом этапе заказчик предоставляет краткий список важных требований к системе. Они будут записаны на карточках пользовательских историй .
    • Фаза принятия обязательств: на этапе принятия обязательств бизнес и разработчики обязуются выполнять функции, которые будут включены, и указать дату следующего выпуска.
    • Этап управления: на этапе управления план может быть скорректирован, могут быть добавлены новые требования и / или существующие требования могут быть изменены или удалены.
  • Планирование итераций : это планирование действий и задач разработчиков. Заказчик в этом процессе не участвует. Планирование итерации также состоит из трех этапов:
    • Этап исследования: на этом этапе требования будут переведены на различные задачи. Задания записываются в карточки заданий.
    • Фаза принятия обязательств: задачи будут назначены программистам, и время, необходимое для их выполнения, будет оценено.
    • Фаза управления: задачи выполняются, и конечный результат сопоставляется с исходной пользовательской историей.

Цель игры в планирование - привести продукт к доставке. Вместо того, чтобы предсказывать точные даты, когда результаты будут необходимы и произведены, что сложно сделать, он стремится «направить проект» к реализации, используя простой подход. [2] Подход «Игра в планирование» также был принят непрограммными проектами и командами в контексте гибкости бизнеса . [3]

Планирование выпуска [ править ]

Фаза исследования [ править ]

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

  • Напишите историю: у бизнеса возникла проблема; во время встречи разработчик попытается определить эту проблему и получить требования. Исходя из бизнес-задачи, нужно написать историю ( пользовательскую историю ). Это делается бизнесом, когда они указывают, что они хотят от части системы. Важно, чтобы развитие никак не повлияло на эту историю. История написана на карточке пользовательской истории.
  • Оценить историю: разработка оценивает, сколько времени потребуется для выполнения работы, подразумеваемой карточкой истории. Разработка также может создавать пиковые решения для анализа или решения проблемы. Эти решения используются для оценки и отбрасываются, когда каждый получает четкое представление о проблеме. Опять же, это может не повлиять на бизнес-требования.
  • Разделите историю: каждая критическая сложность дизайна должна быть рассмотрена до начала планирования итераций. Если разработчик не может оценить историю, ее нужно разделить и написать заново.

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

Фаза обязательства [ править ]

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

  • Сортировка по ценности: бизнес сортирует пользовательские истории по ценности для бизнеса .
  • Сортировать по риску: разработка сортирует истории по риску.
  • Установить скорость: разработка определяет, с какой скоростью они могут выполнять проект.
  • Выберите объем: будут выбраны пользовательские истории, которые будут завершены в следующем выпуске. На основании пользовательских историй определяется дата релиза.
Сортировать по значению [ редактировать ]

Деловая сторона сортирует пользовательские истории по ценности для бизнеса. Они сложат их в три стопки:

  • Критично: истории, без которых система не может функционировать или не имеет смысла.
  • Существенная ценность для бизнеса : некритические пользовательские истории, имеющие значительную ценность для бизнеса.
  • Приятно иметь: пользовательские истории, не имеющие особой ценности для бизнеса.
Сортировать по риску [ править ]

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

  • Определите индекс риска: дайте каждой пользовательской истории индекс от 0 до 2 по каждому из следующих факторов:
    • Полнота (знаем ли мы все подробности истории?)
      • Завершено (0)
      • Незавершенный (1)
      • Неизвестно (2)
    • Волатильность (может ли она измениться?)
      • низкий (0)
      • средний (1)
      • высокий (2)
    • Сложность (насколько сложно построить?)
      • простой (0)
      • стандарт (1)
      • сложный (2)

Добавляются все индексы для пользовательской истории, присваивая пользовательским историям индекс риска: низкий (0–1), средний (2–4) или высокий (5–6).

Фаза управления [ править ]

На этапе управления программисты и бизнесмены могут «управлять» процессом. То есть они могут вносить изменения. Индивидуальные пользовательские истории или относительные приоритеты разных пользовательских историй могут измениться; оценки могут оказаться неверными. Это шанс соответствующим образом скорректировать план.

Планирование итераций [ править ]

Рассмотрение моментов, когда нужно спланировать скорость работы команды. Продолжительность итерации может составлять от 1 до 3 недель.

Фаза исследования [ править ]

Фаза исследования итерационного планирования заключается в создании задач и оценке времени их выполнения.

  • Переведите требование в задачи: разместите на карточках задач.
  • Объединить / разделить задачу: если программист не может оценить задачу, потому что она слишком мала или слишком велика, программисту нужно будет объединить или разделить задачу.
  • Оценить задачу: Оценить время, необходимое для выполнения задачи.
Фаза обязательства [ править ]

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

  • Программист принимает задачу: каждый программист выбирает задачу, за которую он берет на себя ответственность.
  • Программист оценивает задачу: поскольку теперь за задачу отвечает программист, он или она должны дать окончательную оценку задачи.
  • Установите коэффициент загрузки: коэффициент загрузки представляет собой идеальное время практической разработки на одного программиста в пределах одной итерации. Например, в 40-часовой рабочей неделе, когда 5 часов посвящены собраниям, это будет не более 35 часов.
  • Балансировка: когда всем программистам в команде были назначены задачи, выполняется сравнение между расчетным временем выполнения задач и коэффициентом загрузки. Затем задачи распределяются между программистами. Если программист перегружен, другие программисты должны взять на себя некоторые из его или ее задач, и наоборот.
Фаза управления [ править ]

Реализация задач выполняется на этапе управления итерацией.

  • Получите карточку задачи: программист получает карточку задачи для одной из задач, которые он или она взяли на себя.
  • Найдите партнера: программист выполнит эту задачу вместе с другим программистом. Более подробно это обсуждается в разделе «Практическое парное программирование» .
  • Разработайте задачу: при необходимости программисты разработают функциональность задачи.
  • Реализуйте задачу с помощью разработки через тестирование (TDD) (см. Ниже)
  • Запустить функциональный тест: запускаются функциональные тесты (основанные на требованиях в соответствующей пользовательской истории и карточке задачи).

Разработка через тестирование [ править ]

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

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

  • Написание модульного теста : программисты пишут минимальный тест, который должен завершиться неудачно, потому что функциональность не была полностью реализована в производственном коде.
  • Посмотрите, как новый тест не проходит: программисты проверяют, что тест действительно не прошел. Хотя это может показаться пустой тратой времени, этот шаг имеет решающее значение, поскольку он подтверждает правильность вашего мнения о состоянии производственного кода. Если тест не завершился неудачно, программисты должны определить, есть ли ошибка в тестовом коде или что производственный код поддерживает функциональные возможности, описанные в новом тесте.
  • Напишите код: программисты пишут достаточно производственного кода, чтобы новый тест прошел.
  • Выполнить тест: модульные тесты выполняются для проверки того, что новый производственный код проходит новый тест и что никакие другие тесты не завершаются с ошибкой.
  • Рефакторинг : Удалите любые запахи кода как из производственного, так и из тестового кода.

Для более интенсивной версии описанного выше процесса см. Три правила TDD дяди Боба. [4]

Вся команда [ править ]

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

Непрерывный процесс [ править ]

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

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

Улучшение дизайна [ править ]

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

Небольшие релизы [ править ]

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

Общее понимание [ править ]

Стандарт кодирования [ править ]

Стандарт кодирования - это согласованный набор правил, которых вся команда разработчиков соглашается придерживаться на протяжении всего проекта. Стандарт определяет согласованный стиль и формат исходного кода в рамках выбранного языка программирования, а также различные программные конструкции и шаблоны, которых следует избегать, чтобы снизить вероятность дефектов. [5] Стандарт кодирования может быть стандартным соглашением, указанным поставщиком языка (например, соглашением о коде для языка программирования Java, рекомендованным Sun), или индивидуальным соглашением, определенным группой разработчиков.

Сторонники экстремального программирования выступают за код, который максимально самодокументируется . Это снижает потребность в комментариях к коду , которые могут не синхронизироваться с самим кодом. [6]

Коллективное владение кодом [ править ]

Коллективное владение кодом (также известное как «владение командным кодом» и «общий код») означает, что каждый несет ответственность за весь код; следовательно, всем разрешено изменять любую часть кода. Коллективное владение кодом - это не только политика организации, но и чувство. «Разработчики больше ощущают владение командным кодом, когда они понимают контекст системы, внесли свой вклад в рассматриваемый код, воспринимают качество кода как высокое, верят, что продукт удовлетворит потребности пользователей, и ощущают высокую сплоченность команды». [7] Парное программирование, особенно чередование пар с перекрытием, вносит свой вклад в эту практику: работая в разных парах, программисты лучше понимают контекст системы и вносят свой вклад в большее количество областей кодовой базы.

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

Коллективное владение кодом может привести к лучшему резервному копированию участников, более широкому распространению знаний и обучения, совместной ответственности за код, повышению качества кода и уменьшению количества доработок. Но это также может привести к усилению конфликтов между участниками, увеличению количества ошибок, изменению мыслей разработчиков и сбоям в их рассуждениях, увеличению времени разработки или меньшему пониманию кода. [8]

Простой дизайн [ править ]

Программисты должны придерживаться подхода «простое лучше всего» к разработке программного обеспечения. Каждый раз, когда пишется новый фрагмент кода, автор должен спросить себя: «Есть ли более простой способ реализовать ту же функциональность?». Если "да", следует выбрать более простой курс. Для упрощения сложного кода также следует использовать рефакторинг.

Системная метафора [ править ]

Системная метафора - это история, которую каждый - заказчики, программисты и менеджеры - может рассказать о том, как работает система. Это концепция именования классов и методов, которая должна помочь члену команды угадать функциональность конкретного класса / метода только по его имени. Например, библиотечная система может создать loan_records(class)для borrowers(class), а если элемент просрочен, она может выполнить операцию make_overdue для файла catalogue(class). Функциональность каждого класса или операции очевидна для всей команды.

Благополучие программистов [ править ]

Устойчивый темп [ править ]

Идея состоит в том, что программисты или разработчики программного обеспечения не должны работать более 40 часов в неделю, а если в одну неделю есть сверхурочные, то следующая неделя не должна включать больше сверхурочных. Так как циклы разработки - это короткие циклы непрерывной интеграции, а полные циклы разработки (выпуска) встречаются чаще, проекты в XP не выдерживают типичного времени обработки, которое требуется для других проектов (требующих сверхурочных).

Кроме того, в эту концепцию входит то, что люди работают лучше и креативнее, если они хорошо отдохнули.

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

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

См. Также [ править ]

  • Экстремальное программирование
  • Непрерывная интеграция
  • Многоступенчатая непрерывная интеграция
  • Карточка коллективной ответственности-сотрудничества

Ссылки [ править ]

  1. ^ Бек, К. Объяснение экстремального программирования: примите изменения, 2-е. изд. Эддисон-Уэсли, 2000, с. 54
  2. ^ Мельник, Григорий; Маурер, Франк (2004). Введение в гибкие методы: трехлетний опыт . Материалы 30-й конференции Euromicro. IEEE. С. 334–341. CiteSeerX  10.1.1.296.4732 . DOI : 10.1109 / EURMIC.2004.1333388 .
  3. ^ Leybourn, E. (2013). Направление гибкой организации: бережливый подход к управлению бизнесом. Лондон: Издательство по управлению информационными технологиями: 146–150.
  4. ^ Мартин, Роберт. «Три правила TDD» .
  5. ^ Колава, Адам; Хейзинга, Дорота (2007). Автоматическое предотвращение дефектов: передовой опыт управления программным обеспечением . Пресса компьютерного общества Wiley-IEEE. п. 75. ISBN 978-0-470-04212-0.
  6. ^ http://guzdial.cc.gatech.edu/squeakbook/new-lecture-slides/xp.ppt
  7. ^ Седано, Тодд; Ральф, Пол; Перэр, Сесиль. «Практика и восприятие владения командным кодом» . ACM.
  8. ↑ Рибейро, Данило и Сильва, Фабио и Валенса, Диана и Фрейтас, Элида и Франса, Сезар. (2016). Преимущества и недостатки использования общего кода с точки зрения разработчиков: качественное исследование.

Внешние ссылки [ править ]

  • Практика XP
  • Кент Бек Практика XP
  • Рон Джеффрис XP практики