Шопырин Д.Г. Управление проектами разработки ПО

Подождите немного. Документ загружается.

6. Обзор гибких методологий разработки программного

обеспечения

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

История экстремального программирования началась в середине 90-х

годов. В 1995 году промышленная компания Daimler Chrysler, выпускающая

автомобили, начала работу над проектом системы контроля платежей

служащим компании – Chrysler Comprehensive Compensation System (С3).

Действуя в соответствии с общепринятой практикой реализации подобных

проектов, Daimler Chrysler заключила контракт с партнерской компанией, в

соответствии с которым за реализацию проекта бралась объединенная

команда

разработчиков из обеих организаций. Разработчики из партнерской

компании придерживались технологии разработки, ориентированной на

использование графического интерфейса и игнорировавшей автоматизацию

тестирования. В результате была создана система, которая имела

невыразительный графический интерфейс и для большинства служащих

неправильно вычисляла зарплату. Время работы системы было очень велико:

для создания месячной платежной ведомости ей понадобилось бы

свыше

трех месяцев.

Получив столь плачевный результат, руководство корпорации

обратилось с просьбой спасти проект к всемирно известному специалисту в

области разработки программного обеспечения Кенту Беку (Kent Beck).

Анализируя проект С3, Кент Бек обнаружил плохо продуманный код, тесты,

которые нельзя было запустить повторно, руководство, потерявшее

уверенность в своем проекте. Он предложил выбросить весь

написанный к

этому времени программный код и начать полномасштабный ХР-проект.

Прежний контракт был разорван, и Daimler Chrysler почти наполовину

обновила свою команду разработчиков. Начиная с этого времени, команда

стала работать по правилам экстремального программирования. Были

распределены обязанности в команде, спланирован порядок реализации

функций, установлены правила тестирования, опробовано и принято в

качестве стандарта

парное программирование. Результат был

ошеломляющим: к концу 33-й недели была получена система, в которой уже

было можно отлаживать производительность и проводить параллельное

тестирование. В настоящее время система С3 ежемесячно рассчитывает

зарплату более чем 86 тыс. рабочих компании.

6.1.1. Описание экстремального программирования

Экстремальное программирование основано на следующих ключевых

ценностях:

• Коммуникация. Дисциплина ХР нацелена на обеспечение

непрерывной, постоянно осуществляемой коммуникации между

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

создана культура общения, которая предполагает обсуждение

всех возникающих проблем и сложностей непосредственно в

момент их обнаружения.

• Простота. Дисциплина XP предлагает решать задачу самым

простым

способом из всех возможных.

• Обратная связь. Дисциплина XP предлагает сделать все

возможное, чтобы начать получать отзывы о разрабатываемом

продукте как можно раньше и в дальнейшем получать их как

можно чаще.

• Храбрость. Дисциплина XP призывает совершать правильные

поступки в нужные моменты времени.

Дисциплина XP содержит следующие практики, которые позволяют

непротиворечиво следовать

ключевым ценностям:

• Игра в планирование – диалог между заказчиками и

разработчиками с целью определить текущие задачи, приоритеты

и сроки.

• Разработка через тестирование – частью системы являются

автоматические тесты, которые позволяют в любой момент

убедиться в корректности работы системы.

• Парное программирование – любой код разрабатывается двумя

программистами.

• Рефакторинг – непрерывное улучшение

кода путем его

переработки.

• Простой дизайн – постоянное видоизменение дизайна системы с

целью его упрощения и очищения.

• Коллективное владение кодом – все члены команды обладают

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

• Постоянная интеграция – интеграция продукта выполняется

постоянно, по несколько раз в день.

• Заказчик на месте разработки – рядом с

разработчиками

постоянно находится представитель заказчика, который работает

вместе с ними.

• Частые выпуски версий – новые версии продукта выпускаются и

внедряются в эксплуатацию как можно чаще.

• 40-часовая рабочая неделя – разработчики не должны работать

сверхурочно, так как от этого снижается их производительность

и качество их работы.

• Стандарты кодирования – все участники команды должны

придерживаться общих стандартов кодирования.

• Метафора системы – простая аналогия, интуитивно понятная

всем участникам проекта, которая в доступной форме описывает

строение и функционирование

системы.

Очевидно, что все вышеперечисленные практики не являются

уникальными или оригинальными. Более того, от многих из этих практик

