Организация процесса экстремального программирования. ARIS-модель (стр. 2 из 2)

Описание модели «Организация процесса экстремального программирования»

Организацию процесса экстремального программирования можно представить в виде последовательно выполняемых операций.

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

Далее, если команда берется реализовывать проект, она просит представителей заказчика составить карточки с историями. История (story)– некоторая вещь, которую по желанию заказчика должна делать система. Затем эти карточки исследуются разработчиками на предмет возможности программной реализации историй и их целесообразности. Если у программистов появляются замечания относительно историй, предоставленных заказчиком, карточки отправляются на повторную переработку. Как только разработчики получают список историй, который устраивает их и заказчика, они переходят к планированию и согласованию даты выпуска версии программы и заключают договор с заказчиком.

Затем начинается короткий (быстрый) процесс планирования. «Вбрасывается» метафора системы. Системная метафора (system metaphor) – история, описывающая логику работы системы, которую могут рассказать любые участники проекта – заказчики, программисты и менеджеры. Далее все члены команды – менеджеры, инструктора, представители заказчика, программисты и др. занимаются планирование версии системы: отбирают истории, реализация которых более приоритетна для бизнеса (для того чтобы как можно быстрее запустить программный продукт в реальное производство), а также придумывают основные методы, средства и технологии, которые будут использованы при реализации данной версии. Планирование продолжается пока все участники процесса не придут к единому решению, которое будет всех устраивать как с точки зрения затрат ресурсов, так и с точки зрения временных затрат и будет наиболее оптимальным в конкретной ситуации.

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

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

· в программе обнаружены ошибки – версия продукта отправляется на доработку;

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

· версия одобрена и готова для ввода в эксплуатацию на предприятии;

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

Заключение

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

- короткие сроки разработки версии

- контроль времени разработки

- максимально короткие сроки ввода программы в эксплуатацию

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

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

- сведение к минимуму энтропии (тенденции системы к накоплению ошибок с течением времени и к существенному росту стоимости внесения в нее изменений).

- особенная внутренняя организация работы команды и рабочего пространства (небольшое количество человек, парное программирование)

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

Список литературы

1) Кент Бек: Экстремальное программирование — Питер, 2002

2) Кент Бек: Экстремальное программирование: разработка через тестирование — Питер, 2003

Приложение 1

Схема модели