Słownik analityka biznesowego

SAFe (ang. Scaled Agile Framework) to framework skalowania zwinności ponad poziom pojedynczego zespołu - na programy i całe organizacje.

SELECT to podstawowa instrukcja języka SQL - pobiera dane z bazy.

SIPOC to prosta tabelka, która pomaga zrozumieć, jak działa jakiś proces od początku do końca. Używamy jej na początku analizy, żeby szybko zorientować się, kto dostarcza materiały (Supplier), co wchodzi do procesu (Input), jakie są kroki procesu (Process), co z niego wychodzi (Output) i kto jest odbiorcą (Customer). Na przykład, jeśli analizujemy proces robienia kawy, to dostawcą jest sklep z kawą, wejściem są ziarna kawy, proces to mielenie i parzenie, wyjściem jest filiżanka kawy, a odbiorcą jesteś Ty.

SLA (ang. Service Level Agreement, umowa o poziomie usług) to formalne zobowiązanie dostawcy wobec odbiorcy usługi, wyrażone mierzalnymi parametrami: dostępnością, czasem reakcji na incydent, czasem przywrócenia działania - wraz z metodą po

SOA (ang. Service-Oriented Architecture, architektura zorientowana na usługi) to styl architektury, w którym funkcje biznesowe są udostępniane jako usługi: samodzielne, wielokrotnego użytku, o jawnie zdefiniowanych kontraktach i luźnych pow

SQL (ang. Structured Query Language) to standardowy język pracy z relacyjnymi bazami danych: pobieranie danych (SELECT), ich modyfikacja (INSERT, UPDATE, DELETE) i definiowanie struktur (CREATE, ALTER).

Scenariusz testowy (ang. test scenario) to opis sytuacji do przetestowania sformułowany z perspektywy celu biznesowego: co sprawdzamy i po co.

Scenariusze testowe - jako praktyka projektowania ich zestawu - to budowanie kompletu scenariuszy, który pokrywa wymagania, zamiast zbioru przypadkowych pomysłów testerów.

Scope Creep, czyli "pełzający zakres" w projekcie, to sytuacja, gdy do projektu dodawane są nowe, nieplanowane wcześniej zadania lub funkcje, bez odpowiedniego dostosowania budżetu i harmonogramu. Używamy tego terminu, gdy chcemy opisać sytuację, w której projekt powoli rozrasta się poza pierwotne ramy, co może prowadzić do opóźnień i przekroczenia kosztów. Na przykład, budujesz stronę internetową, a klient nagle prosi o dodanie sklepu internetowego, czego nie było w pierwotnym planie.

Scrum to taki sposób pracy, w którym dzielimy duży projekt na małe kawałki, żeby szybko zobaczyć postępy i łatwo wprowadzać zmiany. Używamy go, gdy tworzymy coś nowego, na przykład oprogramowanie, i chcemy mieć pewność, że to, co robimy, naprawdę odpowiada potrzebom klienta. Wyobraź sobie, że budujesz domek z klocków LEGO: zamiast od razu budować cały domek, najpierw składasz jedną ścianę, pokazujesz ją komuś i pytasz, czy mu się podoba, a potem robisz kolejną, uwzględniając jego uwagi.

Scrum Master (SM) to rola w Scrumie odpowiedzialna za skuteczność zespołu: usuwa przeszkody (impediments), dba o zrozumienie i rzetelne stosowanie Scruma, wspiera Product Ownera w pracy z backlogiem i pomaga organizacji współpracować z zesp

Service Blueprint (plan usługi) to rozszerzenie mapy podróży klienta o warstwy zaplecza.

Sign-off (zatwierdzanie wymagań) to formalny akt, w którym osoba odpowiedzialna biznesowo (zwykle Product Owner, sponsor projektu lub klient zewnętrzny) potwierdza, że zaakceptowane wymagania w bieżącej wersji odpowiadają potrzebom biznesowym i zgadza się na rozpoczęcie ich realizacji. Sign-off tworzy baseline - formalny punkt odniesienia, od którego każda zmiana wymaga oddzielnego procesu change control. Forma sign-off zależy od projektu: w small/Agile zespołach to akceptacja PO w Jirze, w projektach enterprise/regulated podpis na PDF lub formalna akceptacja w systemie (DOORS, Polarion, Jama). Sign-off różni się od 'akceptacji' tym, że zawsze tworzy artefakt nadający się do audytu. Najczęstsza pułapka - 'sign-off bez przeczytania' - gdy biznesowy podpisuje 80 wymagań w 30 minut, a po 4 miesiącach twierdzi, że tego nie zamawiał. Praktyka: sign-off odbywa się na warsztacie czytania, nie mailem.

Six Sigma to metoda doskonalenia procesów oparta na danych, której celem jest ograniczenie zmienności - tak, aby proces produkował maksymalnie 3,4 defektu na milion okazji.

Smoke testing (testy dymne) to krótki zestaw testów sprawdzający, czy podstawowe funkcje systemu w ogóle działają - czy nowa wersja „nie dymi" i nadaje się do dalszego, dokładniejszego testowania.

Specyfikacja wymagań oprogramowania (SRS, Software Requirements Specification) to dokument opisujący kompletny zestaw wymagań na system: funkcjonalne, niefunkcjonalne, interfejsy zewnętrzne, ograniczenia i przyjęte założenia.

Spike to krótki, intensywny okres czasu poświęcony na zbadanie problemu lub znalezienie rozwiązania technicznego, którego nie rozumiemy. Używamy go, gdy potrzebujemy zdobyć wiedzę przed podjęciem decyzji lub rozpoczęciem pracy nad zadaniem. Przykładowo, zanim zaczniemy integrować nowy system płatności, robimy spike, żeby sprawdzić, jak działa jego API i czy w ogóle da się go łatwo połączyć z naszym sklepem.

Sprint to krótki okres czasu (zazwyczaj 1-4 tygodnie), w którym zespół pracuje nad konkretnym zestawem zadań, aby dostarczyć działający fragment produktu. Używa się go w zwinnych metodach pracy, żeby regularnie i szybko uzyskiwać postępy oraz zbierać informacje zwrotne. Na przykład, zamiast tworzyć całą stronę internetową na raz, zespół może zrobić w jednym sprincie formularz kontaktowy, a w kolejnym galerię zdjęć.

Sprint Planning to spotkanie na początku każdego sprintu (krótkiego okresu pracy), podczas którego zespół planuje, co konkretnie zrobi w danym sprincie. Chodzi o to, żeby ustalić, które zadania z listy priorytetów (backlogu) zespół zrealizuje i jak to zrobi, żeby osiągnąć cel sprintu. Na przykład, jeśli celem sprintu jest "ulepszenie strony głównej", to podczas Sprint Planning zespół wybiera konkretne zadania, np. "dodanie baneru z promocją" i "poprawa szybkości ładowania", i planuje, jak to zrobić.

Story Points to jednostka miary używana do szacowania wysiłku, jaki trzeba włożyć w realizację zadania (historyjki użytkownika) w projekcie, np. w tworzeniu oprogramowania. Używa się ich zamiast godzin, bo są bardziej abstrakcyjne i uwzględniają złożoność, ryzyko i niepewność. Na przykład, zadanie "Dodanie przycisku" może mieć 1 Story Point, a "Zaimplementowanie systemu logowania" - 5 Story Points, bo jest bardziej skomplikowane.