Jeśli specyfikacja jest źródłem prawdy, potrzebuje cyklu życia

Zespół przechodzi na rozwój sterowany specyfikacją i przez pierwsze tygodnie wszystko działa tak, jak to opisano. Specyfikacje powstają i są recenzowane, agenci implementują według nich, kryteria akceptacji zamieniają się w testy. Specyfikacje są dobre, bo wszyscy jeszcze na nie uważają.

Potem defekt na produkcji zostaje naprawiony prosto w kodzie, bo jest druga w nocy. Drobna zmiana zachowania, uzgodniona w wątku na czacie, trafia do agenta jako jednozdaniowe polecenie. Recenzent proponuje w diffie lepsze rozwiązanie i zostaje ono wprowadzone tam. Każda z tych decyzji jest rozsądna. Trzy miesiące później specyfikacja mówi jedno, system robi drugie, a gdy agent następnym razem odtwarza moduł ze specyfikacji, po cichu przywraca stare zachowanie.

Bycie źródłem prawdy nie jest cechą dokumentu. To reguła mówiąca, w którą stronę płyną zmiany.

Dlaczego specyfikacje psują się szybciej niż kod

Kod ma kompilator, testy i produkcję, a wszystkie trzy protestują, gdy coś jest nie tak. Specyfikacja ma tylko czytelników i gdy zostaje w tyle, nic się nie wywraca.

Każdy skrót biegnie też od strony kodu. Poprawka awaryjna, drobna korekta, ulepszenie wypatrzone w przeglądzie: wszystkie dotykają kodu i zostawiają specyfikację „na potem”, a potem nie nadchodzi.

Agenci sprawiają, że ta rozbieżność kosztuje więcej niż kiedyś. W kodzie pisanym ręcznie nieaktualny dokument tylko wprowadza w błąd i ludzie uczą się go ignorować. W kodzie sterowanym specyfikacją nieaktualny dokument jest poleceniem. Agent czyta go dosłownie i wiernie wykonuje — łącznie z fragmentami, które od tamtej pory celowo zmieniono.

Reguła, która utrzymuje ją w prawdzie

Zmiany płyną od specyfikacji do kodu, nigdy odwrotnie. Dotyczy to także poprawek awaryjnych: pod presją kod może pójść pierwszy, ale zmiana w specyfikacji idzie za nim tego samego dnia, a incydent nie jest zamknięty, dopóki jej nie ma.

Dla przeglądu konsekwencja jest konkretna. Pull request, który zmienia zachowanie, a nie zmienia specyfikacji, jest niekompletny — tak samo jak zmiana bez testów. Recenzent może upomnieć się o brakującą część, a z czasem może to sprawdzać potok.

Cała reszta to mechanizmy, dzięki którym przestrzeganie tej reguły jest na tyle tanie, że ludzie naprawdę jej przestrzegają.

Infografika

Cykl życia specyfikacji

1. 01Zmiana specyfikacjiKażda zmiana zachowania zaczyna się od edycji specyfikacji.
2. 02Przegląd intencjiDecyzja zapada na specyfikacji, a nie na kodzie.
3. 03Testy z kryteriówKryteria akceptacji stają się testami, zanim cokolwiek zostanie wygenerowane.
4. 04Generowanie i weryfikacjaAgenci implementują, potok sprawdza wynik względem testów.
5. 05Droga powrotnaPoprawki awaryjne i incydenty wracają do specyfikacji tego samego dnia.

Z czego składa się cykl życia

Specyfikacja leży obok kodu. To samo repozytorium, ten sam pull request. Zmianę w specyfikacji i kod, który z niej wynika, recenzuje się razem, więc intencję i implementację czyta się w jednym miejscu.

Powiązanie w obie strony. Każde kryterium akceptacji ma swój test, a każdy test swoje kryterium. Test bez kryterium to zwykle zachowanie, o którym nikt nie zdecydował. Kryterium bez testu to obietnica, której nic nie sprawdza.

Każda specyfikacja ma właściciela. Nie tego, kto ją napisał, tylko tego, kto decyduje, kiedy się zmienia — zwykle tę samą osobę, która odpowiada za dany obszar kodu.

Sekcja „poza zakresem” zostaje na miejscu. Ludzie usuwają ją najpierw, a to właśnie ona powstrzymuje agenta przed usłużnym dodawaniem rzeczy, o które nikt nie prosił.

Wycofanie jest jawne. Gdy znika funkcja, jej specyfikacja znika w tej samej zmianie. Martwa specyfikacja jest gorsza niż żadna, bo agent, który ją przeczyta, znajdzie instrukcje do czegoś, czego już nie ma.

Test, który możecie zrobić w tym tygodniu

Weźcie moduł zbudowany ze specyfikacji. Na osobnej gałęzi niech agent odtworzy go wyłącznie z aktualnej specyfikacji, a potem uruchomcie na wyniku istniejące testy.

Jeśli przechodzą i moduł zachowuje się tak samo, specyfikacja nadal jest źródłem prawdy. Jeśli nie, różnice są listą decyzji, które zapadły w kodzie i nigdy nie zostały zapisane. A jeśli zespół nie chce nawet spróbować — to też jest odpowiedź.

Powtarzajcie ten test co kilka miesięcy. Jest tani i jako jedyny sprawdza samą specyfikację, a nie kod, który z niej zbudowano.

Dyscyplina, nie narzędzie

Nic z tego nie wymaga nowego narzędzia. Wymaga jednej reguły, stosowanej także wtedy, gdy jest niewygodna, i kilku nawyków, dzięki którym jej stosowanie jest tanie.

To również ta część metody, którą najłatwiej pominąć, bo koszt pominięcia przychodzi po miesiącach i w cudzej zmianie. W rozwoju sterowanym specyfikacją warto ustalić od początku nie tylko to, jak się specyfikację pisze, ale też to, jak się ją zmienia — bo specyfikacja napisana raz i nigdy więcej nieruszana jest po prostu lepszym zgłoszeniem.