Рассмотрим любой вид спорта, которым вы занимаетесь. Вы должны соблюдать правила этого вида спорта или игры. Аналогичным образом, в экстремальном программировании, поскольку весь проект определяется сотрудничеством между членами команды и бизнесом (который представляет клиента), определенные правила для проекта должны быть изложены в самом начале. Эти правила должны соответствовать практике экстремального программирования.
Правила предоставляют общую справочную информацию для всех в команде, чтобы они напоминали всем о том, что и как им нужно делать, когда дела идут гладко, а также когда они идут не очень хорошо.
Игра, на которую мы ссылаемся в экстремальном программировании, — это игра в планирование.
Правила планирования игры
В Extreme Programming игра по планированию начинается с первого совещания по планированию и заканчивается финальным выпуском.
Вы должны определить правила Игры Планирования в соответствии с практиками Экстремального Программирования до первого совещания по планированию релиза и ознакомиться с правилами для бизнеса и команды. Вы должны управлять проектом, гарантируя соблюдение правил.
Тем не менее, при разработке программного обеспечения не существует способа, которым простой набор правил применяется в каждом проекте. Они могут варьироваться в зависимости от бизнеса и команды, не ставя под угрозу практику экстремального программирования. Следовательно, набор правил с необходимыми целями может быть изначально введен в действие и может быть изменен по мере развития разработки только в случае необходимости.
Цель игры — максимизировать ценность программного обеспечения, созданного командой. Из стоимости программного обеспечения вы должны вычесть стоимость его разработки и риск, понесенный в процессе разработки.
Стратегия команды заключается в том, чтобы как можно меньше инвестировать, чтобы как можно быстрее внедрить наиболее ценные функциональные возможности в производство в сочетании со стратегиями проектирования и кодирования для снижения риска.
Принимая во внимание уроки технологии и бизнеса этой первой работающей системы, бизнесу становится ясно, что является наиболее ценной функциональностью, и команда быстро внедряет ее в производство.
Этот процесс продолжается итерациями и выпусками, пока вся разработка не будет завершена.
Основные правила планирования игры можно разбить на следующие области —
-
планирование
-
Управление
-
Проектирование
-
кодирование
-
тестирование
планирование
Управление
Проектирование
кодирование
тестирование
планирование
Планирование выполняется во время планирования выпуска и итерационного планирования. Правила одинаковы для обоих.
В планировании релиза
-
Бизнес и команда — игроки.
-
Карты истории используются.
-
Пользовательские истории написаны заказчиком на карточках историй.
-
Пользовательские истории написаны заказчиком на карточках историй.
-
Бизнес решается с приоритетом функциональности для реализации.
-
Оценки даются командой на основе карт истории.
-
Короткие (часто небольшие) релизы должны быть запланированы
-
График релиза должен быть создан по взаимному согласию.
-
Следующий выпуск должен быть разделен на итерации.
Бизнес и команда — игроки.
Карты истории используются.
Пользовательские истории написаны заказчиком на карточках историй.
Пользовательские истории написаны заказчиком на карточках историй.
Бизнес решается с приоритетом функциональности для реализации.
Оценки даются командой на основе карт истории.
Короткие (часто небольшие) релизы должны быть запланированы
График релиза должен быть создан по взаимному согласию.
Следующий выпуск должен быть разделен на итерации.
Планирование итерации запускает каждую итерацию.
В планировании итераций
-
Члены команды — игроки.
-
Карты задач используются.
-
Для каждой истории, выбранной для итерации, создаются карты задач.
-
Члены команды должны оценить задачи на основе карт задач.
-
Каждому члену команды присваиваются карточки с заданиями.
-
Каждый член команды должен затем переоценить на основе его или ее назначения, для
-
Принимая работу.
-
Взять на себя ответственность за завершение работы.
-
Получение обратной связи о фактическом времени.
-
Улучшение оценок.
-
Уважая эти оценки.
-
Члены команды — игроки.
Карты задач используются.
Для каждой истории, выбранной для итерации, создаются карты задач.
Члены команды должны оценить задачи на основе карт задач.
Каждому члену команды присваиваются карточки с заданиями.
Каждый член команды должен затем переоценить на основе его или ее назначения, для
Принимая работу.
Взять на себя ответственность за завершение работы.
Получение обратной связи о фактическом времени.
Улучшение оценок.
Уважая эти оценки.
Таким образом, правила для того, кто может составлять и изменять оценки, ясны.
-
Окончательное назначение выполняется с учетом 40-часовой недели и коэффициента загрузки.
Окончательное назначение выполняется с учетом 40-часовой недели и коэффициента загрузки.
Управление
-
Команде предоставляется выделенное открытое рабочее пространство.
-
Каждая рабочая станция должна быть расположена таким образом, чтобы два разработчика могли сидеть рядом и легко перемещать клавиатуру и мышь.
-
Должны быть установлены устойчивые темпы (40-часовая неделя и не сверхурочные в течение более одной недели) и управление ими.
-
Применяйте правила планирования игры.
-
Исправление любой экстремальной практики программирования, когда она ломается.
-
Обеспечить общение в команде.
-
Препятствуйте общению, которое —
-
не полезно
-
не в нужное время
-
сделано очень подробно
-
-
Заставить людей двигаться.
-
Измеряйте фактическое время и периодически сообщайте команде, чтобы каждый член команды знал производительность по сравнению с прогнозом. Это гарантирует, что член команды улучшится в оценке.
-
Делайте еду доступной для команды по мере необходимости.
Команде предоставляется выделенное открытое рабочее пространство.
Каждая рабочая станция должна быть расположена таким образом, чтобы два разработчика могли сидеть рядом и легко перемещать клавиатуру и мышь.
Должны быть установлены устойчивые темпы (40-часовая неделя и не сверхурочные в течение более одной недели) и управление ими.
Применяйте правила планирования игры.
Исправление любой экстремальной практики программирования, когда она ломается.
Обеспечить общение в команде.
Препятствуйте общению, которое —
не полезно
не в нужное время
сделано очень подробно
Заставить людей двигаться.
Измеряйте фактическое время и периодически сообщайте команде, чтобы каждый член команды знал производительность по сравнению с прогнозом. Это гарантирует, что член команды улучшится в оценке.
Делайте еду доступной для команды по мере необходимости.
Проектирование
Правила проектирования —
-
Выберите метафору для системы и развивайте ее по мере развития.
-
Сохраняйте дизайн простым.
-
Никакой функциональности не добавляется рано.
-
Внедрите столько архитектуры, сколько вам нужно для удовлетворения ваших текущих потребностей, и верьте, что вы сможете добавить больше в будущем
-
Рефакторинг всегда и везде, где это возможно.
Выберите метафору для системы и развивайте ее по мере развития.
Сохраняйте дизайн простым.
Никакой функциональности не добавляется рано.
Внедрите столько архитектуры, сколько вам нужно для удовлетворения ваших текущих потребностей, и верьте, что вы сможете добавить больше в будущем
Рефакторинг всегда и везде, где это возможно.
кодирование
Правила кодирования —
-
Бизнес (который представляет клиента) всегда должен быть доступен.
-
Разработчики должны писать весь код в соответствии с правилами, подчеркивающими связь через код.
-
Парное программирование должно быть обеспечено.
-
Стандарты кодирования должны соблюдаться.
-
Весь код должен иметь модульные тесты.
-
Сначала напишите модульный тест, прежде чем код будет написан для каждого компонента системы, чтобы было проще и быстрее создавать свой код. Общее время, необходимое для создания модульного теста и создания некоторого кода для его прохождения, равнозначно простому кодированию. Это облегчает регрессионное тестирование.
-
Когда вы кодируете, вы должны носить только одну из следующих четырех шляп —
-
Добавление нового функционала, но только изменение реализации.
-
Добавляем новый функционал, но только меняем интерфейс.
-
Рефакторинг кода, но только изменение реализации.
-
Рефакторинг кода, но только смена интерфейса.
-
-
Выделенная рабочая станция интеграции предоставляется для всей команды.
-
Только одна пара интегрирует код за раз и гарантирует, что все тесты пройдены.
-
Интеграция должна быть сделана часто.
-
Коллективная собственность должна быть использована.
Бизнес (который представляет клиента) всегда должен быть доступен.
Разработчики должны писать весь код в соответствии с правилами, подчеркивающими связь через код.
Парное программирование должно быть обеспечено.
Стандарты кодирования должны соблюдаться.
Весь код должен иметь модульные тесты.
Сначала напишите модульный тест, прежде чем код будет написан для каждого компонента системы, чтобы было проще и быстрее создавать свой код. Общее время, необходимое для создания модульного теста и создания некоторого кода для его прохождения, равнозначно простому кодированию. Это облегчает регрессионное тестирование.
Когда вы кодируете, вы должны носить только одну из следующих четырех шляп —
Добавление нового функционала, но только изменение реализации.
Добавляем новый функционал, но только меняем интерфейс.
Рефакторинг кода, но только изменение реализации.
Рефакторинг кода, но только смена интерфейса.
Выделенная рабочая станция интеграции предоставляется для всей команды.
Только одна пара интегрирует код за раз и гарантирует, что все тесты пройдены.
Интеграция должна быть сделана часто.
Коллективная собственность должна быть использована.
тестирование
Правила тестирования:
Все коды должны пройти все модульные тесты, прежде чем они будут выпущены.
Тесты должны быть написаны, когда обнаружен дефект.
Приемочные испытания должны проводиться часто.