Журнал «Компьютерра» № 33 от 12 сентября 2006 года

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

Итак, если мы на каком-то этапе работы пошли по неверному пути, мы очень быстро это поймем — одна-две итерации, и ошибка будет исправлена.

Общение с заказчиком

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

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

Ежедневные релизы

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

Отсюда, кстати, известное выражение «вечная бета» — веб-сайт выкладывается «в бой», программа становится доступной пользователям как можно раньше. И далее проектная команда корректирует процесс разработки (вплоть до концепции самого проекта) «на лету», наблюдая за реакцией пользователей.

Творчество, а не копирование

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

• Тестирование до начала разработки.

• Парное программирование.

• Постоянный рефакторинг.

• Простота разработки.

• Коллективное владение кодом.

• Быстрый выпуск версий.

• Постоянная интеграция.

• Стандарты кодирования.

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

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

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

Простота разработки — из двух вариантов выбирается более простой и быстро реализуемый.

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

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

Сотрудничество, а не конфликтование

Одно из важных следствий принятия концепции хаотичности окружающего мира — исчезновение конфликтов между менеджерами и исполнителями. Эти, казалось бы, вечные «грабли» хорошо знакомы всем, кто имеет отношение к разработке веб-сайтов. В традиционной (каскадной) модели разработки пик конфликта приходится на самый важный этап — предвыпуск или выпуск проекта. Главная причина — разработчики сделали не совсем то, что хотел менеджер или заказчик.

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

Спиральная модель жизненного цикла разработки ПО