Оценка трудоемкости при планировании релиза в Agile
Предварительные оценки используются Agile-командами и владельцами продукта для расстановки приоритетов среди работ и для планирования релизов продуктов. Произвести оценку можно на разных уровнях и различными путями. Пользовательские истории хороши для выполнения текущих задач, но планирование релиза на их основе требует стольких усилий, что это для работы не годится. «Если трехмесячный (13 недель по 5 дней) релиз разбить на пользовательские истории, каждая из которых занимает 2 дня, получится где-то 32 истории. Это значительное количество, но оно может быть и больше, если какие-то истории были в работе одновременно или какие-то меньше по объему. Если в каждой истории задействована половина команды, а половина историй занимает всего день, то общее количество сразу возрастает до 96. Теперь представьте, как вся команда в начале проекта высчитывает время по списку из 96 историй - ведь как иначе мы узнаем, сколько историй уместится в эти три месяца или сколько времени займет все то, что мы хотим сделать. Кажется, на это уйдет уйма усилий? (И это речь о маленьком проекте!)» Вместо этого можно использовать для оценки фичи (features): «Я бы составил список фич (некоторые зовут их «большими историями» или «эпиками»), рассортировал на блоки приблизительно равного размера и оценил эти примерные размеры на основании своего опыта. Потом протестировал бы эти предположения, реализовав первые из фич, и поправил ожидании в соответствии с эмпирическими результатами. По мере дальнейшей работы я бы продолжал уточнять свои ожидания. Кроме того, я мог бы с готовностью передумать, какие фичи необходимы или сколько усилий на них требуется потратить, поскольку я пока не вложил в них слишком много энергии.» Почему же так трудно производить оценку и как это облегчить? Джордж дает совет на этот счет: «Оценивать большие блоки работы, такие, как фичи, и оценивать маленькие блоки, такие, как пользовательские истории, - это разные вещи. Мы, специалисты, слабоваты в оценке широкого спектра размеров. Мне не доводилось видеть, чтобы сумма оценок пользовательских историй, составляющих фичу, имела бы прямое отношение к оценке всей фичи в целом. По этой причине я предлагаю рассматривать их по отдельности. Обычно для оценки размеров фич я использую шкалу, как для футболок (S, M, L и т.д.), поскольку о них известно так мало, что численные оценки всегда кажутся чрезмерно точными. В плане пользовательских историй я предпочитаю обычный подсчет. Да, все они разного размера. Хотя не такого уж разного, чтобы это имело существенное значение. И, по моему опыту, проще привести их к схожим размерам, исследуя критерии их приемки, чем точно оценить их численно.» Майк Кон написал в своем блоге заметку «Присваивайте единицы истории в правильное время - или не делайте этого вовсе». По его мнению, есть две причины для оценки бэклога продукта: «Во-первых, оценка элементов бэклога позволяет владельцу продукта расставить приоритеты в самом бэклоге. Без знания стоимости каждого из них успешно выявить приоритеты не получится. Вторая причина для оценки - это долгосрочные прогнозы касательно проекта в целом. Если босс, клиент или заказчик хочет узнать, когда команда закончит работу над набором элементов бэклога, эти элементы необходимо оценить. Аналогичным образом, если босс, клиент или заказчик хочет узнать, сколько всего может быть сделано за три месяца, нужно оценить элементы стоимостью на три месяца работы.» Делать оценку во время планирования слишком поздно, говорит Майк: «Зная, зачем нужно оценивать элементы бэклога, вы сможете также решить распространенную проблему, которую я часто вижу: оценивать бэклог продукта нужно в правильное время. Его нужно оценивать достаточно рано, чтобы владелец продукта мог определиться с приоритетами или ответить на поставленные выше вопросы - о том, когда и сколько всего может быть реализовано.» Оценивать бэклог в единицах истории во время планирования спринта - слишком поздно для того, чтобы извлечь пользу из этих преимуществ. Существуют и другие проблемы с оценкой во время планирования спринта, но вот такая поздняя оценка не позволяет владельцу продукта вовремя воспользоваться выгодой от новой информации до того, как спланирован спринт. В статье «Пользовательские истории не помогают пользователям» Уильям Хадсон указывает на проблему, которую он встречает, когда релиз планируется на основании одних лишь пользовательских историй: «В экстремальном программировании пользовательские истории призваны питать планирование. (…) Но если команда собирается строить оценки и планы на основе пользовательских историй, им нужно как минимум знать, что именно надо делать и хотя бы примерно - как. Особенно это верно для новых систем, где еще нет устоявших и описанных практик. Это значит, нам нужно задуматься о назначении, форме и размере системы до того, как мы напишем пользовательские истории. К несчастью, многие приверженцы Agile верят, что дизайн - зло, хотя вообще-то в «Манифесте Agile» и «12 принципах Agile» написано не совсем так («полновесный дизайн» загодя - это плохо, но в грубом приближении - нет). Потому ничего удивительного, что оценки и планы, построенные на преждевременно написанных пользовательских историях, могут быть не слишком надежны. Стив Повилайтис написал о том, как управлять большими программами для предприятий в Agile при помощи фич. Он объясняет некоторые преимущества, которые можно получить, используя фичи для планирования релиза: «Фичи необходимо масштабировать, поскольку слишком сложно управлять большими программами на основе одних лишь пользовательских историй. Если у вас нет ориентира в виде среднего уровня фич, которые вы пытаетесь реализовать, планирование релиза становится слишком детальным. Без фич вы теряете способность эффективно координировать команды и не можете предоставить достаточно контекста относительно целей и ценностей уровнем выше. Вам нужны фичи, чтобы определить продукт, координировать и планировать, что вы собираетесь создать на уровне команды разработки.» Майкл Кэрью в заметке «Оценка Agile — если футболка впору…» говорит об оценке тем, эпиков и пользовательских историй. На стадии ранних изысканий Майкл предлагает два возможных подхода. Один — оценка «по размерам футболок», другой - оценка при помощи так называемых ADU (Agile Development Units - девелоперские единицы Agile): «ADU - это скрам-команда для одного спринта, включая поддержку. Это служит началом понимания, какой объем ресурсов потребуется. В некоторых случаях сперва покупается ADU, а потом под нее выкраивается работа - это примерно как выкраивать пальто по вашей одежде.» Оценка как на основе размеров футболок, так и на основе ADU дает нам информацию о размере работы, но не об ее длительности. Такие оценки используются при принятии бизнес-решений во время планирования релиза: «К этому моменту у нас есть оценка, основанная не на огромном количестве изысканий, а на относительном размере согласно предыдущему опыту. Это позволяет нам внести поправки в планы релиза согласно последним оцененным работам. Основываясь на приоритетах, расставленных бизнесом через владельца продукта, мы теперь можем начать превращать темы и эпики в пользовательские истории.» Пользовательские истории оцениваются в единицах истории. Майкл предлагать сверять эти оценки с более ранними, например, сопоставляя «футболочную» таблицу с размерами в единицах истории: «Необходимо изучить их, чтобы выявить, нет ли неожиданных расхождений между различными оценками истории. Это означало бы, что присутствует некое недопонимание. (…) Выявление недопониманий на данном уровне означает поиск мест, где, к примеру, бизнес оценил историю как «S», а в единицах истории она оценена в 15. Это значит, налицо разница в понимании. Следующий шаг - обсуждение этого.» Последний шаг для команды - это оценка в часах: «Во время планирования спринта мы переходим от единиц истории к часам и определяем, используем реальные или условные часы. Обычно команда оценивает в условных часах, а потом переводит их в реальные при помощи коэффициента. Чтобы рассчитать коэффициент, мы должны измерить планируемые часы относительно настоящих по мере прогресса спринта».
Оригинал: http://www.infoq.com/news/2014/04/estimation-release-planning Автор: Бен Линдерс Перевод: Александра Родсет |
Сертифицированные курсыАндрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.
Еще интересные статьи на эту тему:
|
