С сайта www.osp.ru

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

Кент Бек
Открытые системы #01-02/2000

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

Вначале была модель "водопада" : мы просим пользователей однозначно сформулировать свои требования; мы разрабатываем проект системы, которая сделает все, что хотят пользователи; мы пишем код; мы тестируем программу, дабы убедиться, что она действительно делает то, что требуется. Все получается замечательно.

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

Итак, длинный цикл разработки плох, поскольку не способен приспосабливаться к изменениям. Тогда, возможно, надо сократить цикл, и все проблемы будут решены? На рис. 1b дана иллюстрация перерождения модели "водопада" в итеративную модель.

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

Академическое сообщество разработчиков ПО взялось разрешить проблему высокой стоимости изменений и создало новые технологии - реляционные базы данных, модульное программирование, сокрытие информации. Но что если все эти труды уже исчерпали свой потенциал? И нам удастся найти новый способ снизить расходы на внесение изменений, не разрезая "водопад" на части, а просто смешав все его компоненты? То, что получилось в результате, показано на рисунке 1с. Мы назвали это "экстремальным программированием" (Extreme Programming, XP).

Анатомия XP

XP отходит от традиционного процесса создания программной системы и вместо единоразового планирования, анализа и проектирования с расчетом на долгосрочную перспективу при XP все эти операции реализуются постепенно в ходе разработки, добиваясь тем самым значительного сокращения стоимости изменений в программе. Методы XP разрабатывались с расчетом на совокупное использование, поэтому, разбираясь в одном из них, вы неизбежно придете к пониманию остальных (врезка "Методы экстремального программирования"). Во врезке "Корни XP" прослеживаются исторические предпосылки возникновения этого подхода).

Цикл разработки XP

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

На рисунке 2 процесс XP соотносится с различными осями времени, где в качестве единицы измерения используются годы, месяцы, недели и дни. Заказчик определяет очередную версию (release) системы, выбирая наиболее ценные функции (в XP их называют историями - story) из всех возможных. Ценность функций определяется материальными и временными затратами на их реализацию командой разработчиков.

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

Истории

С точки зрения XP, период, предшествующий первому запуску системы в реальную эксплуатацию, является опасной аномалией в жизненном цикле проекта, и его надо преодолеть как можно быстрее. Однако работу над любым проектом надо как-то начать.

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

Результаты общего анализа оформляются как истории - индексы с перечислением возможных применений системы. Необходимо, чтобы каждая история была ориентирована на определенные задачи бизнеса, чтобы ее можно было протестировать и оценить с помощью количественных показателей. Месяц - вполне приемлемое время, чтобы сформулировать истории для проекта, рассчитанного на 10 человеко-лет. Понятно, что этого времени недостаточно для детального исследования всех возможных проблем. Но на анализ всех проблем никогда не хватит времени, если вы вообще намерены переходить к реализации системы.

Версия

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

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

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

Итерация

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

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

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

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

Задача

Для того чтобы реализовать задачу, ответственный за нее программист прежде всего ищет себе партнера, поскольку окончательный код всегда пишется двумя людьми на одной машине. Если возникают вопросы о предмете или методах реализации, партнеры проводят короткую (15-минутную) встречу с заказчиком и/или программистами, осведомленными в вопросах кодирования задач, которые с наибольшей вероятностью будут связаны с кодом данной задачи в ходе реализации.

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

С сайта xprogramming.com.ua

Метрика, ведущая к гибкости

A Metric Leading to Agility
Рон Джеффриес (06.14.2004)
Перевод Александра Федоренко.

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

Могут ли метрики вести к гибкости?

Камилла Белл, в дискуссионном листе по гибкому управлению проектом (Agile Project Management), спрашивала о метриках для формирования гибкости. В последующей дискуссии я предложил следующее:

В чём смысл любого проекта?

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

Обратите внимание на следующие определения РПВ:

1. Желаемая программа разбита на именованные возможности (требования, истории), необходимые как части для выпуска конечного продукта.

2. Для каждой именованной функциональности есть один или более автоматизированных приёмочных тестов, и их работоспособность укажет на то, что функциональность реализована.

3. Метрика РПВ, в любой момент времени, показывает, сколько функциональных возможностей прошли приёмочные тесты.

Сколько определённых заказчиком возможностей известно посредством независимо описанных тестов, которые работают?

Вот метрика, с которой можно иметь дело.

Как должна выглядеть кривая РПВ?

Для любой метрики мы должны знать, на что должна быть похожа её кривая. Если взять метрику дефектов, мы хотим наблюдать их уменьшение. Для строк кода и количества тестов, кривая должна идти вверх.

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

Работающие подразумевает возможности, выпускаемые в едином интегрированном продукте.

Протестированные означает, что функциональные возможности продолжают удовлетворять тестам, предоставленным разработчиками требований (заказчики в рамках XP).

Под функциональными возможностями подразумеваются куски данных заказчиком требований. Это не технические возможности, такие как "Установить базу данных" или "Запустить веб сервер".

