Адаптований переклад статті George Wilde, розміщеної на платформі Medium
Як створювати те, чого хоче Ваш замовник
У цій інструкції я розповім Вам про те, як писати класні user stories, які допоможуть вашим командам розробників якісно працювати разом і створювати такий продукт, який потрібен Вашому замовнику
Що таке user story?
Це короткий опис функціоналу, наведений з точки зору користувача
Вони короткі, вони не є технічною специфікацією, але, що важливо, вони показують ситуацію з точки зору користувача.
В цей момент важливо дізнатися “А хто ж наші користувачі?”. Чи ви їх знаєте? Чи вся команда, включно з розробниками знає їх? Скоріш за все у вас буде багато різних користувачів і усі з своїми бажаннями та потребами.
Якщо ви не знаєте своїх користувачів – вам не варто писати user stories (історії користувачів)
Якщо Вашій команді потрібно краще розібратися у тому, хто є Вашими користувачами, Ви можете скористатися інструментом Personas.
Як на мене, найважливішим аспектом user story є те, що це інструмент співпраці (колаборації).
Вони не повинні просто передаватися розробникам. Вони повинні спонукати до дискусії усієї команди. Це відповідальність кожного у команді зрозуміти що і для чого вони створюють. Якщо Ви працюєте за скрамом, то backlog refinement мітинг – це добра нагода, щоб покращувати свої user story/
Чому це взагалі важливо?
Маю надію на те, що результатом написання хороших user story є не тільки задоволення клієнта, але й кращий настрій у команді виконавців.
Погано написані user story можуть викликати непорозуміння, це може спричинити розробку невірних рішень, що в свою чергу викликає переробки і затримки, а це може спричинити невдоволення у всій команді.
Робота над user story є легкою, але написання класних і якісних user story – це дуже непросто!
То як же писати якісні user story?
Я пропоную дотримуватися 5 порад:
- Усі повинні бути щасливі. Важливо, щоб усі були в курсі справ, тому залучайте усіх, хто буде писати чи користуватися user story, щоб вони ділилися своїми ідеями чи побажаннями з приводу формату чи вигляду user story, яким ви будете користуватися
- Будьте послідовними. Після того, як ви домовилися про певну структуру і формат – дотримуйтеся її постійно
- Сфокусуйтеся на важливому. Коли пишете user story, уникайте будь-яких неважливих деталей. Витратьте трішки часу, щоб зробити user story лаконічними і викиньте з них усе зайве.
- Жодних деталей реалізації (імплементації). Завжди фокусуйтеся на “чому”, а не на “як”. Чому користувач хоче щось, а не як ми це будемо реалізовувати. Якщо Ви хочете додати якісь технічні деталі, то це повинно бути зроблено у окремому файлі.
- Чітко, з можливістю виміряти і перевірити (потестувати). Переконайтеся, що кожен розуміє user story і що вона може бути реалізована за той часовий відрізок, який ви передбачили. Якщо ви працюєте у 2-тижневих спринтах, ви повинні переконатися, що реалізація не займе більше 2-х тижнів.
Також цікаво: Гайд по User Stories для Junior BA
Анатомія user story?
Є 3 обов’язкові частини user story: заголовок, опис та критерії прийомки (acceptance criteria). Ви з командою можете погодити і інші додатки перед початком роботи, але переконайтеся, що всі з цим погодилися і в курсі. Наприклад, Ви можете домовитися про такі додаткові атрибути user story як виконавець, story points чи business impact. У кожній компанії перелік цих атрибутів може відрізнятися. Проте важливо, щоб усі достеменно знали і розуміли усі ці атрибути.
Заголовок
Заголовки повинні бути короткі, унікальні та недвозначні.
Хороші приклади:
- “Add contact us panel to home page”
- “Add debit card support to shopping cart”
- “Update email template tagging”
Погані приклади:
- “Make agreed changes”
- “32072 — Updated Mapping- Upsell User story (27263)”
- “Links — tracking query string for bill trigger and smart post install …”
ОПИС
Опис містить у собі найбільшу силу user story. Він повинен спонукати у команди почуття емпатії до користувача і розуміння його проблеми, яку потрібно вирішити.
Найпопулярнішою структурою user story є формат: “As a … I want … so I can …”.
Цей формат спонукає до запитання “як хто”? Хто цей користувач, що має проблему? Ви можете посилатися на persona, якщо ви їх використовуєте, або ж дайте користувачу назву і додайте трохи контексту ситуації. Старайтеся не використовувати формулювання “As a customer” чи “As a user”, оcкільки це не надто сприяє розумінню, хто ж є справжнім користувачем.
Опис повинен бути написаний простою зрозумілою мовою без технічних термінів чи абревіатур. Запитуйте себе “Чи може Ваша бабуся зрозуміти написане?”. Новий член команди повинен бути в змозі прочитати опис і без пояснень зрозуміти яку саме проблему потрібно вирішити.
Наступні реальні приклади взяті з проекту, у якому додавалася функціональність до системи обліку користувачів енергетичної компанії у Великобританії:
- “As John, a customer with a traditional electricity meter, I want to understand why I can’t see charts of my energy usage in any more detail than month by month so I can decide whether I want to change this and get a smart meter installed.”
- “As Bart, a proactive traditional meter customer wanting to make sure my next bill is accurate, I want to know if a meter reading has already been submitted today and that I don’t need to submit another.”
Погані приклади:
- “As a user I want to prevent trad customers from being able to drill down below the highest level so that their customer experience is managed”
- “As a customer who has either provided a meter read today or had a fuel read estimated today, I should not be allowed to submit another meter read today as SAP cannot accept more than one meter read per fuel per day.”
Насправді, ці погані приклади, власне, були переписані у добрі, що знаходяться вище, оскільки з цих поганих не було зрозуміло, про які саме проблеми йдеться. Процес прояснення (refinement) потрібно проводити щоразу, коли хоча б якась частина user story є не повністю зрозумілою. Упевніться, що кожен у команді обізнаний і розуміє про що йдеться у змінах.
Зверніть увагу: Ця чудова (користувацька) історія
Acceptance criteria (Критерії приймання)
Критерії приймання використовуються, щоб довести, що user story є реалізованою. Це допомагає розробникам та тестувальникам.
Написання критеріїв приймання – це, по суті, шлях проходження усіх деталей історії перед початком самої роботи. Чимало потенційних перепон чи неочікуваних додаткових завдань можуть бути “виявлені” раніше, якщо з сумлінням віднестися до написання критеріїв прийомки.
Одним з найпопулярніших форматів написання критеріїв приймання є формат “Given… When… Then…”
Зауважте, що якщо user story має більше ніж 10 критеріїв приймання, то це може бути індикатором того, що user story завелика. У такому випадку рекомендується розділити user story.
Для написання критеріїв приймання доцільно залучати усю команду. Якщо це неможливо, то я настійливо рекомендую, щоб перед початком роботи усі ознайомилися і уважно прочитали усі критерії приймання. Особливо важливо це для тестувальників.
Нумерування критеріїв приймання є хорошою практикою для того, щоб згодом посилатися на критерії.
Хороші приклади:
- Given a customer with a traditional meter on the energy usage bar chart
When clicking on the tool-tip for a month
Then a popup is displayed matching the specified design. - Given a dual fuel customer viewing the energy usage bar chart
When they have months with estimated values
Then the chart legend should clearly show an estimated electricity icon with a light red bar
Then the chart legend should clearly show an estimated gas icon with a light blue bar.
Коли user story не потрібні?
Технічні задачі
Іноді технічна задача не має стосунку до користувача. У такому разі не використовуйте формат user story. Щоправда, завжди важливо усвідомлювати, для чого ви робите цю технічну задачу; можливо ви оновлюєте бібліотеку, щоб підвищити швидкість для користувачів? Якщо так, то це повинна бути user story.
Помилки/Баги (Bugs)
У разі знаходження помилки під час тестування, то завдання з виправленням цієї помилки повинно посилатися на першопочаткову user story.
Якщо ж знаходиться помилка і вона не стосується реалізації поточної user story, то для виправлення помилки потрібно додавати завдання у беклог як незалежне (independent task).
Нетиповий досвід можна прочитати тут: Як схрестити слона з бегемотом, або Чи можна поєднати User Stories та Use Cases в одному проєкті
Постійно покращуйте (Continuous improvement)
User story будуть еволюціонувати і розростатися, щоразу коли ви будете дізнаватися більше про те, що потрібно зробити. Це природно і не бійтеся покращувати свої user story одразу, коли дізнаєтеся, щось нове. Проте дуже важливо, щоб усі члени вашої команди були в курсі змін і були згодні із змінами, які ви вносите до user story!
Будьте гнучкими, постійно переглядайте свої user story і реагуйте на нові зміни чи потреби, щоб доробити і покращити власні user story. Проговорюйте їх формат та деталізацію під час ретро – це допоможе Вам адаптуватися під потреби команди, з якою Ви працюєте.
Оригінал публікації знаходиться тут
2 thoughts on “Як писати хороші User Stories”