Słownik analityka biznesowego

Agile to zbiór wartości i zasad opisanych w Manifeście Agile (2001): iteracyjne dostarczanie działającego produktu, ścisła współpraca z klientem, reagowanie na zmiany zamiast sztywnego trzymania się planu.

Agile Manifesto to taki krótki manifest, czyli zbiór zasad, który mówi, jak lepiej tworzyć produkty, zwłaszcza oprogramowanie. Chodzi o to, żeby bardziej cenić współpracę z klientem i szybkie reagowanie na zmiany, niż sztywne trzymanie się planu. Na przykład, zamiast przez rok budować idealny program według specyfikacji, lepiej co miesiąc wypuszczać działającą wersję i zbierać opinie od użytkowników.

Awaria to stan, w którym system, usługa albo urządzenie przestaje działać tak, że nie da się pracować; w umowie utrzymaniowej to klasa dotkliwości incydentu z własną definicją zdarzenia, zegarami i konsekwencją finansową, rozliczana według SLA.

BDD to sposób tworzenia oprogramowania, który zaczyna się od opisania, jak program ma się zachowywać z punktu widzenia użytkownika. Zamiast pisać kod od razu, najpierw ustala się konkretne przykłady działania, a dopiero potem pisze kod, który te przykłady realizuje. Na przykład, zamiast pisać kod do logowania, najpierw opisujesz "Użytkownik wpisuje poprawne dane i zostaje zalogowany" i dopiero wtedy piszesz kod, który to umożliwia.

Backlog refinement (dawniej grooming) to regularne doprecyzowywanie elementów backlogu produktu: rozbijanie dużych pozycji na mniejsze, dopisywanie kryteriów akceptacji, szacowanie, porządkowanie kolejności i wyrzucanie rzeczy nieaktualnych

Burndown chart (wykres spalania) to wykres pokazujący, ile pracy pozostało do końca sprintu lub wydania: oś pozioma to czas, pionowa - pozostała praca (story pointy, godziny albo liczba zadań).

Crystal to rodzina lekkich metodyk zwinnych stworzona przez Alistaira Cockburna - jednego ze współautorów Manifestu Agile.

Cumulative Flow Diagram (CFD), czyli diagram skumulowanego przepływu, to taki wykres, który pokazuje, jak zmienia się ilość pracy w czasie w różnych etapach procesu. Używamy go, żeby zobaczyć, czy praca płynie sprawnie, gdzie są wąskie gardła i jak długo zadania czekają na ukończenie. Wyobraź sobie, że masz lodziarnię. CFD pokaże Ci, ile zamówień czeka na przyjęcie, ile jest w trakcie robienia, a ile już wydano klientom - wszystko na jednym wykresie w czasie. Dzięki temu widzisz, czy kolejka do kasy nie jest za długa albo czy za mało osób robi lody.

Design Thinking to sposób na rozwiązywanie problemów, stawiający użytkownika w centrum uwagi. Chodzi o to, żeby zrozumieć potrzeby ludzi i na tej podstawie wymyślić innowacyjne rozwiązania. Na przykład, zamiast projektować nowy telefon, który ma więcej funkcji, Design Thinking skupiłoby się na tym, jak ludzie naprawdę używają telefonów i co im sprawia trudności, żeby stworzyć coś naprawdę użytecznego.

DevOps to sposób pracy, który łączy programistów (Dev) i osoby odpowiedzialne za działanie systemów (Ops), żeby szybciej i sprawniej tworzyć i wdrażać oprogramowanie. Wyobraź sobie, że programista pisze program, a zamiast czekać tygodniami na jego uruchomienie, DevOps pozwala mu od razu go przetestować i udostępnić użytkownikom. Używamy tego, gdy chcemy szybko reagować na potrzeby klientów i ciągle ulepszać nasze programy.

Extreme Programming (XP) to taka bardzo elastyczna metoda tworzenia oprogramowania, która stawia na szybkie reagowanie na zmiany i bliską współpracę z klientem. Używa się jej, gdy projekt jest skomplikowany, a wymagania mogą się często zmieniać, bo pozwala szybko dostarczać działające fragmenty programu. Na przykład, jeśli klient nagle chce zmienić wygląd przycisku w aplikacji, w XP można to zrobić od razu, zamiast czekać na koniec długiego etapu planowania.

Feature-Driven Development (FDD) to sposób tworzenia oprogramowania, w którym cała praca kręci się wokół dostarczania konkretnych "funkcji" (ang. features) dla użytkownika. Używa się go, gdy chcemy mieć pewność, że rozwijamy oprogramowanie krok po kroku, dostarczając działające kawałki regularnie. Na przykład, zamiast budować cały sklep internetowy na raz, najpierw robimy funkcję "dodawanie produktu do koszyka", potem "realizacja zamówienia", i tak dalej.

