Зачем мы оцениваем и можно ли обойтись без этого?

Попытка найти способ быть более предсказуемым. Часть 2.

Оригинальная статья Альбины Поповой: Why do we estimate and can we do without?

Иллюстрации - Альбины Поповой.

Статья переведена с английского Еленой Максимовой.

Это продолжение. Читайте первую часть: Когда Story Points дают осечку.

Месяц назад я написала статью про анти-шаблоны в оценке. Все началось с отложенного релиза, после которого от менеджмента пришла убедительная просьба стать более предсказуемыми. За этим последовала сумасшедшая идея отказаться от оценки в Story Points.

Поскольку идея витала в воздухе и начала набирать обороты, нам нужно было выяснить, что мы потеряем, если уйдем от оценки в Story Points.

Прошлым летом у нас было выездное мероприятие с 5 командами из XING, которые работали в одной области. Там я провела open space сессию об оценивании и эксперименте с #noestimates.

Группа open space состояла из Владельцев продуктов, разработчиков, QA инженеров, UX и визуальных дизайнеров - такая себе сбалансированная тусовка. Это дало возможность увидеть полную картину того, что именно «потребители» и «производители» процесса оценивания ожидали от него получить.

Мы начали сессию с вопроса "Почему мы на самом деле оцениваем?"

Когда все идеи были собраны, мы рассмотрели каждую и попытались выяснить, можно ли удовлетворить ту же потребность, если удалить оценивание.

1. Мы оцениваем, чтобы понять, нужно ли разбивать пользовательскую историю

Это одно из преимуществ, предложенных «производителями» оценки. При использовании Story Points с Planning Poker действительно легко понять, нужно ли дальше разбивать историю. Во всех трех командах мы установили предел количества Story Points, до которого нужно было разбить историю. В одной команде это было 13 Story Points. Если команда оценивала любую пользовательскую историю больше, чем в 13 Story Points, ее надо было разбивать дальше.

Можем ли мы найти другой способ, чтобы понять, нужно ли разбивать пользовательскую историю без оценки? - Да, можем.

Например, есть карты оценки, которые не используют Story Points.

Или вот, более простое и элегантное решение. Спросите:

1. Можно ли еще разбить эту пользовательскую историю?

2. Имеет ли смысл разбить ее дальше?

   
   

Если оба ответа "Да" - пользовательская история разбивается дальше.

2. Мы оцениваем, чтобы понять друг друга

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

Было ли что-то кроме оценки, что позволило бы нам увидеть, что мы понимаем друг друга? - Да, было.

В предыдущей статье я говорила об альтернативном подходе к построению общего понимания, просто задавая конкретные вопросы:

1. Может ли кто-нибудь из команды перефразировать ценность истории пользователя для бизнеса?

   
   

2. Что технически нужно сделать, чтобы реализовать историю?

   
   

Мы могли бы использовать round robin, чтобы убедиться, что мнение каждого члена команды услышано. Вот как это могло бы выглядеть.

1. Владелец продукта или кто-то еще в команде представляет пользовательскую историю.

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

3. Как только Джек заканчивает, остальная часть команды обсуждает детали, о которых не сказал Джек, или вопросы, с которыми они не согласны. Владелец продукта проясняет эти вопросы.

4. Когда обсуждение заканчивается, кто-нибудь из команды может спросить: «Эта история готова к спринту?».

5. Если да - переходите к истории Б, и следующий по кругу участник начинает обсуждение. Если нет - продолжайте прояснять вопросы к истории A.

   
   

Такой тип round robin не затрагивает вопрос о привязке группы к мнению одного человека или приводит к групповому мышлению слишком рано. Planning Poker работает гораздо лучше в ситуациях, когда людям нужно составить собственное мнение до начала группового обсуждения. В психологически небезопасной среде отказ от Planning Poker может быть не очень хорошей идеей. Но в команде, где люди не боятся оспаривать мнение других независимо от их позиций, где люди не боятся задавать простые или «глупые» вопросы, стоит попробовать отказаться от Planning Poker.

3. Мы оцениваем, чтобы показать Скрам-мастеру, что команда работает

Это был мой самый большой «ага!» и «ой!» момент на этом open space. Никогда раньше я не осознавала, насколько мои постоянные разговоры об улучшении нашей предсказуемости и уверенности в правильности оценки влияли на команду.

В конечном счете оценка была и есть лишь побочным продуктом, чем-то вторичным, что непосредственно не влияет на конечный продукт или услугу, которую мы производим. Но разве не удивительно, как много внимания и значения мы иногда ей уделяем?

Если команда в 100% случаев будет вкладываться в свои оценки, но при этом наш продукт будет некачественным программным обеспечением, которое не будет использоваться, я буду считать это провалом. Не наоборот.

С небольшим вздохом перейдем к следующему пункту.

4. Мы оцениваем, чтобы знать, когда работа будет сделана

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

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

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

Не оценивая истории, мы можем прогнозировать, используя исторические данные, когда будут выполнены X пользовательских историй. Например, в течение последних 5 спринтов команда выполнила в среднем 10 пользовательских историй. Тогда можно завершить примерно 30 историй в 3 спринтах. И это опять-таки только обоснованное предположение.

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