Рабочие протестированные возможности должны показать прирост в первые одну-две недели, и должны следовать равномерным потоком с этого дня вперёд. Сильные колебания в количестве реализованных возможностей (обычно вниз) являются причиной пересмотра проекта для выявления недоработок.

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

Тем не менее, игра в РПВ возможна, но всё же легче будет стать гибкими. Мысль в том, что только очень недобрая команда будет отвечать на требование явным обманом. И я не думаю, что здесь найдётся много плохих команд. Причина работоспособности XP, Scrum и Crystal Clear в том, что они требуют регулярный выпуск реального продукта. Вот это и есть РПВ.

На что кривая РПВ не должна быть похожа?

Кривая РПВ не является правильной, если она с самого начала на протяжении нескольких месяцев полога. РПВ метрика хороша, только когда функциональные возможности начинают коваться сразу же. Проекты, в которых много дизайна на перёд (BDUF), и проекты, фокусирующиеся на преждевременном развёртывании инфраструктуры, в нашем контексте не применимы.

РПВ плоха, если вначале стремительно возрастает, а после замедляется. Проектов без рефакторинга не должно быть.

РПВ неверна, если ни началась с первых дней и не увеличивается последовательно всё время.

Давайте посмотрим, как эта метрика может выглядеть для гибкого проекта, и для сравнения, для проекта по типу водопада.

Гибкий проект: своевременная функциональность.

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

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

Водопад: функциональность попозже.

Проекты в стиле водопада своевременно тоже что-то "выпускают", но только не РПВ. Они выдают документы анализа, документы требований, документы дизайна, и т.п., на протяжении долгого времени до того как начнут выпускать саму функциональность. По теории, когда они начинают выпускать, это должна быть правильная функциональность, к тому же, правильно сделанная, так как у них есть правильные требования и правильный дизайн. Затем они кодируют, что может быть расценено как выпущенная программа, но не рабочие протестированные возможности, так как функциональность не была протестирована, и часто нерабочая вовсе. В конце концов, они тестируют и выявляют, что прогресс РПВ далеко не тот, которого они ожидали. Это выглядит так:

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

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

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

Рон, вы становитесь несправедливым!

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

Да, как сказал судья Рой Бин, если вы хотите справедливости, вам следует поискать её где-нибудь в другом месте. Моя миссия здесь - отбросить процесс водопада назад. Но если быть полностью честным, это заслуженная судьба негибких процессов. Диаграмма водопада показывает графически, почему вещи, которые мы делаем в негибком стиле, трудно измеримы, и зачем измерять то, что нам реально не потребуется.

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

Что же происходит здесь? В самом начале мы видим внезапное падение РПВ. Что это может означать? Мы не знаем, но это, по всей видимости, совсем не хорошо. Возможно, программисты внезапно внесли изменение, сломавшее несколько тестов. Мы ловим их на этом и поджариваем их пятки на огне. Хотя постойте, возможно, требования изменились, и тесты были изменены в ответ на новые требования, что привело к регрессу в программе. Что мы узнали, так это только то, что нам надо в чём-то разобраться. Первое что мы должны сделать - это спросить команду!

Затем, в ходе проекта, прогресс приостановился. Опять же, явная проблема. Но в чём же причина? Это может быть то, что команда не производит достаточный рефакторинг для поддержки прозрачного дизайна. И в связи с этим, они замедлились. Это может быть и по причине приостановки заказчиком определения требований или написания тестов. Опять же, мы не знаем. Необходимо спросить команду!

Как РПВ приводит к гибкости?

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

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

РПВ требует тестирования функциональности независимыми тестами. Так команда получает всесторонний контакт с заказчиком.

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

РПВ требует, чтобы кривая росла равномерно. Поэтому дизайн должен оставаться прозрачным.

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

Гибкие методы Scrum и Crystal Clear реализуют РПВ. "Всё" чего они просят, это чтобы команда выпускала готовые к работе приложения каждую итерацию. Всё остальное приложится. XP даёт чуть больше: вы получаете бесплатный список вещей в помощь.

РПВ требует гибкости

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

Становиться более гибкими совсем не просто. Это требует, чтобы вся организация, а особенно команда разработчиков, направили себя на изучение новых путей работы. Гибкость требуется метрикой, в то время как метрика требует всего лишь, чтобы команда выпускала рабочие протестированные возможности. Что, после всего сказанного, и есть реальная задача разработки программного обеспечения.

Copyright c 1999-2004, Ronald E Jeffries

С сайта www.realcoding.net

Экстремальное программирование и быстрая разработка ПО

Экстремальное программирование - или, сокращенно, XP - является ответом сообщества программистов на наступление формальных подходов к созданию программных продуктов и призвано вернуть в среду разработчиков дух творчества.

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

Противостоять нажиму формализма в работе программистов призвана инициатива группы разработчиков, объединившихся под лозунгом Экстремального Программирования, или XP. И хотя наши разработчики, в основном, еще далеки от проблем своих заокеанских коллег, тем не менее, многие методы с успехом могут быть использованы в нашей практике.

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

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

Экстремальный цикл

