Экстремальное программирование и автоматизация распределения заданий Текст научной статьи по специальности «Экономика и бизнес»

На 1(13)2008

В.Н. Бугорский, С.С. Судаков

Экстремальное программирование и автоматизация распределения заданий

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

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

Методология экстремального программирования (XP) регламентирует два вида планирования разработки программного продукта: планирование совокупности работ по контрольным точкам для клиента и итерационное планирование распределения работ для разработчика.

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

Рассмотрим этапы процесса планирования для клиента. На этапе исследования,

перед началом работы над первой версией, заказчик пишет истории (stories) — требования, которые необходимы для реализации в разрабатываемой системе. Эти истории имеют описательный и неформализованный характер, в отличие от требований в обычном их понимании. По большому счету, истории — это требования, которые описаны клиентом «своими словами». В методологии XP такой подход считается более приемлемым по сравнению с написанием технического задания (ТЗ). Это объясняется двумя причинами. Во-первых, написание ТЗ занимает некоторое время и, соответственно, увеличивает стоимость проекта, что невыгодно для заказчика. Во-вторых, редко когда удается описать в ТЗ, на начальных стадиях, все необходимые требования. Как правило, в ходе проекта выясняется, что заказчик не предусмотрел некоторые из них. Однако обычно разработчик придерживается утвержденного ТЗ, и любые изменения переносятся на конец проекта как доработки. Это невыгодно для заказчика, так как дополнительные требования могут быть критичными для него.

Поэтому в XP заказчик может добавить дополнительные истории в любой момент

83

Ив 1(13)2008

1 и

to

1 I

I

а I

S

В si

¡5

со <0

I

S

0 |

1 I

<u §

л

I I

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

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

На этапе подтверждения заказчик должен разделить все истории на три категории в соответствии с субъективной полезностью:

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

• менее полезные истории;

• истории, которые желательно реализовать, но возможно и отказаться от них.

Таким образом, для каждой истории определяется полезность А по трехбалльной шкале.

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

• истории, время на выполнение которых можно оценить с наибольшей точностью;

• истории, время на выполнение которых можно оценить с приемлемой точностью;

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

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

Вариант 1.

Заказчик выбирает из всех историй необходимое количество.

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

T =1 j

j=1

где N — количество выбранных историй.

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

N

C =£ Zs + R + Tax,

j =1 j

где Zs — затраты на выполнение j-й истории;

R — прибыль;

Tax — налоги.

Определим вектор P = {p1, p2,..., pn}, такой, что:

p =

1, если история выбрана

2, если история не выбрана'

Тогда алгоритм расчета стоимости выбранных историй можно представить следующим образом (рис. 1).

Вариант 2.

Заказчик назначает желаемую дату выхода очередной версии:

^ = ^эк ■

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

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

84

Не 1(13)2008

N — количество историй

р(j) — элемент вектора распределения историй

sum Z — затраты

t{j) — время выполнения j-й истории

d(j) — сложность у-й истории

w — почасовая оплата

sumTotal — общая стоимость выбранных историй

R — прибыль

NDS — НДС

Рис. 1. Алгоритм расчета стоимости выбранных историй

суммарная стоимость их реализации меньше рассчитанного бюджета:

Эс с Э

С < Сь'

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

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

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

Пусть заказчик написал п историй и определил полезность каждой из них по трехбалльной шкале:

А = {а,, а2.....Эп},

где А — вектор полезности.

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

Т ={1, ¡2.....1п},й = {С11, 0*2.....dn},

где Т — вектор времени выполнения историй;

0 — вектор сложности историй.

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

^ =£ ^,

}=1

где Т,^ — время выполнения всех историй версии;

1 — количество историй версии.

Затраты на выполнение 1-й истории будем рассчитывать по формуле:

^ = 1,С,Шор,

где ^ср — средняя заработная плата программиста.

Пусть стоимость всех историй описывается вектором С, таким, что:

С = {с1 с2, сп}.

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

Tv — Tmax n

X ap ^ max

i=1

n

X CiPi ^ min

CO

Si

I

CJ CJ

i I

эё od

85

i=1

Ив 1(13)2008

С учетом налогов и прибыли в величине с, последнее условие системы можно преобразовать к следующему:

Ё гр'

I=1

Тогда:

Т — Ттах

Ё аР

I=1 п

Ё гР'

• тах

• тт

• тт.

Т — Ттах

■ тах

Ё аР

=1

п

Ё р — т1п

В случае когда определяющим фактором для заказчика является не время, а стоимость выполнения историй в рамках версии, задача сводится к поиску вектора Р, для которого:

Zv — 2 т

1 I

1 §

I

I

¡8

В §

¡5

со <0

I

0

1

I I

<и §

I §

Ё ар — тах

=1

п

Ё ЬФорР, — т1п

Алгоритм поиска всех возможных вариантов распределения историй для реализации в версии разрабатываемого продукта представлен на рис. 2.

Для практической реализации описанных моделей авторы статьи разработали программное средство БхвБ, главная форма которого представлена на рис. 3.

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