уже давно отказались в пользу других, более сложных и более

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

создаться впечатление, что XP является упрощенной методологией

разработки программного обеспечения, не вполне подходящей для

реальных

проектов.

Однако это не так. Дело в том, что в XP перечисленные практики

комбинируются таким образом, что недостатки каждой из практик

компенсируются достоинствами других практик. Более того, каждая из

перечисленных практик используется в экстремальном виде, то есть с

максимальной эффективностью. В результате возникает так называемый

«синергетический эффект XP», когда величина результата

превышает

величину суммы составляющих.

6.1.2. Комбинация практик экстремального программирования

Игра в планирование

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

на руках только грубый, приблизительный план предстоящей работы. Более

того, постоянное обновление плана потребовало бы больших трудозатрат и

повлекло бы недовольство заказчиков. Однако эти недостатки

компенсируются в XP следующими факторами:

• заказчики выполняют обновление плана самостоятельно, на

основании оценок

, которые делаются программистами;

• в самом начале проекта имеется план, достаточно четкий для

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

разработки;

• версии продукта выходят достаточно часто, что упрощает

постоянное уточнение плана;

• представитель заказчика является членом команды разработки и

имеет возможность постепенно уточнять план в зависимости

от

складывающейся ситуации.

Эти факторы позволяют приступить к работе, имея на руках только

упрощенный, грубый план проекта. В течение проекта план будет постоянно

пересматриваться и уточняться, в зависимости от текущей ситуации на

проекте.

Небольшие версии

Может показаться, что невозможно приступить к эксплуатации

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

выпуск

версий кажется невозможным с точки зрения обеспечения высокого качества

продукта. Однако:

• игра в планирование позволяет работать над наиболее важными

историями, поэтому даже небольшая система будет способна

приносить пользу заказчику;

• непрерывная интеграция значительно сокращает затраты,

связанные с формированием очередной полноценной версии;

• разработка через тестирование обеспечивает небольшое

количество дефектов в продукте и значительно сокращает

затраты на традиционное тестирование;

• простой дизайн позволяет иметь архитектуру настолько простую,

насколько это позволяет текущая версия продукта, что

значительно упрощает выпуск первых версий продукта.

Эти факторы позволяют выпускать продукт небольшими версиями,

запуская его в полноценную эксплуатацию уже через несколько месяцев

разработки.

Метафора

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

метафорой архитектуры продукта, потому что в метафоре недостаточно

детально отображено строение системы. Кроме того, метафора может

оказаться ошибочной. Однако:

• разработка реального кода и тестов обеспечивает быструю

обратную связь, которая позволяет уточнять и модифицировать

метафору в течение проекта;

• наличие простой

метафоры упрощает общение с заказчиком;

• постоянный рефакторинг позволяет итеративно пересматривать

представление о выбранной метафоре.

Эти факторы позволяют спокойно приступать к разработке продукта,

обладая лишь приблизительной метафорой архитектуры системы.

Простой дизайн

Может показаться, что невозможно разрабатывать систему на основе

архитектуры, которой достаточно лишь для решения сегодняшних задач.

Очевидным кажется факт,

что нельзя проектировать систему не учитывая

проблемы, с которыми придется столкнуться в будущем. Однако:

• постоянный рефакторинг кода значительно упрощает изменение

и развитие архитектуры продукта;

• наличие простой метафоры позволяет систематично развивать

архитектуру продукта;

• парное программирование обеспечивает использование простого

дизайна, а не наивного дизайна.

Эти факторы позволяют строить системы

на основе простого дизайна,

достаточного лишь для решения текущих задач.

Разработка через тестирование

На первый взгляд, разработка через тестирование не приведет не к

чему, кроме увеличения трудозатрат. Более того, разработчики презирают

тестирование. Однако:

• дизайн системы максимально прост, что упрощает, в свою

очередь, написание тестов;

• парное программирование в значительной мере

снимает

эмоциональный барьер, который обычно возникает у

разработчиков во время написания тестов;

• наличие модульных тестов в значительной мере повышает

уверенность в работоспособности продукта, что способствует

улучшению эмоционального климата как в команде

разработчиков;

• наличие модульных тестов в значительной мере повышает

уверенность заказчика.

Эти факторы обеспечивают вам возможность постоянно разрабатывать

тесты. Более того, разработка через тестирование, скорее всего, будет

