Разработчики собирают требования и оценивают влияние работы каждого из этих требований. В парном программировании вы слушаете, чтобы знать, что кодировать или что тестировать. В парном программировании кодирование считается сердцем разработки.
Ведь экстремальное программирование — коллективная игра, рассчитанная не на индивидуумов, а на всю группу целиком. А такая вещь, как, например, парное программирование, возможна лишь при синхронизации биоритмов ее участников. И она невозможна, если один человек будет приходить на работу к девяти, а второй к двенадцати или один решит, что ему лучше поработать в субботу и воскресенье, а другому это неудобно. Каждая пара разработчиков должна отдавать свой код, как только для этого появляется разумная возможность.
Парное программирование – поддержка других практик XP
Кроме того, заказчик может быть не заинтересован или не способен участвовать в процессе в той степени, в которой этого требует XP. Менеджер — это связующее звено между разработчиками и клиентами. Люди в этой роли сводят вместе заказчиков и разработчиков и модерируют встречи, такие как Игра по планированию.
- Экстремальное программирование само по себе не подходит для реализации.
- Это дает предварительное представление о поведении продукта всем в команде, а также помогает в достижении критериев приемлемости в начале самого спринта.
- Позволит скорее использовать программный продукт без дополнительных затрат и усилий по коррекции, доработке.
- Это гарантия того, что изменяемый объект не будет одновременно доступен двум потокам.
- Да и с медицинской точки зрения, задержки на работе ведут к постоянной усталости, раздражительности и снижению мозговой деятельности.
Это позволит быстрее выявить ошибки, ускорить отладку приложения. Суть — по-максимуму использовать имеющиеся ресурсы, оптимизировать процессы, чтобы затратить как можно меньше усилий. Благодаря подходу есть шанс обойтись малыми кадрами, грамотно распределив задачи между программистами команды. За счет оптимизации рабочего процесса разработчики могут выполнить проект с опережением сроков или успеть вовремя без ущерба качеству конечного программного продукта.
История[править | править код]
Чтобы программисты одинаково понимали результат, который должны получить, используется метафора. Систему сравнивают с чем-то, что понятно и знакомо всем в команде. Начните проект с минимально необходимыми правилами экстремального программирования для проекта. Для каждого проекта итерации и истории могут быть добавлены как клиентами, так и сотрудниками. Этот инструмент может использоваться разработчиками, тестировщиками и бизнес-пользователями для создания приемочных тестов.
Балансировка нагрузки выполняется после того, как всем разработчикам в команде были назначены задачи. Разработчики оценивают время, которое потребуется для реализации каждой задачи. В Планировании итерации разработчики участвуют в планировании действий и задач для итерации. Влияние на существующую систему, если какое-либо из существующих требований будет удалено. Какие изменения необходимо внести в существующие требования. Вносить изменения в отдельные пользовательские истории и относительные приоритеты различных пользовательских историй.
Экстремальное программирование в двух словах
В экстремальном программировании заказчик всегда доступен для вопросов, с ним обсуждают код, возможности алгоритмов и функции программы. Любой разработчик может позвонить заказчику в любой момент, чтобы что-нибудь уточнить. Как и у каждого фреймворка, в экстремальном программировании есть свои ценности, практики, принципы работы, роли. После выполнения каждой задачи специалисты проводят ревизию написанного кода.
Следовательно, периодически делайте перерыв, чтобы сохранить выносливость для следующего раунда продуктивного парного программирования. Никогда не включайте какую-либо самостоятельную работу без обзора со стороны партнера. Для благоприятного обмена идеями, при необходимости, должны быть некоторые здоровые разногласия / дебаты. Вы можете устранить эти дефекты без естественной вражды, которая может развиться на официальном совещании инспекторов. Вы должны быть уверены, что выражаете то, что знаете, и открыты, чтобы учиться у своего партнера, когда это необходимо. Они периодически меняют эти роли, даже если одна из них значительно опытнее другой, чтобы обеспечить равное участие.
Планирование релиза – Фаза обязательств
С хорошими модульными тестами вы можете легко реорганизовать свой код для проведения дополнительных тестов. Следовательно, в экстремальном программировании базовые принципы основаны на ценностях, так что методы разработки могут быть проверены на соответствие этим принципам. Модульные тесты сообщают разработчикам о состоянии системы. Ценность обратной связи – это постоянно работающая система, которая предоставляет информацию о себе надежным способом.
Не стоит и пытаться реализовать то, что не было запланировано. У вас еще будет время, чтобы реализовать эти идеи, когда до них дойдет очередь согласно плану релизов. Метафора системы даёт команде представление о том, каким образом система экстремальное программирование работает в настоящее время, в каких местах добавляются новые компоненты, и какую форму они должны принять. Задачи записывают на карточки, выясняют у заказчика последовательность, в которой он хочет получать функционал продукта.
Тестирование с другими практиками XP
Части кода и функции будущего продукта наращивают постепенно, как снежный ком. После каждого релиза команда собирает обратную связь, чтобы двигаться дальше. В экстремальном программировании команды разработчиков работают в чрезвычайно коротких циклах.
Команда разработчиков была сокращена, и в течение примерно полугода после этого проект развивался довольно успешно. В августе 1998 года появился прототип, который мог обслуживать около служащих. Первоначально предполагалось, что проект завершится в середине 1999 года и результирующее ПО будет использоваться для управления выплатами служащим компании. Он был остановлен в феврале 2000 года после 4-х лет работы по XP в связи с полным несоблюдением временных рамок и бюджета.