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

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

Как пишет Брукс [1], программные проекты чаще всего проваливаются из-за нехватки календарного времени. И, действительно, очень часто приходится слышать, что на разработку различных систем потребовалось значительно больше времени, чем планировалось и эта вполне объяснимо — методы оценки продолжительности работ проекта все еще слабо развиты. Как правило, планы предполагаемых работ составляются еще на ранней стадии проекта и в дальнейшем предпринимаются все возможные шаги, чтобы следовать этому плану. Однако в процессе работы появляются новые требования к продукту или изменяются старые. Кроме того, используемые методы оценок отражают молчаливое и совершенно неверное предположение о том, что все будет идти хорошо [1]. В результате, чем дольше длится разработка программного продукта, тем сложней укладываться в запланированные сроки. Здесь уместно напомнить о четырех взаимно-связанных величинах, характеризующих каждый программный проект: функциональность приложения, ресурсы проекта, время разработки продукта и качество изделия. Как правило, функциональность приложения и ресурсы проекта варьируются слабо. Таким образом, остаются две переменные величины: момент завершения проекта и качество разрабатываемого приложения. Естественно, если подгонять разработчиков, только для того, чтобы укладываться в намеченные сроки, то неизбежно будет страдать качество приложения, что может в дальнейшем еще сильней замедлить разработку.

Экстремальное программирование (ХP) констатирует [2, 3], что заранее невозможно предугадать все сложности, возникающие при разработке ПО, а поэтому и не следует пытаться точно планировать работу команды на продолжительный срок. Акцент делается на полезность разрабатываемого продукта для заказчика, нежели на поддержание высокого темпа написания кода (что не означает высокую производительность). Также предлагается максимально сократить продолжительность времени работы над очередной «рабочей» версией программы, чтобы быстрее получить мнение пользователей программы и заказчиков с целью учета всех пожеланий при выпуске следующей версии. При этом совершенно неприемлемо фиксировать объем функциональности приложения и дату выпуска полнофункционального приложения, т. е. использовать традиционную систему планирования — XP предлагает использовать гибкую систему планирования, предназначенную, в основном, для организации работы на сравнительно малый промежуток времени, но способную учитывать всевозможные изменения проекта (изменение требований к разрабатываемому приложению, объема ресурсов проекта и т.д.). Авторами статьи также предлагается процедура, при помощи которой можно оценивать, будет ли завершен проект вовремя и каковы тенденции роста или замедления скорости разработки.

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

Организация процесса и сбор метрик

Используемая нами XP-система планирования (Planning game) является итеративной и в общем виде включает планирование релиза (release) и планирования итераций (рис. 1). Каждый релиз включает несколько итераций. Продолжительность итерации, как правило, фиксирована (две календарные недели). Количество итераций (продолжительность релиза) определяется либо датой релиза, либо объемом функциональности, которая должна быть включена в очередную версию. После выпуска релиза осуществляется планирование нового. Планирование последующей итерации осуществляется по окончанию предыдущей.

Рис. 1. Схема планирования

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

Планирование релиза

Планирование релиза заключается в написании набора «историй заказчика» (user story), которые являются неформальными требованиями к тем частям приложения, над которыми команда разработчиков будет работать до выпуска релиза. User story представляет собой листок бумаги (карточку) где записывается одно из требований к приложению (например, «система должна уметь считывать набор чисел с клавиатуры»). Также на карточке записываются оценки сложности реализации этой истории, риска и приоритета.

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

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

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

Рис. 2. Алгоритм создания набора историй заказчика

Если какая-то история является слишком сложной, то ее разбивают на несколько, более простых. Если несколько историй слишком простые, то их объединяют в одну. Если команда затрудняется дать оценку истории, то объявляется, что требуется некоторое исследование для точной оценки, и помимо исходной карточки появляется дополнительная история (Spike solution). В истории Spike solution команда оценивает, сколько времени надо потратить на то, чтобы стало возможным адекватно оценить сложность исходной истории. После того, как команда разработчиков создала свой набор user stories, необходимо поставить на каждую карточку оценку сложности, риска и приоритет истории.

И, наконец, на последнем этапе заказчик определяет, какие из историй для него являются более важными, а какие менее. Наиболее важные (с наивысшим приоритетом или с наибольшим риском) будут включены в первые итерации, наименее важные могут быть отложены. Заказчик также назначает дату или объем функциональности релиза. Необходимо отметить, что после первого планирования релиза невозможно определить дату завершения всех историй, поскольку все оценки даются в IET (ideal engineering time), а чему равен один IET в календарных днях, будет ясно только после первых итераций.

Оценка сложности истории

Оценка сложности производится разработчиками на основе их предыдущего опыта и выражается в количестве времени, необходимом для реализации описанного в истории требования. Для оценки истории каждый из разработчиков должен решить, за сколько IET он сможет выполнить историю. Обычно IET — это 8 часов, потраченных только на активность, связанную с реализацией истории (сюда не включается время, потраченное на чтение почты, обед, совещания и т.п.). В процессе выставления оценок принимает участие вся команда. Желательно, чтобы через сравнительно небольшой отрезок времени команда пришла к единому решению. Если этого не получается (к примеру, один участник проекта знает технологию лучше других), то ставится либо меньшая — оптимистическая оценка (и давший эту оценку отвечает за реализацию данной истории), либо самая большая — пессимистическая оценка. Пессимистическая оценка, является всегда более предпочтительной, так как позволяет создать и контролировать, до некоторой степени, расход резервов.

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

