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

Экстремальное программирование ( 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 не соответствуют типичному критическому времени, которое требуется другим проектам (требующим сверхурочной работы).

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

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

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

См. также

Ссылки

^ Бек, К. Объяснение экстремального программирования: примите изменения, 2-е место. ред. Аддисон-Уэсли, 2000, стр. 54.
^ Мельник, Григорий; Маурер, Франк (2004). «Внедрение гибких методов: трехлетний опыт». Слушания. 30-я конференция Евромикро, 2004 г. Материалы 30-й Евромикро конференции. IEEE. стр. 334–341. CiteSeerX 10.1.1.296.4732 . дои : 10.1109/EURMIC.2004.1333388 . ISBN 0-7695-2199-1 .
^ Лейборн, Э. (2013). Управление гибкой организацией: бережливый подход к управлению бизнесом. Лондон: Издательство IT Governance: 146–150.
^ Мартин, Роберт. «Три правила TDD» .
^ Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: лучшие практики управления программным обеспечением . Издательство компьютерного общества Wiley-IEEE. п. 75. ИСБН 978-0-470-04212-0 .
^ «Программирование XP-eXtreme» . Архивировано из оригинала (PPT) 17 декабря 2021 г. Проверено 31 января 2015 г.
^ Седано, Тодд; Ральф, Пол; Перайр, Сесиль (2016). «Практика и восприятие владения командным кодом» . Материалы 20-й Международной конференции по оценке и оцениванию в программной инженерии . АКМ. стр. 1–6. дои : 10.1145/2915970.2916002 . ISBN 9781450336918 . S2CID 10016345 .
^ Рибейро, Данило и Сильва, Фабио и Валенса, Диана и Фрейтас, Элида и Франса, Сезар. (2016). Преимущества и недостатки использования общего кода с точки зрения разработчика: качественное исследование.

Внешние ссылки

[XPExplained-1] Бек, К. Объяснение экстремального программирования: примите изменения, 2-е место. ред. Аддисон-Уэсли, 2000, стр. 54.

[2] Мельник, Григорий; Маурер, Франк (2004). «Внедрение гибких методов: трехлетний опыт». Слушания. 30-я конференция Евромикро, 2004 г. Материалы 30-й Евромикро конференции. IEEE. стр. 334–341. CiteSeerX 10.1.1.296.4732 . дои : 10.1109/EURMIC.2004.1333388 . ISBN 0-7695-2199-1 .

[3] Лейборн, Э. (2013). Управление гибкой организацией: бережливый подход к управлению бизнесом. Лондон: Издательство IT Governance: 146–150.

[4] Мартин, Роберт. «Три правила TDD» .

[5] Колава, Адам; Хейзинга, Дорота (2007). Автоматизированное предотвращение дефектов: лучшие практики управления программным обеспечением . Издательство компьютерного общества Wiley-IEEE. п. 75. ИСБН 978-0-470-04212-0 .

[6] «Программирование XP-eXtreme» . Архивировано из оригинала (PPT) 17 декабря 2021 г. Проверено 31 января 2015 г.

[7] Седано, Тодд; Ральф, Пол; Перайр, Сесиль (2016). «Практика и восприятие владения командным кодом» . Материалы 20-й Международной конференции по оценке и оцениванию в программной инженерии . АКМ. стр. 1–6. дои : 10.1145/2915970.2916002 . ISBN 9781450336918 . S2CID 10016345 .

[8] Рибейро, Данило и Сильва, Фабио и Валенса, Диана и Фрейтас, Элида и Франса, Сезар. (2016). Преимущества и недостатки использования общего кода с точки зрения разработчика: качественное исследование.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]