eXtreme Programming

Ноябрь 2015

Содержание

1. Основы
2. Практики
3. Внедрение

История

• Первый XP проект был запущен 6 Марта 1996.
• В 1999 году опубликована книга Кента Бека "Extreme Programming Explained: Embrace Change".
• Авторы методологии: Кент Бек, Мартин Фаулер, Уорд Каннингем и другие.

Место XP

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

Кент Бек

Решаемые проблемы

• Смещение графиков
• Текучка кадров
• Количество дефектов
• Недостаток возможностей
• Потеря полезности/актуальности

Любая из этих проблем может привести к закрытию проекта.

Ценности ХР

• Общение
• Простота
• Обратная cвязь
• Смелость
• Уважение

Жизненный цикл

http://www.extremeprogramming.org

War Room

War Room

Task Board

Обстановка должна быть информативной.

Практики XP

Практики XP

1. TDD
2. Simple Design
3. Refactoring
4. Pair Programming
5. Metaphor
6. Continuous Integration
7. Collective Ownership
8. Coding Standard
9. Sustainable Pace
10. Planning Game
11. Small Releases
12. Customer Tests
13. Whole Team

TDD

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

Простой дизайн (Simple Design)

• "Do The Simplest Thing That Could Possibly Work"
• Добавляйте в дизайн то, что вам нужно,
  только тогда, когда это действительно нужно!
• Благодаря постоянной переработке кода вы легко вносите изменения в дизайн системы.
• Простой дизайн жизненно важен при дальнейшей модификации системы.

Рефакторинг (Refactoring)

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

Парное программирование (Pair Programming)

Парное программирование (Pair Programming)

• Абсолютно весь продуктовый код создается в парах.
• Driver, Observer. Observer думает стратегически:
  • Существует ли способ изменить систему так, что текущая проблема просто исчезнет?
  • Сработает ли подход?
  • Есть ли другие тестовые случаи?
• Преимущества
  • Качество кода
  • Распространение знаний
  • Сфокусированность на задаче

Парное программирование (Pair Programming)

• Исключения
  • Spike: research, design, exploration and prototyping
  • Не продуктовый код
  • Не код
• Ликбез
  • + Персональные рабочие места
  • Одинаковое рабочее окружение
  • Терпимость

Практики XP

1. TDD
2. Simple Design
3. Refactoring
4. Pair Programming
5. Metaphor
6. Continuous Integration
7. Collective Ownership
8. Coding Standard
9. Sustainable Pace
10. Planning Game
11. Small Releases
12. Customer Tests
13. Whole Team

Метафора (Metaphor)

• Проект направляется при помощи метафоры.
• Она помогает понять базовые элементы программы и то, как они взаимосвязаны.
• Метафора во многом заменяет "архитектуру",
  она дает сведения о ней в форме, удобной для общения и обдумывания.

Непрерывная интеграция (Continuous Integration)

• Код интегрируется и тестируется каждые несколько часов,
  минимум один раз в день.
• Ежедневная сборка проекта — сердцебиение системы!
• Только одна пара интегрирует код в данный момент времени.
• Интегрируйтесь чаще.
• Пара программистов вносит изменения и запускает тесты до тех пор, пока все они не сработают на 100%. В противном случае они удаляют свои изменения.

Коллективное владение (Collective Ownership)

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

Стандарты кодирования (Coding Standards)

• Код должен быть написан согласно стандарту!
• Стандарт определяет правила написания кода
• Аспекты:
  • Форматирование
  • Комментирование (подробность)
  • Специфические моменты для языка программирования
  • Критерии качества кода
• Стандарт должен способствовать коммуникации, облегчать работу в парах, переработку и способствовать созданию простого дизайна.

40-часовая рабочая неделя (Sustainable Pace)

• Никто не способен работать по 60 часов в неделю на протяжении многих недель и оставаться свежим, творческим, внимательным и уверенным в своих силах.
• Правило XP — нельзя работать во внеурочное время две недели подряд.
• Сверхурочные — признак серьезных проблем (не решатся увеличением времени работы).
• Смертельные марши не являются продуктивными, и не производят качественное ПО.

Практики XP

