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

В этой главе дается обзор экстремального программирования.

Что такое Agile?

Слово «проворный» означает —

• Способен двигать своим телом быстро и легко.

• Умеет думать быстро и четко.

Способен двигать своим телом быстро и легко.

Умеет думать быстро и четко.

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

Ссылка: кембриджские словари онлайн.

В разработке программного обеспечения термин «гибкий» адаптирован для обозначения «способности реагировать на изменения — изменения в требованиях, технологиях и людях».

Agile Manifesto

Команда разработчиков программного обеспечения опубликовала Agile Manifesto в 2001 году, подчеркивая важность команды разработчиков, учитывая изменяющиеся требования и участие клиентов.

Agile Manifesto утверждает, что —

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

• Люди и взаимодействия по процессам и инструментам.

• Рабочая программа над исчерпывающей документацией.

• Сотрудничество с заказчиком по договору.

• Реагировать на изменения в соответствии с планом.

Люди и взаимодействия по процессам и инструментам.

Рабочая программа над исчерпывающей документацией.

Сотрудничество с заказчиком по договору.

Реагировать на изменения в соответствии с планом.

То есть, хотя в элементах справа есть ценность, мы слева оцениваем элементы больше.

Характеристики ловкости

Ниже приведены характеристики ловкости —

• Гибкость в Agile Software Development ориентирована на культуру всей команды с многопрофильными, многофункциональными командами, которые наделены полномочиями и самоорганизуются.

• Это способствует совместной ответственности и подотчетности.

• Облегчает эффективное общение и постоянное сотрудничество.

• Подход всей команды позволяет избежать задержек и времени ожидания.

• Частые и постоянные поставки обеспечивают быструю обратную связь, что, в свою очередь, позволяет команде соответствовать требованиям.

• Совместная работа способствует своевременному внедрению различных точек зрения, исправлению дефектов и внесению изменений.

• Прогресс постоянен, устойчив и предсказуем, подчеркивая прозрачность.

Гибкость в Agile Software Development ориентирована на культуру всей команды с многопрофильными, многофункциональными командами, которые наделены полномочиями и самоорганизуются.

Это способствует совместной ответственности и подотчетности.

Облегчает эффективное общение и постоянное сотрудничество.

Подход всей команды позволяет избежать задержек и времени ожидания.

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

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

Прогресс постоянен, устойчив и предсказуем, подчеркивая прозрачность.

Тенденции разработки программного обеспечения

Следующие тенденции наблюдаются в разработке программного обеспечения —

• Соберите требования до начала разработки. Однако, если требования будут изменены позже, обычно отмечается следующее:

  • Сопротивление изменениям на более поздней стадии развития.

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

  • Доставка товара с устаревшими требованиями, не отвечающими ожиданиям клиента.

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

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

  • Тестирование начинается только после того, как кодирование завершено, и тестирование считается обязанностью тестировщика, хотя тестер не участвует в разработке.

  • Измеряйте и отслеживайте сам процесс. Это становится дорогим из-за —

  • Мониторинг и отслеживание на уровне задач и на уровне ресурсов.

  • Определение измерений для руководства разработкой и измерение каждой деятельности в разработке.

  • Управленческое вмешательство.

• Разрабатывайте, анализируйте и проверяйте модели перед разработкой.

  • Модель должна быть использована в качестве основы. Однако сосредоточение внимания на модели, а не на разработке, которая имеет решающее значение, не даст ожидаемых результатов.

• Кодированию, которое является сердцем развития, не уделяется достаточного внимания. Причины, являющиеся —

  • Разработчики, которые отвечают за производство, обычно не поддерживают постоянную связь с заказчиками.

  • Кодирование рассматривается как перевод дизайна, и эффективная реализация кода практически никогда не возвращается в дизайн.

• Тестирование считается шлюзом для проверки дефектов перед доставкой.

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

  • Это приводит к перерасходу средств на устранение дефектов после доставки.

  • Тестеры несут ответственность и отвечают за качество продукции, хотя они не участвовали в течение всего процесса разработки.

• Ограничение ресурсов (в основном команды) для размещения бюджета приводит к —

  • Ресурс перераспределен

  • Командное выгорание.

  • Потеря в эффективном использовании командных компетенций.

  • Истощение.

Соберите требования до начала разработки. Однако, если требования будут изменены позже, обычно отмечается следующее:

Сопротивление изменениям на более поздней стадии развития.

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

Доставка товара с устаревшими требованиями, не отвечающими ожиданиям клиента.

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

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

Тестирование начинается только после того, как кодирование завершено, и тестирование считается обязанностью тестировщика, хотя тестер не участвует в разработке.

Измеряйте и отслеживайте сам процесс. Это становится дорогим из-за —

Мониторинг и отслеживание на уровне задач и на уровне ресурсов.

Определение измерений для руководства разработкой и измерение каждой деятельности в разработке.

Управленческое вмешательство.

Разрабатывайте, анализируйте и проверяйте модели перед разработкой.

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

Кодированию, которое является сердцем развития, не уделяется достаточного внимания. Причины, являющиеся —

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

Кодирование рассматривается как перевод дизайна, и эффективная реализация кода практически никогда не возвращается в дизайн.

Тестирование считается шлюзом для проверки дефектов перед доставкой.

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

Это приводит к перерасходу средств на устранение дефектов после доставки.

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

Ограничение ресурсов (в основном команды) для размещения бюджета приводит к —

Ресурс перераспределен

Командное выгорание.

Потеря в эффективном использовании командных компетенций.

Истощение.

Экстремальное программирование — способ справиться с общими недостатками

Разработка программного обеспечения включает в себя —

• Творческий подход

• Обучение и совершенствование через испытания и ошибки

• Итерации

Творческий подход

Обучение и совершенствование через испытания и ошибки

Итерации

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

Экстремальное программирование основано на следующих значениях —

• связь

• Простота

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

• бодрость

• уважение

связь

Простота

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

бодрость

уважение

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

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

E x treme P rogramming (XP) была задумана и разработана для удовлетворения особых потребностей разработчиков программного обеспечения небольшими группами перед лицом неопределенных и меняющихся требований.

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

• Каждая практика проста и самодостаточна.

• Сочетание практик приводит к более сложному и возникающему поведению.

Каждая практика проста и самодостаточна.

Сочетание практик приводит к более сложному и возникающему поведению.

Принять изменения

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

Это может быть достигнуто с —

• Акцент на постоянную обратную связь с клиентом

• Короткие итерации

• Дизайн и редизайн

• Кодирование и тестирование часто

• Устранение дефектов на ранней стадии, что снижает затраты

• Вовлечение клиента в процесс разработки

• Доставка работающего продукта клиенту

Акцент на постоянную обратную связь с клиентом

Короткие итерации

Дизайн и редизайн

Кодирование и тестирование часто

Устранение дефектов на ранней стадии, что снижает затраты

Вовлечение клиента в процесс разработки

Доставка работающего продукта клиенту

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

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

• Написание модульных тестов перед программированием и постоянное выполнение всех тестов. Модульные тесты автоматизированы и устраняют дефекты на ранней стадии, тем самым снижая затраты.

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

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

• Интеграция и тестирование всей системы несколько раз в день.

• Быстрое внедрение минимальной рабочей системы в производство и ее обновление при необходимости.

• Постоянное вовлечение клиента и постоянная обратная связь.

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

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

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

Интеграция и тестирование всей системы несколько раз в день.

Быстрое внедрение минимальной рабочей системы в производство и ее обновление при необходимости.

Постоянное вовлечение клиента и постоянная обратная связь.

Итерации облегчают адаптационные изменения по мере развития программного обеспечения в соответствии с меняющимися требованиями.

Почему это называется «Экстрим»?

Экстремальное программирование выводит эффективные принципы и практики на экстремальные уровни.

• Проверка кода эффективна, так как код проверяется постоянно.

• Тестирование является эффективным, поскольку существует постоянная регрессия и тестирование.

• Дизайн эффективен, так как каждый должен делать рефакторинг ежедневно.

• Интеграционное тестирование важно, так как интегрируйте и тестируйте несколько раз в день.

• Короткие итерации эффективны как игра планирования для планирования выпуска и итерационного планирования.

Проверка кода эффективна, так как код проверяется постоянно.

Тестирование является эффективным, поскольку существует постоянная регрессия и тестирование.

Дизайн эффективен, так как каждый должен делать рефакторинг ежедневно.

Интеграционное тестирование важно, так как интегрируйте и тестируйте несколько раз в день.

Короткие итерации эффективны как игра планирования для планирования выпуска и итерационного планирования.

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

Кент Бек, Уорд Каннингем и Рон Джеффрис сформулировали экстремальное программирование в 1999 году. Другими участниками являются Роберт Мартин и Мартин Фаулер.

В середине 80-х Кент Бек и Уорд Каннингем инициировали парное программирование в Tektronix. В 80-х и 90-х годах компания Smalltalk Culture произвела рефакторинг, непрерывную интеграцию, постоянное тестирование и активное участие клиентов. Эта культура была позже распространена на другие среды.

В начале 90-х годов основные ценности были разработаны в рамках сообщества Patterns, Hillside Group. В 1995 году Кент суммировал их в Besttalk Best Practices, а в 1996 году Уорд суммировал их в эпизодах.

В 1996 году Кент добавил юнит-тестирование и метафору в Хьюитт. В 1996 году Кент принял проект Chrysler C3, к которому в качестве тренера был добавлен Рон Джеффрис. Практики были доработаны на C3 и опубликованы в Wiki.

Скрам-практики были включены и адаптированы как планирование игры. В 1999 году Кент опубликовал свою книгу «Объяснение экстремального программирования». В том же году Фаулер опубликовал свою книгу «Рефакторинг».

Экстремальное программирование развивается с тех пор, и развитие продолжается до сегодняшнего дня.

Успех в промышленности

Успех проектов, которые следуют практикам экстремального программирования, обусловлен —

• Быстрое развитие.

• Немедленное реагирование на меняющиеся требования клиента.

• Фокус на низких показателях брака.

• Система, возвращающая постоянное и постоянное значение клиенту.

• Высокая удовлетворенность клиентов.

• Снижение затрат.

• Сплоченность команды и удовлетворенность сотрудников.

Быстрое развитие.

Немедленное реагирование на меняющиеся требования клиента.

Фокус на низких показателях брака.

Система, возвращающая постоянное и постоянное значение клиенту.

Высокая удовлетворенность клиентов.

Снижение затрат.

Сплоченность команды и удовлетворенность сотрудников.

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

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

• Сдвинутые графики — и достижимые циклы разработки гарантируют своевременные поставки.

• Отмененные проекты — ориентация на постоянное участие клиентов обеспечивает прозрачность работы с клиентами и немедленное решение любых вопросов.

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

• Дефекты производства и после доставки: акцент сделан — модульные тесты для раннего выявления и устранения дефектов.

• Неправильное понимание бизнеса и / или предметной области — Включение клиента в команду гарантирует постоянное общение и разъяснения.

• Изменения в бизнесе — Изменения считаются неизбежными и принимаются в любой момент времени.

• Текучесть кадров — Интенсивное командное сотрудничество обеспечивает энтузиазм и добрую волю. Сплоченность многопрофильных дисциплин способствует развитию командного духа.

Сдвинутые графики — и достижимые циклы разработки гарантируют своевременные поставки.

Отмененные проекты — ориентация на постоянное участие клиентов обеспечивает прозрачность работы с клиентами и немедленное решение любых вопросов.

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

Дефекты производства и после доставки: акцент сделан — модульные тесты для раннего выявления и устранения дефектов.

