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

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

Экстремальное программирование

Ниже я опишу простейшие методы, которые позволят компании постепенно уйти от классической каскадной модели цикла разработки программного обеспечения. Каскадную модель вкратце можно описать так: сначала мы просим пользователей или заказчика сформулировать свои требования, затем разрабатываем проект системы, составляем техническое задание. Затем пишем код, тестируем его. Увы… Эта модель не годится для большинства проектов по разработке веб-приложений.

Что же делать? Ответ прост: принять окружающую действительность, принять изменчивый мир, принять хаос. Стать гибким и разрабатывать свою стратегию с учетом того, что нас окружает хаос. Это нормально. И убедиться при этом, что уже существуют инструменты, позволяющие успешно действовать в условиях хаоса. Например, инструменты экстремального программирования. Все они создавались исходя из того, что окружающая среда гибко и динамично меняется, и не пытаются зафиксировать ее, а наоборот - приспосабливают производственные процессы под подобную среду.

Итерации

Итак, мы приняли концепцию изменчивого мира. Что это меняет? Сразу становится ясно, что писать подробнейшее техническое задание не имеет смысла - оно стремительно устаревает. Ограничимся описанием функций, причем так, как их видит пользователь системы. Как правило, заказчик достаточно хорошо их представляет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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