Планирование итерации

При работе команды над историями их делят на части — задания. Это делается для того, чтобы распараллеливать работу. Во время работы над заданием пара разработчиков тщательно записывает, сколько чистого времени было потрачено на задание. В нашем случае записывается начало и конец времени работы. К примеру, 10.00 — 12.00, 13.00 — 18.00. Вполне очевидно, что один час разработчиками был потрачен на обед. Такая система контроля позволяет точно сказать, сколько времени было потрачено на каждое задание и, соответственно, на каждую историю.

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

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

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

Анализ метрик

Для анализа собираемых метрик у нас пока нет точного и проверенного решения, однако можем предложить некую эмпирическую концепцию, частично позаимствованную из [4]. Данная концепция предлагает оценивать не только степень завершенности проекта, но и, по аналогии с физическим телом, такие динамические характеристики как его «скорость» и «ускорение». Если вы прикладываете некоторое усилие к вашему проекту, то он начинает двигаться. Как только усилие ослабевает (команда теряет энтузиазм) или возникают противодействующие силы (непредвиденные трудности, появляется большое число дефектов и т.п.), движение проекта замедляется. Если усилие не прикладывается вовсе, проект может остановиться или продолжать некоторое время двигаться по инерции.

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

Таблица 1. Данные по оценкам историй и по продолжительности уже выполненных

Таблица 2 содержит информацию об итерациях. Предположим, что команда состоит из 4 человек. Итерация в нашем случае длится 10 календарных дней (2 недели), т. е. команда может выработать 40 календарных дней. Исходя из нашего опыта 1 IET для команды (с учетом парного программирования, собраний, различных посторонних дел) равен 4 календарным дням, т. е. на первую итерацию можно набирать историй на 10 IET.

Видно, что за первую итерацию было фактически выработано 9 IET, а незавершенная история Story2 была запланирована на вторую итерацию. Поскольку во второй итерации производительность команды упала до 8 IET, то история Story4 оказалась полностью невыполненной и была запланирована на третью итерацию вместе с Story5. Кроме того, заказчик посчитал, что Story5 важнее, чем Story4, которая, в результате, осталась незавершенной и снова была запланирована на следующую итерацию. Во время четвертой итерации выяснилось, что команда выполнила Story4 и Story6 досрочно, о чем сразу же уведомила заказчика, который принял решение включить дополнительную историю Story8 в текущую итерацию.

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

Таблица 3

Рис. 3. Демонстрация прогресса проекта

Теперь полагая, что 34 IET — это 100% завершенности проекта мы получаем график, демонстрирующий прогресс проекта (рис. 3).

Можно построить график в терминах завершенности функциональности релиза, считая, что 100% готовности проекта соответствует выполнение всех намеченных на релиз историй. Предполагая, что в дальнейшем оценки и фактические данные расходиться не будут, мы получаем что 100% завершенности проекта соответствуют 51.5 IET и, отнормировав третий столбец таблицы на эту величину, получим искомый график. На его основе менеджер вполне реально может рассчитать, что ждет его к моменту релиза.

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

Рис. 4. График хода работ

Данный график демонстрирует сравнительно стабильный рост метрики готовности проекта, хотя на протяжении работы над проектом у нас были как «белые», так и «черные полосы». Также видно, что оценочные данные в достаточной мере совпадают с фактическими — заметно, что проект как бы делится на две фазы: оценки слишком оптимистичны, затем пессимистичны. Это связано с тем, что в какой то момент было замечено, что мы даем слишком низкие оценки, и было принято решение более детально обсуждать даваемые историям оценки, вследствие чего оценки стали превосходить фактические данные.

Теперь перейдем к наиболее неоднозначной процедуре оценки состояния проекта. Как говорится в [4], только графиков зависимостей метрики прогресса проекта от времени не достаточно для понимания состояния проекта. Для более детального анализа динамики проекта необходимо построить графики первых двух производных. На рис. 5 приведен график первой производной от функции метрики прогресса проекта. Этот график может трактоваться как кривая зависимости скорости разработки проекта от времени. Такая интерпретация в достаточной степени подтверждается нашим опытом. Видно, что средняя скорость была максимальна в начале проекта, а затем начала плавно снижаться. И, действительно, это соответствует тому, что количество ресурсов проекта также снижалось. Провал в графике в период новогодних праздников также вполне предсказуем.

Рис. 5. Первая производная от функции метрики прогресса проекта

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

Рис. 6. Зависимость второй производной от времени

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

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

Заключение

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

Литература

[1] Frederick Brooks, The Mythical Man-Month // Addison-Wesley, 1995, ISBN 0-201-83595-9

[2] Kent Beck, Extreme Programming Explained: embrace change. // Addison-Wesley, 1999, ISBN 201-61641-6

[3] http://www.extremeprogramming.org

[4] Joe Marasco, A physicist looks at project progress // Dr. Dobb?s journal, V. 27, ISSUE 8, p. 37 (Aug 2002)