← Есеї

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

У цій статті я планую розповісти як на своїй практиці ми рахуємо і застосовуємо персональний рейтинг кожного члена команди в Scrum у процесі роботи за фреймворком SAFeПерсональний блог.

5 хв читання
TelegramОригінал
Практика використання персонального рейтингу кожного члена команди в контексті Scrum і SAFe

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

Напевно, багато хто погодиться з тим, що (особливо в Росії) у нас люди досить часто намагаються працювати (доставляти кінцевий продукт у межах своїх компетенцій або через отримання нових) менше і отримувати грошей більше. З розміром компанії можливості для цього, здається, зростають прямо пропорційно. З цим, як правило, працюють різні близькоНR'и, які всіляко намагаються будувати правильну систему мотивації. Сюди ж 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. З сортуванням я досить довго мучився і прийшов ось до такої формули порівняння двох членів команди (team[i] - один член команди і team[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 місце. Зрештою, ця метрика націлена на покращення здатності планування кожного члена команди окремо.