осуществляться с полной поддержкой заказчика.

Рефакторинг

Может показаться, что невозможно постоянно перерабатывать дизайн

системы. Во-первых, это потребует слишком много времени. Во-вторых, в

процессе рефакторинга высока вероятность нарушения работоспособности

системы. Однако:

• коллективное владение кодом и стандарты кодирования

обеспечивают возможность внесения изменений в любую часть

системы, когда это необходимо;

• парное программирование снимает эмоциональный

барьер,

который возникает во время необходимости переработать часть

дизайна системы;

• использование максимально простого дизайна значительно

сокращает трудозатраты на рефакторинг;

• разработка через тестирование значительно сокращает

вероятность внесения дефектов во время рефакторинга;

• непрерывная интеграция обеспечивает оперативное обнаружения

дефектов, внесенных во время рефакторинга;

• 40-часовая рабочая неделя обеспечивает высокий эмоциональный

тонус команды, что значительно сокращает вероятность внесения

дефектов во время рефакторинга.

Эти факторы позволяют вам постоянно осуществлять переработку кода

без опасений потери времени и внесения дефектов в систему.

Парное программирование

На первый взгляд, парное программирование должно сокращать

производительность команды как минимум в два раза. Более того, парное

программирование должно приводить

к постоянным конфликтам между

разработчиками. Однако:

• стандарты кодирования снижают трения между разработчиками;

• 40-часовая рабочая неделя обеспечивает высокий эмоциональный

тонус, что тоже способствует уменьшению вероятности

возникновения конфликтов;

• парное программирование обеспечивает написание

высококачественного кода и тестов;

• парное программирование обеспечивает обсуждение всех

изменений, которые вносятся в дизайн системы.

Эти

факторы обеспечивают высокую эффективность парного

программирования. Более того, парное программирование в значительной

мере повышает качество дизайна и кода продукта.

Коллективное владение кодом

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

вносить любые изменения в любую часть системы в любое удобное для этого

время. Более того, кажется очевидным, что подобное отношение к

коду

системы должно привести к хаосу и заблокировать разработку. Однако:

• непрерывная интеграция значительно сокращает вероятность

возникновения конфликтов, так как все дефекты обнаруживаются

уже через несколько часов после их внесения;

• разработка через тестирование и парное программирование

значительно сокращают вероятность нарушения

работоспособности системы;

• следование общим стандартам кодирования значительно

сокращает вероятность возникновения конфликтов между

членами команды.

Эти факторы обеспечивают возможность

коллективного владения

кодом системы. Более того, коллективное владение кодом значительно

снижает «фактор грузовика» (truck factor).

Непрерывная интеграция

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

невозможной, потому что это, обычно, является трудоемким и болезненным

процессом. Однако:

• разработка через тестирование обеспечивает простой способ

контроля над работоспособностью системы;

• парное программирование значительно сокращает

возможность

внесения дефектов в систему;

• непрерывный рефакторинг и простой дизайн значительно

упрощают интегрирование новой функциональности.

Эти факторы обеспечивают возможность осуществления непрерывной

интеграции. Более того, чем реже выполняется интеграция, тем больше она

требует трудозатрат и тем вероятнее возникновение конфликтов в системе.

40-часовая рабочая неделя

Может показаться, что невозможно работать всего 40-

часов в неделю,

потому что это приведет к задержке выпуска продукта. Однако:

• игра в планирование позволяет вам делать наиболее важную

работу в первую очередь;

• комбинация игры в планирование и разработки через

тестирование сокращает вероятность возникновения авральных

ситуаций;

• весь набор предлагаемых в экстремальном программировании

практик позволяет работать с максимальной

производительностью.

Эти факторы обеспечивают возможность использования 40-часовой

рабочей недели. Более того, 40-часовая рабочая неделя обеспечивает

полноценный отдых членов команды, что, в свою очередь, способствует

благоприятному эмоциональному климату в команде разработчиков.

Заказчик на месте разработки

На первый взгляд, невозможно получить реального представителя

заказчика в качестве члена команды разработчиков. Однако:

• представитель заказчика занят разработкой функциональных

тестов системы, которые все равно придется разрабатывать

заказчику;

• представитель заказчика помогает разработчикам в принятие

важных решений по дизайну и функциональности системы;

• представитель заказчика постоянно участвует в игре в

