Specyfikacja oceniona na 7 na 10 nie trafia do realizacji. W 18-osobowym zespole SAP, z którym pracuję, to właśnie tę zasadę zespół wskazuje jako zmianę, która pomogła najbardziej. W ciągu pięciu tygodni mediana czasu cyklu w fazie implementacji spadła z 19 dni do około 5,5.
Spec-driven development oznacza, że specyfikację piszesz, zanim napiszesz kod z AI, więc to ona staje się źródłem prawdy dla człowieka i dla AI. W SAP dodaję jedno: specyfikacja dostaje ocenę, a ocena decyduje, czy ktokolwiek dotyka ABAP.
Spodziewałbyś się, że zysk z AI siedzi w kodzie. Ten zespół mówi, że przyszedł krok wcześniej.
Wąskim gardłem było zadanie, nie ABAP
Zaczęliśmy od AI w raportowaniu i w ABAP. W Jira tego zespołu mediana czasu cyklu w fazie implementacji spadła o 71% w pięć tygodni. Na zgłoszeniach objętych SLA czas rozwiązania spadł o 49%, z 2,72 dnia do około 1,4.
Pracuję z tym zespołem jako fractional AI lead i nie umiem rozłożyć tych 71% na czynniki: bramka na specyfikacjach, skille (zapisane zestawy instrukcji dla AI), praca w parach i agent od incydentów ruszyły w tych samych tygodniach. Mam za to odpowiedź samego zespołu na pytanie, co pomogło najbardziej: „najbardziej pomógł spec-driven development, czyli to, że zespoły zaczęły tworzyć porządne specyfikacje”.
Kiedy zaczynaliśmy, przeciętna specyfikacja w tym zespole dostawała 3,3 na 10. Powód, dla którego to miało znaczenie, jest prosty. Programista ABAP z mglistym zadaniem wraca do konsultanta, czeka na odpowiedź, a resztę zgaduje. AI tego nie naprawia, tylko zgaduje szybciej.
Oceń każdą specyfikację. Poniżej 8 nie wchodzi do sprintu
Zespół zbudował na specyfikacjach ewaluator. To skill dla AI, który czyta zadanie z Jira i ocenia je w skali 10 punktów. Oto lista kryteriów, napisana pod obiekty SAP:
| # | Co specyfikacja musi zawierać | Punkty |
|---|---|---|
| 1 | Cel biznesowy i kto na tym korzysta | 1 |
| 2 | Nazwane obiekty SAP, których dotyczy zmiana: tabele, moduły funkcyjne, BAdI, interfejsy | 2 |
| 3 | Zachowanie obecne i docelowe | 1 |
| 4 | Kryteria akceptacji, które da się przetestować (given / when / then) | 2 |
| 5 | Dane testowe i przypadki brzegowe | 1 |
| 6 | Uprawnienia i dane osobowe | 1 |
| 7 | Zależności i skutki uboczne: interfejsy, zadania wsadowe, transporty | 1 |
| 8 | Co jest poza zakresem | 1 |
| Razem | 10 |
Lista kryteriów jest moja; ewaluator zbudowaliśmy na niej razem z zespołem. Kryteria akceptacji i obiekty, których dotyczy zmiana, mają po 2 punkty, bo właśnie te braki bolały najbardziej: specyfikacje nie miały testowalnych kryteriów akceptacji ani przypadków brzegowych, ani kontekstu o API i architekturze technicznej.
Próg stoi na 8, więc specyfikacja może stracić dwa punkty i dalej przejść. Jeśli straci więcej, wraca do autora z listą brakujących elementów. Słowami zespołu:
Jeśli specyfikacja ma ocenę niższą niż 8 na 10, zespół nie może pracować nad tym zadaniem.
Jedno zadanie, przed i po
Tak wygląda odrzucona specyfikacja. To przykład ilustracyjny, który wymyśliłem na potrzeby tego tekstu, a nie zadanie klienta: ta sama prośba, oceniona przed powrotem do autora i po nim.
| Kryterium | Przed | Po |
|---|---|---|
| Cel | „Zamówienia z blokadą kredytową nie mogą być dostarczane. Proszę naprawić” (1) | To samo, plus kto korzysta: finanse przestają uganiać się za zwróconymi dostawami (1) |
| Obecne i docelowe | Tylko docelowe (1) | Dziś nocny proces wsadowy dostarcza wszystko; cel: pomijać zablokowane zamówienia (1) |
| Obiekty | Żadnych (0) | Status kredytowy CMGST w nagłówku zlecenia sprzedaży VBAK, zadanie wsadowe ZSD_DELIVERY_BATCH, BAPI_OUTB_DELIVERY_CREATE_SLS (2) |
| Kryteria akceptacji | Brak (0) | Zamówienie z blokadą kredytową: gdy uruchamia się nocny proces wsadowy, dostawa nie powstaje, a zamówienie trafia na listę wyjątków (2) |
| Przypadki brzegowe | Brak (0) | Blokada zdjęta między selekcją a utworzeniem dostawy; zamówienia zwolnione częściowo (1) |
| Zależności | Brak (0) | Musi działać po nocnym procesie zwalniającym blokady kredytowe (1) |
| Poza zakresem | Nie podano (0) | Zmiany limitów kredytowych (1) |
| Ocena | 2/10 | 9/10 |
Uprawnień wciąż brakuje, dlatego to 9, a nie 10.
Najmocniejszy sprzeciw, jaki znalazłem, pochodzi od Birgitty Böckeler. Po przetestowaniu trzech narzędzi do spec-driven development na martinfowler.com napisała, że „wolałaby przeglądać kod niż te wszystkie pliki markdown” i że przy małych problemach cały proces wydał jej się przesadą. Przy poprawce na dwie linijki ma rację.
W SAP ten rachunek wygląda inaczej: skill daje ocenę, a konsultant czyta tylko brakujące punkty. Zapomniane uprawnienie albo zależność od transportu kosztuje więcej niż dziesięć linijek kryteriów.
Potem AI przyspieszyło ABAP
Kiedy specyfikacje były już dobre, część kodowa zaczęła się opłacać. Zespół stworzył skille „zdolne zajrzeć do bazy kodu, żeby znaleźć kontrakty i powiązane błędy”, więc AI pracuje na prawdziwym kodzie Z, a nie na fragmencie, który ktoś wkleił.
Drugim krokiem było jedno środowisko dla wszystkich. W praktyce: „stworzyliśmy zestaw skilli i instrukcję instalacji dla każdej osoby w zespole SAP, co pomaga nam szybciej wprowadzać kolejne osoby w AI”.
Dwa z tych skilli robią większość roboty. Ewaluator specyfikacji ocenia zadanie z Jira według powyższych kryteriów i wypisuje brakujące punkty. Wyszukiwarka kontraktów przeszukuje kod zespołu w poszukiwaniu kontraktów i powiązanych błędów stojących za zadaniem.
Razem działają jako plugin. Swój zestaw skilli dla SAP trzymam w prywatnym repozytorium; jeśli chcesz porównać go ze swoim, poproś mnie o dostęp.
Agent od incydentów powstał w 3 godziny
Ten sam ruch zadziałał po stronie wsparcia: wiedza, która siedziała w jednej głowie, stała się spisanymi regułami. Wąskim gardłem była tam ręczna kategoryzacja incydentów.
„Wcześniej wszystko zależało od wiedzy jednej osoby, a tę wiedzę zamieniliśmy w agenta, który potrafi poprawnie kategoryzować zgłoszenia”. Agent, który zastąpił tę ręczną pracę, powstał w 3 godziny.
Nie jest idealny. Osoba ze wsparcia wciąż kategoryzuje ręcznie 20% zgłoszeń, tych, przy których agent ma niską pewność. „Nie jesteśmy jeszcze na etapie automatycznego naprawiania, ale to nadchodzi”.
Połącz w parę początkującego z kimś, kto żyje AI
Skille rozeszły się dzięki jednej zasadzie.
„Zasada jest taka, że pracujemy w parach. Osoba, która nie czuje się mocno w AI, dostaje buddy’ego, kogoś, kto jest w AI już daleko, i siedzą razem. Razem popychają rzeczy do przodu. Dzięki temu wiedza rozchodzi się bardzo szybko”.
Praca w parach pokazuje też, kto nie chce ruszyć z miejsca. O tej części napisałem w tekście o tym, jak opór wobec AI dzieli Twój zespół.
Albo zrób to z całym zespołem w jeden dzień
CIO 50-osobowego zespołu IT poprosił mnie, żebym pokazał to wszystkim w jeden dzień: pół SAP, pół infrastruktura IT i helpdesk. Ich IT nie podłączy AI do SAP i to w porządku, bo specyfikacja nie potrzebuje dostępu do SAP, a dane z Jira też nie.
Dzień zaczyna się od 75 minut budowania na żywo i od przypadku opisanego wyżej. Potem programiści ABAP pracują na jednym wspólnym środowisku i na kawałku starego kodu Z, a konsultanci, helpdesk i infrastruktura oceniają sześć miesięcy własnych specyfikacji z Jira i prowadzą jeden incydent od logu do propozycji poprawki. Dzień kończy się 3 uzgodnionymi metrykami: mediana czasu cyklu w fazie implementacji, udział specyfikacji z oceną 8 lub wyżej i realizacja sprintu względem planu.
Zacznij w poniedziałek, nie dotykając SAP
Nic z tego nie wymaga AI podłączonego do Twojego systemu SAP. Wymaga Twoich danych z Jira.
Najpierw zmierz medianę
Wybierz w Jira dwa statusy, między którymi zaczynają się i kończą prace programistyczne, i trzymaj się ich. Weź ostatnie 6 miesięcy i zapisz medianę czasu między nimi.
To jest ten czas cyklu w fazie implementacji z początku tego tekstu. Bez liczby „przed” liczba „po” jest tylko deklaracją. Jeśli chcesz, żeby na Twoje dane o dowożeniu spojrzała druga para oczu, od tego jest audyt produktywności zespołu.
Oceń 20 starych specyfikacji
Przepuść powyższe kryteria przez 20 specyfikacji z zeszłego kwartału. Policz, ile dochodzi do 8. Ten udział to Twoja linia startu i nie przeraź się: zespół z tego tekstu startował ze średniej 3,3.
Zamknij bramkę
Od następnego sprintu specyfikacja poniżej 8 wraca do autora z listą brakujących punktów.
Jedno środowisko dla każdego programisty ABAP
To samo IDE, te same skille, jedna instrukcja instalacji i buddy dla każdego, kto dopiero zaczyna z AI.
Które z Twoich ostatnich 20 specyfikacji przeszłyby 8 na 10? Jeśli chcesz to sprawdzić z własnym zespołem w jeden dzień, od tego jest warsztat AI dla zespołów SAP.
[Czas pisania: 5 h]
