Звучит круто, не правда ли? Готов поспорить, что вы уже представляете себе мега-кодера, который, обложившись гигабитным интернетом, usb-примочками, тремя компьютерами с включенными Visual Studio, Eclipse, Qt, Comodo и десятком-другим серваков неустанно тестирует в голове еще ненаписанный код, одновременно проверяя работоспособность написанного, скользя по вершинам книги рекордов Гиннеса в скорости печатания. Нет, это — идеал, а мы с вами живые люди, которым требуется время от времени откатиться на спинку стула, запрокинуть голову назад и крепко так проанализировать, что же мы сейчас написали? Трудно быть одиноким, особенно когда дело идет о коде — если не с кем обсудить, голова мягко потрескивает... лучше работать вдвоем, а еще лучше — вдесятером! Но тогда вам, как и любой группе, понадобиться организация, распределение обязанностей, начальство, в конце концов. Именно для этих целей стали придумываться различные методики разработки.

Экстремальное программирование, или XP (нет, не в честь любимой всеми ОС, а аббревиатура от eXtremal Programming) — это методика гибкой разработки приложений, на сегодняшний день очень популярная и перспективная. Трудно сказать, является ли XP определенным набором правил или полноценной методологией, но это не мешает группам разработчиков успешно применять его в своем деле и быть лучшими! Уже не терпится узнать как это работает? Не беспокойтесь, сейчас расскажу!

Секрет XP зиждется на пяти принципах: simplicity, communication, feedback, respect, courage. Это не методики, а достоинства проекта, его участников, цели, к которым надо стремиться. Рассмотрим по порядку:

1. Simplicity. Делайте все максимально просто: если есть готовое решение, придуманное ранее — берите его, не изобретайте велосипеды. Ваша задача — удовлетворить желание заказчика, а все остальное — «было бы неплохо привинтить сюда новую технологию, заодно — проверить, как бегает», или «я слышал, вышел новый плагин, только он еще не протестирован, может приконнектим?» — оставьте на домашнее изучение.

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

3. Feedback. Довольно экстремально вставать посреди ночи, зимой, в кромешной темноте и наощупь искать ручку от холодильника туалета, боясь наступить на кота или угодить рукой в кактус. Нам нужен свет. Так и в экстремальном программировании нам нужна так называемая обратная связь — результат работы. Разработчику нужно видеть, что он делает, поэтому XP советует нам делать короткие итерации, собирать все воедино и анализировать. Частые релизы приносят и другие плюсы — например, накладывают определенные обязанности по времени на программистов, тем самым искореняют лень и синхронизируют общий прогресс. А уж как заказчик будет рад, когда в первую же неделю его «детище» уже скажет «мама»!

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

5. Courage. Каждый в команде XP должен быть способен взять на себя ответственность за свои поступки, решения. С самого начала коллектив настраивается на безоговорочную победу, все предложения приветствуются, все начинания поддерживаются! Не раз приходится признавать то, что ты уперся в тупик и искать обходной путь. И, наконец, заметив ошибку в чужом коде, нужно не побояться и рассказать об этом коллегам. Для всего этого, несомненно, нужна сильная воля, умение пойти на риск, храбрость, которую XP в нас воспитывает.

Осознав эти основные правила, мы уже начинаем понимать атмосферу XP. В ней все ориентировано на клиента и изменчивость его желаний, в XP нет «прямых линий». Уход от линейности достигается путем разбиения проекта на выпуски и итерации. По окончанию каждой итерации проводятся собеседования с клиентом для опроса его мнения, планирование дальнейшей работы. Итерации в XP, в отличие от RUP или других, не гибких методологий, занимает обычно 2-3 недели. Таким образом, обеспечивается довольно быстрая обратная связь и выявление ошибок, недоделок еще на ранних стадиях проекта.

