Принципы быстрой разработки ПО - План выпуска версий

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



 

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

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

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

Интересное




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

Партнёры