Неправильное понимание бизнеса и / или предметной области — Включение клиента в команду гарантирует постоянное общение и разъяснения.

Изменения в бизнесе — Изменения считаются неизбежными и принимаются в любой момент времени.

Текучесть кадров — Интенсивное командное сотрудничество обеспечивает энтузиазм и добрую волю. Сплоченность многопрофильных дисциплин способствует развитию командного духа.

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

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

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

Экстремальное программирование (XP) основано на пяти значениях —

• связь

• Простота

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

• бодрость

• уважение

связь

Простота

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

бодрость

уважение

связь

Коммуникация играет важную роль в успехе проекта. Проблемы с проектами часто возникают из-за отсутствия связи. Многие обстоятельства могут привести к сбою в общении. Некоторые из общих проблем —

• Разработчик не может сказать кому-либо еще о критических изменениях в дизайне.

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

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

• Разработчик может игнорировать что-то важное, переданное клиентом.

Разработчик не может сказать кому-либо еще о критических изменениях в дизайне.

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

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

Разработчик может игнорировать что-то важное, переданное клиентом.

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

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

Простота

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

• Делай то, что нужно и просишь, но не более.

  • «Делай самое простое, что могло бы сработать». Принцип DTSTTCPW.

  • Реализуйте новые возможности самым простым способом. Также известный как принцип KISS «Делай это просто, глупый!».

  • Тренер может сказать DTSTTCPW, когда видит, как разработчик экстремального программирования делает что-то излишне сложное.

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

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

• Создайте то, чем вы гордитесь, и поддерживайте это в течение длительного срока за разумные деньги.

• Никогда не применяйте функцию, которая вам не нужна сейчас, то есть принцип «Вы не будете нуждаться в этом» (YAGNI).

Делай то, что нужно и просишь, но не более.

«Делай самое простое, что могло бы сработать». Принцип DTSTTCPW.

Реализуйте новые возможности самым простым способом. Также известный как принцип KISS «Делай это просто, глупый!».

Тренер может сказать DTSTTCPW, когда видит, как разработчик экстремального программирования делает что-то излишне сложное.

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

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

Создайте то, чем вы гордитесь, и поддерживайте это в течение длительного срока за разумные деньги.

Никогда не применяйте функцию, которая вам не нужна сейчас, то есть принцип «Вы не будете нуждаться в этом» (YAGNI).

Общение и простота поддерживают друг друга.

Чем больше вы общаетесь, тем яснее вы видите, что именно нужно сделать, и вы получаете больше уверенности в том, что действительно не нужно делать.

Чем проще ваша система, тем меньше вам приходится сообщать о меньшем количестве разработчиков, которые вам требуются. Это приводит к лучшему общению.

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

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

В экстремальном программировании обратная связь обеспечивается на всех уровнях в разных временных масштабах —

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

• Модульные тесты сообщают разработчикам о состоянии системы.

• Система и код обеспечивают обратную связь о состоянии разработки для руководителей, заинтересованных сторон и клиентов.

• Частые выпуски позволяют заказчику выполнять приемочные тесты и предоставлять обратную связь, а разработчики — работать на основе этих отзывов.

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

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

Модульные тесты сообщают разработчикам о состоянии системы.

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

Частые выпуски позволяют заказчику выполнять приемочные тесты и предоставлять обратную связь, а разработчики — работать на основе этих отзывов.

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

Таким образом, в Extreme Programming обратная связь —

• Работает как катализатор перемен

• Указывает на прогресс

• Дает разработчикам уверенность, что они на правильном пути

Работает как катализатор перемен

Указывает на прогресс

Дает разработчикам уверенность, что они на правильном пути

бодрость

Экстремальное программирование дает смелость разработчикам следующим образом —

• Сосредоточиться только на том, что требуется

• Чтобы общаться и принимать отзывы

• Говорить правду о прогрессе и оценках

• Рефакторинг кода

• Чтобы адаптироваться к изменениям, когда они происходят

• Выбросить код (прототипы)

Сосредоточиться только на том, что требуется

Чтобы общаться и принимать отзывы

Говорить правду о прогрессе и оценках

Рефакторинг кода

Чтобы адаптироваться к изменениям, когда они происходят

Выбросить код (прототипы)

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

уважение

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

• Все уважают друг друга как ценный член команды.

• Каждый вносит свой вклад, например, в энтузиазм.

• Разработчики уважают опыт клиентов и наоборот.

• Руководство уважает право разработчиков принять ответственность и получить власть над своей работой.

Все уважают друг друга как ценный член команды.

Каждый вносит свой вклад, например, в энтузиазм.

Разработчики уважают опыт клиентов и наоборот.

Руководство уважает право разработчиков принять ответственность и получить власть над своей работой.

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

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

• Простота поддерживает смелость, потому что вы можете позволить себе быть намного смелее с простой системой. У вас гораздо меньше шансов сломать его по незнанию.

• Смелость поддерживает простоту, потому что, как только вы видите возможность упростить систему, вы пробуете ее.

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

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

Простота поддерживает смелость, потому что вы можете позволить себе быть намного смелее с простой системой. У вас гораздо меньше шансов сломать его по незнанию.

Смелость поддерживает простоту, потому что, как только вы видите возможность упростить систему, вы пробуете ее.

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

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

Ценности важны, но они расплывчаты, в том смысле, что может быть невозможно решить, является ли что-то ценным. Например, что-то простое с чьей-то точки зрения может быть сложным с чьей-либо точки зрения.

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

Основополагающими принципами экстремального программирования являются —

• Быстрая обратная связь

• Примите простоту

• Постепенное изменение

• Принимая изменения

• Качественная работа

Быстрая обратная связь

Примите простоту

Постепенное изменение

Принимая изменения

Качественная работа

Быстрая обратная связь

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

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

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

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

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

Примите простоту

Предполагать простоту — значит относиться к каждой проблеме так, как будто она может быть решена с простотой.

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

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

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

• Следуйте за ЯГНИ (Вам это не нужно).

• Следуйте принципу СУХОЙ (не повторяйте себя). Например,

  • Не имейте несколько копий идентичного (или очень похожего) кода.

  • Не иметь избыточных копий информации.

  • Никаких потерь времени и ресурсов на то, что может и не понадобиться.

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

Следуйте за ЯГНИ (Вам это не нужно).

Следуйте принципу СУХОЙ (не повторяйте себя). Например,

Не имейте несколько копий идентичного (или очень похожего) кода.

Не иметь избыточных копий информации.

Никаких потерь времени и ресурсов на то, что может и не понадобиться.

Постепенное изменение

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

В экстремальном программировании пошаговое изменение применяется многими способами.

• Дизайн меняется немного за один раз.

• План меняется немного за один раз.

• Команда меняется немного за один раз.

Дизайн меняется немного за один раз.

План меняется немного за один раз.

Команда меняется немного за один раз.

Даже принятие экстремального программирования должно быть сделано в несколько шагов.

Охватывая изменения

Лучшая стратегия — это та, которая сохраняет большинство вариантов, в то же время фактически решая вашу самую насущную проблему.

Качественная работа

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

• Работает хорошо

• Наслаждается работой

• Чувствует себя хорошо в производстве ценного продукта

Работает хорошо

Наслаждается работой

Чувствует себя хорошо в производстве ценного продукта

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

Существует четыре основных вида деятельности в экстремальном программировании. Они —

• кодирование

• тестирование

• прослушивание

• Проектирование

кодирование

тестирование

прослушивание

Проектирование

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

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

Кент Бек, автор «Объяснения экстремального программирования», определил 12 практик экстремального программирования следующим образом:

• Планирование игры

• Короткие Релизы

• метафора

• Простой дизайн

• тестирование

• Рефакторинг

• Парное программирование

• Коллективная собственность

• Непрерывная интеграция

• 40 часовая неделя

• Клиент на месте

• Стандарты кодирования

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

Короткие Релизы

метафора

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

тестирование

Рефакторинг

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

Коллективная собственность

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

40 часовая неделя

Клиент на месте

Стандарты кодирования

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

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

• Быстрая, Прекрасная Обратная Связь —

  • тестирование

  • Клиент на месте

  • Парное программирование

Быстрая, Прекрасная Обратная Связь —

тестирование

Клиент на месте

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

• Непрерывный процесс —

  • Непрерывная интеграция

  • Рефакторинг

  • Короткие Релизы

Непрерывный процесс —

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

Рефакторинг

Короткие Релизы

• Общее понимание —

  • Планирование игры

  • Простой дизайн

  • метафора

  • Коллективная собственность

  • Стандарты кодирования

Общее понимание —

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

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

метафора

Коллективная собственность

Стандарты кодирования

• Благосостояние разработчика —

  • Сорокчасовая неделя

Благосостояние разработчика —

Сорокчасовая неделя

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

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

На следующей диаграмме показано, как экстремальное программирование сплетено с практиками экстремального программирования:

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

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

Бизнес и развитие должны принимать решения в тандеме. Бизнес-решения и технические решения разработки должны согласовываться друг с другом.

Деловые люди должны решить о —

• Масштаб — Какую часть проблемы нужно решить, чтобы система была ценной в производстве? Бизнесмен в состоянии понять, сколько не достаточно, а что слишком много.

• Приоритет — если вам предоставляется вариант, какой из них вы хотите? Бизнесмен в состоянии определить это, больше, чем разработчик при участии клиента.

• Состав релизов — Сколько или как мало нужно сделать, чтобы бизнес стал лучше с программным обеспечением, чем без него? Интуиция разработчика по этому вопросу может быть совершенно неверной.

• Даты выпусков — Какие важные даты, в которые присутствие программного обеспечения (или часть программного обеспечения) будет иметь большое значение?

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

Приоритет — если вам предоставляется вариант, какой из них вы хотите? Бизнесмен в состоянии определить это, больше, чем разработчик при участии клиента.

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

Даты выпусков — Какие важные даты, в которые присутствие программного обеспечения (или часть программного обеспечения) будет иметь большое значение?

Технические люди должны решить о —

• Оценки — Сколько времени займет реализация функции?

• Последствия — Есть стратегические бизнес-решения, которые должны приниматься только тогда, когда сообщается о технических последствиях. Развитие должно объяснить последствия.

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

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

Оценки — Сколько времени займет реализация функции?

Последствия — Есть стратегические бизнес-решения, которые должны приниматься только тогда, когда сообщается о технических последствиях. Развитие должно объяснить последствия.

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

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

Таким образом, план является результатом сотрудничества между заказчиком, бизнесменом и разработчиками.

Игра в планирование — преимущества

Игра в планирование имеет следующие преимущества:

• Сокращение времени, потраченное впустую на бесполезные функции

• Большая оценка клиентов стоимости функции

• Меньше догадок при планировании

Сокращение времени, потраченное впустую на бесполезные функции

Большая оценка клиентов стоимости функции

Меньше догадок при планировании

Короткие Релизы

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

• Достижимо за короткий цикл

• Содержит самые ценные и актуальные бизнес-требования

• Рабочая система

Достижимо за короткий цикл

Содержит самые ценные и актуальные бизнес-требования

Рабочая система

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

Короткие Релизы — Преимущества

Преимущества коротких релизов —

• Частые отзывы

• отслеживание

• Уменьшить вероятность общего проскальзывания проекта

Частые отзывы

отслеживание

Уменьшить вероятность общего проскальзывания проекта

метафора

Согласно интернет-словарю Кембриджа, метафора — это выражение, часто встречающееся в литературе, которое описывает человека или объект, ссылаясь на то, что, как считается, имеет сходные характеристики с этим человеком или объектом. Например, «ум — это океан» и «город — джунгли» — это и есть метафоры.

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

