Экстремальное программирование: Экстремальная разработка программного обеспечения

В наши дни существует множество различных ответвлений гибкой разработки программного обеспечения. Помимо scrum и kanban, экстремальное программирование — еще один метод, который постоянно обсуждается и внедряется. Что же делает этот подход к разработке настолько экстремальным?

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

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

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

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

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

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

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

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

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

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

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

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

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

• Вам это не понадобится (YAGNI): чтобы избежать ненужной работы, программисты не должны добавлять функциональность, если она специально не запрашивается.
• Не повторяйтесь (DRY): Следует избегать избыточности и разрабатывать код таким образом, чтобы изменение нужно было сделать только один раз, а не в нескольких местах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Благополучие команды важно для успеха проекта: Члены команды должны быть хорошо отдохнувшими и мотивированными для выполнения высококачественной работы. Чтобы обеспечить это, экстремальное программирование предписывает 40-часовую рабочую неделю. Сверхурочная работа должна быть исключена любой ценой и допускается только в том случае, если следующая неделя не включает в себя никаких сверхурочных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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