Приметка: я узнала интересный способ управления ожиданиями между командами маркетинга и разработки после визита одного из стартапов в Гамбурге. Там команды тоже не оценивали истории пользователей. Вместо того, чтобы команда разработчиков оценивала свою часть продукта и передавала дату релиза маркетинговой команде, они подсчитали, сколько времени требуется маркетинговой команде для подготовки и развертывания рекламных кампаний. В среднем это было 5 недель. И теперь вместо того, чтобы давать приблизительную оценку заранее, команда разработчиков связывалась с командой маркетинга только тогда, когда была уверена, что поставка продукта возможна через 5 недель.

5. Мы оцениваем, чтобы показать, что продумали историю

Этот момент схож с тем, который использует оценку для понимания друг друга.

Можем ли мы показать, что продумали историю пользователя без оценки? - Да, можем.

Как? См. пункт "Мы оцениваем, чтобы понять друг друга".

6. Мы оцениваем, чтобы спланировать ресурсы

Мы работаем в стабильной командной среде, а не в матричной организации. Пункт "Спланировать ресурсы" касался случаев высокой специализации внутри команд. Иногда не хватало работы для frontend-разработчиков, иногда - для backend-разработчиков. Процесс оценки и его обсуждения помогли найти такой объем работы в спринте, которого хватит на всех участников.

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

Я не сдаюсь и все еще стараюсь воплотить эту картинку в жизнь, но в то же время это реальная проблема в некоторых командах.

Можем ли мы убедиться, что все люди в команде имеют достаточную рабочую нагрузку без оценки? - Да, можем.

Как? Просто спросив команду во время планирования.

7. Мы оцениваем, чтобы избежать неожиданностей и задержек

Мы не хотим неожиданностей. Они нам не нравятся. Это одна из причин, по которой дети так любят рекламные паузы по телевизору. Они повторяемы и предсказуемы. Там не страшно или, другими словами, там мало неожиданности.

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

Можем ли мы избежать неожиданностей и задержек без оценки? - Нет, не можем. Самое главное, что мы не можем избежать их даже при оценке.

8. Мы оцениваем для минимизации риска

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

Но тут такое дело. Я изо всех сил пытаюсь понять, как ярлык на пользовательской истории может уменьшить связанные с ней риски. Каким образом утверждение, что история "весит" 13 Story Points, помогает нам убедиться, что эта же история не раздуется до 40 Story Points? Оценка действительно помогает выявить рискованные или сложные детали, но все меры по снижению рисков, которые необходимо провести, чтобы убедиться, что история пользователя действительно не раздута, на мой взгляд, происходят за пределами мира оценки. Для меня эта идея настолько важна, что заслуживает отдельного упоминания.

Оценка ≠ снижение рисков

Желание избежать неожиданностей и задержек естественно. Качество обещать, а затем поставлять продукт в течении обещанного времени, рассматривается многими как признак истинного профессионализма. Тогда оценка вступает в игру, и мы видим ее как необходимый инструмент для самых разных вещей:

• Чтобы помочь нам согласовать контракт между командой и руководством или заинтересованными сторонами

• Для уменьшения рисков

• Чтобы сделать поставку вовремя, показав свой профессионализм

  
  

Бедная маленькая оценка ошеломлена таким количеством внимания.

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

Приведу несколько инструментов, которые могли бы помочь в уменьшении рисков вместо оценки:

1. Согласовать с заинтересованными сторонами и руководством перепланирование при старте нового эпика. Независимо от соглашения про объем работ и необходимое время, оно основано на огромном количестве допущений и очень небольшом количестве проверенных знаний. Договоренность перепланировать, в то время как часть проверенных знаний о продукте будет возрастать, поможет смягчить риск не поставить продукт вовремя или переопределить то, что значит вовремя. Есть замечательный отчет Хенрика Книберга о поэтапном процессе принятия решений при создании нового продукта @ Spotify. У нас в XING другой подход к поэтапному принятию решений с ежеквартальными обзорами дорожных карт и использованием ACE или Auftragsklärung в качестве стартового формата.

   
   

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

   
   

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

   
   

4. Убедиться, что команда получает обратную связь как можно раньше. Не только отзывы пользователей о работе нового функционала, а также собирается ли код, интегрируется ли код, есть ли некачественные фрагменты кода, хорошо ли он работает на основном сервере. Обычно «Непрерывная Троица» отвечает на эти вызовы - Непрерывная Интеграция, Поставка и Развертывание

   
   

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

   
   

9. Мы оцениваем, чтобы приоритезировать

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

Обычно оценка в Story Points помогает ответить на вопрос о приоритетах в таких случаях. Идея A/B теста с наименьшей оценкой выигрывает.

Можем ли мы приоритезировать истории пользователей в беклоге без процесса оценки? - Да, можем.

Мы по-прежнему можем обсудить альтернативы A/B тестов, что имеет смысл сделать сначала, даже без оценки. Какой из тестов проще в разработке, A или B?

10. Мы оцениваем, чтобы создать дорожную карту

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

Можем ли мы разработать квартальную дорожную карту без оценки в Story Points? - Да, можем.

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

В конце концов, во время этого open space я не предлагала полностью отказаться от процесса оценки, скорее не оценивать пользовательские истории или что-то меньшее, чем эпик.

Итого или послесловие

Полезное упражнение

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

Да, можем!

Идея отказа от оценок в Story Points казалась довольно радикальной для многих до этого open space. По мере приближения к концу списка в аудитории становилось все меньше встревоженных лиц. У меня было ощущение, что люди в целом расслабились, когда поняли, что оценка сама по себе не так важна.

Предпосылки #noestimates

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

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