Принципы быстрой разработки ПО

E-mail Печать PDF
Рейтинг пользователей: / 0
ХудшийЛучший 
Индекс материала
Принципы быстрой разработки ПО
Экстремальное программирование
Игра в планирование (Planning Game)
Пользовательские истории
«Билль о правах» заказчика
«Билль о правах» программиста
Притча
xUnit
Приемочные тесты
План рабочего цикла
План выпуска версий
Все страницы

Принципы быстрой разработки ПО

Процесс разработки ПО

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

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

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

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

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

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

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

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

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

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

·                    Рабочее программное обеспечение — это первостепенный критерий процесса. Прогресс в проектах быстрой разработки ПО отслеживается путем оценки части ПО, которая в текущий момент времени удовлетворяет требования заказчика. Прогресс подобных проектов не связан с текущим этапом их выполнения, а также не может оцениваться на основе объема выпущенной документации или кода инфраструктуры, разработанного в результате их выполнения. Программный проект считается выполненным на 30%, если получен на 30% функционирующий программный продукт.

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

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

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

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

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


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

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

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

Экстремальное программирование основано на том, что процесс разработки программного обеспечения — это процесс тесного и интенсивного взаимодействия между людьми. Хорошая методика разработки программ должна с максимальной эффективностью использовать сильные человеческие качества и сглаживать человеческие недостатки. На наш взгляд, ХР лучше других методик учитывает весь комплекс факторов, оказывающих влияние на людей, занятых разработкой программ. За истекшее десятилетие ХР является наиболее радикальной инновацией в индустрии производства программного обеспечения. В рамках ХР каждому участнику проекта назначается определенная роль с соответствующим набором полномочий. ХР способствует тому, что все участники проекта исполняют назначенные им роли, а следовательно, каждый из них действует в границах своей компетенции. Благодаря этому люди, принимающие участие в проекте, эффективно работают, как единая команда. Разработка программного продукта, решающего поставленную бизнес-задачу, выглядит как диалог, в котором принимает участие каждая из заинтересованных сторон. Заказчики формулируют пожелания (stories), назначают им приоритеты (priorities), создают приемочные тесты (acceptance tests), а также снабжают программистов и менеджеров всей необходимой информацией тогда, когда это необходимо. Программисты сообщают заказчикам предварительные оценки трудозатрат (estimates), а позже передают им работающий код в совокупности с тестами модулей (unit test). Менеджеры выступают посредниками — они уравновешивают требования заказчиков и затраты, необходимые для реализации этих требований программистами, кроме того, менеджеры разрешают споры и определяют, какие ресурсы требуются для работы над проектом с учетом постоянно меняющихся бизнес-условий.

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

Кент Бек (Kent Beck) сформулировал ключевые ценности ХР в своей книге Extreme Programming Explained. Здесь мы опишем их очень коротко:

1.         Коммуникация (Communication). Если при работе над проектом возникает проблема, зачастую ее причиной является то, что в какой-то момент времени кто-то не сказал кому-то что-то очень важное. В ХР возникновение подобной проблемы маловероятно. Если вы работаете над проектом в стиле ХР, вы фактически не можете избежать общения.

2.         Простота (Simplicity). ХР всегда предлагает решать задачу самым простым способом из всех возможных (simplest thing that could possibly work). Кент выражает эту мысль следующим образом: «ХР формулирует предположение. ХР предполагает, что лучше сегодня написать самый простой код... чем сегодня потратить время на разработку более сложного кода, а завтра узнать, что этот код вам не нужен».

3.         Обратная связь (Feedback). Чем раньше вы начнете получать отзывы о разрабатываемом продукте от заказчика, от команды разработчиков и от реальных конечных пользователей и чем чаще вы будете это делать, тем точнее вы сможете выбирать дальнейшее направление развития вашего проекта. Это позволит вам всегда оставаться па правильном пути и никогда не съезжать в кювет.

4.         Храбрость (Courage). Если вы двигаетесь не с самой высокой скоростью, вас постигнет неудача. Вы должны обладать храбростью для того, чтобы в нужные моменты времени совершать правильные поступки. Например, вы должны обладать достаточной храбростью для того, чтобы отказаться от кода, на разработку которого вы потратили значительное время. Вы должны обладать храбростью для того, чтобы преодолев половину пути и обнаружив серьезную ошибку, вернуться обратно и начать все с начала.

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

