Żywa mapa z doczepioną pamięcią.

Mapa: elementy i typowane zależności

Modeluj system w takiej skali szczegółu, w jakiej naprawdę myślisz – moduły, funkcjonalności, biblioteki, konfiguracje, środowiska testowe, nawet rytuały. Strukturę niosą dwie typowane relacje: has buduje drzewo, depends-on niesie ryzyko. Rozwiń drzewo, idź po krawędziach i zobacz zasięg rażenia – w dół i w górę – zanim zdecydujesz się na zmianę.

Uśpione zobowiązania – nazywamy je surtami

Przypnij zobowiązanie dokładnie do węzła, którego dotyczy, i daj mu zapalnik: gdy tamto zadanie się zamknie, gdy ruszy ta iteracja, gdy ktoś ponownie otworzy to, co naprawiłeś. Do tego czasu śpi – bez szumu, bez gnicia backlogu. Gdy zapalnik odpali, zobowiązanie budzi się i ląduje na pulpicie właściwej osoby.

→ trafiło do Marty · właścicielki Billingu

Własność, która odpowiada

Elementy mają właścicieli – ludzi i zespoły, z dziedziczeniem w dół struktury i jawnymi wyjątkami tam, gdzie rzeczywistość nie zgadza się z drzewem. Efektywni właściciele są zawsze widoczni – więc „kogo zapytać?” ma odpowiedź szybciej niż firmowy czat. Gdy zobowiązanie się budzi, to własność prowadzi je do człowieka.

Iteracje: pakiety pracy na elemencie

Zbierz zestaw zobowiązań na jednym elemencie w iterację i otwórz ją na żądanie – pakiet roboty nad tym kawałkiem systemu, z własnym cyklem życia. Architekci rozdają zobowiązania hurtowo kampaniami.

Zacznij od pliku. Utrzymuj ręcznie.

Twoje skrypty znają już sporą część mapy – wyeksportuj ją i zaimportuj tutaj. Import jest dwufazowy: raport na sucho pokazuje każdą zmianę i konflikt, zanim cokolwiek się zapisze, a cały przebieg można wycofać. Import tylko dokłada i aktualizuje – mapa nigdy nie traci wiedzy za twoimi plecami. Bezpośrednie integracje z gitem i CI są na roadmapie w planach.

Niepisana wiedza – czarno na białym

Opisy żyją na elementach i na krawędziach między nimi – bo połowa tej wiedzy dotyczy relacji, nie rzeczy. Wszystko przeszukiwalne z jednego omniboksa, który też tworzy: wpisz, potwierdź, gotowe.