Напишите опис задатка за агента

Опишите промену коју друга особа може да процени

„Додајте извоз података о клијентима” оставља више одлука отвореним. Ко може да извози записе? Који су записи и поља укључени? Шта се дешава када захтев не успе? Агент може да попуни ове празнине уверљивим изборима. Ти избори ипак могу да буду погрешни за пословање.

Почните од корисника и проблема. Затим опишите захтевано понашање. Укључите доказе који ће показати да ли је резултат прихватљив.

Опис задатка треба да смањи неизвесност без одређивања сваког унутрашњег дизајнерског избора. Наведите захтевану границу података. Нека имплементација користи постојеће обрасце репозиторијума, осим ако постоји разлог за њихову промену.

Користите конкретан пример

Следећи опис задатка односи се на измишљену апликацију за подршку. Ово је образовни пример, а не потпуна спецификација за продукцију.

Исход: Руководилац подршке може да преузме списак клијената.
Извршилац: Руководилац у тренутној организацији.
Подаци: Само активни клијенти те организације.
Поља: ID клијента, назив компаније и статус налога.
Формат: UTF-8 CSV са редом заглавља.
Одбијен захтев: Вратити постојећу грешку ауторизације.
Празан резултат: Вратити важећи CSV само са заглављем.
Опсег: Користити постојећу руту извоза и образац ревизијског евидентирања.
Изостављено: Без нових улога, зависности или постављања у окружење.
Докази: Тестови дозвољених, одбијених, празних и захтева из друге организације.

Овај опис утврђује корисно понашање и границе. Отвара и додатна питања. Треба ли систем да ограничи величину извоза? Може ли поље да садржи формулу за табеларни прорачун? Ко може да приступи ревизијском запису? Разрешите питања са значајним последицама пре имплементације. Не третирајте пример као универзалну контролну листу.

Раздвојите захтеве од претпоставки

Захтев наводи понашање које промена мора да испуни. Претпоставка је чињеница коју још нисте проверили. Држите их одвојено.

На пример, „Користите постојећи образац ревизијског евидентирања” претпоставља да погодан образац постоји. Затражите да га агент пронађе. Ако га у репозиторијуму нема, агент треба да пријави тај недостајући предуслов пре него што осмисли нов систем евидентирања.

Ограничење може и да буде у сукобу са исходом. Постојећа рута можда намерно враћа податке свих организација. Агент треба да прикаже сукоб и предложи ограничену исправку. Не сме прећутно да уклони границу података или прошири задатак на преписивање архитектуре.

Укључите доказе у завршетак задатка

Затражите сажетак испоруке који објашњава коначно понашање, промене опсега и извршене провере. Захтевајте тачне команде и резултате тамо где су важни. Разликујте проверу која је прошла од провере која није могла да се изврши.

Pull request треба да сачува разлог промене. Особа која касније одржава код можда неће видети првобитни разговор. Укључите довољно контекста да објасните зашто извоз изоставља одређена поља и како се спроводе правила приступа.

Google смернице за опис промена корисна су референца за овај запис. Опис треба да објасни промену и њену сврху. После исправки током прегледа ускладите запис са коначном имплементацијом.

Прилагодите опис обиму задатка

Мала исправка текста може да има кратак опис. За извоз података потребно је више детаља јер грешке могу да изложе информације. Нов ток плаћања захтева још више анализе и прегледа.

Не мерите квалитет описа његовом дужином. Питајте да ли би компетентна особа при прегледу могла да разликује исправан резултат од погрешног. Ако би се две разумне имплементације разликовале у понашању са значајним последицама, прво разјасните то понашање.