1.         Игра в планирование (Planning Game) - диалог между заказчиками и разработчиками с целью определить текущие задачи, приоритеты и сроки реалии

2.         Тестирование (Testing) — как программисты, так и заказчики пишут тесты, позволяющие в любой момент времени убедиться в корректности работы системы.

3.         .Парное программирование (Pair Programming) — любой код разрабатывается одновременно двумя программистами, работающими на одном компьютере.

4.         Рефакторинг (Refactoring) — улучшение кода путем его переработки

5.         Простой дизайн (Simple Design) — постоянное видоизменение дизайна системы с целью его улучшения.

6.         Коллективное владение кодом (Collective Code Ownership) — правом вносить изменения в любой код системы обладает любой член команды.

7.         Постоянная интеграция (Continuous Integration) — интеграция продукта выполняется постоянно, по несколько раз в день.

8.         Заказчик на месте разработки (On-Site Customer) — рядом с разработчиками постоянно находится представитель заказчика, который работает вместе с ними.

9.         Частые выпуски версий (Small Releases) — каждая следующая версия продукта выходит вскоре после выхода предыдущей версии. Новые версии продукта внедряются в эксплуатацию как можно чаще.

10.      40-часоваярабочая неделя (40-hour Week) — разработчики не должны работать сверхурочно, так как от этого снижается производительность и качество их работы.

11.      Стандарты кодирования (Coding Standards) — все участники команды должны придерживаться общих стандартов кодирования.

12.      Метафора системы (System Metaphor) — простая аналогия, интуитивно понятная всем участникам проекта, описывающая собой внутреннее строение и функционирование системы.

13.      Открытая рабочая среда – разработчики находятся близко друг от друга и имеют возможность свободно общаться

Для многих все это покажется знакомым. Здесь нет ничего нового. Эти практики используются в индустрии разработки программного обеспечения на протяжении многих лет. Почему же в ХР эти практики приводят к значительно более впечатляющим результатам? Дело в том, что слово «экстремальное» в названии методики ХР означает в основном две вещи:

1.         ХР использует каждую из этих практик в «экстремальной» форме, то есть с максимально возможной интенсивностью.

2.         ХР комбинирует эти практики таким образом, что величина результата превышает величину суммы составляющих.

Что это означает? Если перепроверка (review) кода — это хорошо, значит, мы будем делать это постоянно, для этого мы будем программировать в парах. Если тестирование — это хорошо, значит, мы будем заниматься этим постоянно, для этого мы будем вначале писать тесты, а потом — тестируемый код. Если документация зачастую не соответствует реальному состоянию кода, значит, мы будем писать лишь необходимый минимум документации, а всю необходимую информацию о строении и функционировании программы будем извлекать из кода и прилагаемых к нему тестов. ХР не гарантирует того, что люди все время будут совершать только правильные действия, однако ХР облегчает им эту задачу и смягчает серьезность проблем, возникающих в результате ошибок. Практики в ХР комбинируются таким образом, что каждая из них способствует реализации других практик благодаря этому значительно увеличивается скорость и эффективность работы над проектом.

Давайте подробнее рассмотрим каждую из 12 практик и роль, которую они играют в ХР.


Игра в планирование (Planning Game)

ХР – признает тот факт, что, приступая к работе над проектом, вы не можете предусмотреть абсолютно всего. ХР предполагает, что ответы на большую часть вопросов, имеющих отношение к разрабатываемой системе и техническому заданию, будут найдены в процессе работы над продуктом. Получив в свое распоряжение рабочую версию продукта, заказчик сможет точнее понять, что ему нужно, и скорректировать свои требования. Программисты, получив от заказчика новые пожелания и коррективы, смогут без особых осложнений внести в продукт необходимые изменения и реализовать новую, ранее не предусмотренную функциональность. Подобный обмен информацией происходит постоянно, — требования заказчика и поведение продукта постоянно меняется. Традиционные методики, как правило, игнорируют возможность каких-либо изменений. ХР, напротив, подразумевает, что изменения неизбежны и даже полезны. Для обмена информацией между заказчиком и разработчиками применяется игра в планирование (Planning Game).

Сущность планирования заключается в распределении ответственности между заказчиками и разработчиками. Деловые люди (заказчики) принимают решения о важности того или иного элемента программы, а разработчики рассчитывают стоимость его проектирования и внедрения.

