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

Доклады БГУИР

2011 № 7 (61)

УДК 004.413

МЕТРИКИ СЛОЖНОСТИ ДЛЯ УПРАВЛЕНИЯ ПРОЦЕССОМ РАЗРАБОТКИ ПРОГРАММНОГО СРЕДСТВА ПО МЕТОДОЛОГИИ SCRUM

А.А. КУЗИКОВ, В В. БАХТИЗИН

Белорусский государственный университет информатики и радиоэлектроники П. Бровки, 6, Минск, 220013, Беларусь

Поступила в редакцию 5 июля 2011

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

Ключевые слова: сложность программных средств, разработка программных средств.

Введение

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

Из многообразия существующих гибких методологий получила достаточно широкое распространение [2] методология Scrum, которая, предоставляя каркас организации и управления процессом разработки ПС, успешно сочетается с методологиями, ориентированными на другие инженерные практики [3-5], например, экстремальное программирование и разработку, управляемую тестами. Фиксированные рамки итераций (от двух до шести недель [3, 4]), на протяжении каждой из которых Scrum-командой выполняются работы процесса разработки ПС по реализации требований заказчика, представленных в журнале требований продукта в виде историй, ориентируют Scrum-команду на реализацию только полезных и важных заказчику требований и на выпуск работоспособных версий ПС на регулярной основе.

Как показывает практика, Scrum-команды, в частности, начинающие работать по гибкой методологии, нередко не способны выполнить все истории, запланированные с учетом производительности работы членов команды. Наиболее распространенными причинами срыва графиков разработки ПС являются:

1) заниженная оценка трудозатрат на выполнение запланированных историй вследствие неубывающей сложности разрабатываемого ПС,

2) неравномерная загруженность членов Scrum-команды в течение итерации в отсутствие учета взаимосвязей между задачами, на которые декомпозирована история.

К концу итерации при невыполнении нормативов времени по реализации Scrum-командой отдельной истории, как правило, имеет место снижение качества разрабатываемого ПС и, следовательно, его ценности для заказчика и конкурентоспособности:

- за счет не реализованной в полном объеме функциональности ПС, ввиду переноса такой истории в журнал продукта для проведения доработки в рамках одной из последующих итераций;

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

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

Метрики Scrum, используемые при планировании

Одной из основных метрик методологии Scrum, учитываемых на этапе планирования каждой итерации, является скорость работы Scrum-команды. Данная метрика эмпирически определяется как средний объем работ, который выполняется Scrum-командой за одну итерацию по отношению к элементам журнала продукта (историям) [4] либо средний суммарный объем историй, работа над которыми выполнена командой за одну итерацию [5]. При этом объем работ, необходимых для выполнения отдельной истории, ассоциируется с ее сложностью. Так, сложность истории принято описывать в единицах трудозатрат, рассчитываемых как отношение объема работ (обычно измеряется в часах) для завершения истории к средней занятости члена команды в течение фиксированного промежутка времени (обычно измеряется в часах в день), то есть

Eff* (t ) =

где: Eff(t) - объем работ, необходимых для завершения истории на момент времени t от начала итерации; X - средняя занятость члена команды в течение фиксированного промежутка времени; [ ] - операция получения целой части числа.

Метрика сложности истории (1) обычно рассчитывается для момента времени t = 0 от начала итерации и не отражает внутреннюю структуру организации работ по выполнению данной истории. Далее в работе предлагаются метрики, которые позволят рассчитать фактическую сложность историй и тем самым предоставить более достоверные данные для этапов планирования выполнения работ в рамках итерации с целью снижения рисков невыполнения командой заданного объема работ.

Термины и определения

Определение 1. Множество членов Scrum-команды можно описать следующим образом:

M = {п, 11 = 1L},

где: m — l -ый член команды; L — количество членов Scrum-команды.

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

s = = 1K},

где: sk -к -ая история итерации; K - число историй, выбранных для реализации в рамках итерации.

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

Eff(t)

(1)

X

^ = К,|/ =N },

