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

Дизайн

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

Практики XP

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

• Планирование
• Дизайн
• Кодирование
• Тестирование

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

• Пользовательские истории (User stories) – пользовательские истории играют похожую роль что и варианты использования (Use-case). Они используются для сбора требований пользователей и планирования итераций. Пользовательские истории записываются пользователями (или разработчиками под диктовку пользователей) и описывают то что система должна делать с точки зрения пользователя получающего результат. Обычно они занимают три предложения обычного текста без использования технических терминов. Кроме того, пользовательские истории используются для создания приёмочных тестов (acceptance test). Один план итерации включает как правило около 80 пользовательских историй, котрые требуется реализовать в рамках данной итерации.
• Планирование релиза. – этот (совместный пользователи и разработчики) процесс решает какие пользовательские истории или требования должны быть реализованы и какие итерации предстоят в рамках релиза. (Т.е. релиз состоит из нескольких итераций)
• Необходимо выпускать частые маленькие релизы. Одной из задач планирования релизов является выявление обособленной группы функциональности которая имеет какое либо существенное бизнес-значение.
• Релиз делится на итерации, каждая длится 1 – 3 недели. Недопускается менять сроки итерации, и если становиться ясно, что какая то функциональность не может быть реализована до конца итерации, не следует откладывать окончание итерации, а функциональность перенести на следующую итерацию.
• Планирование итерации – каждая итерация планируется заново, пользователи выбирают истории из тех которые вошли в план релиза, которые должны войти в следующую итерацию. Кроме того отводится время на исправление автоматических тестов и рефакторинг.
• Ротация людей – необходимо менять пары программистов, с тем что бы знания распространялись как можно быстрее и не возникало ситуаций при которых лишь один или два человека знают какую то конкретную часть системы.
• Стоячие совещания (stand-up meeting) – их следует проводить каждый день в назначенное время (желательно сутра) для того чтобы убеждаться что все чётко понимают свои ближайшие задачи, а кроме того чтобы повысить общение в проекте.

• Простота – необходимо делать самое простое решение которое удовлетворяет пользовательские истории. Заказчик платит за реализацию пользовательских историй а не за создание технологичных каркасов (frameworks).
• Метафора – я специально опускаю её определение – так как это нечто такое, что должно вести весь процесс в нужном направлении. Некоторые понимают под этим упрощённую версию языка предметной области. Хотя, на мой взгляд, это более глубокое понятие.
• Используйте CRC карточки (Class Responsibility Collaboration Card) для выработки дизайна классов. Каждая карточки может представлять объект. На ней удобно писать то что должен делать этот объект и за что он отвечает.
• Делайте технологические прототипы или быстрые решения на скорую руку (spike solution) – их суть заключается не в том чтобы реализовать функциональность пользовательской истории в полном объёме, а в том что бы лишь исследовать возможность её реализации тем или иным способом и далее чтобы дать адекватную оценку трудозатрат для её реализации.
• Пытайтесь делать систему как можно меньше загруженную функциональностью и механизмами, которые вам МОГУТ понадобится в дальнейшем.
• Проводите рефакторинг (Refactoring) всегда когда и где это возможно.

• Заказчик должен быть доступен всегда всем участникам проектной команды. Идеальной является ситуация, когда заказчик сидит в одной комнате с разработчиками.
• Используйте соглашения по кодированию (Coding Standards)
• Сначала пишется тест, потом код его реализующий.
• Весь код, который является частью системы (production code) – должен быть написан программистами в парах.
• Постоянная интеграция – существуют продукты, которые позволяют организовать среду разработки так, что система будет автоматически собираться из version manager’а (репозитория исходного кода) и проходить автоматическое тестирование. Постоянная интеграция позволяет выявлять ошибки как можно раньше, а следовательно стоимость их исправления остаётся невысокой (программисту гораздо проще вспомнить то что он делал пару часов назад, чем то что написал другой человек год назад).
• Коллективное владение кодом – в идеале в системе не должно быть частей или модулей закреплённых за одним каким либо программистом (или парой). Любой участник проектной команды имеет право вносить изменения, добавлять или рефакторить любой код системы.
• Не прибегайте к сверхурочной работе (overtime).

Дата добавления: 2014-01-05