1. TDD
2. Simple Design
3. Refactoring
4. Pair Programming
5. Metaphor
6. Continuous Integration
7. Collective Ownership
8. Coding Standard
9. Sustainable Pace
10. Planning Game
11. Small Releases
12. Customer Tests
13. Whole Team

Игра в планирование (Planning Game)

• Планирование релизов (roadmap)
  • проект разбивается на итерации
  • пользовательские истории => задачи на итерацию
  • частые релизы
  • планирование происходит перед началом каждой итерации
• Представители бизнеса определяют:
  • Объем работ
  • Приоритет
  • Сроки выпуска версий
• Разработчики определяют:
  • Оценка времени выполнения
  • Процесс
  • Подробный график работ
• Итеративный процесс формулирования и приоритезации задач.

Небольшие версии (Small Releases)

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

Присутствие заказчика (On-Site Customer, Customer Tests)

• Заказчик (пользователь системы) должен постоянно находиться с командой для ответов на возникающие вопросы, разрешения споров и установки приоритетов — всегда доступен!
• Он занимается написанием функциональных тестов.
• При его отсутствии риск резко увеличивается.
• Программисты пишут модульные тесты, заказчики пишут функциональные тесты — их совместная уверенность в надежности системы растет.
  • Нет необходимости в длительном тестированием продукта перед введением его в эксплуатацию.

Полная команда (Whole Team)

• Сидят все вместе + представитель заказчика
• Кросс-функциональные специалисты
• Парное программирование => обмен знаниями
• 40-часовая рабочая неделя
• Ежедневный stand-up meeting

Внедрение

• Всегда нужно идти от реальной проблемы, желательно подтвержденной данными
• Осваивать ХР с новой командой — непросто, с существующей — еще сложнее
  • Нельзя менять процесс в разгар работы
  • Лучшее время — начало новой итерации
• Внедрять практики ХР следует по одной
  • Важно помнить про тесную связь методик,
    половинчатое внедрение может навредить.
  • "Fix XP when it breaks".

Алгоритм внедрения

1. Обновите список проблем, которые мешают проекту быть более успешным
   • Для каждой проблемы оцените потенциальный выигрыш от ее решения
   • Оцените готовность приступить к решению каждой проблемы
2. Выберите проблему и спланируйте ее решение
   • Она должна быть самой приоритетной, но в то же время "решаемой"
   • Составьте список из методик XP, которые будут полезны
   • Помним про взаимосвязь методик
3. Решите проблему, применяя методики ХР
   • Последовательно внедряем отобранные методики
   • Всякий раз отводим одну или несколько итераций, чтобы они "прижились"
4. Вернитесь на шаг 1

Вся эта работа идеально вкладывается в практику Ретроспектива из Scrum.

Контрольные вопросы

1. Определение XP
2. Круг решаемых проблем
3. Ценности XP (на всех уровнях)
4. Жизненный цикл XP проекта
5. Рабочее окружение
6. Практики XP
7. Парное программирование (роли, ответственности, преимущества)
8. Метафора: назначение практики, примеры
9. Внедрение XP (алгоритм, важные моменты которые нужно учитывать)

Спасибо за внимание!

Вопросы?

Backup

Planning Strategy

• User stories are written
• Make frequent small releases
• Release planning creates the release schedule
• The project is divided into iterations
• Iteration planning starts each iteration

Managing Strategy

• Give the team a dedicated open work space
• Set a sustainable pace
• A stand up meeting starts each day
• Move people around
• Fix XP when it breaks
• The Project Velocity is measured

Designing Strategy

• Simplicity (TUBE)
• Choose a system metaphor
• Create spike solutions to reduce risk
• No functionality is added early
• Refactor whenever and wherever possible
• Use CRC cards for design sessions

Coding Strategy

• The customer is always available
• Code must be written to agreed standards
• Use collective ownership
• Code the unit test first
• All production code is pair programmed
• Only one pair integrates code at a time
• Integrate often
• Set up a dedicated integration computer

Testing Strategy

• All code must have unit tests
• All code must pass all unit tests before it can be released
• When a bug is found tests are created
• Acceptance tests are run often and the score is published