где: wki - / -ая задача к -ой истории; Ык - число задач в к -ой истории.

Поскольку к -ая история декомпозирована на задачи таким образом, что каждая задача может быть выполнена только одним членом команды, то каждой задаче wk 1 истории sk можно поставить в соответствие исполнителя, роль которого играет член Scmm-команды.

Определение 4. Множество исполнителей в рамках к -ой истории можно описать следующим образом:

Л = = №},

где: ак1 - / -ый исполнитель, назначенный на выполнение / -ой задачи к -ой истории итерации; Ык - число исполнителей задач в к -ой истории.

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

Assgn: Ак ^ М . (2)

В общем случае, последовательность выполнения задач имеет значение, ввиду наличия зависимостей между задачами. Поскольку множество задач Жк составляет декомпозицию истории sk, но к -ая история считается выполненной только после прохождения приемки у владельца истории (обычно владельца продукта), то можно полагать, что некоторая конечная задача wk 0, представляющая собой работы по приемке истории sk, будет зависеть от выполнения всего множества задач к -ой истории. Исполнителем задачи wk 0, как правило, является лицо, выполняющее приемку истории, например, владелец продукта ак 0.

Определение 5. Ориентированный граф Gk = (Ук, Ек ) является представлением истории sk, если множество его вершин Ук = Жк и ^к0} есть множество задач истории Sk . Элементами множества Ек являются упорядоченные пары задач вида ^к 1, wk у), / Ф у, причем, задача wk у зависит от выполнения задачи wk 1.

Из определения 5 и способа построения графа следует, что

- граф Gk истории sk не является тривиальным, ввиду того, что {wк 1, wk 0 }с Ук ;

- граф Gk является связным, так как из любой вершины из множества Жк существует путь в вершину wk 0.

Определение 6. Множество Жк называется множеством начальных задач, если выполнение таких задач не зависит от выполнения каких-либо других задач к -ой истории, т.е.

/ , ( , г п)\ {V/ е 1, N., 1 Ф у ^

у 1 Wk,г еЖк, (Wk,/, wk j ^ ек

Применительно к каждой задаче wk 1 к -ой истории будем полагать, что задача обладает свойством атомарности (неделимости) в той мере, что

- задача wk 1 может быть назначена только одному исполнителю ак 1,

- переход от выполнения задачи wk 1 к выполнению одной из зависимых от нее задач wk у, например, при ^к,, wk у )е Ек и indeg (wk у )= 1, возможен только при условии завершения исполнителем ак 1 работ над задачей wk 1.

Свойство атомарности задачи исключает наличие в орграфе Gk петель и циклов, четко определяя изменение объема работ Scrum-команды над конкретной историей.

Поскольку в случае методологии Scrum объем работ для каждого члена команды выражается в единицах времени (часах, днях), то показатель времени, требующегося исполнителю для завершения задачи, будет отражать риски, связанные с несвоевременным выполнением запланированных работ. Подобным показателем служит временная функция ^(wk i, aki, t), определяемая отображением

т :Wk xAk x(R+ U{0})^R+ U{0}, (3)

где: R + - множество положительных действительных чисел.

Функция (3) отражает время, необходимое исполнителю aki для непосредственного выполнения работ над задачей wk i на момент времени t от начала итерации. Как правило, для хорошо оцененных исполнителем задач функцию т можно рассматривать как невозрастающую и неотрицательную в течение итерации.

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

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

Определение 7. Dki есть такое подмножество задач истории sk, что начало работ над

задачей wki непосредственно зависит от результатов их выполнения в порядке логического следования:

Dk,, ={wk,j | Vj e [l, Nk ] j * i, (wk, j, Wki )e Ek }. (4)

Из определения 7 следует, что для любой начальной задачи wk, e Wk Dki = 0 .

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

Рассмотрим время, необходимое исполнителю ak, для завершения всех работ над задачей wk,. Очевидно, что данная величина слагается из времени непосредственного выполнения исполнителем ak, работ над задачей wki, а также времени ожидания завершения работ над множеством задач (4), от которых зависит задача wk,, на момент времени t от начала итерации:

tc (Wk,i, ak,i, t) = т(Wk,i, ak,i, t) + tw (Wk,i, ak,i, t) . (5)

Время ожидания TW (wki, aki, t) исполнителем aki начала работ над задачей wk, можно определить как максимальное время, необходимое для завершения работ над задачами Dk i. Следует отметить, что задачи из множества Dk i, назначенные разным членам Scrum-команды, предполагают возможность их одновременного выполнения. Таким образом, если в k -ой истории для каждого члена команды щ имеется не более одной назначенной ему на выполнение задачи wk i, то время ожидания начала выполнения задачи wk i исполнителем ak i таким, что Assgn (ak i )= п1, на момент времени t от начала итерации составит:

tw (wk,i, aki , t) =

max tc (wk,j, akj, t). (6)

Vwk, jeDk ,i

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

дачи wk 7 исполнителем ак 7 на момент времени t от начала итерации также рассчитывается по формуле (6) с учетом влияния, оказанного преобразованным графом Gk на множество Dk 7.

Функция (6) характеризует потенциальную величину времени простоя члена Scrum-команды, назначенного исполнителем задачи wk 7.

Алгоритм преобразования графа истории

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

1) выбрать члена команды т7 из множества М членов Scrum-команды;

