Írjon feladatleírást az agentnek

Írjon le értékelhető módosítást

Az „ügyfélexport hozzáadása” több döntést nyitva hagy. Ki exportálhat rekordokat? Mely rekordok és mezők kerülnek bele? Mi történik sikertelen kérésnél? Az agent hihető döntésekkel kitöltheti ezeket a hiányokat. A döntések mégis hibásak lehetnek az üzleti igény szempontjából.

Kezdje a felhasználóval és a problémával. Ezután írja le az elvárt működést. Adja meg azokat a bizonyítékokat is, amelyek megmutatják, elfogadható-e az eredmény.

A feladatleírás csökkentse a bizonytalanságot anélkül, hogy minden belső tervezési döntést rögzítene. Határozza meg a szükséges adathatárt. A megvalósítás kövesse a repozitár meglévő mintáit, hacsak nincs ok a módosításukra.

Használjon konkrét példát

Az alábbi feladatleírás egy fiktív támogatási alkalmazásra vonatkozik. Oktatási példa, nem teljes éles specifikáció.

Eredmény: A támogatási menedzser letölthet egy ügyféllistát.
Szereplő: Az aktuális szervezet menedzsere.
Adatok: Kizárólag az adott szervezet aktív ügyfelei.
Mezők: Ügyfélazonosító, cégnév és fiókállapot.
Formátum: UTF-8 CSV fejlécsorral.
Elutasított kérés: A meglévő jogosultsági hiba visszaadása.
Üres eredmény: Érvényes CSV, amely csak a fejlécet tartalmazza.
Hatókör: A meglévő exportroute és auditminta használata.
Kizárva: Nincs új szerepkör, függőség vagy telepítés.
Bizonyíték: Tesztek az engedélyezett, elutasított, üres eredményű és más szervezet adataira irányuló kérésekre.

A leírás meghatározza a hasznos működést és a korlátokat. További kérdéseket is felszínre hoz. Korlátozza-e a rendszer az export méretét? Tartalmazhat-e egy mező táblázatkezelő-képletet? Ki férhet hozzá az auditrekordhoz? A jelentős következményekkel járó kérdéseket a megvalósítás előtt rendezze. A példát ne tekintse általános ellenőrzőlistának.

Válassza külön a követelményeket és a feltételezéseket

A követelmény olyan működést ír elő, amelyet a módosításnak teljesítenie kell. A feltételezés még nem ellenőrzött tény. Tartsa őket külön.

A „használja a meglévő auditmintát” például feltételezi, hogy létezik megfelelő minta. Kérje meg az agentet, hogy keresse meg. Ha a repozitárban nincs ilyen, az agent jelezze a hiányzó előfeltételt, mielőtt új auditrendszert találna ki.

Egy korlátozás az eredménnyel is ellentmondásba kerülhet. A meglévő route például szándékosan minden szervezet adatait adhatja vissza. Az agent mutassa meg az ellentmondást, és javasoljon korlátozott javítást. Ne szüntesse meg észrevétlenül az adathatárt, és ne bővítse a feladatot az architektúra újraírására.

A befejezéshez bizonyíték is tartozzon

Kérjen átadási összefoglalót a végső működésről, a hatókör változásairól és az elvégzett ellenőrzésekről. Ahol számít, kérjen pontos parancsokat és eredményeket. Különböztesse meg a sikeres ellenőrzést attól, amelyet nem lehetett futtatni.

A pull request őrizze meg a módosítás okát. Egy későbbi karbantartó az eredeti beszélgetés nélkül láthatja a kódot. Adjon elég kontextust ahhoz, hogy megértse, miért zár ki az export bizonyos mezőket, és hogyan érvényesül a hozzáférés-szabályozás.

A Google változásleírási útmutatója hasznos támpont ehhez a dokumentáláshoz. A leírás magyarázza el a módosítást és annak célját. A review során végzett változtatások után igazítsa a dokumentációt a végső megvalósításhoz.

A leírás részletessége igazodjon a feladathoz

Kis szövegjavításhoz elég lehet rövid feladatleírás. Az adatexport több részletet igényel, mert hibái információt fedhetnek fel. Egy új fizetési munkafolyamat még több elemzést és review-t igényel.

A feladatleírás minőségét ne a hosszával mérje. Azt vizsgálja, hogy egy hozzáértő reviewer meg tudná-e különböztetni a helyes eredményt a hibástól. Ha két észszerű megvalósítás eltérne egy jelentős következményű működésben, először ezt tisztázza.