Agile: оценка и планирование проектов - [82]
Эти факторы (выполненная работа, изменение требований и пересмотренные оценки) можно считать аналогами силы ветра (называемой дрейфом) и силы моря (называемой сносом). Посмотрите на рис. 19.1, где показаны силы, действующие на парусную лодку. Лодка на этом рисунке проходит меньшее расстояние, чем то, которое должно получиться на основе показаний ее измерителя скорости. Аналогичным образом, даже если компас лодки показывает на восток в течение всего плавания, ветер заставит эту лодку сместиться к югу. Без корректировки курса нашей лодке потребуется больше времени, чтобы добраться до цели, не вполне совпадающей с первоначальной. Мысленно переименуйте стрелки на рис. 19.1 так, чтобы дрейф и снос стали изменением требований (добавлением или удалением функций) и изменением оценок. Теперь рис. 19.1 отражает проблемы отслеживания прогресса софтверного проекта по отношению к его календарному графику.
Скорость
Темп продвижения корабля измеряют в узлах; agile-команда измеряет темп своего продвижения в единицах скорости. Скорость выражается как число пунктов (или идеальных дней), реализованных за итерацию. О команде, которая реализовала 12 историй, оцениваемых в сумме в 30 пунктов, в прошлой итерации, говорят, что ее скорость равна 30, или 30 пунктам на итерацию. Если считать, что объем проекта не меняется, то именно на столько меньше работы осталось выполнить команде.
Скорость — это основной показатель прогресса команды, поэтому очень важно установить базовые правила ее расчета. Прежде всего команда должна учитывать пункты при определении скорости только для тех историй или функций, которые полностью завершены к концу итерации. Завершение — это не что-то вроде «кодирование завершено, но программа еще не протестирована» или «программа написана, но ее нужно еще интегрировать». Под завершенной понимают программу, которая хорошо написана, хорошо сбалансирована, проверена и вычищена, а кроме этого удовлетворяет стандартам кодирования и прошла все тесты. Чтобы узнать, какой прогресс был достигнут, мы учитываем пункты только той работы, которая завершена.
С подсчетом объема незавершенной работы связаны три проблемы. Во-первых, незаконченную, или незавершенную, работу чрезвычайно трудно измерить. Что считать более завершенным — пользовательскую историю, которая была запрограммирована, но не протестирована, или историю, которая частично запрограммирована и частично протестирована? Насколько далеко продвинулся программист, который спроектировал решение для истории, но не начал кодирование? Мы хорошо знаем объем того, что не было начато, и довольно хорошо знаем объем того, что уже выполнено. Оценивать объем работы необходимо в одном из этих состояний и ограничиться этим.
Во-вторых, незавершенные истории разрушают доверие между командой-разработчиком и командой-клиентом в проекте. Если историю не удается завершить во время итерации, как планировалось, разработчики и клиент должны совместно решать проблему, как только она обнаруживается. Обычно это означает, что историю удаляют из итерации или разбивают ее на части и некоторые из них удаляют. Владелец продукта и команда-клиент могут принимать такие решения в режиме реального времени в процессе итерации и изменять приоритеты на основе новых знаний о стоимости истории. Как вариант, команда-клиент может изменить критерии приемки истории и сделать их более мягкими. Она не должна, конечно, опускаться до приемки неотлаженной или непротестированной версии истории, но вполне может снизить требования к производительности в конкретных ситуациях и т. п.
В-третьих, и это самое важное, незаконченная работа ведет к увеличению объема незавершенного производства в процессе разработки. Чем больший объем незавершенного производства допускает команда, тем больше времени требуется для превращения новых функций из сырых идей в функционирующее программное обеспечение. С течением времени это снижает производительность команды в целом. Аналогичным образом при значительном объеме незавершенного производства в процессе команде нужно больше времени на получение обратной связи по разрабатываемому продукту. Это означает задержку обучения.
Если у команды остаются незавершенные истории в конце итерации, то она работает с функциями или историями слишком большого размера. Небольшие истории обеспечивают стабильный поток работы на всем протяжении процесса разработки. Если истории остаются незавершенными, их необходимо разбивать на части. Вместе с тем если в процессе выполнения итерации выясняется, что та или иная история оказалась длиннее, чем ожидалось, то к этому необходимо привлечь внимание владельца продукта. Владелец продукта должен совместно с командой найти способ разбить историю или сократить ее объем так, чтобы можно было завершить эту часть в пределах текущей итерации, а остаток перенести в будущую итерацию.
Так как же команде учесть частично завершенную историю при оценке скорости? Как она будет оценивать такую историю, менее важно, чем определение причин, по которым это произошло, и того, как избежать повторения подобной ситуации. Причиной могла быть недооценка истории. В этом случае команде необходимо выяснить, какой тип работы был недооценен или забыт, и попытаться не забывать о нем при проведении оценки в будущем. А может быть, история оказалась незавершенной из-за того, что в текущую итерацию включили слишком много историй. В таком случае необходимо более тщательно планировать итерацию.