Метафора состоит из специфичных для предметной области элементов и показывает их взаимосвязанность. Используемый язык является языком домена. Чтобы идентифицировать технические объекты, слова, используемые в метафоре, должны восприниматься последовательно.

По мере развития и развития метафоры вся команда обретет новое вдохновение от изучения метафоры.

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

Метафора — преимущества

Преимущества Метафоры —

• Поощряет общий набор терминов для системы

• Сокращение модных слов и жаргона

• Быстрый и простой способ объяснить систему

Поощряет общий набор терминов для системы

Сокращение модных слов и жаргона

Быстрый и простой способ объяснить систему

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

Система должна быть спроектирована максимально просто в любой момент. Дополнительная сложность удаляется, как только она обнаружена.

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

• Запускает все тесты

• Не имеет дублированной логики, такой как параллельные иерархии классов

• Излагает все намерения, важные для разработчиков

• Имеет как можно меньше классов и методов

Запускает все тесты

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

Излагает все намерения, важные для разработчиков

Имеет как можно меньше классов и методов

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

Простой дизайн — преимущества

Преимущества простого дизайна —

• Время не теряется, добавляя лишнюю функциональность

• Проще понять, что происходит

• Рефакторинг и коллективная собственность стала возможной

• Помогает держать программистов на ходу

Время не теряется, добавляя лишнюю функциональность

Проще понять, что происходит

Рефакторинг и коллективная собственность стала возможной

Помогает держать программистов на ходу

тестирование

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

Тестирование — преимущества

Преимущества тестирования —

• Модульное тестирование способствует полноте тестирования

• Test-first дает разработчикам цель

• Автоматизация дает набор регрессионных тестов

Модульное тестирование способствует полноте тестирования

Test-first дает разработчикам цель

Автоматизация дает набор регрессионных тестов

Рефакторинг

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

Рефакторинг — преимущества

Преимущества рефакторинга —

• Предлагает разработчикам активно улучшать продукт в целом

• Увеличивает знания разработчиков системы

Предлагает разработчикам активно улучшать продукт в целом

Увеличивает знания разработчиков системы

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

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

В каждой паре две роли —

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

• Другой разработчик думает более стратегически

  • Весь этот подход будет работать?

  • Какие еще тестовые примеры могут еще не работать?

  • Есть ли способ упростить всю систему, чтобы текущая проблема просто исчезла?

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

Другой разработчик думает более стратегически

Весь этот подход будет работать?

Какие еще тестовые примеры могут еще не работать?

Есть ли способ упростить всю систему, чтобы текущая проблема просто исчезла?

Спаривание динамическое. Это означает, что две роли A и B могут поменяться местами или объединиться с другими членами команды. Чаще кто-либо в команде будет выступать в качестве партнера. Например, если вы несете ответственность за выполнение задачи в незнакомой вам области, вы можете попросить кого-то с недавним опытом объединиться с вами.

Парное программирование — преимущества

Преимущества парного программирования —

• Две головы лучше одной

• фокус

• Два человека с большей вероятностью ответят на следующие вопросы —

  • Весь этот подход будет работать?

  • Какие тестовые случаи могут еще не работать?

  • Есть ли способ упростить это?

Две головы лучше одной

фокус

Два человека с большей вероятностью ответят на следующие вопросы —

Весь этот подход будет работать?

Какие тестовые случаи могут еще не работать?

Есть ли способ упростить это?

Коллективная собственность

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

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

Коллективная собственность — преимущества

Преимущества коллективной собственности —

• Помогает смягчить потерю члена команды, который уходит.

• Предлагает разработчикам взять на себя ответственность за систему в целом, а не за ее части.

Помогает смягчить потерю члена команды, который уходит.

Предлагает разработчикам взять на себя ответственность за систему в целом, а не за ее части.

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

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

• Сидит, когда машина свободна.

• Загружает текущий выпуск.

• Загружает их изменения (проверка и устранение любых коллизий).

• Запускает тесты до тех пор, пока они не пройдут (100% правильно).

Сидит, когда машина свободна.

Загружает текущий выпуск.

Загружает их изменения (проверка и устранение любых коллизий).

Запускает тесты до тех пор, пока они не пройдут (100% правильно).

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

Непрерывная интеграция — преимущества

Преимущества непрерывной интеграции:

• Уменьшает продолжительность, которая в противном случае является длительной.

• Включает практику коротких выпусков, так как время, необходимое для выпуска, минимально.

Уменьшает продолжительность, которая в противном случае является длительной.

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

40-часовая неделя

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

40-часовая неделя — преимущества

Преимущества 40-часовой недели —

• Большинство разработчиков теряют эффективность за последние 40 часов.

• Ценность придается благосостоянию разработчиков.

• Менеджмент вынужден находить реальные решения.

Большинство разработчиков теряют эффективность за последние 40 часов.

Ценность придается благосостоянию разработчиков.

Менеджмент вынужден находить реальные решения.

Клиент на месте

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

Клиент на месте — преимущества

Преимущества наличия местного клиента —

• Может дать быстрые и знающие ответы на реальные вопросы развития.

• Уверен, что то, что разработано, — то, что нужно.

• Функциональность расставлена ​​по приоритетам правильно.

Может дать быстрые и знающие ответы на реальные вопросы развития.

Уверен, что то, что разработано, — то, что нужно.

Функциональность расставлена ​​по приоритетам правильно.

Стандарты кодирования

Разработчики пишут весь код в соответствии с правилами, подчеркивающими

• Общение через код.

• Наименьший объем работы возможен.

• В соответствии с правилом «один раз и только один раз» (без дублирующего кода).

• Добровольное усыновление всей командой.

Общение через код.

Наименьший объем работы возможен.

В соответствии с правилом «один раз и только один раз» (без дублирующего кода).

Добровольное усыновление всей командой.

Эти правила необходимы в экстремальном программировании, потому что все разработчики —

• Может переключаться с одной части системы на другую часть системы.

• Меняйте партнеров пару раз в день.

• Рефакторинг кода друг друга постоянно.

Может переключаться с одной части системы на другую часть системы.

Меняйте партнеров пару раз в день.

Рефакторинг кода друг друга постоянно.

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

Стандарты кодирования — Преимущества

Преимущества стандартов кодирования —

• Сокращает время, которое разработчики тратят на переформатирование кода других людей.

• Уменьшает необходимость внутреннего комментирования.

• Призывает к ясному, однозначному коду.

Сокращает время, которое разработчики тратят на переформатирование кода других людей.

Уменьшает необходимость внутреннего комментирования.

Призывает к ясному, однозначному коду.

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

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

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

The Planning Game — Поддержка других практик XP

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

Игра в планирование — недостатки

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

Игра в планирование с другими практиками XP

Другие практики XP поддерживают игру планирования следующим образом —

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

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

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

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

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

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

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

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

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

Короткие релизы — Поддержка других практик XP

Короткие Релизы — Недостатки

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

Короткие релизы с другими практиками XP.

Другие практики XP поддерживают короткие версии следующим образом:

• Игра в планирование помогает вам работать над наиболее ценными историями, поэтому даже небольшая система будет иметь деловую ценность.

• Непрерывная интеграция делает стоимость упаковки релиза минимальной.

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

• Вы можете сделать простой дизайн, достаточный для этого релиза, не на все времена.

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

Непрерывная интеграция делает стоимость упаковки релиза минимальной.

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

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

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

Метафора — поддержка из других практик XP

Вы не можете начать разработку только с метафоры. Там может быть недостаточно подробностей, и вы можете ошибаться.

Метафора с другими практиками XP

Другие практики XP поддерживают Metaphor следующим образом —

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

• Вашему клиенту на месте удобно говорить о системе с точки зрения метафоры.

• Непрерывный рефакторинг позволяет вам лучше понять, что означает метафора в реализации.

• Простой дизайн помогает вам составить карту с метафорой.

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

Вашему клиенту на месте удобно говорить о системе с точки зрения метафоры.

Непрерывный рефакторинг позволяет вам лучше понять, что означает метафора в реализации.

Простой дизайн помогает вам составить карту с метафорой.

Таким образом, вы можете начать разработку только с метафоры.

Простой дизайн — поддержка других практик XP

Простой дизайн — недостатки

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

Простой дизайн с другими практиками XP.

Другие практики XP поддерживают Simple Design следующим образом —

• Рефакторинг позволяет вносить изменения.

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

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

• 40-часовая неделя поможет вам сосредоточиться на правильном дизайне.

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

Рефакторинг позволяет вносить изменения.

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

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

40-часовая неделя поможет вам сосредоточиться на правильном дизайне.

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

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

Тестирование — поддержка из других практик XP

Тестирование — недостатки

Вы можете подумать, что —

• Вы не можете написать все эти тесты.

• Написание тестов может занять слишком много времени.

• Разработчики не будут писать тесты.

Вы не можете написать все эти тесты.

Написание тестов может занять слишком много времени.

Разработчики не будут писать тесты.

Тестирование с другими практиками XP

Другие практики XP поддерживают Тестирование следующим образом —

• Простой дизайн облегчает написание тестов.

• Рефакторинг позволяет вам решить, какие тесты необходимы.

• С парным программированием, даже если вы не можете думать о другом тесте, ваш партнер может. Вы можете позволить своему партнеру запускать тесты, передавая клавиатуру, и вы чувствуете себя уверенно, когда видите, что все тесты запущены.

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

• Непрерывная интеграция и немедленное выполнение тестов для каждого набора изменений, сделанных парой, обеспечивает —

  • Что новый код работает, если 100% тестов пройден, или

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

• Короткие выпуски гарантируют, что работающая система доступна для клиента, чтобы выполнить тесты и дать обратную связь.

• Он-лайн заказчик успеет выполнить все тесты и сразу же оставить отзыв о работающей системе.

• Планирование игры гарантирует получение обратной связи от клиента после тестирования для планирования следующего релиза.

Простой дизайн облегчает написание тестов.

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

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

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

Непрерывная интеграция и немедленное выполнение тестов для каждого набора изменений, сделанных парой, обеспечивает —

Что новый код работает, если 100% тестов пройден, или

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

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

Он-лайн заказчик успеет выполнить все тесты и сразу же оставить отзыв о работающей системе.

Планирование игры гарантирует получение обратной связи от клиента после тестирования для планирования следующего релиза.

Таким образом, разработчики и заказчики будут писать тесты. Далее, тесты автоматизированы, чтобы обеспечить работу остальной части Extreme Programming.

Рефакторинг — Поддержка других практик XP

Рефакторинг — недостатки

Вы не можете реорганизовать дизайн системы все время. Это было бы —

• Слишком долго

• Быть слишком трудно контролировать, и

• Скорее всего сломать систему.

Слишком долго

Быть слишком трудно контролировать, и

Скорее всего сломать систему.

Рефакторинг с другими практиками XP

Другие практики XP поддерживают рефакторинг следующим образом:

• С коллективной собственностью вы можете вносить изменения везде, где они необходимы.

• Со стандартами кодирования вам не нужно переформатировать перед рефакторингом.

• Благодаря парному программированию у вас хватит смелости заняться сложным рефакторингом.

• Благодаря простой конструкции рефакторинг становится проще.

• С метафорой вы можете легко общаться.

• С тестированием вы вряд ли что-то сломаете, не зная об этом.

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

• С 40-часовой неделей вы отдохнете, поэтому у вас будет больше смелости и меньше шансов совершить ошибки.

С коллективной собственностью вы можете вносить изменения везде, где они необходимы.

Со стандартами кодирования вам не нужно переформатировать перед рефакторингом.

Благодаря парному программированию у вас хватит смелости заняться сложным рефакторингом.

