ХР (Экстремальное программирование) проектное управление

Любая команда, работающая над разработкой собственного или клиентского проекта, сталкивается с тем, что без чёткой методики управления быстро наступает хаос. Этот хаос затрагивает все аспекты: отношения между участниками, взаимодействие с клиентами и внешними партнёрами, финансирование, сроки и прочее. И в конечном итоге проект разваливается, не дойдя до конца.

Ниже подробно рассмотрим одну из гибких методологий разработки программных продуктов – экстремальное программирование.

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

Итак, начнём.

Что такое экстремальное программирование

Extreme Programming (XP), оно же экстремальное программирование – это методология управления IT-проектами или программными продуктами, разработанная Кентом Бэком и обкатанная им в работе над крупными проектами. В основе методологии лежит тесное взаимодействие участников, включая заказчиков, непрерывную обратную связь, простоту реализации и храбрость, необходимую для принятия на себя ответственности.

Вместе с тем от команды разработчиков (то есть исполнителей) не требуется никаких судьбоносных решений. Предполагается, что делать они будут только то, что попросил заказчик или клиент. Ничего нового или дополнительного.

В парадигме экстремального программирования очень важны ценности и правила. Без них она не работает. Для внедрения методологии все участники процесса должны принять декларируемые ценности и правила. О них ниже.

Ценности экстремального программирования

Ценности – это наиболее важный элемент методологии. В иерархии приоритетов они будут выше правил. Это нужно знать и учитывать, особенно в сложных и спорных ситуациях.

Ещё один интересный момент: вы можете начать с ценностей, зафиксированных автором, но позже добавить в список свои.

Ценностей экстремального программирования всего пять:

1. Простота.
2. Коммуникация.
3. Обратная связь.
4. Уважение.
5. Храбрость.

Теперь немного подробнее о каждой ценности.

Простота

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

Шаги к поставленной цели должны быть максимально простыми. А возникающие по пути неудачи и промахи нужно стараться смягчать по мере их выявления.

Разработчики должны за разумные деньги создавать продукт, которым смогли бы гордиться в долгосрочной перспективе. 

Коммуникация

Каждый участник проекта является частью команды. Над любыми задачами и проблемами нужно трудиться вместе. Результат проекта – это то лучшее, что команда может создать общими усилиями, то есть  в соответствии с имеющимися возможностями.

Обратная связь

На каждой итерации команда демонстрирует заказчику рабочий продукт. Затем внимательно слушает пожелания и замечания. На основе обратной связи вносятся необходимые изменения.

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

Уважение

Каждый член команды важен и вносит свой посильный вклад. Это касается не только отношений внутри команды, но отношений с внешним миром. Разработчики должны уважать опыт клиентов, а клиенты – опыт разработчиков. Руководство проекта должно правильно понимать свои полномочия по управлению и уважать право разработчиков на самостоятельные решения.

Храбрость

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

Правила экстремального программирования

Примерно так выглядит процесс разработки в 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 во многом схожа с другими популярными методологии программных проектов. Различия между ними часто бывают тонкими и могут размываться при определенных условиях.