Сеть оценок для планирования в Scrum

Original author: Kirill Klimov
  • Translation
  • Tutorial
Scrum — достаточно простая методология. Работать же по скраму не так и просто. Точно так же происходит со многими инструментами, например с покером для планирования. Практика сама по себе вполне понятная, но продуктивно её использовать в течении длительного времени затруднительно.
В этой статье я расскажу про технику, которая упрощает процесс оценок в работе скрам команды.
Итак, в чём же сложность?
Как вы знаете, story points — это относительные оценки объёма работы в истории. Нет способа оценить одну единственную историю в story points, вы всегда сравниваете историю с другими историями через story points. Покер может хорошо сработать в начале проекта, когда команды оценивает много историй в течении короткого промежутка времени.
Но позже, во время регулярной переоценки существующих историй и оценок новых историй становится значительно труднее, потому что калибровка одного story point забывается: «что такое один story point», «что-то я не уверен, что эта история действительно в 3 раза больше нашего золотого эталона», «эти две истории размером 5 не выглядят одинаковыми в размере, с моей точки зрения». Знакомые проблемы?

Предлагаемое решение

Решение, которое я называю “оценочной сеткой” — визуальная таблица, по одной строке для каждого размера истории, которым вы пользуетесь. Если вы пользуетесь рядом Фибоначчи для оценок, у вас будут строки для “0.5”, “1”, “2”, “3”, “5” и “8”. Затем для каждого размера (в каждую строку) вы размещаете несколько карточек с историями, примерами в этом размере. Вот иллюстрация как это должно выглядеть:


Такая сетка на виду у вашей команды делает процесс оценок значительно проще, потому что у вас есть несколько примеров историй в каждом размере, и вы можете сравнить вашу новую историю с этими примерами.
Как заполнить эту сетку в самом начале..? Общее правило такое: добавляйте только «типичные истории», если есть шанс, что вы будете делать что-то подобное в будущем.
Желательно помещать истории в сетку после того, как мы завершаем работу с ними, что бы у нас был реальный опыт.
Инструмент «Сетка оценок» нацелен на помощь с будущими оценками. Поэтому, если какая-то конкретная история была уникальной, и вряд ли вы будете делать что-то подобное в будущем – для такой истории нет места в сетке.

Ещё пара советов как построить сеть

Ещё один трюк, снимающий сложности, которые могут возникнуть у многих членов команды: важно помнить, что значит конкретное значение оценки. Например, «5» — это сколько? Давайте вспомним, как мы проводим оценки. Если команда верит, что размер истории больше «3» и меньше «5» – он становится «5». Так что «5» означает все истории в интервале от 3 до 5. Если вы это помните, становится намного проще поместить две достаточно разные по размеру истории (например, одна чуть больше, чем 3 и другая чуть меньше, чем 5) в один ряд, как одинаковые. Я даже показываю эти интервалы рядом с размером в первой колонке (как вы можете видеть на картинке) чтобы визуально напомнить об этом. И вы пересматриваете и улучшаете эту сеть со временем. Во время ретроспективы каждую итерацию, или раз в несколько итераций, вы проходите по сетке, чтобы проверить все ли присутствующие там истории всё ещё актуальны, и, может быть, стоит добавить новые истории, с которыми вы работали.
Лучше всего если у вас будет 2-5 карточек примеров в каждом размере. Вам нужен какой-то минимум как базис для оценок, и у вас не должно быть слишком много примеров, потому что это только затруднит и замедлит сравнение.
Пара примеров как это может выглядеть в реальной жизни:



Нет смысла помещать в вашу сетку все возможные размеры историй (как 20, 40 или 100). Нужно сфокусироваться только на размерах, которые актуальны для историй достаточно маленьких, что бы зайти в итерацию. Это зависит от вашего выбора размера. Моя рекомендация – всё до 8.
Этот инструмент очень просто внедрить и использовать. Из моего опыта, у него очень низкий уровень сопротивления со стороны команд, то есть его хорошо принимают. Это пример простого процессного эксперимента, который вы можете обсудить со своей командой на следующей ретроспективе и попробовать, не сильно рискуя.
Если у вас есть вопросы, задавайте в комментариях – буду рад помочь.
Share post

