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

Опишете промена што рецензент може да ја оцени

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

Почнете со корисникот и проблемот. Потоа опишете го потребното однесување. Вклучете ги доказите што ќе покажат дали резултатот е прифатлив.

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

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

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

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

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

Одделете ги барањата од претпоставките

Барање наведува однесување што промената мора да го исполни. Претпоставка е факт што сè уште не сте го провериле. Чувајте ги одделно.

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

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

Вклучете докази во условите за завршување

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

Барањето за спојување код треба да ја зачува причината за промената. Иден одржувач може да го види кодот без првичниот разговор. Вклучете доволно контекст за да објасните зошто извозот исклучува одредени полиња и како се спроведува контролата на пристап.

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

Приспособете го описот на задачата

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

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