Благодаря простой конструкции рефакторинг становится проще.

С метафорой вы можете легко общаться.

С тестированием вы вряд ли что-то сломаете, не зная об этом.

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

С 40-часовой неделей вы отдохнете, поэтому у вас будет больше смелости и меньше шансов совершить ошибки.

Таким образом, вы можете рефакторинг всякий раз, когда вы видите возможность —

• Сделайте систему проще

• Уменьшить дублирование

• Общаться более четко

Сделайте систему проще

Уменьшить дублирование

Общаться более четко

Парное программирование — поддержка других практик XP

Парное программирование — слабость

Вы не можете написать весь код попарно. Это будет слишком медленно. Ситуация осложняется, если два человека не ладят.

Парное программирование с другими практиками XP.

Другие практики XP поддерживают парное программирование следующим образом:

• Стандарты кодирования уменьшают конфликты.

• Благодаря 40-часовой работе все свежи и сосредоточены, что еще больше снижает вероятность ненужных дискуссий.

• Пары пишут тесты вместе, давая им возможность согласовать свое понимание, прежде чем приступить к реализации.

• Метафора помогает парам обосновывать свои решения о наименовании и базовом дизайне

• Простой дизайн позволяет паре иметь общее понимание.

• Рефакторинг помогает паре обсуждать и принимать совместные решения для упрощения системы.

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

• Коллективное владение позволяет команде смешивать и сочетать и позволяет им поддерживать сердечные отношения.

Стандарты кодирования уменьшают конфликты.

Благодаря 40-часовой работе все свежи и сосредоточены, что еще больше снижает вероятность ненужных дискуссий.

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

Метафора помогает парам обосновывать свои решения о наименовании и базовом дизайне

Простой дизайн позволяет паре иметь общее понимание.

Рефакторинг помогает паре обсуждать и принимать совместные решения для упрощения системы.

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

Коллективное владение позволяет команде смешивать и сочетать и позволяет им поддерживать сердечные отношения.

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

Коллективное владение — поддержка от других практик XP

Коллективная собственность — недостатки

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

Коллективное владение другими практиками XP

Другие практики XP поддерживают коллективное владение следующим образом:

• Непрерывная интеграция снижает вероятность конфликтов.

• Тестирование снижает вероятность случайного поломки.

• С парным программированием вы с меньшей вероятностью нарушите код, и разработчики быстрее узнают, что они могут выгодно изменить.

• Благодаря стандартам кодирования у вас не будет конфликтов в коде.

• С помощью рефакторинга вы поддерживаете систему простой, чтобы все ее понимали.

Непрерывная интеграция снижает вероятность конфликтов.

Тестирование снижает вероятность случайного поломки.

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

Благодаря стандартам кодирования у вас не будет конфликтов в коде.

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

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

Непрерывная интеграция — поддержка других практик XP

Непрерывная интеграция — недостатки

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

Непрерывная интеграция с другими практиками XP

Другие практики XP поддерживают непрерывную интеграцию следующим образом:

• Тестирование быстро поможет вам узнать, что вы ничего не сломали.

• При парном программировании можно интегрировать вдвое меньше потоков изменений.

• С рефакторингом есть меньшие части, уменьшающие вероятность конфликтов.

• Со стандартами кодирования код будет согласован.

• Короткие релизы обеспечивают немедленную обратную связь с системой.

• Коллективное владение гарантирует, что тот, кто изменяет код и интегрируется, будет иметь полное представление о системе.

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

При парном программировании можно интегрировать вдвое меньше потоков изменений.

С рефакторингом есть меньшие части, уменьшающие вероятность конфликтов.

Со стандартами кодирования код будет согласован.

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

Коллективное владение гарантирует, что тот, кто изменяет код и интегрируется, будет иметь полное представление о системе.

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

40-часовая неделя — поддержка от других практик XP

40-часовая неделя — недостатки

Вы не можете работать 40 часов в неделю. Вы не можете создать достаточно деловой ценности за 40 часов.

40-часовая неделя с другими практиками XP

Другие практики XP поддерживают 40-часовую неделю следующим образом —

• Планирование игры дает вам, что более ценная работа, чтобы сделать.

• Сочетание планирования игры и тестирования гарантирует, что вам придется работать только над тем, что вы думали.

• Простой дизайн и рефакторинг позволяет вам оставаться сосредоточенным и полным вовремя.

• Парное программирование помогает вам работать над тем, что вы можете сделать, делясь другой работой с вашим партнером.

• Практика в целом помогает вам развиваться на максимальной скорости, и, следовательно, вы не можете двигаться быстрее.

Планирование игры дает вам, что более ценная работа, чтобы сделать.

Сочетание планирования игры и тестирования гарантирует, что вам придется работать только над тем, что вы думали.

Простой дизайн и рефакторинг позволяет вам оставаться сосредоточенным и полным вовремя.

Парное программирование помогает вам работать над тем, что вы можете сделать, делясь другой работой с вашим партнером.

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

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

Клиент на месте — поддержка из других практик XP

Клиент на месте — недостатки

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

Клиент на месте с другими практиками XP

Другие практики XP поддерживают клиента на месте следующим образом.

Они могут создавать ценность для проекта —

• В Planning Game, принимая решения о приоритетах и ​​масштабах для разработчиков.

• С Metaphor, чтобы внести ясность для разработчиков в области.

• При тестировании, написании приемочных испытаний и проведении приемочных испытаний после каждого короткого выпуска.

В Planning Game, принимая решения о приоритетах и ​​масштабах для разработчиков.

С Metaphor, чтобы внести ясность для разработчиков в области.

При тестировании, написании приемочных испытаний и проведении приемочных испытаний после каждого короткого выпуска.

Таким образом, они могут принести большую ценность для организации, внеся свой вклад в проект.

Стандарты кодирования — Поддержка других практик XP

Стандарты кодирования — недостатки

Вы не можете попросить команду написать общий стандарт, так как разработчики обычно индивидуальны.

Стандарты кодирования с другими практиками XP

Другие практики XP поддерживают стандарты кодирования следующим образом:

• Парное программирование позволяет им легко адаптироваться к необходимым стандартам кодирования.

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

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

Парное программирование позволяет им легко адаптироваться к необходимым стандартам кодирования.

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

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

Экстремальное программирование — развивающиеся практики

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

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

Практика экстремального программирования	эволюция
Клиент на месте	Вся команда
Планирование игры	Планирование релиза Планирование итерации
тестирование	Приемочное тестирование Модульное тестирование Разработка через тестирование
Рефакторинг	Улучшение дизайна
40-часовая неделя	Устойчивый темп

Планирование релиза

Планирование итерации

Приемочное тестирование

Модульное тестирование

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

Клиент на месте — вся команда

Экстремальное программирование опирается на проектное сообщество с упором на командно-ориентированный подход. Все участники проекта Extreme Programming, включая клиента, являются одной командой.

Заказчик устанавливает требования, устанавливает приоритеты и руководит проектом. Это позволяет клиенту понять практические детали разработки и соответственно расставить приоритеты и ожидания. Это меняется с «Когда заказчик запрашивает разработку» на «Когда заказчик понимает и сотрудничает с разработкой».

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

Планирование игры — Планирование выпуска и итерации

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

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

Планирование итераций устанавливает краткосрочные временные рамки с итерациями, обычно в диапазоне от 1 недели до 1 месяца. Основная цель итерационного планирования — это работающее программное обеспечение в конце каждой итерации. Разработчики выбирают функции / истории для итерации, разбивают их на задачи, оценивают задачи и фиксируют выделенные задачи. Устойчивый темп обеспечивается балансировкой коэффициента нагрузки по команде с учетом 40-часовой рабочей недели.

Приемочное тестирование

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

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

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

Система всегда улучшается и никогда не отступает.

Модульное тестирование

Разработчик пишет модульные тесты с достаточным охватом, включающие намерение и использование модулей и методов кода. Модульные тесты автоматизированы, с четким прохождением / провалом. Большинство языков имеют платформу xUnit (например, nUnit, jUnit).

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

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

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

В Test Driven Development разработчик пишет модульный тест перед написанием кода. Цель состоит в том, чтобы заставить модульный тест не пройти Поскольку код еще не реализован, модульный тест не пройден. Разработчик пишет достаточно кода, чтобы выполнить модульное тестирование, а затем разработчик рефакторинг, чтобы гарантировать, что код прост и чист (без дублирования и сложности).

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

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

Разработка через тестирование приводит к 100% охвату модульных тестов и гарантирует, что код будет простым и минимальным.

Рефакторинг — Улучшение дизайна

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

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

40-часовая неделя — устойчивый темп

Работайте в темпе, который можно поддерживать бесконечно. Sustainable Pace обеспечивает человеческий вклад в успех проекта, учитывая факты, которые —

• Усталость и стресс снижают производительность, а также качество продукта. Это может привести к текучести кадров.

• Развитие не останавливается на спринте, и оно должно быть направлено на достижение долгосрочных целей

• Если команда не согласится с ожиданиями, не будет обязательств и ответственности.

• Точные часы не так важны, как умение выступать.

• Следует избегать микроуправления, обеспечивая при этом доступность по мере необходимости

Усталость и стресс снижают производительность, а также качество продукта. Это может привести к текучести кадров.

Развитие не останавливается на спринте, и оно должно быть направлено на достижение долгосрочных целей

Если команда не согласится с ожиданиями, не будет обязательств и ответственности.

Точные часы не так важны, как умение выступать.

Следует избегать микроуправления, обеспечивая при этом доступность по мере необходимости

Экстремальное программирование — технологический цикл

Экстремальное программирование — это гибкий процесс.

Экстремальное программирование — это гибкий процесс, потому что он —

• Подчеркивает много общения и обратной связи —

  • Внутри команды (парное программирование, коллективное владение кодом, простой дизайн)

  • С клиентом (клиент на месте и приемочные испытания)

  • Для планирования выпуска (с заказчиком и разработчиками, участвующими в оценке)

• В Extreme Programming работает тренер, чья работа замечает, когда люди не общаются и не вводят их заново.

• Объятия меняются с —

  • Частые итерации (короткие выпуски)

  • Проектирование и модернизация легко (простой дизайн)

  • Кодирование и тестирование постоянно (парное программирование)

  • Постоянное участие клиента (онлайн-клиент)

• Доставляет рабочий продукт заказчику в короткие итерации (короткие выпуски).

• Устраняет дефекты на ранней стадии, тем самым снижая затраты (парное программирование)

  • Кодовые обзоры

  • Модульное тестирование

  • Интеграция для каждого набора изменений и тестирования

Подчеркивает много общения и обратной связи —

Внутри команды (парное программирование, коллективное владение кодом, простой дизайн)

С клиентом (клиент на месте и приемочные испытания)

Для планирования выпуска (с заказчиком и разработчиками, участвующими в оценке)

В Extreme Programming работает тренер, чья работа замечает, когда люди не общаются и не вводят их заново.

Объятия меняются с —

Частые итерации (короткие выпуски)

Проектирование и модернизация легко (простой дизайн)

Кодирование и тестирование постоянно (парное программирование)

Постоянное участие клиента (онлайн-клиент)

Доставляет рабочий продукт заказчику в короткие итерации (короткие выпуски).

Устраняет дефекты на ранней стадии, тем самым снижая затраты (парное программирование)

Кодовые обзоры

Модульное тестирование

Интеграция для каждого набора изменений и тестирования

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

Экстремальное программирование является итеративным и инкрементным и управляется циклами с временными рамками. Поэтому ритм процесса экстремального программирования имеет решающее значение.

Экстремальное программирование имеет следующие уровни активности —

• Жизненные циклы продукта