Comments 15

    0
    Полезный инструмент.

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

    P.S. Не сразу увидел, что «Если у вас есть вопросы, задавайте в комментариях – буду рад помочь.» — тоже часть перевода статьи :)
      0
      тут речь не о каждом отдельном сотруднике а о комманде.
      всреднем команда будет делать не 2 или 8 часа а от 4 до 6
        +4
        хороший вопрос, спасибо
        это оценки размера историй, а не времени исполнения.
        в этом фокус. молодой и опытный никогда не сойдутся на времени, но могут сойтись на размере.
        мой классический пример — вырыть яму куб земли. у ребенка с совочком займет одно время, у проф. рабочего с лопатой — другое, у экскаватора — третье. для них эта работа всегда будет разное время занимать, но на размере 1х1х1 они сойтись могут.
        вот так и работают относительные единицы размера — story points
          +1
          «Если у вас есть вопросы, задавайте в комментариях – буду рад помочь.» — тоже часть перевода статьи :)
          Перевод-то авторский.
          0
          Хорошей практикой считается при оценке времени на задачу считать его в «идеальных часах» т.е. без траты времени на «попить чай», «покурить», «ответить на вопрос коллеги». и т.д. Плюс надо закладывать 25% времени на фикс багов и незапланированные задачи.
            0
            >>Хорошей практикой считается при оценке времени на задачу считать его в «идеальных часах» т.е. без траты времени на «попить чай», «покурить», «ответить на вопрос коллеги».

            Да-да-да, работает просто отлично!

            А вот, время на фикс багов, незапланированные задачи, плохое настроение и тому подобное — лучше получать статистически — по сути оно будет влиять на скорость (velocity) команды. Т.е. Если Вы сделали в этом спринте 100 идеальных часов — то и в следующем сделаете столько же (скорее всего).
            0
            хм, а как Вы решаете вопрос с тем, что:
            1) Проект всётаки — это не два файла с кодом. Есть люди которые не занимались разработкой модуля А, и просто не смогут понять объём задач, там выполнявшихся. (Этот вопрос может появлятся в случае длительной разработки, и с приходом новичков).

            2) Часто «тяжёлыми» оцениваются задачи, которые требуют неких исследований — например интеграция с ранее неиспользовавшимся API (не известно, насколько хорошо оно работает, и какие есть причуды). С высоты реализованной задачи, исследования не видно, т.к. уже всё известно.

            3) И мы, конечно же, ошибаемся с оценками.

            По сути, все вопросы сводятся к «обновляете ли Вы сетку» и «оставляете ли Вы задачам первоначальную оценку, или переоцениваете по факту, прежде чем поместить в сетку»
              0
              Выкиньте Scrum и прочие методологии — возмите человека который вел разработку хотя бы пары проектов и занимался до этого программированием. Думаю найти таких можно.
                0
                А что помешает этому новому человеку вести проект по Scrum?
                  0
                  Я думаю он не стал бы уделять столь большое внимание Scrum. Говорю исходя из своего опыта.
                    +1
                    Scum — набор инструментов, интересно, какие используете вы?
                    Для оценки, планирования, фидбека, устранения ботлнеков и т.п.
                    (а то может вы за «свобода + 1 год = результат»? Всё готово осталось потестить и задеплоить? Кто же вас знает ;)
                      0
                      Нет. Свободы плюс один год такого нет. Я управлением проектов не занимаюсь, но участвовал в разработке многих (около 15). Очень часто было так, что у руководителей проекта не было технического бэкграунда, что крайне отрицательно сказывалось на самом проекте.

                      Часто слепое следование методологиям тоже шло во вред. К примеру на одном из проектов целый день отводилось на планирование и оценку при этом терялся рабочий день команды разработчиков (больше 10 человек) и в конечном результате все ровно был частый срыв сроков.

                      В общем каждый проект был по своему уникальным. Какие-то существующие методики можно и нужно использовать, но их нужно подстраивать под нужды проекта а не проект под нужды методики.
                      0
                      А какой у Вас опыт?
                        0
                        6 лет Web разработки. Около 15 проектов.
                          0
                          Судя по Вашему комментарию, управлением проектами Вы не занимались. То есть и опыта в этой сфере у Вас нет.

                          Я побывал с обоих сторон «баррикад» и поверте — реально оценить ситуацию только с точки зрения исполнителя — не возможно. С точки зрения программиста иногда кажется — задобали эти менеджеры, сующие свои методологии, дайти просто поработать, и всё вам будет. Практика показывает — что да, будет. Только непонятно что, и непонятно когда.

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

                Only users with full accounts can post comments. Log in, please.