Programy rzadko zawodzą na końcu. Zawodzą w drugim tygodniu — gdy architekturę założono zamiast ją zbadać — i spędzają pozostałe miesiące na kosztownym odkrywaniu tego.
Trzy schematy porażek, które discovery by wychwyciło
Ograniczone czasowo discovery architektury jest korektą: krótkim, ustrukturyzowanym badaniem systemów, ograniczeń i założeń, od których program zależy, przeprowadzonym zanim zespół się rozrośnie. To najtańszy sprint, jaki program może wykonać — pod jednym warunkiem: że jest kontraktowo zobowiązany do wyprodukowania decyzji, nie dokumentów.
Schematy powtarzają się między organizacjami:
- Założenie nośne. Program planuje się wokół integracji, która okazuje się wyłącznie batchowa, z rate limitami albo kontraktowo zamknięta. Fakt był do odkrycia w jeden dzień; wyszedł na jaw w czwartym miesiącu, wbudowany w projekt zakładający coś przeciwnego.
- Ograniczenie odziedziczone. Nowa zdolność musi żyć w środowisku o stałych realiach operacyjnych — bazie, która nie udźwignie obciążenia, granicy bezpieczeństwa zakazującej planowanego przepływu danych. Nikt nie zbadał środowiska; wszyscy projektowali wersję greenfield.
- Decyzja niepodjęta. Dwa zespoły ruszyły z dwoma różnymi rozumieniami architektury, bo decyzja, od której oba zależały, nigdy nie zapadła jawnie. Oba były produktywne; program nie.
Każdy schemat ma ten sam kształt: pytanie tanie do odpowiedzi wcześnie i drogie do odpowiedzi późno.
Kiedy discovery jest konieczne — a kiedy jest zwlekaniem
Discovery zasługuje na swój time-box, gdy prawdziwe jest przynajmniej jedno: program zależy od systemów, których nikt w zespole nie otwierał; założenie techniczne, jeśli błędne, unieważniłoby plan; realnie otwartych jest kilka opcji architektonicznych, a wybór kształtuje budżet; albo ograniczenia środowiska są nieudokumentowane, a ludzie, którzy je znają, są trudno dostępni.
Discovery jest zwlekaniem — nie starannością — gdy na pytania już można odpowiedzieć, gdy służy odroczeniu decyzji, której ktoś nie chce podjąć, albo gdy proponuje się drugie discovery, bo odpowiedzi pierwszego się nie spodobały. Test: proszę nazwać pytanie, na które to discovery odpowiada. Jeśli nikt nie potrafi — należy budować.
Co badać
Discovery to badanie z listą celów, nie ogólny przegląd:
- Systemy, których dotyka plan — ich rzeczywiste interfejsy, jakość danych, przepustowość i zachowanie w awarii, z ich kodu i od ich operatorów, a nie z dokumentacji.
- Ograniczenia wyznaczające projekt — granice bezpieczeństwa, wymogi compliance, zdolność operacyjna, istniejące umowy, kompetencje zespołu.
- Zależności między decyzjami — które wybory są odwracalne, które wiążą program i w jakiej kolejności trzeba je podejmować.
- Założenie krytyczne — każdy program takie ma; pierwszym zadaniem discovery jest je nazwać i przetestować, spikiem, jeśli czytanie nie wystarcza.
Wyniki, które się liczą
Discovery jest skończone, gdy wyprodukowało cztery rzeczy: architecture decision records dla podjętych wyborów, z rozumowaniem, które je przesądziło; opcje docelowe z uczciwymi kosztami — zwykle dwie lub trzy, każda z wycenionym ryzykiem, zamiast jednej wypolerowanej rekomendacji; rejestr ryzyk z tego, co znaleziono, uporządkowany według kosztu pomyłki; oraz założenie krytyczne potwierdzone lub obalone, z dowodami.
Czym discovery się nie kończy: opisem stanu obecnego, choćby najdokładniejszym. Mapa istniejącego jest wejściem do decyzji, nie deliverable'em.
Antywzorzec: analiza jako wynik
Tryb porażki discovery jest dobrze znany — tygodnie stają się miesiącami, a wynikiem jest dziewięćdziesięciostronicowy dokument, który opisuje wszystko i nie decyduje o niczym. Dzieje się tak z przewidywalnego powodu: opisywanie jest bezpieczne, decydowanie jest wystawione na ocenę. Dokument można podziwiać; decyzja może być błędna.
Korekta jest strukturalna, nie motywacyjna: każdy wątek discovery nazywa się od decyzji, której służy. „Ocenić krajobraz integracji" zaprasza do geologii. „Zdecydować, czy przepływ zamówień może iść przez istniejący ESB" zaprasza do odpowiedzi.
Reguły time-boxu i checklista wyjścia
Reguły utrzymujące discovery w uczciwości: zwykle ograniczamy discovery do dwóch–czterech tygodni, przedłużając je wyłącznie tam, gdzie sama decyzja wymaga więcej dowodów — nigdy dryfem; obsada doświadczona i nieliczna; w połowie — read-out wstępnych odpowiedzi, który wcześnie ujawnia zwlekanie; a spotkanie decyzyjne zarezerwowane na ostatni dzień zanim discovery się zacznie, żeby termin miał publiczność.
Checklista wyjścia — discovery jest zamknięte, gdy: założenie krytyczne ma dowody w jedną albo drugą stronę · każda decyzja na ścieżce krytycznej ma ADR albo właściciela i datę · opcje niosą koszty, które sponsor może porównać · rejestr ryzyk nie zawstydzi nikogo za pół roku · a zespół budujący dalej umie powiedzieć na jednej stronie, co buduje najpierw i dlaczego.
Program, który tak startuje, spędza pierwszy sprint na budowaniu właściwej rzeczy. Alternatywa spędza czwarty miesiąc na odkrywaniu tego, co tydzień zerowy mógł jej powiedzieć.