• релизы

• Итерации

• Задачи

• развитие

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

Жизненные циклы продукта

релизы

Итерации

Задачи

развитие

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

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

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

• Сессии планирования выпуска предоставляют входные данные для циклов итерации.

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

• Задача разработки предоставляет материалы для эпизодов развития.

• Разработка производит продукт.

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

Сессии планирования выпуска предоставляют входные данные для циклов итерации.

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

Задача разработки предоставляет материалы для эпизодов развития.

Разработка производит продукт.

Обратная связь — это постоянная деятельность на протяжении всего проекта и на всех вышеперечисленных уровнях деятельности.

Жизненные циклы продукта

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

Истории являются основным результатом этого уровня деятельности.

релизы

Это также называется фазой обязательства. В этой деятельности —

• Вся команда собирается так, чтобы —

  • Прогресс пересматривается.

  • Новые требования могут быть добавлены и / или существующие требования могут быть изменены или удалены.

  • Заказчик представляет истории.

  • Истории обсуждаются.

• Разработчики определяют технический подход и риск. Они предоставляют оценки и варианты первого уровня.

• Клиент расставляет приоритеты для историй и выбирает целевое время выпуска.

• Заказчик и разработчики обязуются использовать функциональность, которая должна быть включена, и дату следующего выпуска.

• Разработчики —

  • Расставьте истории в вероятные итерации.

  • Включите исправления дефектов из приемочного тестирования предыдущего выпуска.

  • Начните итерации.

Вся команда собирается так, чтобы —

Прогресс пересматривается.

Новые требования могут быть добавлены и / или существующие требования могут быть изменены или удалены.

Заказчик представляет истории.

Истории обсуждаются.

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

Клиент расставляет приоритеты для историй и выбирает целевое время выпуска.

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

Разработчики —

Расставьте истории в вероятные итерации.

Включите исправления дефектов из приемочного тестирования предыдущего выпуска.

Начните итерации.

План релиза является основным результатом этого уровня деятельности.

Итерации

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

План итерации является основным результатом этой деятельности.

Разработчики —

• Определить подробный технический подход.

• Создайте список задач для каждой истории.

• Начните разработку.

• Разверните систему до

Определить подробный технический подход.

Создайте список задач для каждой истории.

Начните разработку.

Разверните систему до

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

Задачи

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

развитие

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

Каждая пара —

• Проверяет их понимание истории.

• Определяет детальный подход к реализации, обеспечивая простой дизайн.

• Начинается разработка через тестирование, т. Е. Написание модульного теста, реализация кода для прохождения модульного теста, рефакторинг для упрощения кода.

• Интегрирует их код в системную кодовую базу через соответствующие промежутки времени.

• Часто проверяет прогресс.

Проверяет их понимание истории.

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

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

Интегрирует их код в системную кодовую базу через соответствующие промежутки времени.

Часто проверяет прогресс.

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

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

Обзоры итерации и выпуска предоставляют общее состояние и баллы для настройки и улучшения процесса.

• Эпизоды развития могут вызвать переосмысление задач.

• Разработка задачи может привести к переосмыслению истории.

• Переоценка истории может вызвать изменения итерации или восстановления.

• Результаты итерации могут вызвать изменения в плане выпуска.

Эпизоды развития могут вызвать переосмысление задач.

Разработка задачи может привести к переосмыслению истории.

Переоценка истории может вызвать изменения итерации или восстановления.

Результаты итерации могут вызвать изменения в плане выпуска.

Цикл процесса экстремального программирования показан ниже.

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

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

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

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

Парное программирование — преимущества

Существенные преимущества парного программирования —

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

• Содержание концевых дефектов статистически ниже.

• Дизайн лучше, а длина кода короче.

• Команда быстрее решает проблемы.

• Люди узнают значительно больше о системе и о разработке программного обеспечения.

• Проект заканчивается тем, что несколько человек понимают каждый элемент системы.

• Люди учатся работать вместе и чаще разговаривать вместе, что улучшает обмен информацией и командную динамику.

• Люди больше наслаждаются своей работой.

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

Содержание концевых дефектов статистически ниже.

Дизайн лучше, а длина кода короче.

Команда быстрее решает проблемы.

Люди узнают значительно больше о системе и о разработке программного обеспечения.

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

Люди учатся работать вместе и чаще разговаривать вместе, что улучшает обмен информацией и командную динамику.

Люди больше наслаждаются своей работой.

Эксперименты по парному программированию

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

Исследование парного программирования показывает, что —

• Пары используют не больше человеко-часов, чем одиночные.

• Пары создают меньше дефектов.

• Пары создают меньше строк кода.

• Пары больше наслаждаются своей работой.

Пары используют не больше человеко-часов, чем одиночные.

Пары создают меньше дефектов.

Пары создают меньше строк кода.

Пары больше наслаждаются своей работой.

Университет Юты проводил эксперименты по парному программированию. Результаты показали, что —

• Пары потратили на программу на 15% больше времени, чем отдельные лица.

• Код, написанный парами, последовательно прошел больше тестов, чем код, написанный отдельными людьми.

• Пары последовательно реализуют одну и ту же функциональность, создаваемую отдельными лицами в меньшем количестве строк кода.

• Научиться программировать в среде, где есть быстро ощутимые результаты, — это весело и позволяет учиться быстрее.

Пары потратили на программу на 15% больше времени, чем отдельные лица.

Код, написанный парами, последовательно прошел больше тестов, чем код, написанный отдельными людьми.

Пары последовательно реализуют одну и ту же функциональность, создаваемую отдельными лицами в меньшем количестве строк кода.

Научиться программировать в среде, где есть быстро ощутимые результаты, — это весело и позволяет учиться быстрее.

Адаптация к парному программированию

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

По словам Лори А. Уильямс и Роберта Р. Кесслера, в их книге «Все, что мне действительно нужно знать о парном программировании, которое я изучил в детском саду», хорошо объясняется, как развивать навыки, которые мы все изучили в детском саду, чтобы установить командную сплоченность в целом и парное программирование в частности.

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

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

Уроки детского сада

В детском саду мы узнали следующее —

• Поделись всем

• Играй честно

• Не бей людей

• Положите вещи туда, где вы их нашли

• Убери свой беспорядок

• Не бери вещи, которые не твои

• Скажи, что ты сожалеешь, когда причиняешь кому-то боль

• Мойте руки перед едой

• Промывать

• Теплое печенье и холодное молоко полезны для вас

• Живи сбалансированной жизнью — учись и думай, рисуй, рисуй, пой, танцуй, играй и работай каждый день

• Вздремнуть каждый день

• Когда вы выходите в мир, следите за движением, держитесь за руки и держитесь вместе

• Знать о чуде

Поделись всем

Играй честно

Не бей людей

Положите вещи туда, где вы их нашли

Убери свой беспорядок

Не бери вещи, которые не твои

Скажи, что ты сожалеешь, когда причиняешь кому-то боль

Мойте руки перед едой

Промывать

Теплое печенье и холодное молоко полезны для вас

Живи сбалансированной жизнью — учись и думай, рисуй, рисуй, пой, танцуй, играй и работай каждый день

Вздремнуть каждый день

Когда вы выходите в мир, следите за движением, держитесь за руки и держитесь вместе

Знать о чуде

Далее мы рассмотрим принципы парного программирования в контексте приведенных выше учений.

Поделись всем

В парном программировании

• Два программиста сидят вместе и совместно создают один артефакт (дизайн, алгоритм, код и т. Д.)

• Один человек печатает или пишет, другой постоянно просматривает работу. И то и другое

  • Равные участники процесса

  • Ответственный за каждый аспект артефакта

  • Владеть всем

Два программиста сидят вместе и совместно создают один артефакт (дизайн, алгоритм, код и т. Д.)

Один человек печатает или пишет, другой постоянно просматривает работу. И то и другое

Равные участники процесса

Ответственный за каждый аспект артефакта

Владеть всем

Играй честно

В парном программировании

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

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

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

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

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

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

Не бей своего партнера

В парном программировании

• Убедитесь, что ваш партнер остается сосредоточенным и на задаче.

• Вы остаетесь сосредоточенным и на задаче.

• Убедитесь, что ваш партнер соблюдает предписанные стандарты кодирования и, таким образом, поддерживает приверженность остальной части команды.

Убедитесь, что ваш партнер остается сосредоточенным и на задаче.

Вы остаетесь сосредоточенным и на задаче.

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

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

• Каждый держит своего партнера сосредоточенным и на задаче без возможности расслабиться.

• Каждый артефакт проверяется постоянно, так как он создается для обеспечения качества.

Каждый держит своего партнера сосредоточенным и на задаче без возможности расслабиться.

Каждый артефакт проверяется постоянно, так как он создается для обеспечения качества.

Положите вещи обратно на место

В парном программировании

• Вы должны верить в свои навыки и навыки своего партнера, а также. Любые негативные мысли в этом аспекте должны быть помещены в мусорное ведро.

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

• Вы должны быть уверены, что —

  • Везде, где есть вероятность отставания, вы можете сразу же забрать у своего партнера.

  • Вместе, как пара, вы можете решать проблемы, которые вы не могли решить в одиночку.

  • Вы можете помочь улучшить навыки друг друга.

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

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

Вы должны быть уверены, что —

Везде, где есть вероятность отставания, вы можете сразу же забрать у своего партнера.

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

Вы можете помочь улучшить навыки друг друга.

Убери свой беспорядок

В парном программировании, с техникой «смотреть через плечо»,

• Вы обнаружите, что удивительно знать, сколько явных, но незамеченных дефектов замечено вашим партнером.

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

• Характеризует предотвращение дефектов и эффективность устранения дефектов.

Вы обнаружите, что удивительно знать, сколько явных, но незамеченных дефектов замечено вашим партнером.

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

Характеризует предотвращение дефектов и эффективность устранения дефектов.

Не принимай вещи слишком серьезно

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

Это необходимо, потому что,

• Избыточное эго может проявляться двумя способами —

  • Отношение «мой путь или шоссе» может помешать программисту обдумать идеи других.

  • Защищенность может привести к тому, что программист не получит конструктивную критику или не воспримет эту критику как недоверие.

Избыточное эго может проявляться двумя способами —

Отношение «мой путь или шоссе» может помешать программисту обдумать идеи других.

Защищенность может привести к тому, что программист не получит конструктивную критику или не воспримет эту критику как недоверие.

Оба эти способа проявления эго наносят ущерб отношениям сотрудничества.

• С другой стороны, человек, который всегда соглашается с партнером, чтобы не создавать напряженности, также сводит к минимуму преимущества совместной работы. Для благоприятного обмена идеями, при необходимости, должны быть некоторые здоровые разногласия / дебаты.

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

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

Скажи, что ты сожалеешь, когда причиняешь кому-то боль во время перемещения мебели

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

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

Отречься от скептицизма, прежде чем начать

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

Опыт показал, что наличие одного программиста, очень позитивного и / или опытного в парном программировании, может привести к тому, что пара победоносно станет одной объединенной командой.

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

• Удовольствие, которое люди получают от своей работы, больше, чем вы ожидаете, учитывая характер самой работы.

• Как только команда начинает жевать, вероятность успеха резко возрастает.

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

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

Как только команда начинает жевать, вероятность успеха резко возрастает.

Промывать

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

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

Теплое печенье и холодное молоко полезны для вас

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

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

Жить сбалансированной жизнью

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

Сделайте перерыв в совместной работе каждый день

Нет необходимости работать отдельно каждый день, но допустимо работать в одиночку 10-50% времени. Это потому что —

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

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

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

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

Следите за движением, держитесь за руки и держитесь вместе