Основная цель игры в планирование — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся все более четкими. Артефактами игры в планирование является набор бумажных карточек, на которых записаны пожелания заказчика (customer stories), и приблизительный план работы по выпуску следующих одной или нескольких небольших версий продукта.

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


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

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

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

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

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

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

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

Команда разработчиков:

·                    формирует оценку времени, которое предположительно потребуется для того, чтобы реализовать каждое из пожеланий;

·                    оценивает затраты, связанные с выбором той или иной технологии, на основе которой будет выполняться реализация;

·                    распределяет задачи между членами команды;

·                    оценивает риск, связанный с реализацией каждого из пожеланий;

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

Заказчик:

·                    определяет объем работ (Scope), то есть набор пожеланий для выпуска (release) и набор пожеланий для итерации (iteration);

·                    определяет дату завершения работы над выпуском (release);

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

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

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


 «Билль о правах» заказчика

·                    У вас есть право получить общий план работ и узнать, что может быть сделано, когда и за какие деньги.

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

·                    У вас есть право по заданным вами тестам регулярно контролировать ход выполнения проекта на работающей версии системы.

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

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


«Билль о правах» программиста

·                    У вас есть право знать, что именно нужно сделать и каков приоритет каждой задачи.

·                    У вас есть право в любое время производить качественный программный продукт.

·                    У вас есть право просить и получать помощь от коллег, начальства и заказчиков.

·                    У вас есть право самостоятельно оценивать объем трудозатрат по задачам, а потом вносить в эти оценки изменения.

·                    У вас есть право взять на себя ответственность и не ждать, пока ее на вас возложат.

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


Притча

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

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

Тестирование (Testing)

В ХР используется две разновидности тестирования:

·                    тестирование модулей (unit testing);

·                    приемочное тестирование (acceptance testing).

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

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

·                    наиболее полный набор всевозможных тестов;

·                    наиболее простой код, который (скорее всего) реализует заданную функциональность;

·                    четкое представление о том, какую задачу решает код.

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

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


xUnit

Все описанные возможности, имеющие отношение к тестированию и тестам модулей, реализованы в семействе библиотек xUnit. В настоящее время библиотеки этого семейства используются огромным количеством разработчиков. Каждая из этих библиотек позволяет разработчикам создавать тесты, в состав каждого из которых входит одно или несколько тестовых условий (assertions). Если каждое из условий теста удовлетворяется, считается, что тест выполнен. Запуск всех тестов можно инициировать из GUI (графического интерфейса), щелкнув на специальной кнопке. Результаты выполнения тестов в виде набора текстовых сообщений отображаются в нижней части главного окна. Для наглядности в главном окне графического интерфейса каждой из библиотек присутствует большой хорошо заметный цветной индикатор законченности процесса тестирования. Индикатор реализован в виде горизонтальной полосы, которая окрашивается в зеленый цвет в случае, если все тесты успешно выполнены, и в красный в случае, если хотя бы один тест не сработал. Эта полоса является символом, который часто используют в разговорах об ХР. Выражение «зеленая полоса» (green bar) означает, что все тесты успешно выполнены, а выражение «красная полоса» (red bar) означает, что по крайней мере один, а возможно и несколько тестов не сработали.


Приемочные тесты

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

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

Программирование парами (Pair Programming)

В ХР любой программный код разрабатывается одновременно двумя программистами, работающими на одном компьютере с одной мышью и одной клавиатурой. Эффективность такого подхода вовсе не так низка, как это может показаться. Программирование в паре (pair programming) обладает следующими преимуществами:

·                    любые решения в области дизайна принимаются не одной головой, а двумя;

·                    какую бы часть системы вы не взяли, в ней будут хорошо разбираться по крайней мере два человека;

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

·                    партнеры в парах постоянно меняются, благодаря чему знание о внутреннем устройстве разрабатываемой системы быстро распространяется между членами команды;

·                    происходит постоянная перепроверка (review) чужого кода: один партнер пишет код, другой просматривает этот код.

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

Рефакторинг (Refactoring)

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

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

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

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

Простой дизайн (Simple Design)

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

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

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

Что такое самый простой дизайн, который подходит для решения задачи (simlest design that could possibly work)? Согласно Кенту, это дизайн, который:

·                    Обеспечивает корректное срабатывание всех тестов.

·                    Не содержит дублирующегося кода.

·                    Хорошо выражает намерения программиста для каждого из участков кода.

