Потребителски истории и прецизиране на Product Backlog
Научете защо потребителските истории са разговори, а не договори, и как ефективното прецизиране на Backlog помага на Scrum екипите да доставят ценен Increment всеки Sprint.
Много екипи третират потребителските истории като олекотени документи с изисквания. Те ги записват в цифрова система за проследяване, добавят списъци с точки и приемат, че работата е свършена. Потребителската история обаче никога не е имала за цел да бъде спецификация. Тя винаги е била покана за разговор. Прецизирането на Product Backlog е мястото, където се случва този разговор. Когато екипите разберат тази разлика, техните срещи стават по-кратки, кодът им става по-прост, а работният процес върви много по-бързо.
Scrum Guide не изисква потребителски истории
Самият Scrum не задължава използването на потребителски истории. Scrum Guide говори единствено за Product Backlog елементи. Един Backlog елемент е просто конкретна задача, която може да донесе стойност. Той може да бъде отстраняване на бъг, архитектурен експеримент, техническа задача или описание на функционалност в свободен текст. Екипите приеха формата на потребителската история, защото той ги принуждаваше да назоват потребителя и желания краен резултат.
С течение на времето много организации превърнаха този шаблон в догма. Писането на фрази от типа „Като потребител искам X, за да постигна Y“ се превърна в бюрократично задължение. Ако съставянето на това изречение не ви помага да разберете кой печели от промяната, спрете да го пишете. Стойността не е в синтаксиса. Стойността се състои в това всеки, който изгражда функционалността, да разбира защо тя съществува.
Прецизирането е дейност, а не среща
Scrum Guide от 2020 г. описва прецизирането на Product Backlog като непрекъсната дейност за добавяне на детайли, оценки и подредба на елементите. Това не е събитие с твърдо фиксирана продължителност. Не е необходимо да седите на една двучасова среща всеки втори четвъртък, за да разглеждате тикети. Силните екипи прецизират постоянно.
Един Product Owner може да покани двама разработчици за петнадесет минути във вторник сутрин, за да начертаят работен процес на бялата дъска. Даден разработчик може да обсъди план за миграция на база данни с Product Owner след обяд. Когато прецизирането е непрекъснат процес, Backlog остава актуален, без да изтощава екипа с маратонски заседания.
Трите съставни части на всяка история
Преди десетилетия Рон Джефрис описа потребителските истории с три прости думи: Карта, Разговор и Потвърждение (Card, Conversation, Confirmation). Този модел остава най-добрият ориентир за прецизиране на Backlog:
- Карта: Кратко напомняне за това какво трябва да бъде обсъдено, записано на хартиена карта или в софтуерен инструмент.
- Разговор: Диалог между разработчиците и продуктовите специалисти за изследване на проблема, компромисните варианти и техническите крайни случаи.
- Потвърждение: Конкретните примери и критерии за приемане, които показват кога работата е напълно завършена и готова за внедряване.
Повечето неуспешни сесии за прецизиране пренебрегват разговора. Product Owner описва картата и потвърждението напълно самостоятелно, след което ги предава на разработчиците по време на Sprint Planning. Това не е гъвкава разработка. Това е миниатюрен waterfall процес, прикрит като поредица от тикети.
Разбиване на елементите за завършване в рамките на един Sprint
Основната цел на прецизирането е елементите да станат достатъчно малки, за да бъдат завършени в рамките на един Sprint. Scrum Guide посочва, че разработчиците, които ще вършат работата, носят отговорност за нейното оразмеряване. Ако даден елемент изглежда твърде голям, рискован или неясен, не му задавате просто повече точки. Вие го разделяте.
Най-чистият начин да разделите дадена история е според поведението на потребителя или пътя на данните, а не според архитектурните нива. Не разделяйте история на отделни frontend и backend задачи за различни Sprint периоди. Това води до незавършен и непроверен софтуер в края на съответния Sprint. Вместо това изградете тънък вертикален срез, който изпълнява един прост и успешен потребителски сценарий от базата данни до интерфейса. Щом този срез заработи в продукционна среда, прецизирайте и добавете следващата вариация.
Критерии за готовност на даден елемент
Даден Backlog елемент е готов за Sprint Planning, когато разработчиците разбират какъв проблем решават, защо той е важен и как ще проверят готовото решение. Не е нужно всеки детайл да бъде уточнен предварително. Нужна ви е само достатъчно яснота, за да започнете работа, без да блокирате още на втория ден.
Ако даден екип изисква пълна архитектурна сигурност, преди да изтегли елемент в даден Sprint, той се опитва да избегне емпиричния подход. Несигурността е нормална част от разработката на софтуер. Прецизирането не елиминира несигурността. То я намалява точно толкова, колкото е нужно, за да може екипът да научи останалото чрез реално изграждане.