планирование, что обеспечивает взаимопонимание между

разработчиками и заказчиком.

Эти факторы обеспечивают возможность использования представителя

заказчика в качестве члена команды разработчиков. Более того, это в

значительной мере способствует успешности проекта и снижения рисков.

Стандарты кодирования

Может показаться, что невозможно убедить команду разработчиков

следовать общим стандартам кодирования. Однако:

• стандарты кодирования значительно

сокращают трения между

членами команды;

• стандарты кодирования способствуют взаимопониманию между

разработчиками.

Эти факторы обеспечивают возможность использования общих

стандартов кодирования. Более того, стандарты кодирования позволяют

значительно увеличить производительность членов команды.

6.2. Scrum

Термин Scrum, применительно к разработке программного

обеспечения, был впервые использован в работах Хиротаки Такеучи и

Икуджиро Нонака, где авторы отметили успешность проектов, в которых

участвуют небольшие сплоченные команды без жесткой специализации. Этот

термин был заимствован из игры регби, где scrum – это команда из восьми

человек, каждый член которой в

каждый момент играет конкретную роль и

взаимодействует с другими членами команды для достижения общей цели.

Джеф Сазерленд использовал работу Такеучи и Нонака при создании

методологии для корпорации Easel в 1993 году, которую по аналогии была

названа Scrum, а Кен Швабер формализовал процесс для использования в

индустрии разработки программного обеспечения.

Методология Scrum устанавливает

простые и понятные правила

управления процессом разработки и позволяет использовать уже

существующие практики проектирования и кодирования, итеративно

корректируя требования к продукту. Использование этой методологии дает

возможность итеративно выявлять и устранять отклонения от желаемого

результата на всех этапах разработки программного продукта.

Основой Scrum является итеративная разработка. Scrum определяет

итеративные правила управления

проектом, которые призваны обеспечивать

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

Также в Scrum определяются основные правила взаимодействия участников

команды, которые призваны обеспечивать максимально быстрой реакции на

существующую ситуацию. Каждая итерация в Scrum может быть описана

следующим образом: планируем – фиксируем – реализуем – анализируем. За

счет фиксирования требований на время одной итерации и изменения

длины

итерации методология Scrum позволяет управлять балансом между

гибкостью и предсказуемостью разработки.

100

6.2.1. Описание Scrum

В методологии Scrum формально выделены три роли, для каждой из

которых формально определены зоны прав и ответственности: владелец

продукта (Product Owner), команда (Team) и скрам-мастер (ScrumMaster).

Владелец продукта является лицом, ответственным за определение

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

инициативных разработчиков, ответственных за реализацию проекта. Скрам-

мастер

является лицом, ответственным за решение всех организационных

проблем и соблюдение методологии Scrum.

В методологии Scrum проект разбивается на три фазы: подготовка

(Pregame), реализация (Game) и завершение (Postgame). Во время фазы

подготовки проекта формируется общий план проекта, определяется список

основных требований к продукту и разрабатывается высокоуровневая

архитектура продукта. Во время фазы

реализации осуществляется

итеративное развитие продукта. Во время фазы завершения проекта

осуществляются действия, необходимые для подготовки продукта к выходу

на рынок.

Фаза реализации разбита на последовательность итераций, которые

называются спринтами (Sprint). В результате каждого спринта в продукте

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

функциональности. Важно, что в конце каждого спринта

продукт остается в

работоспособном состоянии. Каждый спринт начинается с сессии

планирования (Sprint Planning Meeting), во время которой определяется

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

Ежедневно, в течение спринта, проводится собрание участников проекта,

называемое скрам-сессия (Daily Scrum Meeting), на котором все члены

команды сообщают о своих текущих планах и всех трудностях, возникающих

в работе. По завершению спринта проводится демонстрационная сессия

(Sprint Review Meeting), во время которой реализованная функциональность

демонстрируется владельцу проекта.

Реализация проекта в методологии Scrum управляется тремя

документами: журнал продукта (Product Backlog), журнал спринта (Sprint

Backlog) и график спринта (Burndown Chart). Журнал продукта является

высокоуровневым списком функциональных и технических требований,

необходимых для реализации продукта. Журнал спринта

является

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

необходимых для успешного завершения итерации. График спринта

показывает ежедневное изменение общего объема работ, оставшегося до

завершения итерации.