Практика использования персонального рейтинга каждого члена команды в контексте Scrum и SAFe | Амплеев Евгений - Scrum Master / Full stack web developer
Читаете:
Практика использования персонального рейтинга каждого члена команды в контексте Scrum и SAFe
Поделиться:
heart interface icon84

Практика использования персонального рейтинга каждого члена команды в контексте Scrum и SAFe

Avatar
Автор статьи: Yevgeniy Ampleev
14 декабря 2019 в 08:54
Image

В этой статье я планирую рассказать как на своей практике мы применяем Персональный рейтинг каждого члена команды в Scrum в процессе работы по фреймворку SAFe

Наверное, многие согласятся с тем, что (особенно в России) у нас люди достаточно часто стараются работать (доставлять конечный продукт в рамках своих компетенций или посредством получения новых) поменьше и получать денег побольше. С размером компании возможности для этого, кажется, что растут прямо пропорционально. С этим, как правило, работают различные околоHR'ы, которые всячески пытаются строить правильную систему мотивации. Сюда же OKR'ы и т.д. В целом, кажется, все это нацелено на сбалансированность нагрузки каждого внутри корпорации и комфорт всех заинтересованных групп лиц/команд корпорации. В данной статье я поделюсь метрикой, которую сам придумал и применяю в команде. Она позволяет, как мне кажется, дополнить усилия HR'ов и OKR'ов в сбалансированности нагрузки внутри одной конкретной команды или увидеть дисбаланс, соответственно. Также, она вполне может и масштабироваться на команду команд, не вижу в этом особой проблемы.

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

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

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

Итак, пример конкретного случая. Конечно, мы используем доску для передвижения User Stories по статусам от DOR (Definition Of Ready) до DOD (Definition Of Done). Она у нас виртуальная (т.е. расположена в интернете по ссылке. Команда у нас тоже распределенная и стендапы проходят через корпоративный скайп как раз с трансляцией доски.

Члену команды удобно ставить себя в участники User Story, чтобы при использовании фильтра по себе можно было быстро оставить только те истории, в которых он участвует в данный момент(чаще всего этим фильтром мы пользуемся на стендапах).

Image


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

Таким образом, чтобы посчитать рейтинг каждого члена команды, нам нужно посмотреть на сколько SP влияет каждый член команды. В нашем случае Аркадий влияет на 29 SP (истории 1, 2, 5, 6), Татьяна влияет на 33 SP (Участвует во всех историях), Василий на 23 SP (истории 1, 3, 5, 6).

Закрыто(выполнен DOD) у Аркадия 5 из 29 SP, у Татьяны 6 из 32 SP, у Василия 5 из 23. С сортировкой я достаточно долго мучился и пришел вот к такой формуле сравнения двух членов команды (member[i] и member[j]):

Image

Согласно этой сортировке мы получим текущий рейтинг членов команды в следующем виде.

  • 1 место. Василий (Выполнено 5 из 23)
  • 2 место. Аркадий (Выполнено 5 из 29)
  • 3 место. Татьяна (Выполнено 6 из 32)

Теперь давайте сгенерируем все данные по спринту. Представим, что спринт длится 5 рабочих дней.

  • 1 день
    Image
    Image

    1 место: Василий (сожжено 0 из 23)
    2 место: Аркадий (сожжено 0 из 29)
    3 место: Татьяна (сожжено 0 из 32)
  • 2 день
    Image
    Image

    1 место: Василий (сожжено 0 из 23) динамика(1->1)
    2 место: Аркадий (сожжено 0 из 29) динамика(2->2)
    3 место: Татьяна (сожжено 0 из 32) динамика(3->3)
  • 3 день
    Image
    Image

    1 место: Василий (сожжено 5 из 23) динамика(1->1->1)
    2 место: Аркадий (сожжено 5 из 29) динамика(2->2->2)
    3 место: Татьяна (сожжено 5 из 32) динамика(3->3->3)
  • 4 день
    Image
    Image

    1 место: Василий (сожжено 8 из 23) динамика(1->1->1->1)
    2 место: Аркадий (сожжено 8 из 29) динамика(2->2->2->2)
    3 место: Татьяна (сожжено 9 из 32) динамика(3->3->3->3)
  • 5 день
    Image
    Image

    1 место: Василий (сожжено 23 из 23) динамика(1->1->1->1->1)
    2 место: Татьяна (сожжено 24 из 32) динамика(3->3->3->3->2)
    3 место: Аркадий (сожжено 21 из 29) динамика(2->2->2->2->3)

Таким образом, используя данную метрику можно накапливать персональную статистику каждого члена команды и помогать ему делать правильные выводы. Например, здесь мы видим, что Василий очень грамотно спланировал свое время с самого начала(т.е. на планировании спринта он договорился с командой о том объеме работ, который он и выполнил по факту.) Но, в то же время, может он мог как-то помочь другим членам команды? Возможно и нет, но стоит подумать над этим вопросом перед ретроспективой.

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

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

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

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



    Добавить комментарий
    divider graphic

    Возможно, вам будет интересно

    Image
    04 февраля 2020 в 15:59
    heart interface icon191

    Специфика работы Agile-команды в SAFe относительно Scrum на практике

    В данной статье я постараюсь описать основные и, наиболее яркие отличия фреймворка SAFe относительно SCRUM, которые я заметил за год работы в SAFe.

    Image
    Yevgeniy Ampleev
    Image
    13 декабря 2019 в 08:54
    heart interface icon73

    Практика применения Cumulative Flow в контексте Scrum и SAFe

    В этой статье я планирую рассказать как на своей практике мы применяем Cumulative Flow Chart в Scrum в процессе работы по фреймворку SAFe

    Image
    Yevgeniy Ampleev
    arrow-up icon