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

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

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

Игра, на которую мы ссылаемся в экстремальном программировании, - это игра в планирование.

Правила планирования игры

В экстремальном программировании игра планирования начинается с первого совещания по планированию и заканчивается финальным выпуском.

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

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

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

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

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

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

Основные правила планирования игры можно разделить на следующие области -

  • планирование

  • Управление

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

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

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

планирование

Планирование выполняется во время планирования выпуска и итерационного планирования. Правила одинаковы для обоих.

В планировании релиза

  • Бизнес и команда - игроки.

  • Карты истории используются.

  • Пользовательские истории пишутся заказчиком на карточках историй.

  • Пользовательские истории пишутся заказчиком на карточках историй.

  • Бизнес решается с приоритетом функциональности для реализации.

  • Оценки даются командой на основе карт истории.

  • Короткие (часто небольшие) релизы должны быть запланированы

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

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

Планирование итерации запускает каждую итерацию.

В планировании итераций

  • Члены команды - игроки.

  • Карты задач используются.

  • Для каждой истории, выбранной для итерации, создаются карты задач.

  • Члены команды должны оценить задачи на основе карт задач.

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

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

    • Принимая работу.

    • Взять на себя ответственность за завершение работы.

    • Получение обратной связи о фактическом времени.

    • Улучшение оценок.

    • Уважая эти оценки.

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

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

Управление

  • Команде предоставляется выделенное открытое рабочее пространство.

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

  • Должны быть установлены устойчивые темпы (40-часовая неделя и сверхурочная работа более одной недели) и управление ими.

  • Применяйте правила планирования игры.

  • Исправление любой экстремальной практики программирования, когда она ломается.

  • Обеспечить общение в команде.

  • Препятствуйте общению, которое -

    • не полезно

    • не в нужное время

    • сделано очень подробно

  • Заставить людей двигаться.

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

  • Делайте еду доступной для команды по мере необходимости.

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

Правила проектирования -

  • Выберите метафору для системы и развивайте ее по мере развития.

  • Сохраняйте дизайн простым.

  • Никакой функциональности не добавляется рано.

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

  • Рефакторинг всегда и везде, где это возможно.

кодирование

Правила кодирования -

  • Бизнес (который представляет клиента) всегда должен быть доступен.

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

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

  • Стандарты кодирования должны соблюдаться.

  • Весь код должен иметь модульные тесты.

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

  • Когда вы кодируете, вы должны носить только одну из следующих четырех шляп -

    • Добавление нового функционала, но только изменение реализации.

    • Добавляем новый функционал, но только меняем интерфейс.

    • Рефакторинг кода, но только изменение реализации.

    • Рефакторинг кода, но только смена интерфейса.

  • Выделенная рабочая станция интеграции предоставляется для всей команды.

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

  • Интеграция должна быть сделана часто.

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

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

Правила тестирования:

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

  • Тесты должны быть написаны, когда дефект найден.

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