Майк Кон - Agile - оценка и планирование проектов

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

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

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

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

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

На рис. 19.2 приведена диаграмма выгорания релиза (Schwaber and Beedle, 2002). На вертикальной оси откладывается количество оставшихся пунктов в проекте. (С таким же успехом это может быть количество оставшихся идеальных дней.) На горизонтальной оси откладываются итерации. Диаграмма выгорания релиза показывает количество оставшейся работы в начале каждой итерации. Она служит эффективным визуальным индикатором быстроты продвижения команды к ее цели. На рис. 19.2 представлена гипотетическая диаграмма выгорания для проекта объемом 240 пунктов, реализуемых равными частями за восемь итераций.

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

На рис. 19.3 представлен прогресс команды после трех итераций. Ее прогресс нестабилен. В первой итерации она выполнила объем работы, довольно близкий к плановым 30 пунктам. Однако в конце второй итерации у нее фактически осталось больше работы, чем было выполнено к началу этой итерации. Такая ситуация могла возникнуть, например, если команда выяснила, что разработка пользовательского интерфейса требует намного больше усилий, чем предполагалось первоначально, и увеличила свои оценки для всех оставшихся историй, связанных с пользовательскими интерфейсами.