ITIL (Information Technology Infrastructure Library) to biblioteka dobrych praktyk zarządzania usługami IT (ITSM): jak obsługiwać incydenty, zarządzać problemami i zmianami, utrzymywać katalog usług i rozliczać się z poziomu usług (SLA).

Incydent to nieplanowane przerwanie działania usługi albo obniżenie jej jakości - pojedyncze zdarzenie, które trzeba zarejestrować, nadać mu priorytet i przywrócić działanie, zanim ktokolwiek zajmie się przyczyną.

Model spiralny (ang. spiral model) to iteracyjny model cyklu życia oprogramowania opisany przez Barry'ego Boehma w 1986 r., w którym projekt przechodzi kolejne pętle spirali, a każda z nich obejmuje cztery ćwiartki: ustalenie celów, analizę

PMBOK (ang. Project Management Body of Knowledge) to zbiór standardów i dobrych praktyk zarządzania projektami publikowany przez PMI (Project Management Institute); podstawa certyfikacji PMP i CAPM.

PRINCE2 (ang. PRojects IN Controlled Environments) to metodyka zarządzania projektami zbudowana wokół siedmiu pryncypiów, siedmiu tematów i siedmiu procesów.

Planning Poker (inaczej Scrum poker) to technika zespołowego szacowania pracochłonności, najczęściej w story pointach: po omówieniu elementu backlogu każdy członek zespołu jednocześnie odsłania kartę ze swoją oceną (zwykle ciąg zbliżony do

Przyczyna albo potencjalna przyczyna jednego lub wielu incydentów, prowadzona w utrzymaniu jako osobny rekord dochodzenia. W analizie biznesowej to samo słowo oznacza opisany ból biznesowy, od którego zaczyna się projekt.

Product Owner (PO) to rola w Scrumie odpowiedzialna za maksymalizację wartości produktu: zarządza backlogiem produktu, ustala kolejność prac i podejmuje decyzje o zakresie.

RAD, czyli Rapid Application Development, to szybki sposób tworzenia oprogramowania. Zamiast długiego planowania, stawia się na częste testowanie i zmiany w trakcie, żeby szybko dostarczyć działającą wersję. Używa się go, gdy czas jest ważny i klient może aktywnie uczestniczyć w procesie. Na przykład, zamiast pisać szczegółową instrukcję obsługi aplikacji, tworzy się jej działający prototyp i od razu pokazuje klientowi, żeby zebrać opinie i szybko wprowadzić poprawki.

Retrospektywa to spotkanie zespołu, na którym rozmawiamy o tym, co poszło dobrze, co źle i co możemy poprawić w naszej pracy. Robimy to regularnie, np. po każdym zakończonym projekcie, żeby uczyć się na błędach i stawać się lepszym zespołem. Na przykład, po stworzeniu nowej strony internetowej, możemy porozmawiać, co sprawnie poszło w projektowaniu, co nas spowalniało w programowaniu i jak możemy usprawnić komunikację w przyszłości.

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

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

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.

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ć.

Timeboxing to technika zarządzania pracą polegająca na przydzieleniu zadaniu sztywnego limitu czasu: gdy czas mija, kończysz - niezależnie od tego, czy rezultat jest kompletny - i podejmujesz decyzję, co dalej.

V-Model to sekwencyjny model wytwarzania oprogramowania, w którym każdemu poziomowi specyfikacji odpowiada poziom testów: wymaganiom biznesowym - testy akceptacyjne, projektowi systemu - testy systemowe, projektowi szczegółowemu - testy int

WIP (Work in Progress) to po prostu praca w toku, czyli zadania, które już zaczęliśmy robić, ale jeszcze ich nie skończyliśmy. Ograniczanie WIP pomaga skupić się na dokończeniu tego, co już robimy, zamiast zaczynać nowe rzeczy, co często prowadzi do szybszego zakończenia projektów. Na przykład, jeśli masz 5 zadań do zrobienia, ale ograniczasz WIP do 2, to skupiasz się tylko na dwóch zadaniach naraz, aż je skończysz, zamiast przeskakiwać między wszystkimi pięcioma.

Waterfall (model kaskadowy) to sekwencyjne podejście do wytwarzania oprogramowania: wymagania → projekt → implementacja → testy → wdrożenie → utrzymanie, przy czym każda faza kończy się formalnym zatwierdzeniem, zanim ruszy następna.

XP (Extreme Programming) to metodyka zwinna skoncentrowana na praktykach inżynierskich: programowanie w parach, TDD (najpierw test, potem kod), ciągła integracja, refaktoryzacja, wspólna własność kodu, krótkie cykle wydawnicze i stała obecn

YAGNI (You Aren't Gonna Need It - „nie będziesz tego potrzebować") to zasada z Extreme Programming: nie buduj funkcjonalności na zapas, tylko dlatego, że „kiedyś może się przydać".