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