Практики экстремального программирования в Scrum
Узнайте, как объединить инженерные дисциплины экстремального программирования со Scrum, чтобы устранить технический долг и поставлять работающее программное обеспечение в каждом Sprint.
Многие команды разработчиков внедряют Scrum и через полгода замечают, что их темп замедляется. Код становится хрупким, количество регрессионных ошибок растет, а каждый Sprint превращается в судорожную попытку исправить дефекты перед Sprint Review. Scrum описывает, как организовать работу и оценивать прогресс, но намеренно не предписывает технические практики. Руководство по Scrum 2020 года оставляет выбор инженерных методов исключительно на усмотрение Developers. Когда команды игнорируют инженерную дисциплину, Scrum лишь усугубляет их технические проблемы, а не решает их. Экстремальное программирование, известное как XP, дает ту самую недостающую техническую базу.
Проблема пустого фреймворка
Scrum определяет зоны ответственности, события и артефакты. Он создает эмпирический цикл обратной связи. Однако этот цикл работает ровно настолько быстро, насколько безопасно вы можете изменять код. Если проверка изменений требует двух недель ручного тестирования, создать готовый к использованию Increment за двухнедельный Sprint математически невозможно. Вы не сможете инспектировать и адаптировать работающее программное обеспечение, если не умеете надежно его создавать.
Кент Бек сформулировал простую идею в основе экстремального программирования. Если какая-то инженерная практика полезна, доведите ее применение до максимума. Тестирование работает, поэтому тестируйте каждое изменение сразу же. Интеграция работает, поэтому интегрируйте код по нескольку раз в день. Ревью кода работает, поэтому проверяйте код непрерывно в парном режиме. Когда вы внедряете практики XP в Scrum, этот фреймворк перестает казаться бюрократической обузой и начинает давать обещанную гибкость.
Непрерывная интеграция вместо изолированных веток
Командам часто бывает трудно выполнить критерии Definition of Done, потому что слияние кода откладывается на конец Sprint. Developers изолированно трудятся в долгоживущих ветках девять дней, а на десятый день разбирают конфликты слияния и ищут причины сломанных сборок. Такой подход превращает Sprint Planning в гадание и гарантирует неприятные сюрпризы в последний момент.
XP решает эту проблему с помощью непрерывной интеграции. Developers отправляют свои изменения в основную ветку несколько раз в день. Каждый коммит запускает автоматическую сборку и прогон тестов. Если тест падает, его исправление становится важнее начала новой работы. Всего одна эта привычка гарантирует, что Increment продукта готов к использованию в любой день Sprint, а не только за пару часов до подведения итогов.
Ключевые дисциплины XP для Scrum команд
Вам не нужно согласование руководства, чтобы внедрить эти подходы. Руководство по Scrum четко указывает, что Developers являются самоуправляемыми, то есть они сами определяют, как превращать элементы Product Backlog в ценный Increment. Четыре конкретные дисциплины XP идеально вписываются в процесс выполнения Sprint:
- Разработка через тестирование, при которой создание автоматического теста перед написанием рабочего кода дисциплинирует архитектуру и создает постоянную защиту от регрессий.
- Непрерывный рефакторинг, который улучшает архитектуру шаг за шагом в каждой истории, не откладывая наведение порядка на отдельные технические Sprints, до которых редко доходят руки.
- Простой дизайн, ориентированный исключительно на успешное прохождение текущих тестов и выполнение актуальных требований без лишних умозрительных абстракций.
- Коллективное владение кодом, позволяющее любому Developer исправить или улучшить любой участок кодовой базы, не дожидаясь одобрения узких специалистов.
Парное программирование и качество кода
Руководители нередко считают парное программирование пустой тратой ресурсов. Кажется, что работа двух инженеров за одним экраном снижает общую производительность вдвое. Это заблуждение, поскольку узким местом разработки ошибочно считается скорость набора текста. Настоящие препятствия кроются в недопонимании, логических ошибках, изоляции знаний и pull request, которые ждут проверки днями.
Работа в парах обеспечивает непрерывную инспекцию кода в режиме реального времени. Она органично распространяет понимание архитектуры среди всех участников. Когда в течение Sprint состав пар регулярно меняется, в команде не возникает незаменимых людей. Задачи плавно переходят из начатых в состояние Done без задержек на передачу дел, что делает ход Sprint ровным и предсказуемым.
Как сделать Definition of Done работающим инструментом
Критерии Definition of Done без автоматической технической проверки остаются лишь благими пожеланиями. Команды фиксируют требования о надежном тестировании, поддерживаемости и готовности кода к развертыванию, но ручные проверки неизбежно отбрасываются при сжатых сроках. XP превращает Definition of Done в исполняемый программный код.
Когда автоматические тесты запускаются при каждом коммите, а код интегрируется непрерывно, соответствие Definition of Done перестает быть головной болью в последнюю пятницу Sprint. Это становится рабочим фактом, который подтверждается десятки раз в день. Scrum дает команде свободу выбирать способы работы. XP дает мастерство, чтобы эта работа была надежной.