·                    Включает наименьшее количество классов и методов.

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

Коллективное владение кодом (Collective Code Ownership)

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

Но не возникает ли при этом каких-либо проблем? Ведь если кто угодно будет как угодно менять код системы, в каком угодно месте, неизбежно возникнет хаос. Для решения этой проблемы в ХР действует строгое правило: «You break it, you fix it» (Кто сломал, тот и исправляет). Если, модифицировав код, программист нарушил работоспособность системы, он обязан восстановить работоспособность.

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

Постоянная интеграция (Continuous Integration)

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

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

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

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

Заказчик в команде (On-Site Customer)

Чтобы работать с оптимальной скоростью, команда разработчиков ХР должна постоянно поддерживать контакт с заказчиком. Для этого представитель заказчика должен постоянно находиться рядом с разработчиками. Он должен пояснять смысл пожеланий (stories) и принимать важные бизнес-решения, которые не могут быть приняты самими разработчиками. Если представитель заказчика будет постоянно находиться рядом с разработчиками, разработчики смогут избежать простоев, связанных с тем, что они вынуждены ждать пояснений, уточнений и решений со стороны заказчика.

ХР не утверждает, что карточка, на которой записано пожелание заказчика (customer story), содержит все необходимое для того, чтобы программист написал весь необходимый код. Записанное на карточке пожелание - это лишь приглашение к дальнейшему устному разговору между заказчиком и разработчиком, нацеленному на прояснение и освежение в памяти сопутствующих деталей. Идея состоит в том, что при общении лицом к лицу снижается вероятность непонимания. Мы обнаружили, что постоянное присутствие представителя заказчика рядом с разработчиками — это наиболее эффективное решение данной проблемы, однако это далеко не единственный допустимый сценарий. Основная идея этой практики состоит в том, что заказчик должен быть в любой момент времени доступен для ответов на возникающие у разработчиков вопросы и для уточнения общего направления работы на основании бизнес-условий. Иногда для этого вовсе не обязательно, чтобы заказчик постоянно находился в непосредственной близости от разработчиков. Однако, физическое присутствие представителя заказчика рядом с разработчиками — это наиболее эффективный из возможных вариантов.

Частые выпуски версий (Small Releases)

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


План рабочего цикла

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

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

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


План выпуска версий

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

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

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

Равномерная работа

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

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

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

Стандарты кодирования (Coding Standards)

Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому:

1.         Члены команды не тратят время на глупые споры о вещах, которые фактически никак не влияют на скорость работы над проектом;

2.         Обеспечивается эффективное выполнение остальных практик.

Если в команде не используются единые стандарты кодирования, разработчикам становится сложнее выполнять рефакторинг (refactoring), то есть переделывать общий код; при смене партнеров в парах возникает больше затруднений, поэтому смена партнеров осуществляется не так часто, как нужно; в общем и целом, продвижение проекта вперед затрудняется. В рамках ХР необходимо добиться того, чтобы было сложно понять, кто является автором того или иного участка кода, — вся команда работает унифицировано, как один человек. Команда должна сформировать набор правил, а затем каждый член команды должен следовать этим правилам в процессе кодирования. Перечень правил не должен быть исчерпывающим или слишком объемным. Задача состоит в том, чтобы сформулировать общие указания, благодаря которым код станет понятным для каждого из членов команды. Стандарт кодирования поначалу должен быть простым, затем он будет эволюционировать по мере того, как команда обретает опыт. Вы не должны тратить на предварительную разработку стандарта слишком много времени.

Метафора системы (System Metaphor)

Что такое архитектура программы? Архитектура — это некоторое представление о компонентах системы и о том, как они взаимосвязаны между собой. Разработчики используют архитектуру для того, чтобы понять, в каком месте системы добавляется некоторая новая функциональность и с чем будет взаимодействовать некоторый новый компонент.

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

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

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

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

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

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

Зачастую метафора сводится к правильному именованию элементов программы. Такая система позволяет не только определить по названию назначение отдельного модуля, но и видеть его связь с другими компонентами.

Открытая рабочая среда

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

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

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

ХР — это комбинация практик

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

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

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

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

 

Добавьтe Ваш комментарий

Ваше имя (псевдоним):
Ваш адрес почты:
Заголовок:
Комментарий:

Комментарии, категория: "IT"

Интересное




Похожие материалы

Партнёры