Источник изображения: pixabay.com

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

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

Вы, вероятно, скажете, Agile Project Management, конечно! Но какую методологию вы бы хотели использовать? Есть несколько вариантов: во-первых, есть чрезвычайно популярный Scrum: он включает в себя создание коротких «спринтов» на основе невыполненных клиентом задач. И еще, есть Канбан, который работает над оптимизацией конвейера работы. Существует также экстремальное программирование, часто сокращенное до XP, которое фокусируется на усилении положительных аспектов традиционных моделей программирования, чтобы они максимально использовали свой потенциал.

Экстремальное программирование - чрезвычайно популярная (хотя и не такая популярная, как Scrum) методология, ориентированная на удовлетворение меняющихся требований клиентов. Первый проект экстремального программирования был начат в марте 1996 года Кентом Беком в Chrysler. В своей книге 1999 года « Объяснение экстремального программирования: охватить изменения» он подробно описал аспекты разработки программного обеспечения.

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

Пять значений экстремального программирования на основе объясненного находятся:

связь

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

Простота

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

Обратная связь

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

Отзывы могут быть разными:

  • Из самой Программы: Код активно тестируется на протяжении всего цикла разработки проекта, поэтому разработчики могут вносить изменения.
  • От клиента: это неотъемлемая часть большинства гибких систем. Клиенты пишут приемочные тесты, на которых основана разработка, и это составляет основу процесса разработки. Все итерации также доставляются клиенту для периодической обратной связи.
  • От команды: Как только новый сценарий использования / история была создана, команда немедленно возвращается с оценкой затрат и сроков, уточняя требования по мере их возникновения. В экстремальном программировании ни один человек не «владеет» каким-либо кодом, и поэтому в командах экстремального программирования приветствуется обратная связь по коду друг друга.

бодрость

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

уважение

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

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

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

  • Кодирование : экстремальное программирование считает это самым важным видом деятельности. «Без кода нет ничего», - говорит Кент Бек, основатель Extreme Programming.
  • Тестирование : код только это, если не проверено. Экстремальное программирование навязчиво относится к тестированию, используя модульные тесты, чтобы подтвердить, что код работает, и сгенерированные клиентом приемочные тесты, чтобы подтвердить, что код тестирует то, что нужно тестировать.
  • Прослушивание: прослушивание, примером которого является основная ценность общения, - это деятельность, требующая от разработчиков не просто слышать клиентов, но и действительно слушать то, что они хотят. Разработка и бизнес - это две разные вещи, и часто разработчики не понимают бизнес-обоснование конкретного решения. Потребности заказчика, а также разработчиков, составляют основу деятельности «прослушивания».
  • Проектирование . Вас может удивить то, что в проекте разработки программного обеспечения проектирование, зачастую столь важное и первичное, ставится в конце. Это связано с тем, что экстремальное программирование намеренно хочет избавить людей от мышления «проектируй и развивай», которое индустрия вынашивает многие годы. Это не ограничивает важность проектирования. Скорее, хороший и минимальный дизайн является одной из отличительных черт проекта.

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

  • Планирование игры
  • Парное программирование
  • Разработка через тестирование
  • Вся команда
  • Непрерывная интеграция
  • Улучшение дизайна
  • Небольшие релизы
  • Стандарты кодирования
  • Коллективный код собственности
  • Простой дизайн
  • Системная метафора
  • Устойчивый темп

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

  1. Планирование игры

Это часть планирования проекта, называемая «Игра в планирование». Он включает в себя планирование следующей итерации и выпуска, по согласованию с пользователем / клиентом, а также внутреннее планирование команд относительно задач, над которыми они будут работать.

  1. Парное программирование

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

  1. Разработка через тестирование

Весь написанный код проверяется в единицах, т. Е. Каждый фрагмент кода, который может что-то делать, сначала проверяется. Экстремальное программирование уделяет большое внимание тестированию. Это помогает подтвердить, что код работает, и поэтому его можно рассматривать для включения в сам проект экстремального программирования. Это похоже на модульные тесты в школе: тестируются небольшие фрагменты информации, так что учитель / ученик может вносить исправления в курс и не колебаться во время ежегодных экзаменов!

  1. Улучшение дизайна (рефакторинг)

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

  1. Простой дизайн

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

  1. Системная метафора

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

Роли в рамках проекта экстремального программирования:

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

Роли экстремального программирования:

  • Заказчик : не требует пояснений. Причина проекта. Она решает, что нужно сделать проекту. Она предоставляет пользовательские истории.
  • Программист : Это человек, который:
    • Принимает истории, которые придумывает клиент
    • Создает задачи программирования из историй
    • Реализует пользовательские истории
    • Проверяет код на единицу
  • Тренер : Тренер обычно следит за тем, чтобы проект был на ходу, а также помогает, когда это необходимо.
  • Трекер : Трекер задает конкретные запросы программистам с заданным интервалом. Как правило, он проверяет прогресс программистов, предлагая помощь там, где это необходимо, несколькими способами: закатывая рукава и помогая непосредственно с кодом, сообщая Coach или назначая встречу с клиентом, в зависимости от необходимости.
  • Тестер : запускает функциональные тесты. Тестер не запускает модульные тесты, которые выполняются самими программистами.
  • Смертник: Это, как следует из названия, сродни Черной Шляпе в системе группового мышления Эдварда де Боно. Любой может быть Doomsayer, который обычно отмечает потенциальные проблемы и помогает держать проблемы в правильной перспективе.
  • Менеджер : Менеджер в проекте экстремального программирования больше похож на планировщик, гарантирующий, что встречи происходят, как запланировано, и гарантирующий, что решения, принятые во время встреч, передаются соответствующему человеку, чаще всего, Трекеру. Менеджер, однако, не говорит людям, что и когда делать. Это делается самими Заказчиком и / или Пользовательскими историями.
  • Владелец золота : Владелец золота - это человек, который финансирует проект. Это может быть клиент, но не обязательно так.

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

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

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

Недостатки экстремального программирования:

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

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

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

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

Категория:

Развитие предпринимательства