Разработчики чувствуют себя увереннее, если объем работы известен заранее, поэтому в XP есть такое понятие, как «нулевая итерация», которую можно еще назвать глобальным планированием. Да, это именно когда все собираются за одним большим столом, берут огромную белую доску, фломастер и начинают творить магию, перебивая друг друга своими гениальными мыслями, рвущимся наружу креативом! Хотя перебивать все же не стоит, мы же помним об уважении. После такого оживленного общения принимается большое решение, которое включает в себя «расписание занятий» на ближайшую итерацию, первые прототипы UI, доменную модель, карточки CRC и прочие полезные артефакты. После каждой успешной итерации составляются user stories — краткие записи о новых свойствах всей системы и проводится новое планирование. Еще один плюс XP — минимум достаточной документации, на уровне понимания (чуть ли не записки на стикерах). Считается, что это лучше чем фолиантного вида кипы бумаг, которые понятны только их создателям, а уж заказчик при виде такого отчета навсегда от вас убежит.

Кстати о заказчиках: принцип on-site customer говорит нам всегда держать его при себе, или самому идти к «горе» за советом. Клиент является частью XP-команды и по возможности экспертом в области разработки (чаще всего — представитель реального заказчика). Поэтому работать с ним одно удовольствие: и расскажет, и покажет, и совет еще даст!

Конечно, ваша команда должна работать как атомные часы. Но не будем наивными, есть более успешные дни, есть — менее. Введем в наш проект такое понятие как «идеальный день», который будет означать 8 часов непрерывной работы. Нет, тиранить своих подчиненных не стоит, такой термин введен для расчета времени, требуемого для выполнения той или иной задачи. Например, если для разработки участка кода требуется один «идеальный день», то мы говорим: «Ребята, справляемся за три дня!» — обычно коэффициент берут равный трем.

Ребята, кстати работают в парах: один пишет код, другой проверяет. Пары полезно перемешивать, таким образом, достигается коллективное владение кодом, штука весьма полезная. Это значит, что любой член команды может беспрепятственно править любой участок кода, ибо он понимает, как работает система в целом, потому что работал в разных отделах с разными людьми. Такая уникальность каждого сотрудника вполне покрывает расходы на «простой» наблюдающего программиста в паре; ведь теперь вы можете не бояться, если один из членов команды заболеет, уйдет в отпуск, или совсем уволится, хрупкие звенья становятся взаимозаменяемыми.

Когда мы идем по улице, сидим в ресторане, то стараемся придерживаться правил хорошего тона, на нас смотрят люди. Так и парное программирование способствует стандартизации кода, к чему всегда очень серьезно относятся компании. Легко ли вам разбираться в чужом подчерке? Уважайте других, пишите одинаково.
Еще одной уловкой экстремального программирования является небезызвестный рефакторинг — усовершенствование кода. Представьте что ваша система постоянно растет, как пирамида; тогда нам нужен прочный фундамент на каждом уровне, чтобы последующий был таким же устойчивым. Добавление нового функционала всегда приводит к усложнению кода, которое мы сглаживаем путем его переработки. Это настолько мощный инструмент обеспечения качества программы, что его выделяют в отдельную дисциплину! Обязательно познакомьтесь с ним, если хотите работать в сфере разработки ПО.

А если хотите работать еще и в команде, то вы должны уметь вливаться в коллектив, действовать как единое целое. Не секрет, что программисты — скрытный народец, сердечно любящий свою работу, светлые мысли, и готовый задержаться в офисе допоздна, лишь бы разговорить свой код! Так вот XP это строго запрещает (мой совет сисадминам — закрывайте все открытые VPN-туннели), биоритмы вашего творческого персонала должны совпадать.

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

Запомните: в любом деле главное — оптимизм и заинтересованность его участников, так что думайте: в качестве начальника — как поддержать интерес подчиненных, дать им хлеб для дальнейшего развития; в качестве рядового — как бы сделать денек поинтереснее! Желаю всем хорошего настроения и гибких решений.