2) выбрать подмножество задач Qk 1 := 7 1i е [0, Ык ]}с Vk, для исполнителей которых выполняется условие Assgn {ak 7 )= т1;

3) если для члена команды т7 в k -ой истории имеется более одной назначенной ему для выполнения задачи, т.е. Qk 11 > 1, то перейти к шагу 4. Иначе перейти к шагу 14;

4) выбрать очередную задачу wk 7 из множества Qk 1. Для определенности будем полагать, что просмотр множества задач Qk 1 для выбора очередной задачи организован слева направо. Если задача wki последняя в множестве Qk1, то перейти к шагу 14. Иначе перейти к шагу 5;

5) из задач, следующих за wk 7 в множестве Qk 1, выбрать очередную задачу wk. Если подобный выбор задачи wk ^ не осуществим, то перейти к шагу 4. Иначе перейти к шагу 6;

6) если в графе Gk существует путь через вершины wk 7 и wk ^, то перейти к шагу 5. Иначе перейти к шагу 7;

7) если приоритет задачи wk 7 выше приоритета задачи wk, необходимо расширить

множество ребер Ek графа Gk за счет нового ребра (wk 7, wk ^) и перейти к шагу 5. Иначе перейти к шагу 8;

8) если приоритет задачи wk 7 ниже приоритета задачи wk, необходимо расширить множество ребер Ek графа Gk за счет нового ребра (wk ^, wki) и перейти к шагу 5. Иначе перейти к шагу 9;

9) расширить множество ребер Ek графа Gk за счет нового ребра (wk 7, wk ^) и рассчитать значение Tw1 := 0, ak0, t);

10) заменить ребро (wki, wkj) ребром (wkj, wki) в множестве ребер Ek графа Gk и рас-

считать значение Tw2 := (wk 0, ak 0, t);

11) если Twl <Tw2, то перейти к шагу 12. Иначе перейти к шагу 13;

(у kj, wkiJ ребром \vyki, wkj} в множестве ребер Ek трафа Gk ;

12) заменить ребро (wkj, wki) ребром (wki, wkj) в множестве ребер Ek графа Gk;

13) перейти к шагу 5;

14) если рассмотрено все множество М членов команды, то завершить алгоритм. Иначе перейти к шагу 1.

Потенциальная реализуемость истории

Рассмотрим функцию Тс (wk0, ak 0, t), значение которой соответствует времени, необходимому для завершения работ над k -ой историей на момент времени t от начала итерации. Т.е. значение функции Тс(wk0, ak 0, о) отражает фактическую трудоемкость истории на момент начала итерации.

Определение 8. Потенциальная реализуемость k -ой истории характеризуется следующей величиной