В основе экстремального программирования - очень короткий, постоянно повторяющийся цикл разработки, составляющий одну-три недели. К концу каждого цикла вы должны иметь полностью рабочий, функциональный и протестированный релиз приложения. Эти циклы должны быть повторяющимися и бесперебойными на протяжении всего проекта.

Предпосылкой для такого режима работы является многократно проверенный факт, что требования редко бывают полными, своевременными и корректными. Иными словами, как бы хорошо вы ни планировали свое приложение, имейте в виду, что его 100% придется переделывать. Более того, его, возможно, придется переделывать даже на завершающей стадии. Не откладывайте переделки на конец работы, делайте их регулярно.

Как следствие постоянно изменяющихся требований следует другой принцип - позднее принятие решений.

Позднее принятие решений

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

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

Кодирование в глубину

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

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

Из готовых, законченных функциональностей складываются истории пользователя, и именно "закрытие" отдельного класса проблем пользователя в самый быстрый срок должно стать основной целью. В противном случае может сложиться ситуация, когда на 90% готовое приложение нельзя показать заказчикам и пользователям, поскольку оно до конца не выполняет ни одной функции.

Помимо концентрации на одной задаче в каждом конкретном цикле важное значение имеют также скорость проекта и фактор загрузки.

Идеальный день разработчика и фактор загрузки

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

Фактор загрузки - это отношение реальных календарных рабочих дней к идеальным дням разработчика; он характеризует "температуру" разработки. Нормальными считаются факторы от двух до пяти, причем чем больший фактор вы можете позволить - тем больший запас адреналина есть в запасе у вашей команды. Опытные менеджеры используют "три" как стартовое значение, но для новых неосвоенных технологий следует использовать четыре или пять.

Другим временным фактором является скорость проекта.

Скорость проекта

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

История пользователей

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

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

Считается, что 80?20 историй пользователей являются идеальным числом для составления плана нового релиза.

План релиза

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

Выбранные истории являются основой для планов итераций.

План итераций

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

Если в результате детализации ожидаемое время разработки превосходит время цикла, то некоторые истории переносятся на более поздний срок. Этот эффект снежного кома - вполне обычная практика, поскольку детальные задачи часто распадаются на отдельные части, когда сумма времени для каждой превосходит время для целого.

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

Параллельно с выборкой историй пользователей план предусматривает создание набора тестов приемки, которые будут сопровождать код в процессе всех последующих сборок.

Тесты приемки

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

Тестирование - не приложение к приложению, а, скорее, наоборот. Часто контроль качества (QA) и составление тестов возлагается на отдельную группу, в состав которой входят представители заказчиков.

Представители заказчиков

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

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

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

Помимо тесного взаимодействия с заказчиками, особого внимания требует и структура группы разработчиков.

Структура группы разработчиков

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

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

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

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

В обстановке групповой работы важное значение получает максимальная простота и эффективность используемого кода.

Простота и эффективность используемого кода

Часто предоставленный сам себе разработчик решает использовать новую технологию или инструмент, который, по его мнению, обещает дополнительную производительность или выгоду. На самом деле это редко оправдывается, а в атмосфере, когда ваш код завтра будет прочитан и использован партнерами по команде, у вас просто не остается возможностей для экспериментов за чужой счет. Фактически, все члены команды изначально должны выбрать технологии, которыми владеют все или большинство членов команды. Например, любой разработчик должен уметь программно обрабатывать текстовые файлы, многие знают C++, Java, Perl, SQL и подобные инструменты. Использование редких технологий и инструментов, например сложных, особенно заказных RAD и т.п., может вызвать не только проблемы понимания, но и впоследствии проблемы поддержки. Учитывайте, что освоение сложного инструмента может занять больше времени, чем вся разработка проекта.

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

Рефракторинг

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

Тестирование модулей

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

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

Тесты служат четырем целям: во-первых, они, собственно, помогают протестировать функциональность; во-вторых, это естественная форма проектной документации, то есть на вопрос "что делает этот класс" можно ответить "пытается пройти набор функциональных тестов". Третье: тесты - это готовая часть описательной документации, сопровождающей класс после разработки, всегда отвечающая на вопрос "как использовать данный класс". И, наконец, это средство групповой разработки.

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

Групповое авторство

Одной из проблем программирования является недоступность по той или иной причине разработчика определенного фрагмента кода, в результате чего его поддержка становится сложной или невозможной. Многие заказчики и группы попадали и попадают в зависимость от "гуру" - и всегда с негативными последствиями.

В обстановке, когда "все делают все", идеи свободно высказываются и распространяются в группе. Более того, каждый может вносить изменения в любую строку кода. Это сложно понять с первого раза, отсутствие одного "супервизора" может сбить с толку - но это работает. По крайней мере, вполне распространена ситуация, когда весь коллектив выполняет одно неверное указание системного архитектора. Зависимость группы от одного, даже высококвалифицированного человека - весьма опасный путь. Участие в обсуждении архитектуры всех сотрудников не только повышает самооценку, улучшает квалификацию, но и приводит к значительно лучшим результатам разработки.

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