Історії робіт (Job Stories)

Історії робіт (Job Stories)

Історії робіт (Job Stories) використовуються для представлення позиції бэклога продукту (Product Backlog Item - PBI) або вимог до роботи, яку повинен виконати стейкхолдер.

Історії робіт (Job Stories) одна з методик Agile Extension to the BABOK® Guide v2

Опис Історії робіт (Job Stories) 7.4.2

Історії робіт (Job Stories) фокусуються на мотивації стейкхолдера і надають якомога більше контексту для мотивації, тривог і боротьби стейкхолдера. Вони додають контекстуальну інформацію, яка може вплинути на те, якою стейкхолдер хоче бачити бажану функцію, і допомагають приймати правильні рішення щодо впровадження.

Історії робіт (Job Stories) також слугують інструментом комунікації для стейкхолдерів. Вони полегшують взаємодію та співпрацю між окремими особами і зосереджують команду розробників на потребах клієнта, залишаючи деталі реалізації на розгляд.

Елементи Історії робіт (Job Stories) 7.4.3

Формат (Format)

Розповідь про роботу має певний формат. Вона може бути написана від першої або третьої особи. Історія роботи може бути відформатована наступним чином:

  • Коли <ситуація> я хочу <мотивація>, щоб я міг <очікувані результати> / When <situation> I want to <motivation> so I can <expected outcomes>
  • Коли хтось <ситуація>, актор(и) <мотивація>, щоб <очікувані результати> / When someone <situation>, actor(s) <motivation> so that <expected outcomes>

Приклад

Коли (When) я хочу зняти гроші з мого банківського рахунку, я хочу (I want to) знати, що на моєму рахунку достатньо грошей, щоб зняти їх зараз, щоб я міг (so I can) піти на вечерю з моїми друзями.

Коли (When) хтось бажає зняти гроші зі свого рахунку, клієнт (the customer) хоче знати, чи є кошти на рахунку, касир хоче знати, чи обслуговується ця особа в нашому банку, щоб (so that) особа, яка просить, могла отримати бажану суму готівки.

Ситуація (Situation)

Першим елементом синтаксису історії завдання є ситуація.

Ситуація визначає контекст, в якому робота повинна бути виконана. Контекст ситуації спонукає команду виконавців думати про широкий спектр можливих рішень. Чим більше контексту, тим краще команда може розробити рішення.

Якщо є кілька ролей, які повинні виконати роботу, ці ролі включаються в твердження "коли".

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

Мотивація (Motivation)

Другим елементом синтаксису історії вакансії є мотивація.

Мотивація фокусується на мотивації клієнта. Вона може включати внутрішні та зовнішні сили мотивації.

Бажані функції або рішення спеціально не включаються в Історії роботи, щоб зосередитися на клієнті.

Очікувані результати (Expected Outcomes)

Третій елемент синтаксису job story - очікувані результати.

Результат повинен задовольнити або послабити мотивацію, яка спонукала до виникнення ситуації.

Міркування щодо використання Історії робіт (Job Stories) в Agile Extension to the BABOK® Guide v2 (7.4.4)

Сильні сторони Історії робіт (Job Stories)

  • Цей формат зменшує припущення щодо ролі та усуває особистісні упередження.
  • Його можна налаштувати для причинно-наслідкових сценаріїв.
  • Цей формат фокусується на мотивації зацікавлених сторін, а не на визначенні впровадження.
  • Це корисно для дизайну користувацького досвіду.
  • Командам легше співпереживати зацікавленим сторонам.
  • Прибирає фокус на функціях і натомість фокусується на бажаному майбутньому стані стейкхолдера.
  • Команди можуть використовувати Job Stories та User Stories разом для роботи над беклогом. Історія завдання вказує на мотивацію і результат для стейкхолдера, в той час як історія користувача вказує на функції, які можуть вирішити проблему.

Обмеження Історії робіт (Job Stories)

  • Цей формат має тенденцію бути більш багатослівним, ніж User Stories, через контекст, ролі та результати, що включаються.
  • Робочі історії можуть розкладатися на кілька менших робочих історій, які потребують управління шляхом уточнення і визначення пріоритетів.
  • Якщо в беклозі продукту є як Job Stories, так і User Stories, команди можуть заплутатися при перемиканні між форматами.


Якщо стаття була для вас корисна підпишіться на розсилку або на мій телеграм канал.


Read more

Організація як Код: Від Кібернетики до Агентних Компаній

Організація як Код: Від Кібернетики до Агентних Компаній

Якщо форму час від часу не досліджувати, не аналізувати, не рухати й не змінювати, вона завмирає. Дослідження концепції "Organization as Code" та її застосування для Venture Builder (побренштормив разом з Claude ) Уявіть компанію, де більшість рутинних процесів — пошук ніш, аналіз конкурентів, написання контенту, онбординг клієнтів, фінансова звітність — виконуються

By Zosym Maxym
Модель фідбеку STAR

Модель фідбеку STAR

Модель фідбеку STAR — це інструмент для надання конструктивного, структурованого зворотного зв’язку, що фокусується на конкретних діях і результатах. Вона допомагає чітко пояснити, що саме було зроблено правильно або де є можливості для вдосконалення, з метою підтримки професійного розвитку і вдосконалення співробітників. Назва STAR є абревіатурою і розшифровується як: * S

By Zosym Maxym
Формули Ерланга для колл-центрів

Формули Ерланга для колл-центрів

Формули Ерланга B і C - були створені датським математиком Агнером Крерупом Ерлангом на початку XX століття для вирішення задач телефонної мережі. Ерланг шукав спосіб визначити, скільки телефонних ліній або операторів потрібно для обробки дзвінків у межах заданого рівня обслуговування. Його робота заклала основи теорії черг, яка використовується в різних

By Zosym Maxym
Модель фідбеку GROW

Модель фідбеку GROW

Модель фідбеку GROW — це інструмент, що використовується для надання структурованого зворотного зв’язку, спрямованого на розвиток співробітників, команд або організацій. На відміну від моделі коучингу GROW, модель фідбеку зосереджується на оцінці минулої діяльності та подальшому вдосконаленні шляхом створення діалогу між керівником і співробітником. Назва моделі також розшифровується як: * G — Goal

By Zosym Maxym