Практики ХР

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

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

Сам Кент Бек никак не классифицирует практики, однако мне кажется уместным разделить их на четыре категории:
Анализ требований и планирование;
Команда и человеческий фактор;
Проектирование;
Программирование и выпуск продукта.

Обращаю ваше внимание на то, что многие практики можно было бы отнести сразу к нескольким категориям. Так, «парное программирование» значится у меня в группе «Команда и человеческий фактор», однако с тем же успехом ее можно было бы поместить в категорию «Программирование и выпуск продукта». Далее я опишу каждую практику лишь один раз – в той категории, которая показалась мне наиболее уместной.
Основные практики
Анализ требований и планирование
«Рассказы»: функциональность приложения описывается короткими «рассказами», в которых работа системы изложена с точки зрения заказчика. Эти «рассказы» также являются основной движущей силой разработки приложения.
Еженедельный цикл: вся разработка проекта происходит в виде череды еженедельных циклов. В начале недели происходит собрание, на котором заказчик выбирает, какие «рассказы» надо сделать за эту неделю.
Ежеквартальный цикл: планирование в большем масштабе происходит каждый квартал. Оно состоит из обсуждений работы команды и темпов разработки.
Слабина: избегайте обещаний, которые не сможете выполнить. В любой план включайте задачи, которые вы сможете выкинуть, если не будете укладываться в срок. В этом случае у вас будет выход даже в случае непредвиденных проблем.
Команда и человеческий фактор
Работа в одном помещении: команда разработчиков должна сидеть в одном большом помещении – это облегчает общение.
Команда как одно целое: команда должна состоять из людей, обладающих всеми необходимыми для проекта навыками и знаниями. Всех их должно объединять чувство принадлежности общему делу, они должны всячески поддерживать друг друга.
Информативность окружения: в рабочем помещеним должны быть информативные постеры и прочие наглядные пособия, которые показывали бы статус проекта и другую информацию о проделанной работе.
Энергичная работа: люди не должны быть истощены работой, им надо сохранять свежесть и энергичность, чтобы фокусироваться на задачах и уметь эффективно их решать. Следовательно, надо жестко ограничить сверхурочную работу, так чтобы у каждого оставалось время и на личную жизнь. В прежней версии методологии это называлось «приемлимый темп разработки».
Парное программирование: код всегда пишут два программиста, сидящих за одним компьютером.
Проектирование
Инкрементное проектирование: согласно ХР, не следует заниматься подробным проектированием системы в самом начале работ. Вместо этого команда разработчиков старается как можно скорее начать писать программный код, чтобы получить отзывы пользователей о системе, и улучшать ее по ходу дела. Конечно, чтобы написать хороший код, система должна быть должным образом спроектирована. Этого ХР не отрицает. Вопрос лишь – когда заниматься проектированием. Согласно экстремальному программированию, проектированием должно происходить инкрементально во время написания программного кода. Особенно полезно делать это, чтобы убирать ненужное дублирование.
Сначала тесты: перед тем, как редактировать старый код или писать новый, нужно написать тесты, которые будут его проверять. Это поможет решить четыре проблемы:
«Программирование по-ковбойски»: во время написания кода так легко увлечься и начать писать код для всех задач подряд, которые приходят на ум. Если же сначала написать тесты, которые затем будут проверять код, нам волей-неволей придется сосредоточиться на задаче, которую мы пытаемся решить, а также проверить, насколько правильно мы спроектировали данную часть системы.
Слаженность и единство: если написать тест трудно, значит, у вас проблемы с дизайном системы, а не с тестированием или программированием. Когда программный код разбит на функционально связанные модули с минимальным количеством двусторонних зависимостей между ними, тестировать его не составит большого труда.
Доверие: если вы пишете код, который работает, и документируете его с помощью автоматизированных тестов, ваши коллеги будут доверять вам.
Ритм: во время программирования можно легко увлечься и блуждать в коде в течение нескольких часов. Если вы приучите себя к ритму «тест, код, рефакторинг, тест, код, рефакторинг», этого никогда не случится.
Программирование и выпуск продукта
Десятиминутная сборка: систему должно быть можно собрать (с учетом прогона всех тестов) за десять минут. Это позволит часто повторять операцию и получать отзывы о разрабатываемом продукте.
Постоянная интеграция: разработчики должны выкладывать в репозиторий результаты своей работы каждые два часа, чтобы избежать проблем с интеграцией нового кода.
Дополнительные практики
Анализ требований и планирование
Непосредственное вовлечение заказчика: люди, для которых вы пишете программный продукт, должны стать частью команды и вносить свою лепту в ежеквартальное и еженедельное планирование.
Инкрементная поставка продукта: когда вам предстоит целиком сменить существующую систему, начинайте процесс с изменения нескольких функций, и так постепенно замените всю систему. Избегайте подхода, который можно выразить словами «Все или ничего!»
Контракт с оговоренным объемом работ: контракт на разработку программного обеспечения включает в себя время, затраты и качество системы, однако точные объемы этой системы надо оговаривать в процессе работы. Заключив с заказчиком серию небольших контрактов, можно значительно снизить риски.
Плата за использование: обычно заказчик платит за каждый выпуск программного продукта. Это нередко дает повод для конфликтов между разработчиками и заказчиком, который хочет внести как можно больше новой функциональности в наименьшее количество выпусков продукта. Если исчислять деньгами непосредственную работу над функциональностью, заказчик будет получать более точную и своевременную информацию, и сможет точнее направлять разработку продукта.
Команда и человеческий фактор
Постоянство: команда разработчиков должна работать в одном и том же составе на протяжении нескольких проектов. Те связи, которые возникают между людьми, воистину бесценны, поэтому старайтесь перераспределять людей как можно реже.
«Усушка и утряска»: если команда становится все более продуктивной, не увеличивайте ее нагрузку. Оставьте объем работ прежним, но выделите свободных членов этой команды с тем, чтобы они создавали свои собственные новые команды.
Проектирование
Анализ причин и следствий: каждый раз, когда вы находите ошибку в системе, исправляйте не только ее, но и ее причину. В противном случае эта ошибка может повториться в будущем.
Программирование и выпуск продукта
Код и тесты: только программный код и тесты являются постоянными артефактами системы, которые надо сохранять. Все остальное может быть получено из программного кода и тестов.
Общий код: любой член команды может в любой момент изменить любую часть системы. Эта практика называлась в прежней версии ХР «коллективное владение кодом».
Единая база программного кода: существует только одна официальная версия разрабатываемой системы. Если вам понадобилось создать для чего-то ее ветку, оставляйте ее лишь на несколько часов.
Ежедневная поставка системы: каждую ночь надо собирать новую версию системы и вводить ее в действие. Чем больше разрыв между официальной версией системы и той, что находится у вас в компьютере, тем это рискованнее и дороже для проекта.

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

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

И в заключение я хотел бы сказать, что постарался максимально ясно – как обещает книга Кента Бека – изложить суть «гибкой» методологии разработки ПО. Новое экстремальное программирование сильно отличается от того, что было описано в первой книге Кента. Каждый принцип ХР, изложенный в первой версии, подвергается сомнению и основательно перерабатывается. Это закономерная эволюция методологии, прошедшей пятилетний путь развития с момента выхода первой книги. В этой книге много новых идей, практик и принципов, за которые некоторые последователи, возможно, даже обвинят Бека в ереси. А может быть, и прислушаются к его советам и сначала все попробуют применить его новые идеи в своих проектах. Впрочем, мне кажется, что Бек никогда не стремился превратить свои книги в «задачник с ответами», которым вы должны безукоснительно подчиняться. Нет, он стремится начать дискуссию – открытое обсуждение того, как надо разрабатывать программное обеспечение, предлагает каждой компании разработать свою собственную версию экстремального программирования, наиболее подходящего для этой компании, ее опыта и контекста ее работы.

maxkir.com

Июль 1, 2008 — Рубрика: Практика
Метки: , , , ,