Любая команда, которая задумывается о разработке своего проекта или проекта своего клиента/заказчика, упирается в то, что без какой-либо чёткой методики управления очень быстро возникает хаос. Он касается всего: отношений между участниками, взаимодействия с клиентами и внешним миром, финансирования, сроков и т.д. И в конечном итоге проект разваливается, не дойдя до конца.
Ниже подробно рассмотрим одну из гибких методологий разработки программных продуктов – экстремальное программирование.
Справедливо будет сказать, что на принципах, которые лежат в основе этой методологии, может строиться и управление другими типами проектов. Такое управление тоже будет называться экстремальным.
Итак, начнём.
Что такое экстремальное программирование
Extreme Programming (XP), оно же экстремальное программирование – это методология управления IT-проектами/программными продуктами, разработанная Кентом Бэком и обкатанная им в работе над крупными проектами. В свою основу методология ставит тесное взаимодействие участников, включая заказчиков, непрерывную обратную связь, простоту реализации и храбрость, необходимую для принятия на себя ответственности.
Вместе с тем, от исполнителей/команды разработчиков не требуется каких-либо судьбоносных решений. Предполагается, что делать они будут только то, что попросил заказчик/клиент. И ничего нового или дополнительного.
В парадигме экстремального программирования очень важны ценности и правила. Без них она не работает. Для внедрения методологии все участники процесса должны принять декларируемые ценности и правила. О них ниже.
Ценности экстремального программирования
Ценности – это наиболее важный элемент методологии. В иерархии приоритетов они будут выше правил. Это нужно знать и учитывать, особенно в сложных и спорных ситуациях.
Ещё один интересный момент: вы можете начать с ценностей, задекларированных автором, но позже добавить в список свои.
Ценностей экстремального программирования всего пять:
- Простота.
- Коммуникация.
- Обратная связь.
- Уважение.
- Храбрость.
Теперь о каждой ценности немного поподробнее.
Простота
Так как наиболее важна ценность инвестиций, актуальных в настоящее время, исполнители должны делать только то, что нужно, и то, о чём их просят. А не то, что они хотят или считают более логичным.
Шаги к поставленной цели должны быть максимально простыми. А возникающие по пути неудачи и промахи нужно стараться смягчать по мере их выявления.
Разработчики должны создавать продукт, которым смогли бы гордиться (в долгосрочной перспективе), за разумные деньги.
Коммуникация
Каждый участник проекта является частью команды. Над любыми задачами и проблемами нужно трудиться вместе. Результат проекта – это то лучшее, что команда может создать общими усилиями (в соответствии с имеющимися возможностями).
Обратная связь
На каждой итерации команда демонстрирует заказчику рабочий продукт. Затем внимательно слушает пожелания и замечания. На основе обратной связи вносятся необходимые изменения.
Во главу угла ставится разрабатываемый продукт. Поэтому о нём нужно говорить и к нему нужно адаптировать рабочие процессы, а не наоборот.
Уважение
Каждый член команды важен и вносит свой посильный вклад. Это касается не только отношений внутри команды, но отношений с внешним миром. Разработчики должны уважать опыт клиентов, а клиенты – опыт разработчиков. Руководство проекта должно правильно понимать свои полномочия по управлению и уважать право разработчиков на самостоятельные решения.
Храбрость
Нужно смотреть в лицо ситуации с текущим прогрессом и с полученными оценками по продукту. Команда должна добиваться успеха, поэтому обязана учитывать обратную связь и неудачи, адаптироваться к изменениям, если они возникают.
Правила экстремального программирования
Примерно так выглядит процесс разработки в XP.
Правила разделены на основные группы.
Группа правил планирования
- Пользовательские истории должны быть написаны.
- В результате планирования выпусков должен быть составлен график релизов.
- Делайте ставку на небольшие и частые релизы.
- Проект должен быть разбит на итерации.
- Каждая новая итерация начинается с планирования.
Пользовательские истории используются для понимания вариантов использования продукта и для правильной оценки времени реализации. User Stories могут легко заменить большой и ненужный документ с требованиями.
Истории пишутся клиентами/заказчиками, здесь важно описать то, что программная система должна делать (за них или для них, какие задачи должна решать).
На основе пользовательских историй нужно будет разработать систему приёмочных тестов, чтобы понять, решает система поставленные задачи или нет.
Время работы над одной пользовательской историей не должно превышать 3 недели (обычно используется цикл в 1, 2 или 3 недели). В противном случае историю нужно сильнее детализировать и разбить на составляющие. Если реализация занимает меньше недели – вы чересчур сильно детализировали историю.
В качестве времени считается полная загрузка. То есть, когда команда будет работать только над одной задачей и не будет отвлекаться на посторонние.
В плане релиза число историй должно быть 80, плюс-минус 20.
На совещаниях по планированию технические специалисты должны отвечать за решения по техническим задачам, а бизнесмены – за бизнес-задачи.
Каждая User Story оформляется в виде карточки и двигается по рабочему столу или на доске для создания набора историй, которые будут отработаны в первый (следующий) релиз.
Именно здесь лучше всего заменить физические карточки на какую-нибудь удобную информационную систему – планировщик задач.
Очень интересный момент. На этапе планирования, когда график релизов уже собран, но всё ещё не нравится инвесторам, может появиться соблазн скорректировать сроки отдельных юзер-стори.
Делать так ни в коем случае нельзя, так как в итоге вы получите потенциально больше проблем в будущем. Гораздо логичнее отказаться от некоторых историй или пересмотреть все наборы релизов до получения оптимальных вариантов, устраивающих все стороны.
Несмотря на то, что полноценная рабочая версия продукта возможно, появится не скоро, команда может выпускать тестовую версию, предназначенную только для клиента, хоть каждый день, чтобы он мог оперативно отслеживать прогресс и корректировать список пользовательских историй при необходимости.
Чем больше цикл релиза, тем меньше у вас будет времени на исправление проблем в случае их обнаружения.
Каждая новая итерация разработки должна включать те юзер-стори, которые наиболее важны для заказчика.
Группа правил управления
- Команда должна работать в едином открытом пространстве (так называемый опенспейс-формат).
- Задается устойчивый темп работы (в основном за счёт правильных итераций).
- Рабочий день начинается с общих встреч (stand up meeting).
- Регулярно измеряется скорость реализации проекта.
- Ротируются специалисты (их можно перемещать между задачами).
- Исправляются те процессы и правила XP, которые мешают или не работают (не стесняйтесь делать это).
Открытое рабочее пространство – это залог оперативной коммуникации участников, а коммуникация – одна из важнейших ценностей XP.
Именно в таком формате легче организовать парное программирование, проводить оперативные встречи и обсуждения, задавать вопросы напрямую и быстро получать ответы. Даже если члены команды не участвуют в непосредственном обсуждении, они обязательно будут в курсе всего происходящего.
Не менее удобными будут общие виртуальные пространства, например, сервисы, где можно нарисовать наброски дизайна и обсудить отдельные элементы, добавить свои замечания, пометки и т.п.
Единый общий чат (рабочая группа) – это тоже формат опенспейса.
Перекрестное обучение с перемещением сотрудников по задачам позволит избежать ситуаций, когда складываются так называемые островки знаний (потеря одного или нескольких профильных разработчиков может быть очень болезненной). Диверсифицируйте знания по проекту.
Выдерживание темпа – это не совсем про правильные циклы разработки или про итерации. Это про завершение задач. Если к концу итерации вы проделали большой объём работы, но не закрыли ни одной задачи (юзер-стори), то это плохой темп.
Если вы не укладываетесь в сроки, то простым увеличением числа исполнителей некоторые задачи не решить. Команду в таких случаях нужно наращивать плавно, в тех местах, где это уместно. В противном случае вы, наоборот, можете получить обратный (отрицательный) эффект.
Стартовые ежедневные встречи должны быть максимально короткими. На обсуждение логично выносить только насущные проблемы. Здесь точно не нужны какие-либо подведения итогов или доведение информации, которая только отнимает время участников команды.
Группа правил проектирования
- Проектирование должно быть простым.
- Выберите системную метафору.
- Используйте CRC-карточки для сеансов проектирования.
- Создавайте быстрые решения на технически сложные проблемы (Spike Solution).
- Не добавляйте никакие функции заранее (наперёд).
- Используйте рефакторинг всегда и везде, где это возможно.
Конечно, простота – это всегда субъективное восприятие, но и усложнять ничего не нужно. Обычно для оценки задач используются такие характеристики, как понятность, тестируемость, доступность для просмотра и объяснимость.
Системная метафора – это короткое описание сути вашего проекта. Это то, как бы вы объяснили посторонним людям, чем сейчас занимаетесь (над чем работаете). Фактически это цель вашего проекта.
CRS расшифровывается как Class, Responsibilities and Collaboration «Класс, обязанности и сотрудничество». Это специальные карточки, которые помогают в планировании процесса разработки. Они обозначают объекты системы (классы объектов).
Группа правил программирования (кодирования)
Это то, что касается непосредственно процесса разработки.
- Клиент должен быть всегда на связи (доступен для вопросов).
- Код пишется по стандартам, которые согласовываются заранее (чтобы это устраивало всех).
- Первым пишется unit-тест.
- Весь код пишется парами программистов.
- Только одна пара интегрирует свой код в проект за один раз.
- Интегрируйте код как можно чаще (чтобы кодовая база была максимально актуальной).
- Выделите для интеграции отдельный компьютер/рабочее место.
- Используйте коллективное владение кодом (за код отвечает вся команда, а не кто-то конкретный).
Обратите внимание, парное программирование, как и коллективное владение кодом, не предполагает подхода «ученик-наставник». Все работают с равными правами. «Вторые» глаза здесь нужны скорее для оперативного контроля и получения альтернативной точки зрения (для многогранной оценки выбранного подхода).
Группа правил тестирования
- Весь код обязательно покрывается unit-тестами (это как прямой аналог непрерывного контроля и одновременно автоматизации).
- Перед выпуском в релиз или перед интеграцией в проект код обязательно должен пройти все тесты.
- При обнаружении ошибок (багов) создаются новые unit-тесты.
- Приёмочные тесты, которые создаются на основе пользовательских историй, проводятся как можно чаще, чтобы результат можно было быстрее выпустить в релиз.
Вместо итогов
У экстремального программирования немало приверженцев и столько же противников. Но нужно отдавать отчёт в том, что XP – это не набор строгих правил. Изложенные выше принципы можно менять прямо на ходу после того, как вы выясните для себя эффективность или неэффективность тех или иных решений.
В результате можно выяснить, что XP во многом похожа на другие популярные методологии программных проектов. Граница (разница) очень тонкая и легко размывается при определённых условиях.