В парном программировании

• Между ними не должно быть конкуренции. Оба должны работать вместе, как если бы артефакт производился одним умом.

• Партнеры должны доверять суждениям друг друга и преданности друг друга команде.

• Партнер никогда не должен обвинять другого партнера в каких-либо проблемах или дефектах.

Между ними не должно быть конкуренции. Оба должны работать вместе, как если бы артефакт производился одним умом.

Партнеры должны доверять суждениям друг друга и преданности друг друга команде.

Партнер никогда не должен обвинять другого партнера в каких-либо проблемах или дефектах.

Знать о силе двух мозгов

Когда двое работают вместе, у каждого свой набор знаний и навыков, состоящий из:

• Общий набор этих знаний и навыков, который позволяет им эффективно общаться.

• Уникальные навыки, которые позволяют им внести свой вклад в выполнение своих задач.

Общий набор этих знаний и навыков, который позволяет им эффективно общаться.

Уникальные навыки, которые позволяют им внести свой вклад в выполнение своих задач.

Вместе пара будет —

• Придумайте более чем в два раза больше возможных решений, чем те, которые были бы при работе в одиночку.

• Приступайте к более быстрому поиску лучшего решения.

• Реализуйте это быстрее и с лучшим качеством.

Придумайте более чем в два раза больше возможных решений, чем те, которые были бы при работе в одиночку.

Приступайте к более быстрому поиску лучшего решения.

Реализуйте это быстрее и с лучшим качеством.

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

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

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

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

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

Роли, которые были признаны эффективными в экстремальном программировании:

• Разработчик (также называемый Программистом некоторыми командами)
• Покупатель
• Менеджер (также называемый трекером)
• Тренер

разработчик

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

• Права разработчика

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

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

  • Вы имеете право просить и получать помощь от сверстников, начальников и клиентов.

  • Вы имеете право составлять и обновлять свои собственные оценки.

  • Вы имеете право принять свои обязанности вместо того, чтобы назначить их вам.

• Основные обязанности, за которые вы будете нести ответственность —

  • Оценивать истории

  • Определите задачи из историй

  • Оценить задачи

  • Написать юнит-тесты

  • Напишите код для прохождения написанных модульных тестов

  • Выполнить юнит-тестирование

  • Refactor

  • Интегрировать непрерывно

• Навыки разработчика

  • Парное программирование

  • Общение — это необходимо и достаточно подробно

  • Всегда используйте метафору, чтобы использовать правильные имена

  • Код только то, что требуется.

  • Поддерживать простоту

• Коллективная собственность

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

  • Будьте готовы признать свои страхи. Помните, что вы являетесь частью команды, и для успеха экстремального программирования требуется смелость.

• Носите разные шляпы в качестве разработчика в команде, такие как —

  • Программист.

  • Архитектор и дизайнер.

  • Архитектор интерфейса / дизайнер пользовательского интерфейса.

  • Дизайнер баз данных и администратор баз данных.

  • Оператор и сетевой дизайнер.

• Иногда одному из разработчиков приходится носить шляпу тестера.

  • Помогите клиенту выбрать и написать функциональные тесты.

  • Регулярно запускайте функциональные тесты.

  • Сообщите о результатах теста.

  • Убедитесь, что инструменты тестирования работают хорошо.

Права разработчика

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

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

Вы имеете право просить и получать помощь от сверстников, начальников и клиентов.

Вы имеете право составлять и обновлять свои собственные оценки.

Вы имеете право принять свои обязанности вместо того, чтобы назначить их вам.

Основные обязанности, за которые вы будете нести ответственность —

Оценивать истории

Определите задачи из историй

Оценить задачи

Написать юнит-тесты

Напишите код для прохождения написанных модульных тестов

Выполнить юнит-тестирование

Refactor

Интегрировать непрерывно

Навыки разработчика

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

Общение — это необходимо и достаточно подробно

Всегда используйте метафору, чтобы использовать правильные имена

Код только то, что требуется.

Поддерживать простоту

Коллективная собственность

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

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

Носите разные шляпы в качестве разработчика в команде, такие как —

Программист.

Архитектор и дизайнер.

Архитектор интерфейса / дизайнер пользовательского интерфейса.

Дизайнер баз данных и администратор баз данных.

Оператор и сетевой дизайнер.

Иногда одному из разработчиков приходится носить шляпу тестера.

Помогите клиенту выбрать и написать функциональные тесты.

Регулярно запускайте функциональные тесты.

Сообщите о результатах теста.

Убедитесь, что инструменты тестирования работают хорошо.

Покупатель

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

Это вызывает необходимость определенных навыков для роли клиента —

• Написание необходимых рассказов с необходимой и достаточной детализацией.

• Выработка отношения к успеху проекта.

• Влияние на проект без возможности контролировать его.

• Принятие решений, которые требуются время от времени на степени функциональности, которая требуется.

• Готов менять решения по мере развития продукта.

• Написание функциональных тестов.

Написание необходимых рассказов с необходимой и достаточной детализацией.

Выработка отношения к успеху проекта.

Влияние на проект без возможности контролировать его.

Принятие решений, которые требуются время от времени на степени функциональности, которая требуется.

Готов менять решения по мере развития продукта.

Написание функциональных тестов.

В экстремальном программировании клиент должен постоянно поддерживать связь с командой и разговаривать с ней как один голос. Это необходимо, так как —

• Заказчиком может быть несколько заинтересованных сторон.

• Клиент может быть сообществом.

• Клиент не всегда ПРИНЦИПАЛ (прокси).

• Заказчиком может быть команда со следующими потенциальными членами —

  • Менеджеры по продукту

  • Маркетинговые продажи

  • Бизнес аналитики

  • Конечные пользователи, их менеджеры

  • Бизнес / Системные операции

Заказчиком может быть несколько заинтересованных сторон.

Клиент может быть сообществом.

Клиент не всегда ПРИНЦИПАЛ (прокси).

Заказчиком может быть команда со следующими потенциальными членами —

Менеджеры по продукту

Маркетинговые продажи

Бизнес аналитики

Конечные пользователи, их менеджеры

Бизнес / Системные операции

Основные обязанности Заказчика:

• Напишите истории пользователей

• Написать функциональные тесты

• Установите приоритеты на истории

• Объяснять истории

• Решите вопросы об истории

Напишите истории пользователей

Написать функциональные тесты

Установите приоритеты на истории

Объяснять истории

Решите вопросы об истории

Клиент несет ответственность за эти обязанности.

Менеджер

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

• Определите правила планирования игры.

• Познакомьте команду и заказчика с правилами планирования игры.

• Следите за планированием игры, исправляйте любые отклонения, изменяйте правила при необходимости.

• Планируйте и проводите встречи по планированию релизов и итерации.

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

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

• Отслеживание дефектов функционального тестирования.

• Отслеживайте фактическое время, потраченное каждым членом команды.

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

Определите правила планирования игры.

Познакомьте команду и заказчика с правилами планирования игры.

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

Планируйте и проводите встречи по планированию релизов и итерации.

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

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

Отслеживание дефектов функционального тестирования.

Отслеживайте фактическое время, потраченное каждым членом команды.

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

Тренер

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

Обязанности тренера:

• Понимать, глубоко, применение экстремального программирования в проекте.

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

• Сохраняйте спокойствие, даже когда все остальные паникуют.

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

• Следите за тем, чтобы команда была самостоятельной.

• Будь готов помочь.

Понимать, глубоко, применение экстремального программирования в проекте.

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

Сохраняйте спокойствие, даже когда все остальные паникуют.

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

Следите за тем, чтобы команда была самостоятельной.

Будь готов помочь.

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

В этой главе мы поймем действия и артефакты экстремального программирования.

XP — Деятельность

В экстремальном программировании четыре основных вида деятельности —

• кодирование

• тестирование

• прослушивание

• Проектирование

кодирование

тестирование

прослушивание

Проектирование

кодирование

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

тестирование

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

прослушивание

В парном программировании вы слушаете, чтобы знать, что кодировать или что тестировать. Если вы не слушаете, вы не знаете, что кодировать или что тестировать.

Проектирование

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

Эти действия выполняются во время —

• Планирование релиза

• Планирование итерации

• Реализация

Планирование релиза

Планирование итерации

Реализация

Планирование релиза

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

Планирование релиза имеет три этапа —

• Этап разведки

• Фаза обязательств

• Фаза управления

Этап разведки

Фаза обязательств

Фаза управления

Планирование релиза — фаза исследования

На этапе разведки —

• Заказчик предоставляет краткий перечень важных требований к системе.

• Разработчики собирают требования и оценивают влияние работы каждого из этих требований.

Заказчик предоставляет краткий перечень важных требований к системе.

Разработчики собирают требования и оценивают влияние работы каждого из этих требований.

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

Активное прослушивание важно на этом этапе, так как

• Разработчики должны понимать, «что заказчик просит» и «какие требования имеют большую ценность».

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

Разработчики должны понимать, «что заказчик просит» и «какие требования имеют большую ценность».

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

Несмотря на то, что клиент записывает требования на карточках пользователей, вам необходимо

• Получить ясность

• Избегайте двусмысленности

• Выразите себя, если есть возможные пробелы в понимании

Получить ясность

Избегайте двусмысленности

Выразите себя, если есть возможные пробелы в понимании

Это возможно только при устном общении.

Планирование релиза — Фаза обязательств

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

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

• Заказчик сортирует пользовательские истории по стоимости бизнеса.

• Разработчики сортируют истории по риску.

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

• Пользовательские истории, которые будут закончены в следующем выпуске, будут выбраны.

• На основе пользовательских историй и оценок определяется дата выпуска.

Заказчик сортирует пользовательские истории по стоимости бизнеса.

Разработчики сортируют истории по риску.

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

Пользовательские истории, которые будут закончены в следующем выпуске, будут выбраны.

На основе пользовательских историй и оценок определяется дата выпуска.

Активное слушание важно на этом этапе, так как —

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

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

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

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

Планирование выпуска — фаза управления

На этапе рулевого управления заказчик и разработчики «рулят» —

• Вносить изменения в отдельные пользовательские истории и относительные приоритеты различных пользовательских историй.

• Чтобы скорректировать план.

• Если оценки оказались неверными.

• Для размещения изменений.

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

Чтобы скорректировать план.

Если оценки оказались неверными.

Для размещения изменений.

Активное слушание важно на этом этапе,

• Чтобы понять —

  • Новые требования будут добавлены.

  • Какие изменения необходимо внести в существующие требования.

  • Влияние на существующую систему, если какое-либо из существующих требований будет удалено.

• Получите оценки, необходимые для корректировки плана, учитывая

  • Работа проделана до сих пор.

  • Новые требования будут добавлены.

  • Существующие требования, которые должны быть изменены или удалены.

Чтобы понять —

Новые требования будут добавлены.

Какие изменения необходимо внести в существующие требования.

Влияние на существующую систему, если какое-либо из существующих требований будет удалено.

Получите оценки, необходимые для корректировки плана, учитывая

Работа проделана до сих пор.

Новые требования будут добавлены.

Существующие требования, которые должны быть изменены или удалены.

Планирование итерации

В Планировании итерации разработчики участвуют в планировании действий и задач для итерации. В этом заказчик не участвует.

Планирование итерации имеет три этапа —

• Этап разведки.

• Фаза обязательств.

• Фаза рулевого управления.

Этап разведки.

Фаза обязательств.

Фаза рулевого управления.

Планирование итерации — фаза исследования

На этапе разведки,

• Требования будут переведены на разные задачи.

• Задачи записаны на карточках задач.

• Разработчики оценивают время, которое потребуется для реализации каждой задачи.