I

г /'= 1

V у

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

у = 0; = 0; ОД = 0; а(0 = 0; спОД = 0

Рассчитать: 4/)=4/) + ?(уТс/0Ти^р(У) ОД = № + ЮТР(У) а(0 = а(/) + а(/)*р(У) спОД = сп1(0 + 1 с( 0 = (1 + Ш3)*(г(0 + Я)

У = у+1

N — количество историй

р(у) — элемент вектора распределения историй

г(/') — суммарные затраты на /'-й набор

?(/') — суммарное время выполнения /-го набора

!(/') — время выполнения у'-й истории

с1(у) — сложность у'-й истории

а(/') — суммарная полезность /'-го набора

а(У) — полезность у-й истории

— почасовая оплата сш(/) — количество историй в /-м наборе с(/') — суммарная стоимость /'-го набора И — прибыль N03 — НДС

Рис. 2. Алгоритм поиска всех вариантов распределения историй и их характеристик

86

=1

=1

=1

Й< EXeS [DocumenMl

В

1

F 2

F 3

4

5

Г 6

Г 1

8

Г 9

[7 10

Истории

Дизайн сайга

Главная страница

Каталог продукции

Клиенты системы

Новости компании

Лицензии и сертификаты

F.A.Q

Голосования

Текстовые страницы

Верстка

Суммарная стоимость реализации выбранных историй: 30564,5 руб. В тон числе НДС: 12239,5 руб.

00 ■ч

Status

Полезность

Сложность

Время (дн.)

14

40

Рис. 3. Главная форма программы EXeS

Количество историй

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

450

Наданка (руб.)

10000

Рассчитать стоимость отмеченных историй

Рассчитать затраты

Просмотреть отчет

default5.ex

|_Jc: |defaultl0.ex

Сохранить данный Загрузить файл

01.11.2007 11:34

§

»* »*

«Й I

В.Н. Бугорский, С.С. Судаков

Nя 1(13)2008

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

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

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

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

При нажатии курсором на заголовки столбцов «Затраты», «Стоимость», «Полезность», «Время» данные таблицы сортируются по соответствующему критерию.

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

в Отчет

88

Ограничение

Кол-во историй

Полезность

Любое

Любая

Е

Вывести

Рис. 4. Форма «Отчет»

Истории Затраты Стоимость Полезность Время (дн.) ж.

(1 234568910) 61650 84547 24 78

(1 234678Э10) 62100 85078 23 79

(1 234578810) 62100 85078 23 79

(1 234567810) 62550 85608 23 80

(1 245678810) 27450 44191 22 42

(2 345678810) 50850 71903 22 68

(1 235678810) 58725 81095 22 75

(1 2 34 68 810) 60300 82954 22 75

(1 2 34 58 810) 60300 82954 22 75

(1 2 34 56 810) 60750 83435 22 76

(1 234567810) 61425 84231 22 79

(1 345678810) 62100 85078 22 79

(1 23456788) 62100 85078 22 78

(1 2 45 68 810) 25650 42067 21 38

(23 45 68 810) 4Э050 68678 21 64

(1 2 35 68 810) 56825 78971 21 71

(1 2 34 56 810) 5Э625 82157 21 75

(1 3 45 68 810) 60300 82954 21 75

(1 2345688) 60300 82954 21 75 ы

П73478Я1П1 6П75П 83495 71 76

□к

Не 1(13)2008

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

Как видно из таблицы, при заданных ограничениях оптимальными по времени и затратам являются первые два варианта. Эти два варианта отличаются на одну историю, в первом — реализуется история номер 6, а во втором — вместо нее история номер 5. Для того чтобы определиться с окончательным вариантом, необходимо уточнить у кли-

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

Решение о выборе оптимального распределения может проводиться по нескольким критериям. На рис. 6 представлен внешний вид формы отчета при ограничении по времени в 14 дней, отсортированный по времени.

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

§ I

со

со *

I

эё со

Рис. 5. Результаты ограничения по затратам, количеству историй и суммарной полезности

89

Nя 1(13)2008

пользуем отведенные 14 дней. Обратив внимание на полезность каждого варианта, можно сделать вывод о том, что максимальная полезность в этом наборе равна 13. Установим ограничение полезности, равное 13. Форма отчета примет следующий вид (рис. 7).

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

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

Начиная планировать итерацию, разработчики вновь просят заказчика выбрать наиболее ценные истории, на этот раз из числа оставшихся для реализации в этой версии.

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

Теперь рассмотрим итерационное планирование разработчика. В рамках данного планирования рассматривается единственная очередная итерация.

в Отчет

Ограничение

Кол-во историй

Полезность

По затратам (* По времени

дн.

Любое

Любая

Е

Вывести

90

ок.

Рис. 6. Вид формы отчета при ограничении по времени

Истории | ■Затраты | Стоимость Полезность | Время (дн.) 3

(26 710) 5650 18703 9 13

(26 79) 6525 19499 9 13

(25 710) 5650 16703 9 13

(25 79) 6525 19499 9 13

(25 67) 5650 18703 3 13

(2 410) 7425 20561 9 13

(2 49) 8100 21358 9 13

(2 46) 7425 20561 В 13

(2 45) 7425 20561 8 13

(5 6 6 910 J 6975 Mallllfelll 12

КЛЕЕ 7675 7

ИИ 6550 7

(4 67) 7875 21092 6 14

(4 57) 7875 21092 6 14

(2 68 910) 6975 20030 13 14

(2 56 910) 6975 20030 13 14

чааддш 6300 19234 14

Ш 6975 20030 12 14

■ЕШ 7675 21092 7 14

(1) 12600 26668 3 14 —

W

Ив 1(13)2008

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

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

В XP существует понятие «идеальное время программирования». Это время, которое программист затрачивает на выполнение своих задач в течение итерации, без учета помощи коллегам при парном программировании:

Тид — Тобщ _ Тпар >

где Тид — идеальное время программирования;

Тобщ — общее время программирования; Тпар — время парного программирования.

Каждый программист выбирает свой фактор нагрузки для итерации. Фактор нагрузки работника (Г) определяется отноше-

§ I

со

со *

I

эё со

Рис. 7. Вид формы отчета при ограничении по времени и полезности

91

Nя 1(13)2008

нием идеальных программных дней к общему числу календарных дней:

р _ Тид

1 I

1 I

I

I

¡8

В §

¡5

со <0

I

0

1

I

<и §

I §

в-

I

Тобщ

Для новых членов команды этот фактор должен быть не более 0,2, т.е. в основном время тратится на обучение работе в паре; для других — не более 0,5; если это значение больше, значит, программист слишком мало уделяет внимания помощи своим коллегам.

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

х

т _ рУ тк

' нагр _ ' ' х > х _1

где Тнагр — общая нагрузка программиста;

X — количество задач программиста;

к — номер программиста.

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

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

I Г * Т,

I _1

где — время на выполнение 1-й задачи.

Нам необходимо распределить задачи между подразделениями таким образом, чтобы затраты были минимальными. Затраты на 1-ю задачу, реализованную в у-м подразделении, можно вычислить как:

z( I)

где ^ — средняя заработная плата программиста в у-м подразделении, в котором данная задача выполняется.

Определим для каждого подразделения вектор Р_{р1, р2,..., рп}, такой, что:

1, если задача выполняется в подразделении

2, если задача не выполняется в подразделении

Тогда затраты на выполнение всех задач в подразделении равны:

к

z{ У) _1 ¡Шур,,

I _1

где к — количество всех задач.

Задача поиска оптимального распределения при наличии б подразделений сводится к следующей модели:

I ¡I * Т

I _1

б к

II

У _11 _1

■ min '

• min

где Г' — наибольшее время, выраженное в календарных днях, потраченное в одном из подразделений на выполнение выделенных для него задач.

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

92

V

Не 1(13)2008

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

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

1

со §

I

со

со *

I

эё со

Распределить задачи по подразделениям

( г = = 0 \

v

Добавить программный код в общую базу

Добавить программный код в общую базу

Добавить программный код в общую базу

г Л

Г = Г + 1

У

Рис. 8. Процесс выполнения задач на традиционном предприятии

93

Не 1(13)2008

1

Распределить задачи по подразделениям

Подразделение 2

Подразделение 3

1 I

1 I

I

I

¡8

В §

¡5

со <0

I

0

1

I I

<и §

I §

Начать рабочий день

т

Выполнить часть задач

Добавить программный код ч_в общую базу_^

т

Окончить рабочий день

Г Начать рабочий день ^ Г Выполнить часть задач ^

Добавить программный код в общую базу

Г Окончить рабочий день

Г Начать рабочий день "1 *

С

Выполнить часть задач

]

Добавить программный код в общую базу

I

Г Окончить рабочий день 1

Рис. 9. Процесс выполнения задач на виртуальном предприятии

94

Ив 1(13)2008

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

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

Тогда после того, как одно подразделение заканчивает рабочий день, другое только начинает его, и при этом имеет возможность воспользоваться результатами работы первого подразделения. Это важно в случае, когда выполнение некоторых задач зависит от законченности других. Данный процесс выполнения задач представлен на рис. 9.

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

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

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

k =

0.5, работа общего типа

1, подразделение специализируется на данном типе работ .

1,5, подразделение не специализируется на данном типе работ

Si

I

CJ CJ

Tf

I

эё

CQ

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

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

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

1. Горнев В.Ф. Проблемы и технология комплексной автоматизации // Автоматизация проектирования. 1999. № 1.

2. Ройс У. Управление проектами по созданию программного обеспечения / пер. с англ. М.: ЛОРИ, 2002.

3. Брукс Ф. Мифический человеко-месяц. М.: Символ-Плюс, 2006.

4. Beck K. Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999.

5. http://www.extremeprogramming.org/

6. http://exprogramming.ru/

95