Лекция

Разработка программ в коллективе.

ХР-процесс

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

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

Заказчик. Человек или группа людей, заинтерисованных в создании конкретного программного продукта. Он имеет следующие права и обязанности:

• зафиксировать сроки выпуска версий продукта;

• принимать решения относительно запланированных составляющих программы;

• знать ориентировочную стоимость каждой функциональной составляющей;

• принимать важные бизнесс-решения;

• знать текущее состояние системы;

• изменять требования к системе, когда это действительно важно.

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

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

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

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

• предоставлять ориентировочные, но откровенные оценки трудозатрат на каждую функциональную часть или историю пользователя;

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

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

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

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

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

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

Сторона разработчика

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

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

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

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

Внешние роли

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

Экстремальное программирование (eXtreme Programming, XP) — облегченный (подвижный) процесс (или методология), главный автор которого — Кент Бек (1999). ХР-процесс ориентирован на группы малого и среднего размера, строящие программное обеспечение в условиях неопределенных или быстро изменяющихся требований. ХР-группу образуют до 10 сотрудников, которые размещаются в одном помещении.

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

Большинство принципов, поддерживаемых в ХР (минимальность, простота, эволюционный цикл разработки, малая длительность итерации, участие пользователя, оптимальные стандарты кодирования и т. д.), продиктованы здравым смыслом и применяются в любом упорядоченном процессе. Просто в ХР эти принципы, как показано в табл. 1.2, достигают «экстремальных значений».

Таблица 1.2. Экстремумы в экстремальном программировании

Практика здравого смысла	ХР-экстремум	ХР-реализация
Проверки кода	Код проверяется все время	Парное программирование
Тестирование	Тестирование выполняется все время, даже с помощью заказчиков	Тестирование модуля, функциональное тестирование
Проектирование	Проектирование является частью ежедневной деятельности каждого разработчика	Реорганизация (refactoring)
Простота	Для системы выбирается простейшее проектное решение, поддерживающее ее текущую функциональность	Самая простая вещь, которая могла бы работать
Архитектура	Каждый постоянно работает над уточнением архитектуры	Метафора
Тестирование интеграции	Интегрируется и тестируется несколько раз в день	Непрерывная интеграция
Короткие итерации	Итерации являются предельно короткими, продолжаются секунды, минуты, часы, а не недели, месяцы или годы	Игра планирования

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

Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:

• Короткий цикл обратной связи (Fine scale feedback)

  • Разработка через тестирование (Test driven development)

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

  • Заказчик всегда рядом (Whole team, Onsite customer)

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

• Непрерывный, а не пакетный процесс

  • Непрерывная интеграция (Continuous Integration)

  • Рефакторинг(Design Improvement, Refactor)

  • Частые небольшие релизы (Small Releases)

• Понимание, разделяемое всеми

  • Простота (Simple design)

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

  • Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)

  • Стандарт кодирования (Coding standard or Coding conventions)

• Социальная защищенность программиста (Programmer welfare):

  • 40-часовая рабочая неделя (Sustainable pace, Forty hour week)

Базис ХР образуют перечисленные ниже двенадцать методов.

1. Игра в планирование (planning game) — быстрое определение плана работ над следующей реализацией путем объединения деловых приоритетов и технических оценок. Заказчик формирует пожелания, приоритетность и сроки выпуска одной или нескольких версий программного продукта, а разработчики ответственны за принятие технических решений и оценку (прослеживание) продвижения (прогресса). План работ обновляется его по мере того, как условия задачи становятся все более четкими.

2. Частая смена версий (небольших релизов, Small releases) — быстрый запуск в производство простой версии системы (releas). Новые версии реализуются в очень коротком (двухнедельном или как можно раньше) цикле. При этом каждая версия должна быть достаточно осмысленной с точки зрения полезности для бизнеса. Чем раньше мы выпустим первую рабочую версию продукта, тем раньше заказчик начнет получать за счёт неё дополнительную прибыль. Чем раньше заказчик приступит к эксплуатации продукта, тем раньше разработчики получат от него информацию о том, что соответствует требованиям заказчика. Эта информация может оказаться чрезвычайно полезной при планировании следующего выпуска.

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

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

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

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

User Stories записываются на карточках. Разработчики и Заказчик вместе тасуют карточки на столе пока не получится набор User Stories которые вместе будут составлять первый (или следующий) Релиз. Всем хочется выпустить как можно раньше полезную систему которую можно протестировать.

Релиз можно планировать по времени или по обьему. Для того чтобы определить сколько User Stories могут быть реализованы к конкретной дате или сколько реального времени займет данный набор задач используют скорость проекта. Если планируете по времени, умножьте количество итераций на скорость проекта для того чтобы узнать сколько User Story может быть реализовано. При планировании по обьему, разделите общее количество идеальных недель необходимых для всех User Stories на скорость проекта и вы получите количество итераций необходимых для окончания релиза.

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