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

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

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

Итак, давайте начнем.

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

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

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

В экстремальном программировании существует всего пять ценностей:

Теперь давайте рассмотрим каждую ценность более подробно.

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

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

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

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

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

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

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

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

Примерно так выглядит процесс разработки в XP.

Правила разделены на основные группы.

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

Истории создаются клиентами или заказчиками, чтобы описать, что система должна делать. Мы сосредотачиваемся на решении их задач.

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

Время работы над одной пользовательской историей не должно превышать 3 недели. Обычно мы используем циклы в 1, 2 или 3 недели. Если реализация занимает меньше недели, значит, история слишком детализирована.

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

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

На совещаниях по планированию технические специалисты отвечают за решения технических задач, а бизнесмены – за бизнес-задачи.

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

Рекомендуется использовать информационную систему для планирования задач вместо физических карточек.

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

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

Чем короче цикл релиза, тем больше времени есть на исправление проблем в случае их обнаружения.

Каждая новая итерация разработки должна включать наиболее важные пользовательские истории для заказчика.

Открытое рабочее пространство способствует оперативной коммуникации, что является одной из ключевых ценностей XP.

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

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

Единый общий чат или рабочая группа также способствуют опенспейсу.

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

Выдерживание темпа работы не сводится только к правильным циклам разработки и итерациям. Оно связано с завершением задач. Если по итогам итерации вы выполнили большой объем работы, но не закрыли ни одной пользовательской истории, то это сигнал о плохом темпе работы.

Если вы не успеваете соблюдать сроки, просто увеличение числа исполнителей не решит проблему. В таких случаях команду следует наращивать постепенно, там, где это действительно необходимо. В противном случае, вы можете столкнуться с обратным (отрицательным) эффектом.

Ежедневные стартовые встречи должны быть максимально краткими. Обсуждайте только насущные проблемы. Здесь не нужно делать какие-либо сводки или предоставлять информацию, которая только отнимает время у участников команды.

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

Эти принципы напрямую относятся к процессу разработки.

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

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

В результате можно понять, что XP во многом схожа с другими популярными методологиями разработки программного обеспечения. Граница между ними очень тонка и может размываться при определенных условиях.