ADR
Sprawdź: Zapis decyzji architektonicznej
Książka / słownik
Engineering
Excellence
Praktyczny słownik pojęć, praktyk i wzorców związanych z tworzeniem dobrego oprogramowania.
Książka w przygotowaniuEngineering Excellence
Słownik pojęć
Wyszukuj po nazwie, skrócie, definicji lub tagach.
AI
Sprawdź: Sztuczna inteligencja
Alarm / OstrzeżenieAlert
Sygnał wskazujący, że określony warunek wymaga uwagi lub działania. Dobry alarm powinien prowadzić do konkretnej reakcji, a nie tylko zwiększać liczbę powiadomień.
Analiza po incydenciePost-mortem
Ustrukturyzowana analiza incydentu lub niepowodzenia, której celem jest zrozumienie przyczyn i poprawa systemu, a nie znalezienie winnego.
AntywzorzecAnti-pattern
Powtarzalny sposób działania, który wygląda rozsądnie lub profesjonalnie, ale w praktyce prowadzi do niepożądanych skutków.
API
Sprawdź: Interfejs programistyczny aplikacji
ArtefaktArtifact
Wytworzony i identyfikowalny rezultat procesu budowania oprogramowania, np. paczka aplikacji, obraz kontenera lub plik binarny. Ten sam zweryfikowany artefakt powinien w miarę możliwości przechodzić przez kolejne środowiska.
Backlog usprawnieńImprovement Backlog
Widoczny zbiór kandydatów do zmian sposobu pracy. Powinien być priorytetyzowany i ograniczany tak jak inna praca, zamiast rosnąć jako lista wszystkich pomysłów z retrospektyw.
Bariera ochronnaGuardrail
Wcześniej uzgodniony warunek, ograniczenie lub próg, który ma zatrzymać zwiększanie ryzyka albo uruchomić reakcję, gdy sytuacja wychodzi poza bezpieczny zakres.
BezpieczeństwoSecurity
Ochrona systemu, danych i użytkowników przed nieuprawnionym dostępem, nadużyciem, utratą integralności i innymi zagrożeniami.
Bezpieczeństwo psychologicznePsychological safety
Warunek współpracy, w którym ludzie mogą ujawniać problemy, zadawać pytania, przyznawać się do niewiedzy i zgłaszać ryzyko bez obawy przed karą za sam fakt zabrania głosu.
Bezpieczny cykl życia wytwarzania oprogramowaniaSecure Software Development Life Cycle
SDLC z bezpieczeństwem włączonym od początku: wymaganiami, projektowaniem, kontrolami, testami i reakcją na podatności.
BlokadaBlocker
Stan, w którym praca nie może sensownie posuwać się dalej bez usunięcia konkretnej przeszkody, decyzji lub zależności.
Błąd / DefektBug
Niezgodność rzeczywistego zachowania systemu z oczekiwanym. Może dotyczyć kodu, konfiguracji, danych, integracji lub innego elementu rozwiązania.
Bramka jakościowaQuality gate
Automatyczny lub ręczny warunek, którego niespełnienie może zatrzymać dalszy przepływ zmiany. Powinna opierać się na wiarygodnym sygnale jakości, a nie na samej obecności ceremonii.
Budowa i weryfikacjaBuild & Verify
Etap drogi Zmiany, w którym rozwiązanie jest tworzone, integrowane i sprawdzane tak, aby można było mu zaufać przed wdrożeniem.
Budżet błędówError budget
Akceptowalny margines niespełnienia celu niezawodności wynikający z SLO. Może służyć jako jawna reguła równoważąca tempo zmian i potrzebę poprawy stabilności.
BuforBuffer
Świadomie pozostawiona przestrzeń na zmienność, pracę nieplanowaną lub niepewność. Nie jest wolnym czasem, lecz ochroną planu przed założeniem, że rzeczywistość zawsze przebiegnie zgodnie z kalkulacją.
B2B
Sprawdź: Relacje firma–firma
CAB
Sprawdź: Komitet doradczy ds. zmian
CD
Sprawdź: Ciągłe dostarczanie
Cel docelowy / Wartość oczekiwanaTarget
Pożądany wynik lub data, do której chcielibyśmy dojść. Target wyznacza kierunek, ale sam nie jest prognozą prawdopodobieństwa ani zobowiązaniem.
Cel poziomu usługiService Level Objective
Oczekiwany poziom wybranego SLI w określonym czasie. Powinien opisywać poziom jakości istotny dla użytkownika i wpływać na decyzje.
Cel SprintuSprint Goal
Jeden spójny cel nadający kierunek pracy w Sprincie. Jest ważniejszy niż traktowanie listy zadań jak niezmiennego kontraktu.
CI
Sprawdź: Ciągła integracja
Ciągła integracjaContinuous Integration
Praktyka częstego integrowania niewielkich zmian z automatyczną weryfikacją, która szybko ujawnia problemy.
Ciągła integracja i ciągłe dostarczanie / WdrażanieContinuous Integration
Zestaw praktyk i automatyzacji służących budowaniu, testowaniu, przygotowywaniu oraz dostarczaniu zmian. Skrót CD bywa rozwijany jako Continuous Delivery lub Continuous Deployment, zależnie od sposobu pracy.
Ciągłe doskonalenieContinuous improvement
Stała zdolność zespołu do obserwowania systemu pracy, formułowania hipotez, eksperymentowania i sprawdzania efektu. Nie jest synonimem samej retrospektywy ani ciągłego dokładania nowych praktyk.
Ciągłe dostarczanieContinuous Delivery
Podejście, w którym oprogramowanie jest stale utrzymywane w stanie pozwalającym na bezpieczne i powtarzalne wydanie.
Ciągłe wdrażanieContinuous Deployment
Model, w którym poprawnie zweryfikowane zmiany mogą automatycznie trafiać na produkcję bez osobnej ręcznej decyzji wdrożeniowej.
Ciągły przepływContinuous flow
Model pracy, w którym kolejne rzeczy są podejmowane i kończone w miarę dostępnej capacity, bez konieczności grupowania ich w sprinty. Może nadal korzystać z regularnego rytmu planowania i przeglądów.
Codzienny przegląd przepływuDaily
Krótka synchronizacja służąca adaptacji planu i przepływu na dziś. Nie jest odprawą statusową dla managera; jej celem jest pomoc w kończeniu rozpoczętej pracy i usuwaniu blokad.
Cofnięcie wdrożeniaRollback
Przywrócenie poprzedniego stanu po problematycznej zmianie. Nie zawsze jest możliwe lub wystarczające, szczególnie przy nieodwracalnych migracjach danych.
Confluence
Narzędzie firmy Atlassian do tworzenia i współdzielenia dokumentacji, stron wiedzy i materiałów zespołowych.
Cykl życia wytwarzania oprogramowaniaSoftware Development Life Cycle
Całość etapów związanych z powstawaniem, rozwijaniem, wdrażaniem i utrzymaniem oprogramowania.
Czas do decyzjiDecision lead time
Czas od chwili, gdy decyzja staje się potrzebna, do momentu jej podjęcia. Długi czas decyzji może tworzyć kolejkę równie kosztowną jak oczekiwanie na review, testy czy środowisko.
Czas na skupioną pracęFocus time
Chroniony fragment dnia przeznaczony na pracę wymagającą koncentracji i dłuższego utrzymania kontekstu. Jego wartość maleje, gdy dzień jest rozcinany wieloma krótkimi spotkaniami i przerwaniami.
Czas odzyskania sprawności po nieudanym wdrożeniuFailed Deployment Recovery Time
Metryka DORA mierząca, jak szybko system wraca do normalnego działania po nieudanej zmianie produkcyjnej.
Czas od uzgodnionego wejścia do dostarczeniaLead Time
Szerszy czas przepływu od zdefiniowanego punktu rozpoczęcia procesu do dostarczenia. Punkt startowy musi być jawnie ustalony, np. od przyjęcia potrzeby lub od gotowości do realizacji.
Czas realizacji aktywnej pracyCycle Time
Czas od uzgodnionego momentu rozpoczęcia aktywnej realizacji do jej zakończenia. Granice pomiaru muszą być zdefiniowane, aby wyniki były porównywalne.
Czas technicznego przepływu zmianyChange Lead Time
Czas od zatwierdzenia zmiany w kodzie do jej skutecznego uruchomienia na produkcji.
Częstotliwość wdrożeńDeployment Frequency
Częstotliwość, z jaką organizacja skutecznie wdraża zmiany na środowisko produkcyjne.
Część interfejsowa aplikacjiFrontend
Część systemu bezpośrednio prezentowana użytkownikowi, np. interfejs webowy lub mobilny.
Część serwerowaBackend
Część systemu realizująca logikę, dostęp do danych, integracje i usługi niewidoczne bezpośrednio dla użytkownika.
DACI
Model porządkowania większych decyzji: Driver prowadzi temat, Approver ma finalne prawo decyzji, Contributors dostarczają wkład, a Informed otrzymują informację. Powinien usuwać niejasność, a nie być obowiązkową macierzą dla każdej decyzji.
Definicja gotowościDefinition of Ready
Umowa zespołu opisująca minimalne warunki, przy których praca jest wystarczająco zrozumiała, mała i bezpieczna do rozpoczęcia. Nie jest formalnym elementem Scrum Guide.
Definicja przepływu pracyDefinition of Workflow
Jawny opis sposobu, w jaki praca przechodzi przez system: gdzie zaczyna się i kończy, jakie ma stany oraz jakie polityki sterują wyborem, WIP, blokadami i obsługą pracy.
Definicja ukończeniaDefinition of Done
Wspólny, jednoznaczny zestaw warunków określających, kiedy element pracy można uznać za rzeczywiście ukończony.
DevOps z bezpieczeństwem włączonym w cały cyklDevSecOps
Podejście, w którym bezpieczeństwo jest częścią projektowania, budowy, testowania, wdrażania i eksploatacji, a nie osobną kontrolą na końcu.
Dług doskonaleniaImprovement debt
Narastający koszt odkładania znanych usprawnień systemu pracy. Powstaje, gdy problemy są wielokrotnie rozpoznawane, ale organizacja nie przeznacza capacity na ich rozwiązanie.
Dług spotkaniowyMeeting debt
Narastający koszt spotkań, które pozostały w kalendarzu mimo utraty celu, dublowania innych kanałów lub zmiany sposobu pracy. Wymaga okresowego przeglądu i świadomego usuwania zbędnych rytuałów.
Dług technologicznyTechnical debt
Przyszły koszt wynikający z wcześniejszych decyzji technicznych, które przyspieszyły dostarczenie rozwiązania kosztem jego dalszej zmienialności.
Docker
Popularna platforma i zestaw narzędzi do budowania, uruchamiania i dystrybucji kontenerów.
DoD
Sprawdź: Definicja ukończenia
Dojrzałość inżynierskaEngineering Excellence
Zdolność organizacji do systematycznego dostarczania wartości poprzez dobre praktyki techniczne, świadome decyzje i ciągłe uczenie się.
DoprecyzowanieRefinement
Praca polegająca na uzupełnianiu i uzgadnianiu informacji potrzebnych do sensownego rozpoczęcia realizacji. Nie musi być osobnym cyklicznym spotkaniem.
Doprecyzuj / Przygotuj do rozpoczęciaDefine
Branżowa etykieta etapu Przygotowania, w którym zespół doprowadza zakres i warunki pracy do poziomu wystarczającego do odpowiedzialnego startu.
DoR
Sprawdź: Definicja gotowości
DORADevOps Research and Assessment
Program badawczy i zestaw praktyk oraz metryk używanych do oceny technicznej zdolności organizacji do dostarczania zmian. W książce wykorzystywany jest model pięciu metryk wydajności dostarczania.
Dostarczanie oprogramowaniaSoftware Delivery
Cały system prowadzący od potrzeby lub problemu do działającego rozwiązania na produkcji i informacji o jego efekcie, a nie tylko samo programowanie czy wdrożenie.
Dostępność zespołuTeam capacity
Realna możliwość podjęcia pracy po uwzględnieniu pracy już rozpoczętej, utrzymania, nieobecności, pracy nieplanowanej i ograniczeń kompetencyjnych.
Doświadczenie użytkownikaUser Experience
Całość doświadczeń użytkownika podczas korzystania z produktu lub usługi, w tym zrozumiałość, wygoda, skuteczność i odczuwana jakość.
Dowód koncepcjiProof of Concept
Minimalny eksperyment sprawdzający, czy krytyczna koncepcja jest wykonalna. Kod z PoC nie jest automatycznie kodem produkcyjnym.
Dowód / Podstawa decyzjiEvidence
Informacja, obserwacja lub wynik, który wzmacnia albo osłabia hipotezę i może zmienić decyzję. W książce evidence jest przeciwieństwem opierania się wyłącznie na przekonaniu lub rytuale.
DRI
Sprawdź: Osoba bezpośrednio odpowiedzialna
Działanie do wykonaniaAction item
Konkretny następny krok wynikający ze spotkania, retrospektywy, analizy lub eksperymentu. Powinien mieć właściciela oraz termin lub sposób sprawdzenia efektu.
Dziennik zdarzeńLog
Zapis zdarzeń i informacji emitowanych przez aplikację lub infrastrukturę. Logi pomagają odtwarzać przebieg działania i diagnozować problemy.
Efekt / RezultatOutcome
Zmiana w zachowaniu użytkownika, wyniku biznesowym, ryzyku lub działaniu systemu, którą chcemy osiągnąć. Outcome odpowiada na pytanie „co ma się zmienić?”, a nie tylko „co zbudujemy?”.
EmpiryzmEmpiricism
Podejście oparte na przejrzystości, inspekcji i adaptacji: podejmujemy decyzje na podstawie tego, co obserwujemy, i zmieniamy sposób działania, gdy pojawiają się nowe informacje.
EskalacjaEscalation
Przekazanie problemu lub decyzji na poziom, który ma odpowiednie uprawnienia, zasoby lub możliwość usunięcia przeszkody. Dobra eskalacja zawiera konkretne pytanie lub potrzebę decyzji.
Estymacja względnaRelative sizing
Ocena rozmiaru pracy przez porównanie z innymi znanymi elementami zamiast bezpośredniego przypisywania godzin. Pomaga ujawniać różnice w rozumieniu, ale nadal pozostaje przybliżeniem.
EstymataEstimate
Przybliżona ocena wielkości, złożoności lub wysiłku. Nie jest automatycznie datą ani zobowiązaniem.
E2E
Sprawdź: Od początku do końca / Całościowo
FaktFact
Informacja, którą można poprzeć wiarygodnym źródłem lub obserwacją. W Rozpoznaniu fakty są oddzielane od założeń i hipotez.
Feature toggle
Sprawdź: Flaga funkcjonalności
Flaga funkcjonalnościFeature flag
Mechanizm pozwalający oddzielić wdrożenie kodu od udostępnienia funkcji. Umożliwia włączanie, wyłączanie lub ograniczanie funkcji bez ponownego wdrażania kodu.
Framework zwinnego wytwarzania produktuScrum
Lekki framework organizowania pracy nad złożonym produktem, oparty m.in. na Sprintach, jasno określonych odpowiedzialnościach, wydarzeniach i artefaktach.
Gałąź koduBranch
Oddzielna linia rozwoju w systemie kontroli wersji. Pozwala pracować nad zmianą bez natychmiastowego modyfikowania głównej gałęzi.
Git
Rozproszony system kontroli wersji używany do śledzenia zmian w kodzie i pracy na gałęziach.
GitLab
Platforma do zarządzania repozytoriami, przeglądami kodu, CI/CD i innymi elementami cyklu wytwarzania. W książce występuje również jako źródło publicznych praktyk organizacyjnych.
Główna gałąź koduMain branch
Wspólna, główna linia kodu, do której integrowane są zmiany. Powinna pozostawać w stanie możliwie wiarygodnym i budowalnym.
Gotowe do rozpoczęciaReady
Określenie sugerujące, że praca ma wystarczający poziom zrozumienia i przygotowania do rozpoczęcia. Sam status „Ready” nie jest dowodem rzeczywistej gotowości.
HipotezaHypothesis
Sprawdzalne przypuszczenie łączące planowaną zmianę z oczekiwanym efektem, np. „jeśli uprościmy proces, spadnie liczba kontaktów do obsługi”.
IncydentIncident
Nieplanowane zdarzenie zakłócające działanie usługi, obniżające jej jakość albo stwarzające istotne ryzyko operacyjne.
Informacja zwrotnaFeedback
Informacja o wyniku działania, zmiany lub decyzji, która pozwala skorygować dalsze postępowanie. Im szybciej wraca, tym tańsza jest zmiana kierunku.
Informacje o wydaniuRelease notes
Krótki opis zmian zawartych w danym wydaniu, istotny dla użytkowników, zespołów operacyjnych lub innych odbiorców.
Instrukcja operacyjnaRunbook
Krótka, praktyczna instrukcja postępowania przy znanym problemie lub operacji, przygotowana tak, aby można było z niej skorzystać pod presją czasu.
Interfejs programistyczny aplikacjiApplication Programming Interface
Uzgodniony sposób komunikacji między systemami lub komponentami. Określa dostępne operacje, dane wejściowe i wynikowe oraz zasady ich użycia.
Inżynieria jakościQuality Engineering
Dyscyplina budowania jakości w całym cyklu życia oprogramowania zamiast sprawdzania jej dopiero na końcu.
Inżynieria niezawodności usługSite Reliability Engineering
Podejście łączące inżynierię oprogramowania z utrzymaniem niezawodnych usług, automatyzacją operacji, SLI/SLO i zarządzaniem ryzykiem niezawodności.
Jira
Narzędzie firmy Atlassian do zarządzania pracą, zadaniami, backlogiem i przepływami. Statusy w Jirze są reprezentacją pracy, a nie samym systemem dostarczania.
Kluczowy wskaźnik efektywnościKey Performance Indicator
Wskaźnik wybrany do oceny postępu względem ważnego celu. Źle dobrany KPI może zachęcać do optymalizacji liczby zamiast rzeczywistego wyniku.
Kody odpowiedzi HTTPHTTP status codes
Trzycyfrowe kody opisujące wynik obsługi żądania HTTP, np. 2xx – sukces, 4xx – problem po stronie żądania, 5xx – błąd po stronie serwera.
Kolejka pracy gotowejReady Queue
Ograniczona liczba rzeczy przygotowanych do podjęcia w najbliższym czasie. Zbyt duża Ready Queue zamienia przygotowanie w magazyn starzejących się specyfikacji.
Komitet doradczy ds. zmianChange Advisory Board
Grupa wspierająca ocenę i koordynację zmian, szczególnie w podejściach IT Service Management. Nie powinna automatycznie stawać się obowiązkową ręczną bramką dla każdej zmiany.
Kompatybilność wstecznaBackward compatibility
Zdolność nowej wersji systemu do współpracy ze starszymi klientami, formatami lub kontraktami. Ułatwia niezależne i stopniowe wdrażanie zmian.
Komunikacja asynchronicznaAsynchronous communication
Komunikacja niewymagająca jednoczesnej obecności wszystkich uczestników. Dobrze sprawdza się przy statusie, kontekście, komentarzach i dokumentowaniu decyzji, jeśli informacja ma wiarygodne źródło prawdy.
Kondycja zespołuTeam Health
Jakościowe i ilościowe sygnały pokazujące, czy sposób pracy jest możliwy do utrzymania i czy zespół ma warunki do współpracy, skupienia i ujawniania problemów. Nie jest oceną ludzi ani rankingiem zespołów.
KontenerContainer
Izolowane środowisko uruchomieniowe pakujące aplikację wraz z potrzebnymi zależnościami, ale współdzielące jądro systemu operacyjnego hosta.
KonteneryzacjaContainerization
Sposób pakowania i uruchamiania aplikacji w kontenerach, ułatwiający powtarzalność środowisk i wdrożeń.
KontraktContract
Jawne uzgodnienie dotyczące zachowania, danych, odpowiedzialności lub interakcji. Może dotyczyć zarówno współpracy zespołów, jak i technicznego interfejsu.
Kontrakt APIAPI contract
Uzgodniony opis sposobu korzystania z API: operacji, danych, formatów, błędów i zasad kompatybilności. Stabilny kontrakt pozwala zespołom pracować bardziej niezależnie.
Kontrolowana atrapa zależnościMock
Obiekt lub usługa zastępująca prawdziwą zależność podczas testów lub pracy równoległej. Może zwracać ustalone odpowiedzi i dodatkowo sprawdzać oczekiwane interakcje.
KPI
Sprawdź: Kluczowy wskaźnik efektywności
Kryteria akceptacjiAcceptance criteria
Warunki opisujące obserwowalne zachowanie lub rezultat, po których można rozpoznać, że dana część rozwiązania działa zgodnie z uzgodnieniem.
Kubernetes
Platforma do automatycznego uruchamiania, skalowania i zarządzania aplikacjami kontenerowymi.
Ład zarządczyGovernance
Mechanizm zapewniający widoczność stanu, ryzyk, zależności i decyzji oraz kierujący problemy do osób, które mogą na nie zareagować. Nie jest synonimem komitetu ani dodatkowej warstwy akceptacji.
Macierz odpowiedzialnościResponsible, Accountable, Consulted, Informed
Model porządkujący role: kto wykonuje pracę, kto ponosi ostateczną odpowiedzialność, kogo konsultujemy i kogo informujemy.
Mainline
Sprawdź: Główna gałąź kodu
Mała partia pracySmall batch
Niewielki, logiczny fragment zmiany, który można szybko zintegrować, zweryfikować i dostarczyć. Mniejsze partie ograniczają koszt błędu i przyspieszają informację zwrotną.
Manifest AgileAgile Manifesto
Manifest Zwinnego Wytwarzania Oprogramowania i stojące za nim zasady. W książce jest punktem odniesienia dla współpracy, prostoty, szybkiej informacji zwrotnej, adaptacji i tempa możliwego do utrzymania, a nie gotową instrukcją procesu.
Mapa kierunkuRoadmap
Widok pokazujący kierunek, kolejność ważnych tematów, zależności i horyzont czasowy. Nie powinna być traktowana jak szczegółowy, niezmienny harmonogram.
MedianaMedian
Wartość dzieląca uporządkowany zbiór wyników na połowę: 50% obserwacji jest mniejszych lub równych tej wartości. Jest mniej wrażliwa na skrajne wyniki niż średnia.
Metoda zarządzania przepływem pracyKanban
Podejście wykorzystujące wizualizację pracy, ograniczanie pracy w toku i zarządzanie przepływem w celu skracania czasu realizacji i ujawniania wąskich gardeł.
Metryka ochronnaGuardrail metric
Miara pilnująca, aby poprawa jednego wyniku nie odbywała się kosztem innego ważnego wymiaru, np. jakości, stabilności lub kondycji zespołu.
Metryka wynikowaLagging indicator
Miara opisująca zdarzenie, które już nastąpiło, np. incydent, przekroczenie terminu lub defekt produkcyjny.
Metryka wyprzedzającaLeading indicator
Sygnał, który może pokazać narastający problem zanim pojawi się końcowy skutek, np. rosnący WIP, wiek pracy lub długo oczekująca zależność.
Metryki przepływuFlow metrics
Zestaw miar opisujących zachowanie przepływu pracy, w szczególności WIP, Throughput, Work Item Age i Cycle Time. Mają wspierać decyzje o systemie, a nie ranking osób.
MigracjaMigration
Kontrolowane przeniesienie danych, konfiguracji, użytkowników lub systemu do nowego modelu, wersji albo środowiska.
Model kaskadowyWaterfall
Sekwencyjny sposób organizacji pracy, w którym kolejne fazy następują po sobie z ograniczonym powrotem do wcześniejszych etapów.
Model operacyjny zespołuTeam Operating Model
Uzgodniony system codziennego działania zespołu: cele, wejście pracy, priorytety, przygotowanie, przepływ, capacity, decyzje, komunikacja, spotkania, zależności i uczenie się. Ma odpowiadać na realne decyzje, a nie opisywać tylko ceremonie.
MonitorowanieMonitoring
Ciągłe obserwowanie znanych wskaźników i warunków działania systemu. Dobrze odpowiada na pytanie „czy coś odbiega od oczekiwań?”, ale nie zawsze wyjaśnia dlaczego.
Najpierw kończ, potem zaczynajFinish before start
Zasada przepływu zachęcająca do pomagania w dokończeniu rozpoczętej pracy przed otwieraniem kolejnych tematów.
Naprawa przez kolejne wdrożenieRoll-forward
Przywrócenie sprawności przez przygotowanie i wdrożenie poprawki zamiast cofania całej zmiany.
NFR
Sprawdź: Wymagania pozafunkcjonalne
NiestabilnyFlaky test
Test, który przy niezmienionym kodzie potrafi raz przejść, a raz nie. Osłabia zaufanie do automatycznych kontroli i uczy zespół ignorować czerwone wyniki.
NiewiadomaUnknown
Pytanie, na które nie mamy jeszcze odpowiedzi. Istotne niewiadome warto nazwać, jeśli mogą zmienić decyzję, zakres, koszt lub ryzyko.
NiezawodnośćReliability
Zdolność systemu do poprawnego i stabilnego świadczenia oczekiwanej usługi w czasie i w uzgodnionych warunkach.
Obciążenie kalendarzaCalendar load
Ilość i rozmieszczenie spotkań zajmujących dzień pracy. Znaczenie ma nie tylko łączny czas, lecz także fragmentacja dnia i wpływ na możliwość pracy wymagającej skupienia.
ObserwowalnośćObservability
Możliwość zrozumienia wewnętrznego stanu systemu na podstawie generowanych przez niego sygnałów, takich jak logi, metryki i ślady.
Ocena stanu obecnegoAssessment
Ustrukturyzowane spojrzenie na to, jak zespół rzeczywiście pracuje. Nie jest egzaminem ze zgodności z frameworkiem, lecz analizą realnej pracy, kolejek, decyzji, spotkań, WIP i wyjątków.
Oczekiwana dataTarget date
Data, w której chcielibyśmy uzyskać wynik. Sama w sobie nie jest terminem granicznym ani zobowiązaniem.
Oczekiwanie poziomu obsługiService Level Expectation
Oczekiwanie dotyczące czasu zakończenia pracy oparte na historycznym zachowaniu systemu. Nie jest gwarancją ani SLA; pomaga identyfikować starzejącą się pracę i wcześniej reagować na ryzyko.
Odpowiedzialność właścicielskaOwnership
Odpowiedzialność za doprowadzenie sprawy do wyniku, decyzji lub następnego kroku, a nie tylko za wykonanie przypisanego fragmentu. Wspólna odpowiedzialność zespołu nie usuwa potrzeby jasnych właścicieli konkretnych decyzji i inicjatyw.
Odsetek nieudanych zmianChange Fail Rate
Metryka DORA pokazująca, jaka część zmian produkcyjnych prowadzi do niepożądanego skutku wymagającego reakcji, np. poprawki, wycofania lub interwencji.
Odsetek wdrożeń wymagających poprawekDeployment Rework Rate
Metryka DORA pokazująca, jaka część wdrożeń wymaga późniejszej pracy naprawczej lub poprawkowej.
Od początku do końca / CałościowoEnd-to-end
Określenie obejmujące cały przepływ przez wiele komponentów lub systemów. W testach oznacza sprawdzanie pełnego scenariusza z perspektywy użytkownika lub procesu.
Ograniczenie czasoweTimebox
Z góry ograniczony czas przeznaczony na aktywność, eksperyment albo decyzję. Timebox ogranicza koszt i wymusza moment oceny; nie oznacza, że wszystkie problemy da się rozwiązać w identycznym czasie.
Ograniczone w czasie badanie techniczneSpike
Krótki eksperyment służący odpowiedzi na konkretne pytanie techniczne lub zmniejszeniu istotnej niewiadomej. Jego wynikiem jest wiedza, nie gotowa funkcja.
Ograniczony czasowo cykl pracy w ScrumieSprint
Stały okres w Scrumie, w którym zespół pracuje nad osiągnięciem Celu Sprintu i tworzy wartościowy przyrost produktu.
Określanie względnej wielkości pracySizing
Praktyka oceny wielkości lub złożoności elementu, często względnej wobec innych prac. Może wykorzystywać story points, rozmiary koszulkowe lub inne skale.
OpenTelemetry
Otwarty standard i ekosystem do generowania, zbierania i eksportowania telemetrii, m.in. metryk, logów i śladów.
OprogramowanieSoftware
Programy, usługi, biblioteki i inne elementy wykonywane przez komputer wraz z ich logiką i konfiguracją.
Osoba bezpośrednio odpowiedzialnaDirectly Responsible Individual
Jedna wskazana osoba pilnująca doprowadzenia sprawy do wyniku lub decyzji. Nie oznacza, że wykonuje całą pracę ani że posiada wszystkie prawa decyzyjne.
Partia pracy / Wielkość partiiBatch
Porcja pracy przenoszona przez system jako jedna całość. Mniejsze partie zwykle skracają czas do informacji zwrotnej, ograniczają zakres błędu i ułatwiają zmianę kierunku.
PercentylPercentile
Wartość pokazująca, jaki odsetek obserwacji mieści się na danym poziomie lub poniżej niego. Np. P85 oznacza, że 85% przypadków zakończyło się w tym czasie lub szybciej.
Plan
Opis aktualnego zamiaru działania przy obecnej wiedzy. Może zmieniać się wraz z nowymi informacjami.
Planning Poker
Grupowa technika estymacji względnej, w której uczestnicy niezależnie wybierają wartości, a różnice stają się punktem wyjścia do rozmowy o rozumieniu pracy i ryzyku. Technika jest narzędziem, nie celem procesu estymacji.
Planowanie bez estymowania każdej pracyNo Estimates
Podejście ograniczające lub rezygnujące z estymowania pojedynczych elementów tam, gdzie wystarczają dane historyczne, małe podobne porcje pracy i metryki przepływu. Nie oznacza rezygnacji z prognozowania ani odpowiedzialności za plan.
Planowanie i prognozowaniePlan & Forecast
Etap drogi Zmiany, w którym ustalamy kolejność, dostępność, ograniczenia i prognozę terminu lub zakresu przy określonym poziomie pewności.
Pobieranie pracyPull
Zasada, w której kolejna praca jest podejmowana wtedy, gdy pojawia się realna capacity w odpowiednim miejscu przepływu. Ogranicza przydzielanie zadań niezależnie od aktualnego obciążenia.
PoC
Sprawdź: Dowód koncepcji
PodręcznikHandbook
Zbiór opisanych zasad i praktyk organizacji. W książce termin pojawia się głównie w odniesieniu do GitLab Handbook.
Potok automatyzacjiPipeline
Sekwencja zautomatyzowanych kroków, np. budowania, testowania, skanowania i wdrażania oprogramowania.
Powodzenie bez treści odpowiedziHTTP 204 No Content
Kod HTTP oznaczający poprawne wykonanie żądania bez zwracania treści w odpowiedzi.
Powodzenie żądaniaHTTP 200 OK
Kod odpowiedzi HTTP oznaczający, że żądanie zostało poprawnie obsłużone. Sam kod 200 nie dowodzi jeszcze, że cały proces użytkownika zakończył się sukcesem.
Poziom pewnościConfidence level
Informacja o tym, jak wiarygodna jest dana prognoza lub założenie. Powinien zmieniać się wraz z nową wiedzą, a nie być tylko stałym kolorem w raporcie.
Praca nieplanowanaUnplanned work
Praca pojawiająca się poza wcześniej przyjętym planem, np. incydenty, pilne poprawki i nieprzewidziane działania operacyjne. Powinna być uwzględniana przy ocenie realnej dostępności.
Praca przeniesionaCarry-over
Praca rozpoczęta w jednym okresie i niedokończona przed rozpoczęciem następnego. Nadal zużywa uwagę i dostępność zespołu, nawet jeśli kalendarzowo rozpoczął się nowy sprint lub miesiąc.
Praca w tokuWork in Progress
Liczba lub ilość pracy rozpoczętej, ale jeszcze niezakończonej. Zbyt wysoki WIP sprzyja kolejkom, przełączaniu kontekstu i dłuższemu czasowi realizacji.
Praca z rzeczywistą datą granicznąFixed Date
Klasa pracy, dla której przekroczenie konkretnej daty powoduje realną konsekwencję, np. prawną, kontraktową, operacyjną lub rynkową. Wymaga jawnej daty, właściciela i wcześniejszego śledzenia ryzyka.
Praktyki łączące rozwój oprogramowania i operacjeDevOps
Podejście łączące wytwarzanie, automatyzację, wdrażanie i utrzymanie w jeden przepływ odpowiedzialności i informacji zwrotnej.
Prawa do decyzjiDecision rights
Jawne określenie, kto może podjąć określony typ decyzji i gdzie kończą się granice autonomii. Współpraca nie wymaga konsensusu wszystkich, jeśli finalne prawo decyzji jest czytelne.
Prawo Little’aLittle's Law
Relacja pomiędzy średnim WIP, przepustowością i średnim czasem przepływu w stabilnym systemie. Pomaga rozumieć, dlaczego nadmiar pracy w toku wydłuża czas realizacji; nie powinno być używane jako sztuczny cel KPI bez sprawdzenia warunków stosowalności.
PriorytetPriority
Informacja o tym, co jest ważniejsze od czego. Priorytet nie jest datą ani zobowiązaniem.
ProblemIssue
Zaistniała trudność lub niepożądany stan, który już wpływa na pracę, usługę lub wynik. W książce jest odróżniany od ryzyka, które dotyczy przyszłego zdarzenia.
Produkcja i naukaOperate & Learn
Etap, w którym obserwujemy rzeczywiste zachowanie rozwiązania na produkcji, sprawdzamy efekt i wykorzystujemy nową wiedzę do kolejnych decyzji.
PrognozaForecast
Ocena najbardziej prawdopodobnego przyszłego wyniku lub terminu oparta na aktualnej wiedzy, danych i założeniach. Powinna zmieniać się, gdy zmieniają się przesłanki.
Prognoza probabilistycznaProbabilistic forecast
Prognoza wyrażająca wynik wraz z prawdopodobieństwem lub percentylem zamiast jednej pozornie pewnej daty.
ProgramistaDeveloper
Osoba projektująca, implementująca i rozwijająca oprogramowanie. W książce termin nie ogranicza odpowiedzialności programisty wyłącznie do pisania kodu.
Prosta atrapa zależnościStub
Zastępnik komponentu zwracający wcześniej przygotowane odpowiedzi. Zwykle jest prostszy niż mock i nie musi weryfikować sposobu interakcji.
Protokół przesyłania hipertekstuHypertext Transfer Protocol
Podstawowy protokół komunikacyjny używany przez WWW i wiele API. Definiuje m.in. żądania, odpowiedzi i kody statusu.
PrototypPrototype
Uproszczona reprezentacja rozwiązania używana do sprawdzenia pomysłu, zachowania lub doświadczenia użytkownika. Nie musi zawierać kodu produkcyjnego.
Przegląd koduCode review
Ocena zmiany przez inną osobę lub osoby w celu wykrycia problemów, rozprowadzenia wiedzy i utrzymania standardów przed scaleniem.
Przegląd przepływuReview
Przegląd osiągniętego rezultatu i okazja do uzyskania informacji zwrotnej oraz adaptacji dalszego kierunku. Nie powinien być wyłącznie pokazem ani formalnym odbiorem pracy.
Przegląd przepływuFlow Review
Okresowy przegląd zachowania całego systemu pracy z użyciem danych o WIP, czasie realizacji, wieku pracy, przepustowości, blokadach i kolejkach. Służy zmianie polityk i ograniczeń systemu.
Przekazanie pracyHandoff
Przekazanie elementu lub odpowiedzialności między osobami, specjalizacjami lub zespołami. Każde przekazanie może tworzyć kolejkę i utratę kontekstu.
Przełączanie kontekstuContext switching
Koszt poznawczy związany z częstym przechodzeniem między różnymi zadaniami lub problemami. Wysoki WIP zwykle zwiększa liczbę takich przełączeń.
PrzepływFlow
Sposób, w jaki praca, decyzje, informacje i wartość przechodzą przez system od potrzeby do efektu. Obejmuje zarówno czas aktywnej pracy, jak i oczekiwanie.
PrzepustowośćThroughput
Liczba porównywalnych elementów zakończonych w jednostce czasu. Może wspierać prognozowanie, ale nie powinna być celem produktywności samym w sobie.
PrzerwanieInterrupt
Nieplanowane zdarzenie odrywające osobę lub zespół od aktualnej pracy, np. incydent, pilna prośba, konsultacja lub zmiana priorytetu. Warto zarządzać jego źródłem i kosztem, a nie zakładać, że każde przerwanie jest nieuniknione.
Przesunięcie kontroli wcześniejShift Left
Przenoszenie działań związanych z jakością, bezpieczeństwem i informacją zwrotną na wcześniejsze etapy wytwarzania, aby problemy były wykrywane wtedy, gdy są tańsze do naprawienia.
Przewodnik po KanbanieKanban Guide
Kanoniczny dokument opisujący Kanban, w tym Definition of Workflow, jawne polityki, kontrolę WIP, pull, aktywne zarządzanie pracą oraz podstawowe metryki przepływu.
Przewodnik po ScrumieScrum Guide
Kanoniczny dokument opisujący zasady, role, wydarzenia i artefakty Scruma. Służy do odróżniania formalnego Scruma od praktyk dodawanych przez organizacje.
Pulpit / Widok wskaźnikówDashboard
Zestaw wykresów i wskaźników pokazujących stan systemu, produktu lub pracy. Powinien wspierać konkretne pytania i decyzje, a nie być tylko dekoracją.
Punkt estymacyjnyStory point
Względna jednostka używana przez część zespołów do szacowania wielkości, złożoności lub niepewności pracy. Nie jest jednostką czasu i nie powinna służyć do porównywania produktywności zespołów.
Punkt końcowy interfejsu APIEndpoint
Konkretny adres lub operacja udostępniana przez API, pod którą system przyjmuje określone żądania.
Punkt odniesieniaBenchmark
Wynik, praktyka lub system używany jako punkt odniesienia do porównania. Benchmark nie musi być normą do bezpośredniego kopiowania.
QA
Sprawdź: Zapewnienie jakości
QE
Sprawdź: Inżynieria jakości
RamyFramework
Ustrukturyzowany zestaw zasad, ról lub praktyk dający ramy działania bez konieczności definiowania każdego szczegółu procesu.
RefaktoryzacjaRefactoring
Zmiana wewnętrznej struktury kodu bez zamierzonej zmiany jego zewnętrznego zachowania, wykonywana np. dla poprawy czytelności, utrzymywalności lub możliwości dalszego rozwoju.
Rejestr decyzjiDecision Log
Lekki zapis istotnych decyzji: co ustalono, dlaczego, kto zdecydował i jaki był kontekst. Pomaga uniknąć odtwarzania tych samych dyskusji i utraty wiedzy po czasie.
Relacje firma–firmaBusiness-to-Business
Model produktów, usług lub relacji kierowanych do innych organizacji, a nie bezpośrednio do konsumenta.
RetrospektywaRetrospective
Jedna z pętli uczenia się zespołu, służąca przeglądowi sposobu pracy i wyborowi usprawnień. Sama rozmowa nie jest sukcesem; liczy się decyzja, działanie i późniejsza weryfikacja efektu.
Rozpoznaj / ZweryfikujDiscover
Branżowa etykieta etapu Rozpoznania. Obejmuje sprawdzenie problemu, hipotez, wykonalności i najważniejszych niewiadomych przed większą inwestycją.
RozpoznanieDiscovery
Praca służąca lepszemu zrozumieniu problemu, użytkownika, rozwiązania, ryzyk i niewiadomych przed podjęciem dalszych decyzji. W książce preferowane jest polskie określenie „Rozpoznanie”.
RozszerzExpand
Wzorzec bezpiecznej zmiany danych lub schematu: najpierw dodajemy nową strukturę zgodną ze starą, następnie przenosimy użycie lub dane, a dopiero na końcu usuwamy elementy starego modelu.
Rytm pracyCadence
Uzgodniony rytm powtarzalnych pętli planowania, synchronizacji, informacji zwrotnej i uczenia się. Powinien wynikać z potrzeb systemu, a nie z przyzwyczajenia do kalendarza ceremonii.
RyzykoRisk
Niepewne przyszłe zdarzenie lub warunek, który może wpłynąć na wynik, termin, koszt, bezpieczeństwo lub jakość. Powinno mieć opisany możliwy skutek i sposób reakcji.
SamoobsługaSelf-service
Możliwość wykonania potrzebnej czynności bez czekania na centralnego specjalistę, zespół lub ręczną akceptację. Dobre platformy, narzędzia i kontrakty zwiększają niezależność przez bezpieczny self-service.
Scrumban
Pomocnicza nazwa modelu łączącego wybrane mechanizmy Scruma i Kanbana, np. cel i rytm iteracyjny z pull, WIP i ageing. Ma sens wtedy, gdy połączenie rozwiązuje konkretne problemy, a nie gdy zachowuje wszystkie rytuały obu podejść.
SDLC
SharePointMicrosoft SharePoint
Platforma Microsoft do współdzielenia dokumentów, stron i informacji w organizacji.
SilosSilo
Granica organizacyjna lub kompetencyjna powodująca, że praca czeka na kolejny dział, a odpowiedzialność kończy się przy przekazaniu. Specjalizacja jest potrzebna; silos zaczyna się wtedy, gdy utrudnia wspólne zakończenie wyniku.
Skumulowany diagram przepływuCumulative Flow Diagram
Wykres pokazujący liczbę rzeczy znajdujących się w kolejnych stanach pracy w czasie. Pomaga obserwować narastający WIP, kolejki i zmiany przepustowości systemu.
SLA
Sprawdź: Umowa o poziomie świadczenia usługi
SLI
Sprawdź: Wskaźnik poziomu usługi
SLO
Sprawdź: Cel poziomu usługi
SPACE
Wielowymiarowy model patrzenia na produktywność programistów przez satysfakcję i dobrostan, wyniki, aktywność, komunikację i współpracę oraz efektywność i przepływ. Przypomina, że jedna metryka aktywności nie opisuje jakości systemu pracy.
SRE
Sprawdź: Inżynieria niezawodności usług
Stan bazowy / Punkt odniesienia przed zmianąBaseline
Obraz stanu przed wprowadzeniem zmiany, z którym porównujemy późniejszy efekt. Może obejmować dane, rozkłady, obserwacje i sygnały jakościowe.
Stopniowe udostępnianieProgressive delivery
Podejście polegające na zwiększaniu ekspozycji nowej wersji lub funkcji etapami, w oparciu o obserwowane sygnały.
Sztuczna inteligencjaArtificial Intelligence
Ogólne określenie systemów wykonujących zadania kojarzone z ludzkim rozumowaniem, generowaniem treści, analizą lub podejmowaniem decyzji. W książce pojawia się także w kontekście narzędzi wspierających redakcję.
Szybka ścieżkaFast track
Uproszczony sposób przejścia przez drogę Zmiany dla małych, dobrze rozumianych i niskiego ryzyka prac. Skraca formalności, ale nie usuwa potrzebnego myślenia.
Ślad rozproszonyDistributed trace
Zapis przebiegu pojedynczego żądania lub operacji przez wiele usług i komponentów. Ułatwia zrozumienie, gdzie w rozproszonym systemie powstaje opóźnienie lub błąd.
ŚredniaMean
Suma wartości podzielona przez ich liczbę. Może być silnie zniekształcona przez skrajne przypadki, dlatego dla czasów przepływu często warto patrzeć także na medianę i percentyle.
Środowisko produkcyjneProduction
Rzeczywiste środowisko, w którym z systemu korzystają użytkownicy lub procesy biznesowe i gdzie pojawiają się realne dane, ruch oraz konsekwencje błędów.
Świadomy kompromisTrade-off
Decyzja, w której poprawa jednego wymiaru wymaga zaakceptowania kosztu w innym, np. zakresie, czasie, ryzyku, jakości lub elastyczności. Dojrzałe planowanie pokazuje ten koszt zamiast obiecywać wszystko jednocześnie.
Tekstowy język opisu zachowania systemuGherkin
Prosty język używany m.in. w BDD do opisywania scenariuszy zachowania w formie czytelnej dla ludzi i możliwej do automatyzacji, często z użyciem Given / When / Then.
TelemetriaTelemetry
Dane emitowane przez system i zbierane do obserwacji jego działania, np. metryki, logi, ślady i zdarzenia.
Tempo możliwe do utrzymaniaSustainable pace
Sposób pracy, który zespół może powtarzać długoterminowo bez chronicznych nadgodzin, ciągłego przeciążenia i regularnego ratowania planu trybem bohatera. Nie oznacza pracy wolniej, lecz stabilną zdolność działania.
Tempo zespołu mierzone ukończonymi punktamiVelocity
Zespołowa miara ilości pracy zakończonej w kolejnych Sprintach, zwykle wyrażona story points. Może wspierać planowanie w obrębie jednego zespołu, ale nie jest miarą produktywności ani podstawą do porównywania zespołów.
Termin granicznyDeadline
Data, po której występuje realna konsekwencja prawna, kontraktowa, rynkowa lub operacyjna. Nie jest tym samym co data oczekiwana.
TestowalnośćTestability
Cecha rozwiązania określająca, jak łatwo i wiarygodnie można sprawdzić jego zachowanie. Dobra testowalność skraca czas uzyskania informacji zwrotnej.
Test automatycznyAutomated test
Test wykonywany przez narzędzie bez ręcznego przechodzenia scenariusza przez człowieka. Pozwala uzyskiwać szybką i powtarzalną informację zwrotną.
Test bezpieczeństwaSecurity test
Test sprawdzający odporność rozwiązania na zagrożenia, nadużycia, błędne uprawnienia lub inne problemy bezpieczeństwa.
Test integracyjnyIntegration test
Test sprawdzający współdziałanie co najmniej dwóch komponentów lub systemów.
Test jednostkowyUnit test
Test niewielkiej jednostki kodu wykonywany w izolacji od większości zewnętrznych zależności.
Test kontraktowyContract test
Test weryfikujący zgodność producenta i konsumenta interfejsu z uzgodnionym kontraktem, np. API.
Test manualnyManual test
Test wykonywany ręcznie przez człowieka. Może być wartościowy tam, gdzie potrzebna jest eksploracja, ocena doświadczenia lub jednorazowa weryfikacja.
Test niezawodnościReliability test
Test sprawdzający zachowanie systemu w warunkach awarii, przeciążenia, utraty zależności lub innych sytuacji wpływających na ciągłość usługi.
Test od początku do końcaEnd-to-end test
Test sprawdzający pełny przepływ przez kilka warstw lub systemów z perspektywy użytkownika albo procesu biznesowego.
Test wydajnościowyPerformance test
Test mierzący zachowanie systemu pod określonym obciążeniem, np. czas odpowiedzi, przepustowość lub wykorzystanie zasobów.
Tryb bohateraHero mode
Wyjątkowy sposób działania oparty na dużym dodatkowym wysiłku, nadgodzinach i indywidualnym ratowaniu sytuacji. Może być potrzebny w kryzysie, ale jego regularne występowanie jest sygnałem problemu systemowego.
Tryb pilnyExpedite
Wyjątkowa klasa obsługi pracy wymagającej natychmiastowej reakcji ze względu na poważny wpływ lub ryzyko. Powinna być rzadka, jawna i mieć wyraźne kryteria, ponieważ jej użycie przerywa normalny przepływ.
Udostępnienie funkcji użytkownikomLaunch
Moment, w którym funkcja lub produkt staje się dostępny dla docelowej grupy użytkowników. Może nastąpić później niż techniczne wdrożenie.
Umowa o poziomie świadczenia usługiService Level Agreement
Formalne uzgodnienie między stronami określające oczekiwany poziom usługi i często konsekwencje jego niespełnienia. Należy odróżniać od wewnętrznego SLO.
Uporządkowana lista pracyBacklog
Lista tematów, funkcji, błędów lub innych prac, które mogą zostać podjęte. Backlog nie powinien być archiwum wszystkich pomysłów ani magazynem tematów bez decyzji.
UsługaService
Wyodrębniona zdolność systemu świadcząca określoną funkcję użytkownikowi lub innemu systemowi. W kontekście SRE i operacji może mieć własne cele niezawodności i odpowiedzialny zespół.
UtrzymanieOperations
Praca zapewniająca poprawne działanie systemu po wdrożeniu: obsługa incydentów, monitoring, diagnostyka, aktualizacje, działania operacyjne i poprawa niezawodności.
UX
Sprawdź: Doświadczenie użytkownika
Uzgodnienia zespołuTeam Agreements
Lekki zestaw uzgodnionych zasad współpracy, np. kanałów komunikacji, oczekiwań wobec review, obsługi przerwań, czasu skupienia czy sposobu eskalacji. Powinny opisywać rzeczywiste zachowania i ewoluować z zespołem.
Uzupełnianie kolejki pracyReplenishment
Moment lub mechanizm wyboru kolejnej pracy do systemu w modelu przepływowym. Pełni podobną funkcję decyzyjną do krótkoterminowego planowania bez konieczności pakowania pracy w sprint.
Wąskie gardłoBottleneck
Miejsce systemu ograniczające przepływ całości, np. kolejka do jednej osoby, środowiska lub przeglądu kodu.
Wdrożenie blue/green / Równoległe środowiskaBlue/green deployment
Strategia utrzymywania równolegle starej i nowej wersji środowiska i przełączania ruchu między nimi. Ułatwia szybki powrót, ale wymaga dodatkowych zasobów i uwagi przy zmianach danych.
Wdrożenie kanarkoweCanary deployment
Stopniowe wdrożenie nowej wersji do niewielkiej części ruchu lub użytkowników. Pozwala obserwować rzeczywiste zachowanie przed zwiększeniem ekspozycji.
Wdrożenie nowej osoby do organizacji lub systemuOnboarding
Proces przekazania nowej osobie dostępu, wiedzy, kontekstu i zasad potrzebnych do skutecznego rozpoczęcia pracy.
Wdrożenie techniczneDeploy
Umieszczenie nowego artefaktu lub konfiguracji w środowisku, zwykle produkcyjnym. Nie musi oznaczać, że funkcja została już udostępniona użytkownikom.
WidocznośćVisibility
Zdolność szybkiego zobaczenia rzeczywistego stanu pracy, ryzyk, zależności, prognozy i potrzebnych decyzji przez osoby, które muszą działać.
Wiek pracyWork item age
Czas, jaki aktywna praca spędziła w systemie od rozpoczęcia do chwili obecnej. Rosnący wiek może wcześniej niż termin pokazać, że element utknął.
WIP
Sprawdź: Praca w toku
Właściciel ProduktuProduct Owner
Odpowiedzialność w Scrumie związana z maksymalizacją wartości produktu i skutecznym zarządzaniem Product Backlogiem. W tej książce tytuł roli nie zwalnia zespołu z udziału w rozumieniu problemu i projektowaniu rozwiązania.
Wnioski z doświadczeniaLessons Learned
Ustrukturyzowane zebranie wiedzy po ważnym zdarzeniu, projekcie, eksperymencie lub sukcesie. Wartość powstaje wtedy, gdy wnioski wpływają na przyszłe decyzje albo sposób pracy.
Wskaźnik poziomu usługiService Level Indicator
Mierzalny wskaźnik jakości usługi, np. dostępność, czas odpowiedzi lub odsetek poprawnie zakończonych operacji.
Wspólne minimumCommon minimum
Najmniejszy wspólny zestaw zasad lub warunków, które warto utrzymać niezależnie od szczegółowego sposobu pracy zespołu.
Wspólne skupienie na dokończeniu pracySwarming
Skupienie kilku osób na doprowadzeniu rozpoczętej pracy do końca zamiast automatycznego rozpoczynania kolejnych tematów. Pomaga przełamywać lokalne kolejki i realizować zasadę finish before starting.
Współistnienie kolejnych wersjiN
Model, w którym aktualna i kolejna wersja systemu lub kontraktu mogą przez pewien czas działać równolegle. Zmniejsza potrzebę idealnej synchronizacji wdrożeń.
Współpraca wielofunkcyjna / MiędzykompetencyjnaCross-functional
Sposób współpracy, w którym potrzebne kompetencje uczestniczą w osiąganiu wspólnego rezultatu zamiast działać jako kolejne silosy przekazujące sobie pracę. Nie oznacza, że każdy musi umieć wszystko.
Wstępna selekcjaTriage
Lekka ocena nowej potrzeby lub problemu służąca decyzji, co zrobić z tematem dalej: rozpoznać, odłożyć, odrzucić albo skierować szybką ścieżką.
WydanieRelease
Decyzja lub moment, w którym wdrożona wersja zostaje uznana za gotową do użycia w zaplanowanym zakresie. W książce release jest odróżniany od samego deploy i od launch.
Wymagania pozafunkcjonalneNon-functional requirements (NFRs)
Wymagania opisujące cechy rozwiązania inne niż sama funkcjonalność, np. wydajność, bezpieczeństwo, dostępność, obserwowalność, zgodność lub kompatybilność.
Wypychanie pracyPush
Sposób uruchamiania lub przydzielania kolejnej pracy niezależnie od tego, czy dalsza część systemu ma capacity, aby ją obsłużyć. Sprzyja narastaniu WIP i kolejek.
Wystarczająco gotoweReady enough
Stan, w którym wiemy wystarczająco dużo, aby odpowiedzialnie rozpocząć pracę, a pozostała niepewność jest świadoma i akceptowalna. Nie oznacza kompletnej specyfikacji ani braku dalszego uczenia się.
Wytwór / Dostarczony rezultat pracyOutput
To, co zostało wykonane lub dostarczone, np. funkcja, raport, API albo migracja. Output może być poprawnie dostarczony i jednocześnie nie przynieść oczekiwanego outcome.
ZakresScope
Zestaw rzeczy planowanych do wykonania w ramach celu, inicjatywy lub okresu. Zakres jest środkiem do osiągnięcia efektu i może być zmieniany, gdy pojawiają się nowe informacje lub stałe ograniczenie czasu.
ZależnośćDependency
Sytuacja, w której wynik jednej pracy zależy od decyzji, danych, systemu, dostawcy lub rezultatu dostarczanego przez kogoś innego.
Zależność miękkaSoft dependency
Zależność, której niespełnienie utrudnia lub obniża wartość rozwiązania, ale nie uniemożliwia dalszej pracy lub dostarczenia minimalnego zakresu.
Zależność twardaHard dependency
Zależność, bez której nie można rozpocząć lub zakończyć określonej części pracy albo osiągnąć wymaganego rezultatu.
ZałożenieAssumption
Informacja przyjęta roboczo bez pełnego potwierdzenia. Założenia o dużym wpływie powinny być widoczne i w razie potrzeby zweryfikowane.
Zamrożenie zmianChange freeze
Okresowe ograniczenie lub zakaz wdrażania zmian, zwykle w czasie zwiększonego ryzyka biznesowego lub operacyjnego. Samo zamrożenie nie naprawia słabego procesu wdrożeniowego.
Zapewnienie jakościQuality Assurance
Tradycyjnie działania mające zapewnić odpowiedni poziom jakości. W praktyce skrót bywa też używany jako nazwa roli lub zespołu testowego, choć jakość jest odpowiedzialnością szerszą niż samo QA.
Zapis decyzji architektonicznejArchitecture Decision Record
Krótki dokument opisujący istotną decyzję architektoniczną, jej kontekst, rozważane możliwości i konsekwencje.
ZapotrzebowanieDemand
Ogólne określenie impulsu do rozpoczęcia pracy: potrzeby biznesowej, problemu użytkownika, ryzyka, wymogu prawnego, długu technicznego lub innego źródła zmiany.
Zarządzanie zmianą w usługach ITChange Management
Sposób oceny, planowania i kontrolowania zmian w środowisku usługowym. W tym znaczeniu nie chodzi o zarządzanie transformacją organizacyjną, lecz o bezpieczne wprowadzanie zmian technicznych i operacyjnych.
ZgodnośćCompliance
Spełnienie obowiązujących wymagań prawnych, regulacyjnych, umownych, norm lub wewnętrznych polityk.
ZmianaChange
Główny „bohater” książki: każda zamierzona modyfikacja istniejącego stanu, np. nowa funkcja, poprawka błędu, zmiana zachowania, migracja, zmiana konfiguracji, zabezpieczeń albo usunięcie niepotrzebnego elementu.
ZobowiązanieCommitment
Świadoma deklaracja odpowiedzialności za określony wynik przy uzgodnionych warunkach. Powinno być odróżniane od estymaty, prognozy i oczekiwanej daty.
Zwinne podejście do pracyAgile
Zbiór zasad i sposobów pracy opartych na krótkich pętlach informacji zwrotnej, współpracy i adaptacji do nowej wiedzy. Nie oznacza jednego konkretnego procesu ani frameworku.
Źródło pierwotne organizacjiFirst-party source
Materiał publikowany przez organizację opisującą własne zasady, praktyki, narzędzia lub sposób działania. W książce takie źródła służą jako benchmark praktyczny, a nie norma do kopiowania 1:1.
Źródło prawdySource of truth
Miejsce uznane za aktualne i wiarygodne źródło danej informacji, tak aby zespół nie musiał rekonstruować stanu z wielu sprzecznych dokumentów.
Żądanie scalenia zmianMerge request
Prośba o połączenie zmian z jednej gałęzi kodu z inną, zwykle poprzedzona przeglądem i automatycznymi kontrolami.
Żądanie scalenia zmian / Pull requestPull request
Sprawdź: Żądanie scalenia zmian
50. percentyl50th percentile (P50)
Wartość, poniżej której mieści się 50% obserwacji. Dla czasu realizacji odpowiada medianie.
85. percentyl85th percentile (P85)
Wartość, poniżej której mieści się 85% obserwacji. Może być używana do bardziej ostrożnych prognoz niż mediana.
90. percentyl90th percentile (P90)
Wartość, poniżej której mieści się 90% obserwacji.
95. percentyl95th percentile (P95)
Wartość, poniżej której mieści się 95% obserwacji. Pomaga analizować dłuższy ogon rozkładu.
99. percentyl99th percentile (P99)
Wartość, poniżej której mieści się 99% obserwacji. Pokazuje skrajne przypadki, które mogą wymagać osobnej analizy.
Brak wyników
Spróbuj innego hasła albo wyczyść wybrane filtry.
Engineering Excellence
Playbooki
Książka w przygotowaniu
Praktyczne przewodniki przekładające idee z książki na konkretne działania, decyzje i rytuały zespołu.