/ч Тс (wk 0, ak 0, Г)

ркк)= ^ 1 • ;, (7)

т1 -'

где wk 0 - конечная задача 1 -ой истории; а10 - исполнитель конечной задачи wk 0; Т, - время, характеризующее продолжительность итерации, в рамках которой запланированы работы над историей sк; t е [0, Т1) - время, прошедшее от начала итерации.

История является потенциально реализуемой в рамках итерации, если вк )< 1. Иначе, если вк )> 1, то существует риск невыполнения 1 -ой истории за время, ограниченное рамками итерации.

Пример. Пусть М = {т/ | V/ = 1,41 - множество участников Scmm-команды; а=и Assgn(а14 )= mi }и ,0 | Assgn(а1,0 )= т4 } - множество исполнителей задач 1 -ой истории; Vk = {wk i | Vi = 1,з}и {wk 0} - множество задач 1 -ой истории; Т1 - продолжительность итерации; т( wk 1 а1,1,0)= t,/2, ^(Wк,2, а1,2 , 0) = уз , ^(Wk,3, а1,3,0)= ^ ^^ а1,0 , 0) = 0 - время выполнения задач первым, вторым, третьим исполнителями и владельцем 1 -ой истории соответственно (рассматривается момент начала итерации t = 0 ). Рассмотрим два предельных случая декомпозиции истории 8к: и 82 - отличающиеся только характером взаимосвязей между задачами.

1. Первый вариант декомпозиции (рис. 1). История 81 декомпозирована на задачи таким образом, что возможно их одновременное выполнение (W1 = W[ ).

1,3

Рис.1. Декомпозиция истории на задачи с возможностью их одновременного выполнения 2. Второй вариант декомпозиции (рис. 2). История 82 декомпозирована на задачи таким образом, что возможно только последовательное их выполнение (Ю2 А = 1, Vi е {0, 2, 3}).

^у-Ч^у-н^у-

Рис. 2. Декомпозиция истории на задачи с необходимостью их последовательного выполнения

В обоих случаях декомпозиции историй и 82 алгоритм преобразования графа истории не влияет на соответствующие множества ребер Е1 и Е2. Следовательно, согласно формуле (5), фактическая трудоемкость историй и 82 составит:

Тс (wl,o, а1,0,0) = 0 + тах(т>/, ^, Т'/4 ) = , Тс (w2,o, а 2,0,0)= 0 + (т/4 +(Т/з + Т/< ))= % • Т,.

Согласно формуле (7), потенциальная реализуемость историй и s2 на момент начала итерации будет равна

Pi (°) =

tc (ai,0,q) _ у < 1

T - 0

p2 ( ° )_ tc ( w2,0, ^°.0) _ % s 1.

T - 0

Метрика (1) для обеих историй s1 и s2 составит:

Eff* (0)_ Efe; ( 0)_

1 з

yZT( w1,¿, ,0)

Л i _0

13 12А,

• T

Несмотря на то, что с точки зрения метрики (1) сложность обеих историй одинакова, только история s1 потенциально реализуема в рамках одной итерации.

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

Заключение

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

COMPLEXITY METRICS FOR MANAGING A SCRUM SOFTWARE

DEVELOPMENT PROCESS

A.A. KUZIKAU, V.V. BAKHTIZIN

Abstract

An impact of software complexity on planning a software development process and its implementation in teams, practicing Scrum methodology, has been examined. An analysis of a number of Scrum metrics used for planning has been conducted. A set of new complexity measures, aimed at assessing organisational management during planning and implementation phases of Scrum iterations, have been proposed.

Литература

1. Бахтизин В.В., Глухова Л.А. Технология разработки программного обеспечения. Минск, 2010.

2. Benefield G. // IEEE Computer Society. 2008. P. 461.

3. Kniberg H. Scrum and XP from the Trenches. C4Media, 2007.

4. Schwaber K. The enterprise and scrum. Microsoft Press Redmond. USA, 2007.

5. Keith C. Agile game development with Scrum. Addison-Wesley Professional, 2010.