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

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

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

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

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

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

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

План работ над первой версией продукта должен быть рассчитан на срок от двух до шести месяцев. За более короткое время вы вряд ли сможете решить какие-либо значительные проблемы бизнеса. (Однако если вы в состоянии справиться за более короткое время, это просто замечательно! В книге Тома Гилба (Tom Gilb) под названием Principles of Software Engineering Management (Принципы менеджмента в области разработки программного обеспечения) содержатся идеи, направленные на сокращение даты выхода первой версии продукта. Если для работы над первой версией требуется больше времени, значит, риск разработки становится слишком большим.

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

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

Подбор историй для последующих итераций целиком и полностью осуществляется на усмотрение заказчика. При этом заказчик должен задать себе вопрос: Какая возможность системы является для нас наиболее полезной? Именно самые полезные возможности включаются в состав следующей итерации.

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

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

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

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

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

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

В ходе этой фазы вы также оптимизируете производительность системы. В данной книге я почти ничего не говорю о производительности. Я уверен в лозунге: Сделайте, чтобы это заработало, сделайте, чтобы это было написано правильно, сделайте, чтобы это работало быстро (Make it run, make it right, make it fast). На завершающих стадиях работы над версией наступает отличное время для оптимизации, потому что именно в это время вы получаете максимально возможное количество знаний, внедренных в дизайн системы, вы получаете наиболее реалистичные оценки производственной нагрузки на систему и, кроме того, вы скорее всего получаете в свое распоряжение реальную производственную аппаратную платформу.

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

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