Zadání se 7 body z 10 do vývoje nejde. V osmnáctičlenném SAP týmu, se kterým pracuju, označuje tým právě tohle pravidlo za změnu, která pomohla nejvíc. Za pět týdnů klesl medián doby průchodu ve fázi implementace z 19 dní na zhruba 5,5.
Spec-driven development znamená napsat zadání dřív, než se s AI napíše kód, takže zadání je zdrojem pravdy pro člověka i pro AI. V SAP přidávám jednu věc: zadání dostane známku a ta známka rozhodne, jestli se někdo dotkne ABAPu.
Čekal bys, že AI vyhraje v kódu. Tenhle tým říká, že vyhrála o krok dřív.
Úzkým hrdlem byl tiket, ne ABAP
Začali jsme s AI v reportingu a v ABAPu. V Jira toho týmu klesl medián doby průchodu ve fázi implementace za pět týdnů o 71 %. U SLA tiketů klesla doba řešení o 49 %, z 2,72 dne na zhruba 1,4.
S týmem pracuju jako fractional AI lead a těch 71 % neumím čistě rozdělit: brána na zadání, skills, párování i agent na incidenty se rozjely ve stejných týdnech. Mám jen vlastní odpověď týmu na otázku, co pomohlo nejvíc: „nejvíc pomohl spec-driven development, tedy že týmy začaly psát pořádná zadání.“
Když jsme začínali, průměrné zadání v tom týmu mělo 3,3 z 10. Důvod je jednoduchý. ABAP vývojář s mlhavým tiketem jde zpátky za konzultantem, čeká na odpověď a zbytek si domyslí. AI to neopraví, jen domýšlí rychleji.
Oboduj každé zadání. Pod 8 nejde do sprintu
Tým si nad zadáními postavil evaluátor. Je to AI skill, který přečte tiket v Jira a oboduje ho na škále 10 bodů. Tohle je ta tabulka, napsaná pro SAP objekty:
| # | Co zadání musí obsahovat | Body |
|---|---|---|
| 1 | Byznysový cíl a komu to pomůže | 1 |
| 2 | Pojmenované dotčené SAP objekty: tabulky, function moduly, BAdI, rozhraní | 2 |
| 3 | Současný a cílový stav | 1 |
| 4 | Akceptační kritéria, která jde otestovat (given / when / then) | 2 |
| 5 | Testovací data a hraniční případy | 1 |
| 6 | Oprávnění a osobní údaje | 1 |
| 7 | Závislosti a vedlejší dopady: rozhraní, batch joby, transporty | 1 |
| 8 | Co je mimo rozsah | 1 |
| Celkem | 10 |
Kritéria jsou moje; evaluátor nad nimi jsme postavili s týmem společně. Akceptační kritéria a dotčené objekty mají po 2 bodech, protože právě tam to bolelo: zadání neměla testovatelná akceptační kritéria ani hraniční případy a chyběl kontext k API a technické architektuře.
Laťka je na 8, takže zadání může dva body ztratit a stejně projde. Chybí-li bodů víc, zadání se vrací autorovi se seznamem toho, co chybí. Slovy týmu:
Když má zadání hodnocení nižší než 8 z 10, tým na tom tiketu nesmí pracovat.
Jeden tiket, před a po
Takhle vypadá vrácené zadání. Je to ilustrační příklad, který jsem pro tenhle článek vymyslel, ne tiket klienta: stejný požadavek, obodovaný předtím a potom, co se vrátil autorovi.
| Kritérium | Před | Po |
|---|---|---|
| Cíl | „Objednávky s blokací kreditu se nesmí expedovat. Prosím opravit.“ (1) | Totéž plus komu to pomůže: finance přestanou řešit vrácené dodávky (1) |
| Současný a cílový stav | Jen cílový stav (1) | Dnes noční job expeduje všechno; cíl: blokované objednávky přeskočit (1) |
| Objekty | Nic nepojmenováno (0) | Kreditní status CMGST na hlavičce zakázky VBAK, job ZSD_DELIVERY_BATCH, BAPI_OUTB_DELIVERY_CREATE_SLS (2) |
| Akceptační kritéria | Žádná (0) | Když je objednávka blokovaná kreditem a proběhne noční job, nevznikne žádná dodávka a objednávka skončí na seznamu výjimek (2) |
| Hraniční případy | Žádné (0) | Kredit uvolněný mezi výběrem a založením dodávky; částečně uvolněné objednávky (1) |
| Závislosti | Žádné (0) | Musí běžet až po nočním jobu na uvolnění kreditu (1) |
| Mimo rozsah | Neuvedeno (0) | Změny kreditního limitu (1) |
| Body | 2/10 | 9/10 |
Oprávnění pořád chybí, proto 9 a ne 10.
Nejsilnější námitku jsem našel u Birgitty Böckeler. Po otestování tří spec-driven nástrojů na martinfowler.com napsala, že „radši bude dělat review kódu než všech těch markdown souborů“ a že jí celý postup u malých problémů přišel jako kanón na vrabce. Překlad je můj. U dvouřádkové opravy má pravdu.
V SAP vychází ta úvaha jinak: body spočítá skill a konzultant čte jen to, co chybí. Zapomenuté oprávnění nebo závislost na transportu stojí víc než deset řádků kritérií.
Pak AI zrychlila ABAP
Jakmile byla zadání dobrá, začala se vyplácet i část s kódem. Tým vytvořil skills, „které se umí podívat do kódu a najít kontrakty a související chyby“, takže AI pracuje se skutečným Z-kódem, ne s úryvkem, který někdo vložil do chatu.
Druhým krokem bylo jedno nastavení pro všechny. V praxi: „vytvořili jsme sadu skills a instalační návod pro každého jednoho člověka v SAP týmu, což nám pomáhá dostat ostatní rychleji do AI.“
Dvě z těch skills nesou většinu práce. Evaluátor zadání oboduje tiket v Jira podle tabulky výš a vypíše chybějící body. Vyhledávač kontraktů projde kód týmu a najde kontrakty a související chyby za tiketem.
Dohromady fungují jako plugin. Svoji sadu SAP skills držím v soukromém repu; jestli si ji chceš porovnat se svou, napiš si o přístup.
Agent na incidenty vznikl za 3 hodiny
Stejný postup zabral i u supportu: znalost, která seděla v jedné hlavě, se stala psanými pravidly. Úzkým hrdlem tam byla ruční kategorizace incidentů.
„Předtím to stálo jen na znalostech jednoho jediného člověka a tu znalost jsme přetavili do agenta, který umí správně kategorizovat.“ Agent, který tu ruční práci převzal, vznikl za 3 hodiny.
Dokonalý není. Člověk v supportu pořád kategorizuje 20 % tiketů ručně, ty, u kterých si agent není jistý. „S nějakým automatickým opravováním ještě nejsme, ale přijde to.“
Spáruj začátečníka s tím, kdo AI žije
Skills se rozšířily díky jednomu pravidlu.
„Pravidlo je, že párujeme. Člověk, který v AI není moc zběhlý, dostane parťáka, který je v AI hodně napřed, a sednou si spolu. Posouvají věci dopředu společně. Takže se znalost šíří hodně rychle.“
Párování taky ukáže, kdo se hnout nechce. O téhle části jsem psal v článku jak odpor k AI roztřídí tvůj tým.
Nebo to s celým týmem zvládni za jeden den
CIO padesátičlenného IT týmu mě požádal, abych to za jeden den přinesl všem: půlka SAP, půlka IT infrastruktura a helpdesk. Jejich IT oddělení AI do SAP nepustí, a to je v pořádku, protože zadání přístup do SAP nepotřebuje a data z Jira taky ne.
Den začíná 75minutovým živým stavěním a případem z tohoto článku. Pak ABAP vývojáři pracují na jednom společném nastavení a kusu starého Z-kódu, zatímco konzultanti, helpdesk a infrastruktura bodují šest měsíců vlastních zadání z Jira a vystopují jeden incident od logu k navržené opravě. Den končí 3 domluvenými metrikami: medián doby průchodu ve fázi implementace, podíl zadání na 8 a víc a plnění sprintu oproti plánu.
Začni v pondělí a na SAP nesahej
Nic z toho nepotřebuje AI napojenou do tvého SAP systému. Potřebuje to tvoji Jira.
Nejdřív změř medián
Vyber dva stavy v Jira, kde vývoj začíná a končí, a drž je pevně. Vezmi posledních 6 měsíců a zapiš si medián času mezi nimi.
To je ta doba průchodu ve fázi implementace ze začátku článku. Bez čísla „před“ je číslo „po“ jen tvrzení. Jestli chceš na data o delivery druhý pár očí, přesně od toho je audit produktivity týmu.
Oboduj 20 starých zadání
Projdi podle tabulky výše 20 zadání z minulého kvartálu. Spočítej, kolik jich dosáhne na 8. Ten podíl je tvoje startovní čára, a nelekni se: tým z tohoto článku začínal na průměru 3,3.
Zavři bránu
Od příštího sprintu se zadání pod 8 vrací autorovi s chybějícími body.
Jedno nastavení pro každého ABAP vývojáře
Stejné IDE, stejné skills, jeden instalační návod a parťák pro každého, kdo s AI začíná.
Které z tvých posledních 20 zadání by prošlo na 8 z 10? Jestli to chceš zjistit s vlastním týmem za jeden den, od toho je AI workshop pro SAP týmy.
[Čas psaní: 5 h]
