Проектирование
Переход к проектированию в стиле ХР во многом напоминает переход к тестированию в стиле ХР. Вы обнаружите, что по сравнению со старым кодом, новый код выглядит совершенно по-другому. Вам захочется исправить все сразу. Не делайте этого. Модернизацию следует осуществлять постепенно. По мере добавления новой функциональности будьте готовы перед этим выполнить переработку кода. Когда вы разрабатываете программу в рамках ХР, вы всегда готовы вначале выполнить переработку, однако если вы осуществляете переход на ХР существующего проекта, вам придется выполнять переработку чаще.На ранних стадиях процесса команда должна определить долгосрочные цели переработки существующего кода. Возможно, в проекте используется слишком запутанная иерархия наследования классов, возможно, некоторая важная функциональность разбросана по всей системе и вы желаете собрать ее воедино. Сформулируйте все эти цели, запишите их на карточках и развесьте эти карточки на видных местах. Когда вы сможете сказать, что большая переработка закончена (для этого могут потребоваться месяцы или даже год работы в описанном постепенном стиле), можете устроить посвященную этому веселую вечеринку. Торжественно сожгите карточки. Хорошенько выпейте и закусите.
Эффект этой стратегии во многом напоминает эффект стратегии тестирования по необходимости. Те части системы, к которым вы обращаетесь чаще всего, в скором времени будут напоминать код, изначально разрабатываемый с применением принципов ХР. Дополнительная нагрузка, связанная с необходимостью переработки существующего кода, в скором времени растворится в воздухе.
Планирование
Вы должны преобразовать существующую информацию о требованиях в набор карточек с историями. Вы должны обучить вашего заказчика правилам игры. Заказчик должен решить, что необходимо включить в следующую версию программы.Наибольшая сложность (равно, как и преимущество) при переходе к планированию в стиле ХР состоит в том, что вы должны объяснить вашему заказчику, насколько больше он сможет получить от команды, если перейдет на новые правила взаимодействия с разработчиками. Скорее всего, заказчик ранее не имел опыта работы с командой, которая приветствует внесение изменений в требования. Конечно, для того, чтобы привыкнуть к новым открывающимся перед ним возможностям, заказчику потребуется некоторое время.
Менеджмент
Освоение менеджмента ХР – один из наиболее сложных переходов в процессе адаптации к ХР. Менеджмент ХР – это игра в направление и влияние. Если вы менеджер, скорее всего, вы поймаете себя на том, что принимаете решения, которые должны приниматься либо программистами, либо заказчиками. Если этот так, то не паникуйте. Просто напомните себе и всем присутствующим, что вы просто обучаетесь. После этого попросите нужного человека принять решение и поставить вас в известность о том, что решено.Программисты, неожиданно наделенные новой ответственностью, вряд ли сразу же начнут делать большую работу. Как менеджер, в течение переходного периода вы должны с особенной тщательностью напоминать всем об избранных правилах действий. В состоянии стресса каждый будет пытаться вернуться к старому стилю поведения вне зависимости от того, эффективным ли был этот стиль или нет.
Ощущения будут напоминать те, которые возникают при адаптации к ХР проектированию или тестированию. Поначалу все будет казаться вам неудобным. Вы будете ощущать, что вы действуете не с самой быстрой возможной скоростью. Однако если вы будете уделять время изучению ситуаций, возникающих изо дня в день, то вы (равно как и программисты, и заказчики) научитесь решать все возникающие проблемы гладко.
В скором времени вы почувствуете себя комфортно в новом процессе. Однако время от времени будет возникать ситуация, в которой вы будете сталкиваться с тем, что сделано до того, как вы приступили к внедрению ХР. Как только возникнет такая ситуация, сделайте шаг назад. Напомните команде о правилах, ценностях и принципах. После этого решите, что делать.
Наиболее сложным аспектом менеджмента в процессе стремительного перехода к использованию ХР является принятие решения о том, что некоторый член команды не справляется с работой в новых условиях. В подобной ситуации лучше расстаться с ним. При этом, если вы уверены, что ситуация не изменится в лучшую сторону, вы должны сделать изменения так быстро, как это возможно.
Разработка
Первым делом, которое вы обязаны сделать, является проверка расположения столов. Я не шучу. Прочтите заново материал о программировании парами (см. главу 16). Передвиньте ваши столы так, чтобы за каждым из них могли с удобством расположиться два человека и чтобы они могли передавать друг другу клавиатуру без необходимости двигать при этом стулья.С одной стороны, при переходе к использованию ХР вы должны более строго следить за обязательным использованием программирования парами. Поначалу программирование парами может показаться вам неудобным. Вы должны заставлять себя программировать парами, даже если вам кажется, что это неудобно и неэффективно. С другой стороны, вы должны время от времени делать перерывы. Уединитесь на пару часиков и попрограммируйте в одиночку. Конечно же, результаты вашей работы следует выбросить, но вы ни в коем случае не должны отказываться от удовольствия, которое вы получаете от программирования, только для того, чтобы сказать, что вы программируете в парах в течение 30 часов за одну неделю.
Проблемы?
Некоторые из читателей данной книги уже обладают готовыми сформированными командами, однако разрабатываемые ими программные системы еще не поступили в эксплуатацию. Возможно, ваш проект погряз во множестве проблем и ХР может выглядеть как возможное спасение.Не рассчитывайте на это. Возможно, если бы вы использовали ХР с самого начала, вы смогли бы (или не смогли бы) избежать возникновения текущей ситуации. Однако если менять коня на переправе сложно, то менять умирающего коня в десять раз сложнее. Эмоции будут на пределе. Моральный дух будет очень низким.
Если перед вами стоит выбор: либо использовать ХР, либо быть уволенным, прежде всего поймите, что ваши шансы последовательно и тщательно внедрить новые методики работы очень низки. В состоянии стресса вы будете постоянно возвращаться к старым привычкам. У вас и без того хватает напряжения. Вы пытаетесь сделать работу, которая ускользает у вас из рук. К этому вы хотите добавить дополнительную нагрузку, связанную с внедрением ХР. Таким образом, ваши шансы на успешный переход к ХР существенно снижаются. Выберите для себя более скромную цель, чем спасение всего проекта. Приближайтесь к ней постепенно, день за днем. Довольствуйтесь тем, что нового вы можете узнать о тестировании или управлении проектом не напрямую, или насколько красивым вы можете сделать дизайн, или насколько большой объем кода вы можете удалить. Возможно, если вы не будете думать о завтрашнем дне, из хаоса сформируется более приемлемый для вас порядок.
Все же если вы собрались переводить проблемный проект на использование ХР, сделайте это драматическим событием. Полумеры, скорее всего, не помогут – все останется в более-менее прежнем состоянии. Тщательно проанализируйте весь имеющийся код. Сможете ли вы обойтись без него? Может быть, будет лучше забыть о его существовании? Если да, то выбросите его. Целиком. Разожгите огромный костер и торжественно сожгите старые ленты резервного копирования. Сделайте неделю передышки. И после этого начните все заново со свежими силами.
Глава 21.
Жизненный цикл идеального ХР-проекта
Идеальный проект ХР проходит сквозь короткую стадию начальной разработки, за которой следуют годы поддержки эксплуатации системы на производстве и одновременно пересмотра и переделки. Наконец, когда проект теряет актуальность, он элегантно отправляется в отставку.
В данной главе дается представление о полном жизненном цикле проекта ХР – его истории от начала до конца. История идеализирована – я полагаю, что на текущий момент вы уже поняли, что никаких два проекта ХР не могут (да и не должны) быть абсолютно одинаковыми. В данной главе дается представление о фазах жизни проекта.
Однако прежде, чем вы сможете приступить к эксплуатации системы, вы должны поверить в то, что система может эксплуатироваться. Вы должны убедиться в том, что имеющиеся у вас инструменты позволят вам успешно завершить работу над программой. Вы должны поверить в то, что, когда код завершен, вы сможете запускать его изо дня в день. Вы должны поверить в то, что у вас есть (или вы сможете получить) все необходимые навыки, которые вам потребуются для работы. Члены команды должны научиться доверять друг другу.
Именно в ходе фазы исследования все эти составляющие собираются в единое целое. Исследование можно считать завершенным тогда, когда заказчик уверен в том, что на карточках историй содержится более чем достаточно материала для того, чтобы сделать самую первую хорошую версию системы, а программисты уверены в том, что они уже не могут оценить эти истории лучше, не реализовав при этом систему в коде.
В процессе исследования программисты осваивают каждую из составляющих технологии, которую они собираются применять при разработке системы. Они активно исследуют варианты организации системной архитектуры. Для этого в течение одной или двух недель они формируют систему, подобную той, которую они собираются реализовать, но несколькими разными способами. Несколько разных пар могут попробовать сформировать систему несколькими разными способами, а затем сравнить. Возможен и другой подход. Две пары по отдельности реализуют систему одним и тем же способом, затем анализируют получившиеся в результате различия.
Если недели недостаточно для того, чтобы освоиться с некоторой технологией, эту технологию следует классифицировать как рискованную. Это не означает, что вы не можете ее использовать. Однако вы должны изучить ее более тщательно и рассмотреть возможные альтернативы. Во время исследования вы можете привлечь к работе сторонних специалистов, владеющих некоторой технологией лучше, чем вы. Благодаря сторонней помощи вам не придется сражаться с какими-либо проблемами, которые могут быть решены без затруднений, если только знать правильный подход. Как правило, специалисты владеют множеством таких правильных подходов. Однако относиться к советам специалистов необходимо с должной осторожностью. Не следует слепо доверять всему, что они говорят. Дело в том, что у экспертов часто вырабатываются привычки, основанные на применении некоторой технологии в крупномасштабных системах. Это не всегда то, на что вы рассчитываете, и это не всегда хорошо сочетается с принципами экстремального программирования. Команда должна хорошо владеть избранными методиками. Фраза: Так посоветовал эксперт – не является удовлетворительным аргументом в случае, если проект выходит из-под контроля.
Программисты должны также экспериментировать с пределами производительности для технологии, которую они собираются использовать. Если это возможно, они должны имитировать реалистичный уровень нагрузки на используемое в производстве аппаратное обеспечение и сеть. Это не означает, что вы должны в лабораторных условиях воспроизвести копию промышленной аппаратной платформы. Очень многие оценки можно сделать на основании расчетов. Например, прикинув примерный объем данных, передаваемых в рамках одного запроса, вы сможете вычислить, какой пропускной способностью должен обладать канал связи. После этого вы можете провести эксперимент, чтобы увидеть, возможно ли реализовать это на практике.
Программисты должны также экспериментировать с архитектурными идеями – как построить систему с несколькими уровнями отмены действий? Попробуйте реализовать этот механизм тремя разными способами и определите, какой из них самый эффективный. Подобные небольшие исследования в области архитектуры особенно важны в случае, если к вам приходит пользователь системы и рассказывает вам истории, которые вы не знаете, как реализовать.
Программисты должны оценить каждую из задач, которые им придется решить в процессе исследований. Проводя исследования, они должны прикинуть, какое время потребуется им для решения задачи. Когда работа над задачей завершается, необходимо сравнить предварительно сделанную оценку с реальным календарным временем, которое потребовалось для решения задачи. Использование такого подхода на практике повышает уверенность команды в своих оценках.
Пока команда практикуется с технологиями, заказчик практикуется с историями. Не ждите, что этот процесс будет протекать гладко и без запинок. Поначалу истории будут не такими, как вам хотелось бы. Чтобы решить проблему, необходимо обеспечить заказчика быстрой обратной связью. Как можно быстрее сообщайте ему вашу оценку предоставляемых им историй. Вы должны сообщить ему, что правильно, а что – нет. Какие данные должны указываться в истории, а какие – нет. В скором времени заказчик научится включать в историю именно то, что нужно программистам, и не включать в нее то, в чем программисты не нуждаются. Ключевым является вопрос: Могут ли программисты с уверенностью оценить усилия, которые потребуются для реализации истории? Иногда оказывается, что историю требуется реализовать иначе. Иногда оказывается, что программисты должны на некоторое время приостановить свое продвижение вперед и заняться экспериментированием.
Если у вас в распоряжении команда, члены которой хорошо знают друг друга, а также уже владеют технологией, которую предполагается использовать, фаза исследований может занять не более нескольких недель. Если команда плохо знакома с технологией, а ее члены еще не успели сработаться друг с другом, для исследований может потребоваться несколько месяцев. Если исследование требует еще больше времени, я порекомендовал бы заняться реализацией менее крупного, но более реального проекта, с которым команда справится без затруднений. В процессе работы вы сможете лучше овладеть дисциплиной и освоиться с методиками.
План работ над первой версией продукта должен быть рассчитан на срок от двух до шести месяцев. За более короткое время вы вряд ли сможете решить какие-либо значительные проблемы бизнеса. (Однако если вы в состоянии справиться за более короткое время, это просто замечательно! В книге Тома Гилба (Tom Gilb) под названием Principles of Software Engineering Management (Принципы менеджмента в области разработки программного обеспечения) содержатся идеи, направленные на сокращение даты выхода первой версии продукта. Если для работы над первой версией требуется больше времени, значит, риск разработки становится слишком большим.
В ходе первой итерации происходит формирование архитектуры. По этой причине для первой итерации следует подобрать истории, которые стимулируют формирование общей структуры системы, пусть даже в форме примитивного каркаса, к которому в дальнейшем будет пристыковываться вся остальная функциональность.
Подбор историй для последующих итераций целиком и полностью осуществляется на усмотрение заказчика. При этом заказчик должен задать себе вопрос: Какая возможность системы является для нас наиболее полезной? Именно самые полезные возможности включаются в состав следующей итерации.
Занимаясь реализацией итераций, вы следите за отклонением от плана. Потребовалось ли для реализации чего-либо в два раза больше времени, чем вы думали? Может быть, вы управились в два раза быстрее? Реализованы ли тестовые случаи в срок? Насколько приятно вам работать?
Если вы обнаруживаете отклонения от плана, значит, вы должны чегото изменить. Возможно, требуется изменить план – добавить или убрать истории или изменить объем работ. Может быть, изменения следует внести в процесс – вы обнаружили более эффективные методы использования вашей технологии или более эффективные способы внедрения ХР.
В идеале, в конце каждой итерации у заказчика есть набор завершенных функциональных тестов и все они срабатывают. В конце каждой итерации рекомендуется устроить небольшую праздничную церемонию – купите пиццу, запалите пару фейерверков, пусть заказчик оставит свой автограф на карточках реализованных историй. Еще бы, ведь вы разработали качественный программный продукт в срок! Возможно, для этого вам потребовалось лишь три недели, но все равно это достижение и это стоит отметить!
В конце последней итерации вы готовы приступить к эксплуатации системы в реальных производственных условиях.
Как правило, для сертификации программного обеспечения (то есть для того, чтобы определить, готово ли оно к использованию в реальных производственных условиях) используется специальный процесс. Будьте готовы к тому, что вам потребуется разработать новые тесты для того, чтобы убедиться в готовности системы к реальной работе. Зачастую именно на этой стадии применяется параллельное тестирование.
В ходе этой фазы вы также оптимизируете производительность системы. В данной книге я почти ничего не говорю о производительности. Я уверен в лозунге: Сделайте, чтобы это заработало, сделайте, чтобы это было написано правильно, сделайте, чтобы это работало быстро (Make it run, make it right, make it fast). На завершающих стадиях работы над версией наступает отличное время для оптимизации, потому что именно в это время вы получаете максимально возможное количество знаний, внедренных в дизайн системы, вы получаете наиболее реалистичные оценки производственной нагрузки на систему и, кроме того, вы скорее всего получаете в свое распоряжение реальную производственную аппаратную платформу.
В процессе внедрения очередной версии системы в эксплуатацию вы замедляете темпы эволюционирования системы. Это не означает, что программа вообще перестает эволюционировать, скорее риск становится более значимым фактором, когда вы размышляете, заслуживает ли то или иное изменение того, чтобы включить его в систему. Однако имейте в виду, что чем большим опытом работы с системой вы будете обладать, тем более четко вы представляете себе, как она должна быть спроектирована. Если у вас возникает огромное количество идей, которые вы не можете включить в текущую версию системы, составьте список и сделайте его доступным для обозрения. Благодаря этому каждый сможет увидеть, в каком направлении будет развиваться система после того, как текущая версия начнет эксплуатироваться на предприятии заказчика.
Когда очередная версия программного продукта будет внедрена, устройте большой праздник. Многие проекты никогда не доходят до внедрения, поэтому если ваш проект дошел до этой стадии и продолжает жить, – это отличная причина собраться и отметить очередную вашу победу. Если на этой стадии вы не чувствуете никаких, пусть даже легких, опасений, значит либо у вас железные нервы, либо вы сумасшедший, однако веселая вечеринка поможет вам избавиться от напряжения, которое в противном случае может только возрасти.
Работа над каждой очередной версией начинается с исследований. Вы можете попробовать выполнить крупномасштабную переработку кода, которой вы опасались на завершающих стадиях работы над предыдущей версией. Вы можете попробовать использовать новую технологию, поддержку которой вы намеревались обеспечить в очередной версии продукта. Возможно, вы захотите перейти на использование новой версии технологии, которую вы уже применяете в рамках продукта. Вы можете поэкспериментировать с новыми архитектурными идеями. Заказчик может попытаться написать новые бредовые истории в поисках золотой жилы, которая способна многократно увеличить производительность бизнеса.
Разработка системы, которая уже функционирует в условиях реального производства, – это не одно и то же, что и разработка системы, которая еще не эксплуатируется на реальном предприятии. Вы более осторожно относитесь к любым осуществляемым вами изменениям. Вы должны быть готовы прервать дальнейшую разработку для того, чтобы прореагировать на проблемы, которые возникли на производстве. Вы имеете дело с реальными данными, с которыми надо обходиться чрезвычайно осторожно. Вы должны позаботиться о миграции этих данных при любом в достаточной степени значительном изменении дизайна. Если бы фаза предварительной разработки не была бы столь рискованной и опасной, вы могли бы оттягивать момент внедрения системы неограниченно долгое время. Внедрение системы в производство, скорее всего, повлияет на скорость разработки. Делая новые оценки, будьте более консервативны.
В процессе исследований оцените эффект, который окажет на процесс разработки необходимость поддержки функционирования системы в реальных производственных условиях. После внедрения первой версии системы на производстве я наблюдал существенные изменения отношения идеального времени разработки к реальному календарному времени (с двух календарных дней к одному идеальному до внедрения до трех календарных дней к одному идеальному после внедрения). Не стоит делать туманных предположений. Постарайтесь определить этот коэффициент точно.
Будьте готовы изменить структуру команды специально для того, чтобы эффективнее обслуживать функционирование системы. Возможно, вам захочется организовать нечто вроде службы технической поддержки, чтобы большая часть программистов не отрывалась слишком часто от текущей разработки для решения возникающих производственных проблем.
Следует организовать смену персонала в этой службе таким образом, чтобы со временем все работающие над системой программисты побывали в этой роли, – существуют вещи, которым можно научиться, только осуществляя техническую поддержку системы на производстве и о которых нельзя узнать как-либо иначе. С другой стороны, техническая поддержка – занятие менее веселое, чем разработка.
Размещайте новые разработанные куски программы в работающей на производстве системе по мере их разработки. Возможно, вплоть до очередной версии эти части не будут использоваться и не будут работать. Я все равно рекомендую вам добавлять новый разработанный код в реально работающую систему. Я работал над проектами, в которых подобный цикл выполнялся ежедневно или еженедельно. В любом случае, вы не должны оставлять готовый код в бездействующем состоянии дольше, чем в течение одной итерации. Это время определяется величиной затрат, связанных с верификацией кода и миграцией данных. Последнее действие, которое вам будет необходимо выполнить в конце работы над версией, это интеграция большого куска кода, который, скорее всего, не сможет ничего поломать. Если вы будете поддерживать код, используемый на производстве, и код, находящийся в разработке, приблизительно в синхронизированном состоянии, вы будете раньше узнавать об интеграционных проблемах.
В данной главе дается представление о полном жизненном цикле проекта ХР – его истории от начала до конца. История идеализирована – я полагаю, что на текущий момент вы уже поняли, что никаких два проекта ХР не могут (да и не должны) быть абсолютно одинаковыми. В данной главе дается представление о фазах жизни проекта.
Исследование
Предварительная подготовка к работе – это неестественное состояние системы, и этот этап должен быть завершен как можно быстрее. Какую фразу я услышал совсем недавно? Если программа начинает эксплуатироваться на производстве, значит, программа завершена. ХР утверждает прямо противоположное. Если программа еще не эксплуатируется на производстве, это значит, что мы тратим деньги и при этом не зарабатываем деньги. Я рассматриваю эту ситуацию так, как будто это мой бумажник. Ситуация, когда деньги тратятся и при этом не зарабатываются, кажется мне очень дискомфортной.Однако прежде, чем вы сможете приступить к эксплуатации системы, вы должны поверить в то, что система может эксплуатироваться. Вы должны убедиться в том, что имеющиеся у вас инструменты позволят вам успешно завершить работу над программой. Вы должны поверить в то, что, когда код завершен, вы сможете запускать его изо дня в день. Вы должны поверить в то, что у вас есть (или вы сможете получить) все необходимые навыки, которые вам потребуются для работы. Члены команды должны научиться доверять друг другу.
Именно в ходе фазы исследования все эти составляющие собираются в единое целое. Исследование можно считать завершенным тогда, когда заказчик уверен в том, что на карточках историй содержится более чем достаточно материала для того, чтобы сделать самую первую хорошую версию системы, а программисты уверены в том, что они уже не могут оценить эти истории лучше, не реализовав при этом систему в коде.
В процессе исследования программисты осваивают каждую из составляющих технологии, которую они собираются применять при разработке системы. Они активно исследуют варианты организации системной архитектуры. Для этого в течение одной или двух недель они формируют систему, подобную той, которую они собираются реализовать, но несколькими разными способами. Несколько разных пар могут попробовать сформировать систему несколькими разными способами, а затем сравнить. Возможен и другой подход. Две пары по отдельности реализуют систему одним и тем же способом, затем анализируют получившиеся в результате различия.
Если недели недостаточно для того, чтобы освоиться с некоторой технологией, эту технологию следует классифицировать как рискованную. Это не означает, что вы не можете ее использовать. Однако вы должны изучить ее более тщательно и рассмотреть возможные альтернативы. Во время исследования вы можете привлечь к работе сторонних специалистов, владеющих некоторой технологией лучше, чем вы. Благодаря сторонней помощи вам не придется сражаться с какими-либо проблемами, которые могут быть решены без затруднений, если только знать правильный подход. Как правило, специалисты владеют множеством таких правильных подходов. Однако относиться к советам специалистов необходимо с должной осторожностью. Не следует слепо доверять всему, что они говорят. Дело в том, что у экспертов часто вырабатываются привычки, основанные на применении некоторой технологии в крупномасштабных системах. Это не всегда то, на что вы рассчитываете, и это не всегда хорошо сочетается с принципами экстремального программирования. Команда должна хорошо владеть избранными методиками. Фраза: Так посоветовал эксперт – не является удовлетворительным аргументом в случае, если проект выходит из-под контроля.
Программисты должны также экспериментировать с пределами производительности для технологии, которую они собираются использовать. Если это возможно, они должны имитировать реалистичный уровень нагрузки на используемое в производстве аппаратное обеспечение и сеть. Это не означает, что вы должны в лабораторных условиях воспроизвести копию промышленной аппаратной платформы. Очень многие оценки можно сделать на основании расчетов. Например, прикинув примерный объем данных, передаваемых в рамках одного запроса, вы сможете вычислить, какой пропускной способностью должен обладать канал связи. После этого вы можете провести эксперимент, чтобы увидеть, возможно ли реализовать это на практике.
Программисты должны также экспериментировать с архитектурными идеями – как построить систему с несколькими уровнями отмены действий? Попробуйте реализовать этот механизм тремя разными способами и определите, какой из них самый эффективный. Подобные небольшие исследования в области архитектуры особенно важны в случае, если к вам приходит пользователь системы и рассказывает вам истории, которые вы не знаете, как реализовать.
Программисты должны оценить каждую из задач, которые им придется решить в процессе исследований. Проводя исследования, они должны прикинуть, какое время потребуется им для решения задачи. Когда работа над задачей завершается, необходимо сравнить предварительно сделанную оценку с реальным календарным временем, которое потребовалось для решения задачи. Использование такого подхода на практике повышает уверенность команды в своих оценках.
Пока команда практикуется с технологиями, заказчик практикуется с историями. Не ждите, что этот процесс будет протекать гладко и без запинок. Поначалу истории будут не такими, как вам хотелось бы. Чтобы решить проблему, необходимо обеспечить заказчика быстрой обратной связью. Как можно быстрее сообщайте ему вашу оценку предоставляемых им историй. Вы должны сообщить ему, что правильно, а что – нет. Какие данные должны указываться в истории, а какие – нет. В скором времени заказчик научится включать в историю именно то, что нужно программистам, и не включать в нее то, в чем программисты не нуждаются. Ключевым является вопрос: Могут ли программисты с уверенностью оценить усилия, которые потребуются для реализации истории? Иногда оказывается, что историю требуется реализовать иначе. Иногда оказывается, что программисты должны на некоторое время приостановить свое продвижение вперед и заняться экспериментированием.
Если у вас в распоряжении команда, члены которой хорошо знают друг друга, а также уже владеют технологией, которую предполагается использовать, фаза исследований может занять не более нескольких недель. Если команда плохо знакома с технологией, а ее члены еще не успели сработаться друг с другом, для исследований может потребоваться несколько месяцев. Если исследование требует еще больше времени, я порекомендовал бы заняться реализацией менее крупного, но более реального проекта, с которым команда справится без затруднений. В процессе работы вы сможете лучше овладеть дисциплиной и освоиться с методиками.
Планирование
В ходе фазы планирования заказчики и программисты должны прийти к обоюдоодобренному соглашению по поводу даты, к которой будет реализован наименьший возможный полезный для бизнеса набор историй. Этот процесс описан в разделах, посвященных игре в планирование. Если в ходе исследовательской фазы вы достаточно хорошо подготовились, фаза планирования (формирование графика работ) не займет у вас больше, чем один-два дня.План работ над первой версией продукта должен быть рассчитан на срок от двух до шести месяцев. За более короткое время вы вряд ли сможете решить какие-либо значительные проблемы бизнеса. (Однако если вы в состоянии справиться за более короткое время, это просто замечательно! В книге Тома Гилба (Tom Gilb) под названием Principles of Software Engineering Management (Принципы менеджмента в области разработки программного обеспечения) содержатся идеи, направленные на сокращение даты выхода первой версии продукта. Если для работы над первой версией требуется больше времени, значит, риск разработки становится слишком большим.
Итерации в первой версии
График работы над первой версией разбит на несколько итераций длительностью от одной до четырех недель. В ходе каждой итерации разрабатывается набор функциональных тестовых случаев для каждой из историй, запланированных для выпуска в рамках данной итерации.В ходе первой итерации происходит формирование архитектуры. По этой причине для первой итерации следует подобрать истории, которые стимулируют формирование общей структуры системы, пусть даже в форме примитивного каркаса, к которому в дальнейшем будет пристыковываться вся остальная функциональность.
Подбор историй для последующих итераций целиком и полностью осуществляется на усмотрение заказчика. При этом заказчик должен задать себе вопрос: Какая возможность системы является для нас наиболее полезной? Именно самые полезные возможности включаются в состав следующей итерации.
Занимаясь реализацией итераций, вы следите за отклонением от плана. Потребовалось ли для реализации чего-либо в два раза больше времени, чем вы думали? Может быть, вы управились в два раза быстрее? Реализованы ли тестовые случаи в срок? Насколько приятно вам работать?
Если вы обнаруживаете отклонения от плана, значит, вы должны чегото изменить. Возможно, требуется изменить план – добавить или убрать истории или изменить объем работ. Может быть, изменения следует внести в процесс – вы обнаружили более эффективные методы использования вашей технологии или более эффективные способы внедрения ХР.
В идеале, в конце каждой итерации у заказчика есть набор завершенных функциональных тестов и все они срабатывают. В конце каждой итерации рекомендуется устроить небольшую праздничную церемонию – купите пиццу, запалите пару фейерверков, пусть заказчик оставит свой автограф на карточках реализованных историй. Еще бы, ведь вы разработали качественный программный продукт в срок! Возможно, для этого вам потребовалось лишь три недели, но все равно это достижение и это стоит отметить!
В конце последней итерации вы готовы приступить к эксплуатации системы в реальных производственных условиях.
Внедрение в эксплуатацию
На завершающих стадиях работы над очередной версией следует сократить цикл обратной связи. Вместо трехнедельных итераций необходимо перейти на итерации продолжительностью в одну неделю. Возможно, будет полезным устраивать ежедневное совещание, благодаря чему вся команда будет точно знать, над чем в данный момент работает тот или иной член команды.Как правило, для сертификации программного обеспечения (то есть для того, чтобы определить, готово ли оно к использованию в реальных производственных условиях) используется специальный процесс. Будьте готовы к тому, что вам потребуется разработать новые тесты для того, чтобы убедиться в готовности системы к реальной работе. Зачастую именно на этой стадии применяется параллельное тестирование.
В ходе этой фазы вы также оптимизируете производительность системы. В данной книге я почти ничего не говорю о производительности. Я уверен в лозунге: Сделайте, чтобы это заработало, сделайте, чтобы это было написано правильно, сделайте, чтобы это работало быстро (Make it run, make it right, make it fast). На завершающих стадиях работы над версией наступает отличное время для оптимизации, потому что именно в это время вы получаете максимально возможное количество знаний, внедренных в дизайн системы, вы получаете наиболее реалистичные оценки производственной нагрузки на систему и, кроме того, вы скорее всего получаете в свое распоряжение реальную производственную аппаратную платформу.
В процессе внедрения очередной версии системы в эксплуатацию вы замедляете темпы эволюционирования системы. Это не означает, что программа вообще перестает эволюционировать, скорее риск становится более значимым фактором, когда вы размышляете, заслуживает ли то или иное изменение того, чтобы включить его в систему. Однако имейте в виду, что чем большим опытом работы с системой вы будете обладать, тем более четко вы представляете себе, как она должна быть спроектирована. Если у вас возникает огромное количество идей, которые вы не можете включить в текущую версию системы, составьте список и сделайте его доступным для обозрения. Благодаря этому каждый сможет увидеть, в каком направлении будет развиваться система после того, как текущая версия начнет эксплуатироваться на предприятии заказчика.
Когда очередная версия программного продукта будет внедрена, устройте большой праздник. Многие проекты никогда не доходят до внедрения, поэтому если ваш проект дошел до этой стадии и продолжает жить, – это отличная причина собраться и отметить очередную вашу победу. Если на этой стадии вы не чувствуете никаких, пусть даже легких, опасений, значит либо у вас железные нервы, либо вы сумасшедший, однако веселая вечеринка поможет вам избавиться от напряжения, которое в противном случае может только возрасти.
Обслуживание и поддержка
Обслуживание и поддержка в действительности – это нормальное состояние любого ХР-проекта. Вы должны одновременно работать над реализацией новой функциональности, поддерживать существующую систему в рабочем состоянии, принимать в команду новых членов и говорить слова прощания тем, кто уходит.Работа над каждой очередной версией начинается с исследований. Вы можете попробовать выполнить крупномасштабную переработку кода, которой вы опасались на завершающих стадиях работы над предыдущей версией. Вы можете попробовать использовать новую технологию, поддержку которой вы намеревались обеспечить в очередной версии продукта. Возможно, вы захотите перейти на использование новой версии технологии, которую вы уже применяете в рамках продукта. Вы можете поэкспериментировать с новыми архитектурными идеями. Заказчик может попытаться написать новые бредовые истории в поисках золотой жилы, которая способна многократно увеличить производительность бизнеса.
Разработка системы, которая уже функционирует в условиях реального производства, – это не одно и то же, что и разработка системы, которая еще не эксплуатируется на реальном предприятии. Вы более осторожно относитесь к любым осуществляемым вами изменениям. Вы должны быть готовы прервать дальнейшую разработку для того, чтобы прореагировать на проблемы, которые возникли на производстве. Вы имеете дело с реальными данными, с которыми надо обходиться чрезвычайно осторожно. Вы должны позаботиться о миграции этих данных при любом в достаточной степени значительном изменении дизайна. Если бы фаза предварительной разработки не была бы столь рискованной и опасной, вы могли бы оттягивать момент внедрения системы неограниченно долгое время. Внедрение системы в производство, скорее всего, повлияет на скорость разработки. Делая новые оценки, будьте более консервативны.
В процессе исследований оцените эффект, который окажет на процесс разработки необходимость поддержки функционирования системы в реальных производственных условиях. После внедрения первой версии системы на производстве я наблюдал существенные изменения отношения идеального времени разработки к реальному календарному времени (с двух календарных дней к одному идеальному до внедрения до трех календарных дней к одному идеальному после внедрения). Не стоит делать туманных предположений. Постарайтесь определить этот коэффициент точно.
Будьте готовы изменить структуру команды специально для того, чтобы эффективнее обслуживать функционирование системы. Возможно, вам захочется организовать нечто вроде службы технической поддержки, чтобы большая часть программистов не отрывалась слишком часто от текущей разработки для решения возникающих производственных проблем.
Следует организовать смену персонала в этой службе таким образом, чтобы со временем все работающие над системой программисты побывали в этой роли, – существуют вещи, которым можно научиться, только осуществляя техническую поддержку системы на производстве и о которых нельзя узнать как-либо иначе. С другой стороны, техническая поддержка – занятие менее веселое, чем разработка.
Размещайте новые разработанные куски программы в работающей на производстве системе по мере их разработки. Возможно, вплоть до очередной версии эти части не будут использоваться и не будут работать. Я все равно рекомендую вам добавлять новый разработанный код в реально работающую систему. Я работал над проектами, в которых подобный цикл выполнялся ежедневно или еженедельно. В любом случае, вы не должны оставлять готовый код в бездействующем состоянии дольше, чем в течение одной итерации. Это время определяется величиной затрат, связанных с верификацией кода и миграцией данных. Последнее действие, которое вам будет необходимо выполнить в конце работы над версией, это интеграция большого куска кода, который, скорее всего, не сможет ничего поломать. Если вы будете поддерживать код, используемый на производстве, и код, находящийся в разработке, приблизительно в синхронизированном состоянии, вы будете раньше узнавать об интеграционных проблемах.