4. Экстремальное программирование (хр)

1. Теория

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

В ХР четко описаны все роли. Каждая роль предусматривает характерный набор прав и обязанностей. Существует 2 ключевые роли: заказчик и разработчик. Каждая из базовых ролей может уточняться более мелкими ролями. И также возможно совмещение ролей в рамках 1ого человека.

Сторона заказчика:

1. составитель историй – ответственен за написание историй пользователя и прояснения недопонимания со стороны программистов.

2. Приемщик – человек, контролирующий правильность функционирования системы.

3. Большой босс – следит за работой всех звеньев, от разработчиков до конечных пользователей. Может быть инвестором проекта.

Сторона разработчика:

1. Программист – человек, занимающийся кодированием и проектированием на низком уровне.

2. Инструктор – опытный разработчик, владеющий всем процессом разработки и его методиками. Обучает команду аспектам процесса разработки.

3. Наблюдатель – следит за процессом разработки. Сравнивает оценки трудозатрат и реальные показатели

4. Дипломат – инициирует общение между членами команды. Регулирует и упрощает общение между заказчиком и разработчиками.

Внешние роли:

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

Правила

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

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

3. CRC Сессия (Класс, Обязанности, Взаимодействие) – карточки для дизайна системы командой. Это позволяет мыслить объектами, а не функциями и процедурами. Также позволяет большему кол-ву людей участвовать в процессе дизайна. Каждая карточка – экземпляр объекта. CRC сессия происходит так: каждый из участников воспроизводит систему говоря какие сообщения он шлет каким объектам. Проходит по всему процессу сообщение за сообщением. Слабые места и проблемы проявляются сразу.

4. Заказчик всегда доступен. Он должен быть членом команды разработчиков. Во время планирования заказчик должен предоставить свою User Story, которые будут включены в проект.

5. Выбирайте самое простое решение. Сохраняйте решения насколько возможно простыми и как можно дольше. Но сохранять дизайн простым – тяжелая работа.

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

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

8. Планирование итерации. Для итерации выбираются User Store, а также включают функциональные тесты. User Store и невыполненные функциональные тесты разбиваются на задачи. Задачи записывают на карточках. Эти карточки и есть детальный план на итерацию. Каждая задача должна быть продолжительностью от 1-3 дней. Т.о. разработчик сами оценивает сколько времени задача займет именно у него. Возможно придется переделывать план каждые 3-5 итераций. Это нормально.

9. Итерации. Итеративная разработка увеличивает гибкость процесса. Разделите ваш план на итерации продолжительность. От 2-3 недель. Это тот ритм, который позволяет сделать измерение прогресса и планирование простым и надежным. Т.о. возможно держать под контролем изменяющиеся требования заказчика.

10. Меняйтесь задачами. Для уменьшения риска концентрации знаний и узких мест в коде. Вместо1 человека, который знает все о данном куске кода, несколько программистов могут работать над ним одновременно. Команда становится намного более гибкой.

11. Оставляйте оптимизацию на потом. Никогда не оптимизируйте ничего до окончания кодирования.

12. Парное программирование. Весь код для продукционной системы пишется парами. Один работает, другой смотрит. Потом они меняются. Принцип «Одна голова хорошо, а две лучше». Увеличивается качество кода, снижается число ошибок и ускоряется обмен знаниями между разработчиками.

13. Рефакторинг – экономит время и улучшает качество продукта. Пересматривайте код, чтобы сохранять дизайн простым, ясным и понятным, удостоверьтесь, что все написано 1 раз.

14. План Релиза – разрабатывается на собрании по планированию Релиза. Релиз Планы описывают взгляд на весь проект и используют в дальнейшем для планирования итераций. Планирование Релиза определяет набор правил, которые определяют метод выработки удовлетворяющего всех плана работ. Сущность в том, чтобы определить каждую User Store в идеальных неделях (сколько времени займет выполнение задачи).

15. Собрание стоя. Каждое утро проводится собрание для обсуждения проблем, их решений и для усиления концентрации команды.

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

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