При оценке историй команды могут столкнуться с рядом концептуальных проблем. Иногда это может привести к путанице в том, как работает agile, и действительно ли он выполняет то, что обещает.
Знание этих ловушек и четкий ответ на вопросы, которые они поднимают, могут помочь команде не сбиться с пути и не дать наблюдателям чувствовать себя оторванными.
1. Измерение производительности по точкам
Среди наиболее распространенных проблем, которые вызывают путаницу при объяснении гибкой оценки, является идея о том, что точки усилий, связанные с историей, представляют ценность этой истории, либо с точки зрения стоимости бизнеса, либо с точки зрения объективной продуктивности команды. Такое недоразумение может помешать эффективной оценке.
Команду нельзя сравнивать с другой командой, сопоставляя набранные ею очки или их среднюю скорость, так же как нельзя сравнивать их по размеру мониторов.
Сравнение гибких команд по пройденным точкам или средней скорости похоже на сравнение их со средним размером монитора.
Хотя баллы являются ценным внутренним показателем для членов команды, который учитывает усилия, необходимые для выполнения работы, они имеют отношение только к предыдущему опыту работы команды с историями, которые, по их оценкам, требуют такого же количества усилий.
Точки, связанные с историей, являются абстрактными. Они различаются от команды к команде и меняются со временем, когда команда становится лучше в понимании своих собственных производственных возможностей. Единственная внутренняя ценность очков — это их способность помочь команде лучше предсказать, сколько работы они реально могут выполнить в следующем спринте.
2. Приравнивая очки с часами или днями
В командах, незнакомых с тем, как работают точки, члены команды могут по умолчанию назначать значения баллов для историй на основе количества часов, которое, по их мнению, займет история для завершения. Когда команда только начинает, этот подход может помочь запустить мяч. Однако проблематично, если команда не быстро сместит свою точку зрения на баллы с абсолютной почасовой шкалы на относительную.
Очки для команды — это субъективный способ измерения усилий, затраченных на завершение одной истории, на основе усилий, которые потребовались для завершения предыдущей.
Как только часовая шкала не соответствует фактическому усилию первой истории, способность команды использовать часы в качестве метрики для усилия разрушается. В конце концов, восемь фактических часов, потраченных на завершение истории, которая первоначально оценивалась в пять прогнозируемых «часов», не могут сравниться с 13 часами, рассчитанными для завершения следующей истории.
Чем раньше команда поймет, что баллы являются относительной метрикой, а не абсолютной величиной, тем легче им будет оценивать истории на основе их реальных возможностей.
Только после нескольких спринтов команда начинает распознавать свою скорость или среднее количество баллов, которые она может выполнить за один спринт.
Скорость одной команды не имеет никакого отношения к скорости другой команды, и при этом ее оценки пункта не должны. Реальные очки для команды важны только внутри самой команды.
3. Оценивать как героев
Я работал в командах, где члены команды были из среды, которая вознаграждала сверхчеловеческие усилия. Часто члены команды пытались продемонстрировать свою компетентность, оценивая, что история потребует меньше усилий и, следовательно, меньше баллов, чем было разумно. В результате, команде либо приходилось карабкаться, чтобы завершить истории в отставании, либо не достичь своих целей.
В таких случаях важно напомнить всем, что они оценивают усилия, необходимые для того, чтобы кто-то в команде закончил историю, а не доказывали, насколько быстро они могли бы ее завершить.
Культуру героев трудно совместить с гибкими процессами, но многие компании привыкли вознаграждать своих инженеров, основываясь на том, насколько они соответствуют нереалистичным ожиданиям стабильно высокой производительности.
Культуру героев трудно совместить с гибкими процессами, но многие компании привыкли вознаграждать своих инженеров, основываясь на том, насколько они соответствуют нереалистичным ожиданиям стабильно высокой производительности.
Принятие гибкого подхода выявит эти тенденции в любой организации и поможет заменить его реалистичной, устойчивой и продуктивной командной работой между инженерами и остальной частью компании.
Чтобы члены команды не назначали оценки, основанные на их собственном желании продемонстрировать свое мастерство, часто напоминайте людям, что оценка должна отражать, насколько трудной будет история, независимо от того, кто ее закончил в команде.
4. Неясные моменты и ценность для бизнеса
Также очень важно отличать ценность бизнеса от усилий.
В то время как инженерная группа может быть квалифицирована для оценки количества усилий, затраченных на завершение истории, только владелец продукта может взвесить все переменные и эффективно оценить бизнес-ценность данной истории.
Кроме того, ценность бизнеса может часто меняться в зависимости от широкого спектра факторов, в том числе порядка, в котором завершаются истории. Ценность бизнеса может даже измениться в течение спринта, пока команда занята работой над проектом.
Владельцы продуктов могут решить рассматривать соотношение стоимости бизнеса и предполагаемых усилий как способ расставить приоритеты в отставании. Это также может быть мотивацией, чтобы команда знала, сколько бизнес-ценности та или иная история несет для компании в любой момент времени.
Но организация, которая хочет оставаться гибкой, знает, что ценность бизнеса может меняться так же быстро, как меняется рынок. Часто инженеры могут отвлекаться от того глубокого внимания, которое необходимо для выполнения своей работы, если они слишком близки к турбулентным и иррациональным факторам, влияющим на оценку стоимости бизнеса.
Держите понятия бизнес-ценности и точек усилий отдельно, чтобы поддерживать продуктивный рабочий процесс, и позволить команде точно оценивать усилия, затрачиваемые на завершение истории, независимо от того, какую ценность владелец продукта может придать результатам.
5. Корректировка значений точек
Итеративный характер гибкого подхода является одним из ключевых преимуществ, которые он предлагает. Когда команда недооценивает историю как слишком большую или слишком маленькую, может возникнуть тенденция изменить оценку, как только появится больше информации. Это естественный импульс, особенно когда команда приняла гибкую версию, потому что она хочет быть более проворным и гибким. Но это может подорвать эффективность системы баллов.
Точки, связанные с историей, служат напоминанием о том, насколько точно команда взяла историю и сопоставила ее с общим опытом и знаниями, чтобы оценить, сколько усилий потребуется для ее завершения. Когда есть расхождение между фактическим приложенным усилием и предполагаемым усилием, команда получает возможность узнать из практического опыта на уровне интуиции только то, что означают пункты — и как оценить их в будущем.
Когда есть расхождение между фактическим приложенным усилием и предполагаемым усилием, команда получает возможность узнать из практического опыта на уровне интуиции только то, что означают пункты — и как оценить их в будущем.
Заметьте, что история требует гораздо больших или меньших усилий, чем первоначально оценивала команда, но стоит изменить историю, изменяя оценку, стирая реальную ценность баллов, что является бесценной возможностью улучшить свои прогнозы для следующего набора историй. , Время подумать о корректировке оценок — на следующем совещании по планированию спринта, когда подобная история подходит и должна быть оценена.
6. Слепо следуя пунктам
Но сохранение точечных оценок не означает, что они должны вести себя как роботы во время спринта, когда история не соответствует оценкам.
Я помню одну команду, в которой я работал, которая оценивала историю, может быть, довольно просто, в основном потому, что они знали, что есть стандартная библиотека, доступная для выполнения большей части тяжелой работы. Команда подумала, что завершение истории — это всего лишь вопрос интеграции библиотеки.
Но критерии принятия истории вышли за пределы возможностей этой библиотеки. Команда быстро поняла, что им нужно разработать собственные низкоуровневые процедуры, чтобы завершить рассказ. Вскоре работа над этой историей начала подрывать производительность команды и угрожала поставить другие истории в тот же спринт с отставанием от графика.
К счастью, у этой команды были внимательные владельцы продуктов, которые активно посещали ежедневные дежурства и которые вовремя заметили эту тенденцию. Существовали и другие истории, которые они изначально считали более низкими по приоритету, исходя из соотношения стоимости их бизнеса и усилий, которые им потребуются. Но это соотношение было изменено неожиданно большими усилиями, необходимыми для этой конкретной истории.
Путем корректировки приоритетов отставания с учетом фактических усилий, необходимых для завершения этой истории, владельцы продуктов смогли работать с командой, чтобы сместить акцент на истории с более высоким соотношением ценности для бизнеса.
Ни при каких условиях оценка существующей истории не изменилась — это означало бы переписывание истории — но команда смогла перенести фокус на другие истории и оставаться продуктивной.
7. Неспособность учиться
Agile подходы всегда включают в себя концепцию ретроспективы, в которой команда может собраться вместе и обсудить, как прошел спринт, включая то, что прошло хорошо, а что нет.
Это отличное время для того, чтобы поднять истории, которые казались команде похожими на архетипические примеры оценки определенной точки, и которые, следовательно, могут быть полезны в качестве ориентиров в будущем. Это также время для обсуждения историй, которые были сильно переоценены или недооценены.
Я никогда не был в команде, которая не сталкивалась хотя бы с одной историей, которую они переоценили с огромным отрывом.
Одна команда впервые узнала на совещании по планированию спринта об истории, в которой использовалась совершенно незнакомая технология, и поэтому оценила ее слишком слабо. После того, как они начали исследовать историю во время спринта, они быстро обнаружили, что решение было не только простым, но уже было сделано для них. Все, что им нужно было сделать, это подключить его к коду.
Часть процесса оценки и разработки истории включает в себя информирование команды о том, что планирует владелец продукта, чтобы никто не находился в тупике на совещании по планированию спринта с концепцией, которую он не знает, как выполнить.
Хороший владелец продукта будет прозрачным в обсуждении будущих планов с командой во время спринта, а ответственная команда обязательно задаст вопросы и приедет на совещание по планированию спринта, подготовленное, чтобы дать реалистичные и взвешенные оценки для новых историй.
Остерегайтесь старых привычек
Когда у команды есть опыт успешной совместной работы, у каждого есть возможность продемонстрировать свою ценность и принять активное участие. Но когда команда только начинает использовать гибкие методологии, старые привычки могут мешать процессу оценки.
Обратите внимание на эти подводные камни, и вы можете помочь своей команде научиться быстро оценивать.