• Если разработчики не могут оценить задачу, потому что она слишком мала или слишком велика, им нужно объединить или разделить задачу.

Требования будут переведены на разные задачи.

Задачи записаны на карточках задач.

Разработчики оценивают время, которое потребуется для реализации каждой задачи.

Если разработчики не могут оценить задачу, потому что она слишком мала или слишком велика, им нужно объединить или разделить задачу.

Планирование итерации — Фаза обязательств

На этапе принятия обязательств,

• Задачи возлагаются на разработчиков.

• Разработчик принимает задачи, за которые он или она берет на себя ответственность.

• Разработчик оценивает время, необходимое для выполнения задачи, потому что разработчик теперь отвечает за задачу, и он или она должны дать окончательную оценку задачи.

• Балансировка нагрузки выполняется после того, как всем разработчикам в команде были назначены задачи.

• Проводится сравнение между расчетным временем выполнения задач и коэффициентом загрузки.

• Коэффициент загрузки представляет собой идеальное количество практического времени разработки на одного разработчика в течение одной итерации при условии 40-часовой рабочей недели.

• Тогда задачи уравновешиваются среди разработчиков. Если разработчик перегружен, другие разработчики должны взять на себя некоторые из его или ее Задач и наоборот.

Задачи возлагаются на разработчиков.

Разработчик принимает задачи, за которые он или она берет на себя ответственность.

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

Балансировка нагрузки выполняется после того, как всем разработчикам в команде были назначены задачи.

Проводится сравнение между расчетным временем выполнения задач и коэффициентом загрузки.

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

Тогда задачи уравновешиваются среди разработчиков. Если разработчик перегружен, другие разработчики должны взять на себя некоторые из его или ее Задач и наоборот.

Планирование итерации — этап управления

На этапе управления,

• Разработчик получает карточку задачи для одной из задач, которые он или она совершили.

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

Разработчик получает карточку задачи для одной из задач, которые он или она совершили.

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

Реализация

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

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

Экстремальное программирование не является антидокументированием, но поощряет делать минимальное количество, которое действительно необходимо. Документ, когда это необходимо для распределенного обмена, исторических потребностей, подведения итогов и т. Д.

Основные артефакты экстремального программирования —

• Пользовательские истории

• Приемочные испытания

• оценки

• План выпуска

• План итерации

• Карты задач

• дизайн

• Модульные тесты

• Записи общения с клиентами и разработчиками

Пользовательские истории

Приемочные испытания

оценки

План выпуска

План итерации

Карты задач

дизайн

Модульные тесты

Записи общения с клиентами и разработчиками

Карты истории пользователя

Карты истории пользователя имеют следующие особенности:

• Карта истории пользователя —

  • Содержит краткое описание поведения системы с точки зрения заказчика.

  • Должно быть написано заказчиком, а не разработчиками.

  • Использует терминологию заказчика без технических терминов.

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

• Один для каждой основной функции в системе.

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

• Диск создания приемочных испытаний.

Карта истории пользователя —

Содержит краткое описание поведения системы с точки зрения заказчика.

Должно быть написано заказчиком, а не разработчиками.

Использует терминологию заказчика без технических терминов.

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

Один для каждой основной функции в системе.

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

Диск создания приемочных испытаний.

Приемочные испытания

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

Оценки — Планирование выпуска

Оценки усилий и продолжительности для историй, которые будут использоваться при планировании релизов —

• Прибытие к целевой дате выпуска на этапе разведки.

• План корректировки на этапе рулевого управления.

Прибытие к целевой дате выпуска на этапе разведки.

План корректировки на этапе рулевого управления.

План выпуска

План релиза содержит —

• Пользовательские истории, выбранные для релиза.

• Оценка усилий и продолжительности.

• Целевая дата выпуска, которая зафиксирована.

Пользовательские истории, выбранные для релиза.

Оценка усилий и продолжительности.

Целевая дата выпуска, которая зафиксирована.

Карты задач

Карта задач —

• Содержит необходимые задачи для реализации пользовательской истории.

• Одна карта задач на историю пользователя.

• Формы основы для оценки задач и задач.

Содержит необходимые задачи для реализации пользовательской истории.

Одна карта задач на историю пользователя.

Формы основы для оценки задач и задач.

Оценки — планирование итераций

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

План итерации

План итерации содержит —

• Пользовательские истории, выбранные для итерации

• Назначение задач

• Оценка заданий

Пользовательские истории, выбранные для итерации

Назначение задач

Оценка заданий

дизайн

Дизайн содержит простой дизайн, достаточный для реализации пользовательской истории.

Модульные тесты

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

Отчеты о взаимодействии с клиентами и разработчиками

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

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

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

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

Игра, на которую мы ссылаемся в экстремальном программировании, — это игра в планирование.

Правила планирования игры

В Extreme Programming игра по планированию начинается с первого совещания по планированию и заканчивается финальным выпуском.

Вы должны определить правила Игры Планирования в соответствии с практиками Экстремального Программирования до первого совещания по планированию релиза и ознакомиться с правилами для бизнеса и команды. Вы должны управлять проектом, гарантируя соблюдение правил.

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

Цель игры — максимизировать ценность программного обеспечения, созданного командой. Из стоимости программного обеспечения вы должны вычесть стоимость его разработки и риск, понесенный в процессе разработки.

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

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

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

Основные правила планирования игры можно разбить на следующие области —

• планирование

• Управление

• Проектирование

• кодирование

• тестирование

планирование

Управление

Проектирование

кодирование

тестирование

планирование

Планирование выполняется во время планирования выпуска и итерационного планирования. Правила одинаковы для обоих.

В планировании релиза

• Бизнес и команда — игроки.

• Карты истории используются.

• Пользовательские истории написаны заказчиком на карточках историй.

• Пользовательские истории написаны заказчиком на карточках историй.

• Бизнес решается с приоритетом функциональности для реализации.

• Оценки даются командой на основе карт истории.

• Короткие (часто небольшие) релизы должны быть запланированы

• График релиза должен быть создан по взаимному согласию.

• Следующий выпуск должен быть разделен на итерации.

Бизнес и команда — игроки.

Карты истории используются.

Пользовательские истории написаны заказчиком на карточках историй.

Пользовательские истории написаны заказчиком на карточках историй.

Бизнес решается с приоритетом функциональности для реализации.

Оценки даются командой на основе карт истории.

Короткие (часто небольшие) релизы должны быть запланированы

График релиза должен быть создан по взаимному согласию.

Следующий выпуск должен быть разделен на итерации.

Планирование итерации запускает каждую итерацию.

В планировании итераций

• Члены команды — игроки.

• Карты задач используются.

• Для каждой истории, выбранной для итерации, создаются карты задач.

• Члены команды должны оценить задачи на основе карт задач.

• Каждому члену команды присваиваются карточки с заданиями.

• Каждый член команды должен затем переоценить на основе его или ее назначения, для

  • Принимая работу.

  • Взять на себя ответственность за завершение работы.

  • Получение обратной связи о фактическом времени.

  • Улучшение оценок.

  • Уважая эти оценки.

Члены команды — игроки.

Карты задач используются.

Для каждой истории, выбранной для итерации, создаются карты задач.

Члены команды должны оценить задачи на основе карт задач.

Каждому члену команды присваиваются карточки с заданиями.

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

Принимая работу.

Взять на себя ответственность за завершение работы.

Получение обратной связи о фактическом времени.

Улучшение оценок.

Уважая эти оценки.

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

• Окончательное назначение выполняется с учетом 40-часовой недели и коэффициента загрузки.

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

Управление

• Команде предоставляется выделенное открытое рабочее пространство.

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

• Должны быть установлены устойчивые темпы (40-часовая неделя и не сверхурочные в течение более одной недели) и управление ими.

• Применяйте правила планирования игры.

• Исправление любой экстремальной практики программирования, когда она ломается.

• Обеспечить общение в команде.

• Препятствуйте общению, которое —

  • не полезно

  • не в нужное время

  • сделано очень подробно

• Заставить людей двигаться.

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

• Делайте еду доступной для команды по мере необходимости.

Команде предоставляется выделенное открытое рабочее пространство.

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

Должны быть установлены устойчивые темпы (40-часовая неделя и не сверхурочные в течение более одной недели) и управление ими.

Применяйте правила планирования игры.

Исправление любой экстремальной практики программирования, когда она ломается.

Обеспечить общение в команде.

Препятствуйте общению, которое —

не полезно

не в нужное время

сделано очень подробно

Заставить людей двигаться.

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

Делайте еду доступной для команды по мере необходимости.

Проектирование

Правила проектирования —

• Выберите метафору для системы и развивайте ее по мере развития.

• Сохраняйте дизайн простым.

• Никакой функциональности не добавляется рано.

• Внедрите столько архитектуры, сколько вам нужно для удовлетворения ваших текущих потребностей, и верьте, что вы сможете добавить больше в будущем

• Рефакторинг всегда и везде, где это возможно.

Выберите метафору для системы и развивайте ее по мере развития.

Сохраняйте дизайн простым.

Никакой функциональности не добавляется рано.

Внедрите столько архитектуры, сколько вам нужно для удовлетворения ваших текущих потребностей, и верьте, что вы сможете добавить больше в будущем

Рефакторинг всегда и везде, где это возможно.

кодирование

Правила кодирования —

• Бизнес (который представляет клиента) всегда должен быть доступен.

• Разработчики должны писать весь код в соответствии с правилами, подчеркивающими связь через код.

• Парное программирование должно быть обеспечено.

• Стандарты кодирования должны соблюдаться.

• Весь код должен иметь модульные тесты.

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

• Когда вы кодируете, вы должны носить только одну из следующих четырех шляп —

  • Добавление нового функционала, но только изменение реализации.

  • Добавляем новый функционал, но только меняем интерфейс.

  • Рефакторинг кода, но только изменение реализации.

  • Рефакторинг кода, но только смена интерфейса.

• Выделенная рабочая станция интеграции предоставляется для всей команды.

• Только одна пара интегрирует код за раз и гарантирует, что все тесты пройдены.

• Интеграция должна быть сделана часто.

• Коллективная собственность должна быть использована.

Бизнес (который представляет клиента) всегда должен быть доступен.

Разработчики должны писать весь код в соответствии с правилами, подчеркивающими связь через код.

Парное программирование должно быть обеспечено.

Стандарты кодирования должны соблюдаться.

Весь код должен иметь модульные тесты.

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

Когда вы кодируете, вы должны носить только одну из следующих четырех шляп —

Добавление нового функционала, но только изменение реализации.

Добавляем новый функционал, но только меняем интерфейс.

Рефакторинг кода, но только изменение реализации.

Рефакторинг кода, но только смена интерфейса.

Выделенная рабочая станция интеграции предоставляется для всей команды.

Только одна пара интегрирует код за раз и гарантирует, что все тесты пройдены.

Интеграция должна быть сделана часто.

Коллективная собственность должна быть использована.

тестирование

Правила тестирования:

• Все коды должны пройти все модульные тесты, прежде чем они будут выпущены.

• Тесты должны быть написаны, когда обнаружен дефект.

• Приемочные испытания должны проводиться часто.

Все коды должны пройти все модульные тесты, прежде чем они будут выпущены.

Тесты должны быть написаны, когда обнаружен дефект.

Приемочные испытания должны проводиться часто.

Экстремальное программирование — дополнительные функции

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

Петли обратной связи

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

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

Следующая таблица иллюстрирует события обратной связи и продолжительность обратной связи.

Обратная связь Событие	Длительность обратной связи
Парное программирование	секунд
Модульное тестирование	минут
Разъяснения среди Команды и с Заказчиком	часов
Прогресс	В день
Приемочное тестирование	дней
Планирование итерации	Недели
Планирование релиза	Месяцы

Управление проектом

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

Тем не менее, эти действия включают требования управления проектом.

• Планирование релиза

  • Область действия определяется пользовательскими историями в карточках историй.

  • Оценки — это оценки историй, которые могут быть в историях.

  • Вехи доставки фиксируются планами выпуска.

  • Релиз делится на итерации.

• Планирование итерации

  • Истории вдуваются в задания в карточках задач.

  • Оценки являются оценочными заданиями.

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

  • Принятие задачи — обязательство и ответственность команды.

• отслеживание

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

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

  • Отслеживание дефектов

Планирование релиза

Область действия определяется пользовательскими историями в карточках историй.

Оценки — это оценки историй, которые могут быть в историях.

Вехи доставки фиксируются планами выпуска.

Релиз делится на итерации.

Планирование итерации

Истории вдуваются в задания в карточках задач.

Оценки являются оценочными заданиями.

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

Принятие задачи — обязательство и ответственность команды.

отслеживание

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

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

Отслеживание дефектов

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

Из проектов экстремального программирования, выполняемых в отрасли, есть определенные знания, полезные для команд.

Уроки из практики XP

В следующих разделах вы получите представление об этих уроках.

• Простой дизайн — простой дизайн эффективен, прост в сборке и обслуживании.

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

• Коллективное владение — каждый гордится своим хорошим кодом. Работая вместе, каждый гордится кодом каждого.

• Планирование — если команда завершает много пользовательских историй за итерацию, сделайте итерации меньшими. Иметь консенсус команды, чтобы изменить план.

Простой дизайн — простой дизайн эффективен, прост в сборке и обслуживании.

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

Коллективное владение — каждый гордится своим хорошим кодом. Работая вместе, каждый гордится кодом каждого.

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

Scaling Extreme Программирование

Первоначально экстремальное программирование считалось эффективным в небольших командах, с размером команды до 12-16 разработчиков.

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

Документация

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

Преимущества применения XP

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

• Среды, которые очень неопределенны

• Внутренние проекты

• Совместные предприятия

Среды, которые очень неопределенны

Внутренние проекты

Совместные предприятия

Недостатки применения XP

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

• Среды большие и сложные.

• Требования хорошо поняты.

• Клиент находится на расстоянии или недоступен.

Среды большие и сложные.

Требования хорошо поняты.

Клиент находится на расстоянии или недоступен.

Заблуждения XP

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

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

Скрам + Экстрим Программирование

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

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

XP — гибкость как техника

Одна из причин популярности Extreme Programming — его гибкость. Более того, экстремальное программирование больше относится к технике, чем к процессу, и, следовательно, хорошо сочетается с процессно-ориентированными подходами. Таким образом, вы можете легко комбинировать функции экстремального программирования с другими идеями, где бы вы ни находились

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

• Экстремальное программирование само по себе не подходит для реализации.

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

Экстремальное программирование само по себе не подходит для реализации.

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

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

Самым популярным гибридом Extreme Programming, который в настоящее время используется, является гибрид Scrum + Extreme Programming. Мы начнем с базовой и все еще распространенной методологии разработки программного обеспечения — модели водопада.

Модель водопада

В модели водопада развитие развивается поэтапно, и никакая фаза не может начаться до завершения более ранней фазы.

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

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

Давайте посмотрим на недостатки методологии водопада —

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

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

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

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

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

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

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

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

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

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

Если вы прогнозируете такие условия в своем развитии, Agile методологии являются наиболее подходящими.

Agile методологии

Сторонник Agile методологии —

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

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

• Гибкое планирование, ориентированное на обеспечение ценности для клиента, удовлетворение ожиданий клиента, возврат инвестиций.

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

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

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

Гибкое планирование, ориентированное на обеспечение ценности для клиента, удовлетворение ожиданий клиента, возврат инвестиций.

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

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

Как Scrum делает разницу?

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

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

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

• Спринт с временными рамками не даст никакой гибкости в графике выпуска, что затруднит как разработку, так и тестирование.

• Scrum, сам по себе не дает указаний для развития.

Спринт с временными рамками не даст никакой гибкости в графике выпуска, что затруднит как разработку, так и тестирование.

Scrum, сам по себе не дает указаний для развития.

Следовательно, Scrum обычно объединяется с другими Agile-методологиями, которые больше фокусируются на стратегиях развития.

Скрам + Экстрим Гибрид Программирования

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

• Поскольку Scrum — это определенная методология, ее легче адаптировать с первого дня проекта.

• Поскольку Extreme Programming больше ориентируется на общение и сплоченность команды, команда больше сосредоточена на развитии.

Поскольку Scrum — это определенная методология, ее легче адаптировать с первого дня проекта.

Поскольку Extreme Programming больше ориентируется на общение и сплоченность команды, команда больше сосредоточена на развитии.

Таким образом, гибрид Scrum + Extreme Programming оказался эффективным.

Инструменты для гибридных проектов Scrum + XP

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

Некоторые из показателей —

• Требования к тестовому покрытию
• Задача Прогресс
• Скорость проекта
• Основные риски и проблемы

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

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

В этой главе мы узнаем о некоторых инструментах, используемых в экстремальном программировании.

ExtremePlanner

ExtremePlanner — это решение для управления Agile Project на основе браузера, специально разработанное для поддержки Agile-методов, включая Scrum и Extreme Programming.

ExtremePlanner концентрируется на планировании и отслеживании развития функций (или пользовательских историй), которые имеют реальную ценность для бизнеса для клиентов.

Ключевые особенности ExtremePlanner —

• Поддерживает всю команду, включая менеджеров проектов, разработчиков, QA, техподдержку и заинтересованных лиц.

• Оценивает и планирует выпуски программного обеспечения с легкостью перетаскивания.

• Управляет функциями, дефектами, тестовыми примерами и задачами разработки в одном месте.

• Имеет интегрированное отслеживание проблем для управления запросами клиентов от начала до конца.

• Предоставлены последние изменения с уведомлениями по электронной почте и отчетами о деятельности проекта.

Поддерживает всю команду, включая менеджеров проектов, разработчиков, QA, техподдержку и заинтересованных лиц.

Оценивает и планирует выпуски программного обеспечения с легкостью перетаскивания.

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

Имеет интегрированное отслеживание проблем для управления запросами клиентов от начала до конца.

Предоставлены последние изменения с уведомлениями по электронной почте и отчетами о деятельности проекта.

Для получения дополнительной информации — www.extremeplanner.com

Система планирования и отслеживания проектов

PPTS — это веб-среда, поддерживающая команды, которые решили разрабатывать программное обеспечение в соответствии с методологией Agile Scrum и / или Extreme Programming.

Функциональность PPTS включает в себя —

• Администрирование проекта, итерации и атрибутов ресурса

• Отставание продукта, которое может быть приоритетным

• Структура разбивки работ (отставание в спринте)

• Метрики (скорость и расчетное / затраченное усилие)

• Burndown и графики прогресса

• Календари

• Распределение ресурсов

• Детальный доступ к информации на основе общей роли (администратор или пользователь) или роли в проекте (руководитель проекта, разработчик или клиент)

• Настройка меню и языка (доступны английский и голландский языки)

• Взаимодействие с инструментами PR / CR

Администрирование проекта, итерации и атрибутов ресурса

Отставание продукта, которое может быть приоритетным

Структура разбивки работ (отставание в спринте)

Метрики (скорость и расчетное / затраченное усилие)

Burndown и графики прогресса

Календари

Распределение ресурсов

Детальный доступ к информации на основе общей роли (администратор или пользователь) или роли в проекте (руководитель проекта, разработчик или клиент)

Настройка меню и языка (доступны английский и голландский языки)

Взаимодействие с инструментами PR / CR

Для получения дополнительной информации — http://ses-ppts.sourceforge.net/

TargetProcess

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

Targetprocess обеспечивает необходимую прозрачность и прозрачность в вашей организации. Targetprocess, от Kanban и Scrum практически до любого операционного процесса, гибко адаптируется к вашему подходу к управлению и организационной структуре.

Targetprocess обеспечивает —

• Доски для планирования и отслеживания прогресса. Представление «Board» предоставляет множество возможностей для удобной работы с большим количеством карт.

• Доски, которыми можно поделиться с любым человеком, чтобы транслировать информацию извне. Они гибкие.

• Несколько карт могут быть перемещены с помощью перетаскивания.

• Списки для иерархии проектов и легко управлять бэкапами.

• Полная настройка, встроенное редактирование и красивый дизайн.

• Графические отчеты.

• Хронологические.

• Пользовательские виды.

• Сводки.

Доски для планирования и отслеживания прогресса. Представление «Board» предоставляет множество возможностей для удобной работы с большим количеством карт.

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

Несколько карт могут быть перемещены с помощью перетаскивания.

Списки для иерархии проектов и легко управлять бэкапами.

Полная настройка, встроенное редактирование и красивый дизайн.

Графические отчеты.

Хронологические.

Пользовательские виды.

Сводки.

Для получения дополнительной информации — www.targetprocess.com

Plone Extreme Management Tool

Инструмент Plone Extreme Management обеспечивает администрирование проекта, поддерживающее методологию Extreme Programming.

Инструмент Plone Extreme Management обеспечивает —

• Типы контента —

  • Проект — Менеджеры проектов могут добавлять несколько проектов. Для каждого проекта итерации и истории могут быть добавлены как клиентами, так и сотрудниками.

  • Итерация — проект будет планироваться с итерациями. Итерация — это период от 1 до 3 недель, в течение которого будет реализовано несколько историй.

  • Предложение — содержит истории, которые клиент хочет в этом проекте. Он используется как способ связать пожелания клиента и дать первое представление о размере проекта.

  • История — клиент может определить новые функции, описав их в истории.

  • Задача — сотрудники могут оценить историю, определив задачи.

  • Бронирование — Работая над задачами, сотрудники могут отслеживать время и легко бронировать их в конце дня.

• Workflow.

• Время трекера.

• План выпуска.

• Обзор итераций.

Типы контента —

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

Итерация — проект будет планироваться с итерациями. Итерация — это период от 1 до 3 недель, в течение которого будет реализовано несколько историй.

Предложение — содержит истории, которые клиент хочет в этом проекте. Он используется как способ связать пожелания клиента и дать первое представление о размере проекта.

История — клиент может определить новые функции, описав их в истории.

Задача — сотрудники могут оценить историю, определив задачи.

Бронирование — Работая над задачами, сотрудники могут отслеживать время и легко бронировать их в конце дня.

Workflow.

Время трекера.

План выпуска.

Обзор итераций.

Инструменты XP для разработчиков Java

В следующей таблице приведен список инструментов для разработчиков Java для связанных действий.

Инструменты программирования Java Extreme	Деятельность
Мавен и Муравейник	Управление проектами и постоянная интеграция.
Муравей и XDoclet	Автоматизированное строительство и непрерывная интеграция.
Муравейник и КруизКонтроль	Автоматизация непрерывной интеграции.
IntelliJ Идея, Xrefactory, DPT, Jfactor, Jrefactory	Java рефакторинг.
JUnit	Автоматизированное тестирование Java.
Кактус	Автоматизированное тестирование сервлетов, JSP и других J2EE.
Джемми, JFCUnit и Аббат	Автоматическое тестирование свинга.

Инструменты XP для разработчиков .Net

В соответствии с Java, .Net имеет NAnt, NUnit, CruiseControl.NET. Visual Studio имеет много инструментов рефакторинга.

Принятие XP в вашей организации

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

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

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