You are on page 1of 20

DASA DevOps

Fundamentals
Słownik

Wersja 1.0.0
Listopad 2018
Pojęcie Opis
ang. Agile Zwinność jest podejściem do wytwarzania
oprogramowania, które opiera się o
pol. Zwinność
ograniczone czasowo iteracje. Jej celem
jest budowanie oprogramowania, które
tworzone jest w sposób przyrostowy od
samego początku projektu.

ang. Agile Benefits Widoczność: Gotowe części produktu


dostarczane są regularnie. Właściciel
pol. Korzyści Zwinności
Produktu i interesariusze biznesowi mogą
go zobaczyć podczas demo Sprintów
lub kolejnych wydań na środowisko
produkcyjne. Widoczność tego, co jest
dostarczane jest o wiele większa niż w
przypadku podejścia tradycyjnego do
rozwoju oprogramowania.
Ryzyko: Poprzez zwiększoną widoczność
produktu staje się oczywiste, czy zespół
porusza się w odpowiednim kierunku i
buduje odpowiednie rzeczy. Oznacza to,
że dzięki częstym okazjom do informacji
zwrotnej ryzyko związane z rozwijaniem
produktu jest niższe.
Wartość biznesowa: Poprzez dostarczanie
na koniec Sprintu produktu, który może
być wdrożony, może on już generować
wartość biznesową mimo że całkowity cykl
jego rozwoju jeszcze nie został zakończony.
Dzięki temu, funkcjonalności nie „utykają”
i są wdrażane natychmiastowo. Jest
przeciwne do „tradycyjnego podejścia do
pracy”, w którym produkt jest dostarczany
pod koniec projektu. W ten sposób zespół
otrzymuje informację zwrotną na temat
efektów swojej pracy bardzo późno.

2
Pojęcie Opis
ang. Automated Automatyczne zapewnianie środowisk jest
Provisioning definiowane jako w pełni zautomatyzowane
dostarczanie i utrzymanie komponentów
pol. Automatyczne
środowiska aplikacji. Na przykład, bazy
Zapewnianie
danych lub serwera aplikacyjnego. W
Środowisk
organizacji DevOps, automatyczne
zapewnianie środowisk może
być odpowiedzialnością zespołu
platformowego DevOps.

ang. Backlog Określenie Scrumowe – sesja ta jest


Refinement Session wykorzystywana do definiowania i
wyjaśniania historyjek użytkownika,
pol. Doskonalenie
które najprawdopodobniej pojawią się w
Backlogu Produktu
najbliższym Sprincie, a mogą być niejasne.
Sesja odbywa się zwyczajowo w połowie
Sprintu, dając czas Właścicielowi Produktu
i biznesowi na udoskonalenie historyjek
użytkownika zanim rozpocznie się kolejny
Sprint.

ang. Build Automation Automatyzacja builda zamienia w


sposób automatyczny zmiany w kodzie,
pol. Automatyzacja
wcommitowane przez członków zespołu,
Builda
do postaci artefaktów, które są gotowe
do wdrożenia i walidacji na środowisku
(testowym).

3
Pojęcie Opis
ang. Burn Down Chart Określenie Scrumowe – podczas Planning
Pokera, zadania mają przypisywane
ang. Wykres Spalania
przez zespoł tzw. story pointy. Są to
estymaty w wirtualnej jednostce opisujące
złożoność i pracochłonność związaną z
daną funkcjonalnością. Wykres Spalania
pokazuje zespołowi w trakcie Sprintu, czy
prędkość z jaką zamykają poszczególne
zadania pozwala im ukończyć cel sprintu
o czasie. Daje to okazję zespołowi do
natychmiastowej reakcji, gdyby okazało
się w trakcie Sprintu, że istnieje ryzyko nie
osiągnięcia celu Sprintu.

CALMS Kluczowe składniki DevOps zdefiniowane


przez Damona Edwardsa oraz Johna
Willisa. Culture (Kultura), Automation
(Automatyzacja), Lean (Lean – szczupłe
procesy), Measure (Metryki) oraz Sharing
(Współdzielenie)

ang. Continuous Zdefiniowane przez Jeza Humble’a -


Delivery „Ciągłe Dostarczanie jest o przeniesieniu
planu wydań z rąk IT w ręce biznesu.
pol. Ciągłe
Implementacja ciągłego dostarczania
Dostarczanie
oznacza upewnianie się, że Twoje
oprogramowanie jest zawsze gotowe do
bycia wdrożonym na produkcję przez cały
cykl jego wytwarzania. Każdy build może
poprzez naciśnięcie jednego przycisku
znaleźć się w przeciągu sekund lub minut
automatycznie na produkcji.”

4
Pojęcie Opis
ang. Continuous yy Rygorystyczna Automatyzacja
Delivery Base
yy Skrajna Informacja Zwrotna
Principles
pol. Podstawowe yy Ciągła Zmiana
Zasady Ciągłego
Dostarczania

ang. Continuous Zespoły, które zaadaptowały zasady


Delivery Benefits Ciągłego Dostarczania:
pol. Zalety Ciągłęgo yy Zwiększają swoją prędkość
Dostarczania i powtarzalność poprzez
automatyzację

yy Upewniają się, że jest nieustanny


przepływ wartości w ich procesie
dostarczania

yy Są w stanie działać w dużym stopniu


autonomicznie

yy Robią odpowiednie rzeczy


odpowiednio

ang. Continuous „Ciągłe Wdrażanie różni się subtelnie


Deployment od Ciągłego Dostarczania. W Ciągłym
Wdrażaniu zmiany są automatycznie
pol. Ciągłe Wdrażanie
wdrażane na produkcję, gdy wszystkie
testy wykonują się poprawnie. W Ciągłym
Dostarczaniu decyzja o wdrożeniu zależy
od człowieka.” Dave Farley

5
Pojęcie Opis
ang. Continuous yy Dostarczaj wartość szybciej
Improvement
yy Dostarczaj wartość lepiej
Objectives
pol. Cele Ciągłego yy Zapewniaj usługi taniej
Usprawniania yy Zapewniaj więcej znaczenia pracy

yy Twórz zdrowsze środowisko pracy

ang. Continuous Ciągła Integracja (CI) jest praktyką w


Integration (CI) inżynierii oprogramowania polegającą
na łączeniu kopii prac wszystkich
ang. Ciągła Integracja
developerów w jedną całość kilka razy
(CI)
dziennie” (Wikipedia, marzec 2016).
„Ciągła Integracja zwykle odnosi się do
integracji, budowania i testowania kodu na
środowisku developerskim.” Martin Fowler

ang. Culture Cztery elementy kultury DevOps to:


pol. Kultura yy Budowanie zespołów

yy Odwaga

yy Ciągłe Usprawnianie

yy Przywództwo

ang. Daily Stand-up Określenie Scrumowe – każdego dnia


przy tablicy scrumowej zbiera się zespół
pol. Codzienny Scrum
i każdy członek zespołu dzieli się tym, co
zrobił wczoraj i co zamierza zrobić dzisiaj,
by zespół przybliżył się do osiągnięcia
celu Sprintu. Wszelkie trudności, które
mogą zablokować członka zespołu przed
postępem są dyskutowane na tym
spotkaniu. Codzienny Scrum nie powinien
zająć więcej niż 15 minut.

6
Pojęcie Opis
ang. DASA Model kompetencyjny DASA, który definiuje
Competence 8 obszarów wiedzy oraz 4 obszary
Framework umiejętności kluczowych dla DevOps.
pol. Model
Kompetencyjny DASA

ang. DASA Knowledge 1. Optymalizacja wiedzy biznesowej


Areas
2. Analiza biznesowa
pol. Obszary Wiedzy
DASA 3. Architektura i projektowanie

4. Programowanie
5. Ciągłe Dostarczanie

6. Specyfikacja Testów

7. Inżynieria Infrastruktury

8. Bezpieczeństwo, Ryzyko i
Compliance

ang. DASA Principles 1. Akcje zorientowane na klienta


pol. DASA Principles 2. Odpowiedzialność od początku do
końca

3. Ciągłe Usprawnianie

4. Twórz z myślą o efekcie końcowym

5. Multidyscyplinarne, autonomiczne
zespoły

6. Automatyzuj wszystko, co potrafisz

7
Pojęcie Opis
ang. DASA Skills 1. Odwaga
pol. Umiejętności 2. Budowanie zespołów
DASA
3. Przywództwo

4. Ciągłe Usprawnianie

ang. Defects Ponowna praca, która jest konieczna,


ponieważ aktywność nie została wykonana
pol. Defekty
poprawnie za pierwszym razem. Wymaga
to zmiany uwagi z powrotem na pierwotną
aktywność, zatrzymania innych prac,
analizy problemu i jego naprawy.

ang. Definition of Done Określenie Scrumowe – lista kryteriów


(DoD) (najlepiej, gdy widnieje ona obok tablicy
scrumowej) opisująca, jakie tematy
pol. Definicja
muszą zostać zaadresowane, aby wersja
Ukończenia
produktu została określona mianem
potencjalnie użytecznej. Jest to prosta
lista zawierająca takie zapisy jak: kod
zaimplementowany, testy jednostkowe
napisane, pokrycie testami jednostkowymi
powyżej 80%, testy funkcjonalne wykonane,
test wydajnościowe wykonane, testy
akceptacyjne wykonane, kod przejrzany,
zmiany udokumentowane. Definicja
Ukończenia jasno precyzuje kryterium
skończonej funkcjonalności.

8
Pojęcie Opis
ang. Definition of Określenie Scrumowe – lista zasad
Ready (DoR) (najlepiej, gdy widnieje ona obok tablicy
scrumowej) opisująca, jakie standardy
pol. Definicja
powinna spełniać historyjka użytkownika,
Gotowości
by zostać zaakceptowaną przez Zespół
Deweloperski. Przykładem wpisu na takiej
liście może być: „historyjka użytkownika
znajduje się w Backlogu Produktu”,
„Zespół Deweloperski rozumie problem”,
„historyjka użytkownika jest wyestymowana
przez Zespół Deweloperski” itd. Definicja
Gotowości istnieje, by upewnić się, że
wymagania są jasne od ich zrodzenia
a dodatkowe dyskusje na ich temat są
ograniczone do minimum.

ang. DevOps DevOps to model kulturowy i operacyjny,


który zachęca do współpracy, by budować
pol. DevOps
organizacje IT o dużej przepustowości, aby
osiągać cele biznesowe.

ang. DMAIC Metoda rozwiązywania problemów


składająca się z następujących kroków:
pol. DMAIC
Define (Zdefiniuj), Measure (Zmierz),
Analyze (Poddaj analizie), Improve
(Popraw), Control (Sprawdź).

ang. Engineering Definicja kultury inżynieryjnej (wg


Culture Palantira): „Inżynierzy budują rzeczy, które
rozwiązują problemy. Nie musisz być
pol. Kultura
informatykiem lub posiadać szczególnego
inżynieryjna
tytułu, by być inżynierem. Musisz za to
umieć się odezwać, gdy rzeczy nie są
dobre, oceniać pomysły na bazie ich faktów
i budować rzeczy, które naprawiają to, co
jest popsute.”

9
Pojęcie Opis
ang. Experimentation Eksperymentowanie oznacza testowanie
hipotezy, a w praktyce – próbowanie
pol.
czegoś nowego w oparciu o potrzebę.
Eksperymentowanie

ang. Feedback Istnieją cztery typy pętli zwrotnych:


pol. Pętla Zwrotna yy Pętla zwrotna oparta o testowanie.
Na przykład, wyniki automatycznych
testów jednostkowych, wyniki
automatycznej, statycznej analizy
kodu.

yy Pętla zwrotna oparta o wdrażalność.


Na przykład, wynik automatycznego
wdrożenia, automatyczne „smoke”
testy po wdrożeniu aplikacji,
automatyczne testy stanu zdrowia
aplikacji na środowisku produkcyjnym

yy Pętla zwrotna oparta o zachowanie


aplikacji. Na przykład, wyniki
automatycznych testów interfejsu
użytkownika, wyniki automatycznych
testów obciążeniowych.

yy Pętla zwrotna oparta o klientów! Na


przykład: przychód / miary konwersji.

10
Pojęcie Opis
ang. Impediment Określenie Scrumowe – Tablica
Board zawierająca tematy, które powstrzymują
zespół od wykonywania ich pracy, ale ich
pol. Tablica z
naprawa jest poza zasięgiem zespołu.
Problemami
Zazwyczaj Scrum Master upewnia się,
że problemy są rozwiązywane. Tablica
z problemami powinna zawierać tylko
tematy, które członek zespołu już próbował
rozwiązać sam, czyli nie wszystko jest
umieszczane na tej tablicy. Wpisy na tej
liście mogą zawierać: „brak wystarczającej
ilości biurek”, „zespół w różnych lokalizacjach
pracuje wolniej”, „sieć nie działa kilka razy
dziennie”.

ang. Inventory Typ marnotrawstwa spowodowany


zajmowaniem przez produkt zbyt dużej
pol. Zapasy
ilości miejsca. W kontekście wytwarzania
oprogramowania oznacza to zazwyczaj
pracę (historyjkę użytkownika), która
nie jest w pełni skończona wg Definicji
Ukończonenia i z tego powodu nie możesz
jej pokazać lub wydać, co skutkuje, że praca
ta jest ciągle w statusie „w trakcie”.

ang. ITIL Information Technology Infrastructure


Library (ITIL) jest zbiorem praktyk dla IT
pol. ITIL
Service Management (ITSM), który skupia
się na uspójnieniu usług IT z potrzebami
biznesu.

11
Pojęcie Opis
ang. Kanban Kanban po japońsku oznacza „spis
widoczny”. Natura wizualizacji Kanbana
pol. Kanban
pozwala zespołom komunikować się łatwiej
na temat pracy, która wymaga uwagi,
by upewnić się, że przepływ wartości
w procesie pozostaje taki sam. Kanban
jest świetnym narzędziem do wizualizacji
przyrostu pracy, wąskich gardeł w systemie
i pomaga ograniczać marnotrawstwo oraz
maksymalizować wartość.

ang. Motion Typ marnotrawstwa, dla którego


przykładem może być ksero znajdujące
pol. Zbędny ruch
się tylko na drugim piętrze, co zmusza
pracownika, by chodził po budynku, by
wykonać kopię. Innym przykładem może
być brak dostępu do sal konferencyjnych,
zmuszający zespół do poszukiwania
miejsca za każdym razem, gdy potrzebują
prywatności do dyskusji. W świecie rozwoju
oprogramowania, moment przekazywania
pracy jest określany mianem
marnotrawstwa typu zbędny ruch.

ang. MTTR Średni czas potrzebny do przywrócenia


usługi (ang. Mean Time To Recover)
pol. MTTR

ang, Non-Utilized Typ marnotrawstwa spowodowany


Talent ogniskowaniem zasobów wokół aktywności
wymagającej specjalizacji. Jeśli dana
pol. Niewykorzystany
osoba musi wykonywać tylko jeden typ
talent
zadania, inne jej umiejętności pozostają
niewykorzystane!

12
Pojęcie Opis
ang. Over-processing Zazwyczaj ten typ marnotrawstwa jest
spowodowany przez zespół niepotrafiący
pol. Zbędne
zrozumieć Głosu Klienta (ang. Voice of
przetwarzanie
Customer) lub wizji produktu, co powoduje
implementację przez zespół nadmiaru
niepotrzebnych funkcjonalności. Rola
Właściciela Produktu może okazać się
kluczowa w przeciwdziałaniu temu typu
marnotrawstwa.

ang. Overproduction Typ marnotrawstwa polegający na


produkowaniu więcej niż jest to potrzebne,
pol. Nadprodukcja
generując WIP (praca w trakcie)
zmuszający następny etap w procesie
do martwienia się gdzie (tymczasowo)
przechowywać/archiwizować nadmiarowe
artefakty, by użyć je, gdy nadejdzie taka
potrzeba.

ang. Planning Poker Określenie Scrumowe – na początku


każdego Sprintu (i często podczas
pol. Planning Poker
Doskonalenia Backlogu Produktu) zespół
gra w tzw. Planning Poker, aby być w
stanie określić szacunkowy rozmiar pracy,
który jest wymagany, by ukończyć daną
aktywność. Podczas tej sesji, rozmiary
poszczególnych zadań, a także wspólna
perspektywa na nadchodzące zadania
są ustalane przez zespół. Grając w więcej
takich sesji w dłuższym czasie, szacunki
zespołu staną się bardziej wiarygodne,
a efektywność zespołu może zostać
opisywana prędkością z jaką „spalają”
wspomniane szacunki.

13
Pojęcie Opis
ang. Potentially Określenie Scrumowe – przyrost produktu,
Shippable Product który jest dostarczany na koniec każdego
Sprintu. Jeśli biznes uzna to za konieczne,
pol. Potencjalne
artefakt ten zostanie wdrożony na
Wydanie Przyrostu
produkcję natychmiastowo, ponieważ nie
ma z nim utożsamionej żadnej dodatkowej
pracy.

ang. Product Backlog Określenie Scrumowe – ciągle ewoluująca


i posortowana lista wymagań i tematów,
pol. Backlog Produktu
której celem jest upewnienie się, że
optymalna wartość produktu zostanie
osiągnięta. Backlog Produktu jest jedynym
źródłem prawdy dotyczącym modyfikacji
produktu.

ang. Product Demo Określenie Scrumowe – każdy Sprint


kończy się Demem Produktu dla Zespołu,
pol. Demo Produktu
Właściciela Produktu oraz biznesu/
klienta. Demo jest sposobem, by dać i
otrzymać feedback dla/od interesariuszy
i wykorzystać tę informację do rozwoju
produktu w następnym Sprincie.
Uczęszczanie na Demo Produktu jest
kluczowe, by wzmacniać współpracę,
aktualizować Backlog Produktu i oczywiście
sam produkt.

ang. Scrum Scrum jest najpowszechniejszym


sposobem na wprowadzenie zwinności do
pol. Scrum
organizacji. Jego prostota i elastyczność
jest kusząca dla wielu organizacji. Scrum
kładzie nacisk na empiryczną informację
zwrotną, samoorganizujące się zespoły
i dostarczanie przyrostów produktu w
krótkich interwałach.

14
Pojęcie Opis
ang. Scrum Board Określenie Scrumowe – obrazowy wykaz
aktywności w stylu Kanban, w którym
pol. Tablica Scrumowa
aktywności przesuwają się z lewej strony
do prawej poprzez tablicę pomiędzy
stanami „Do zrobienia”, „W trakcie”,
„Zrobione”, „Zablokowane”.

ang. Scrum Master Rola w Scrumie. Osoba odpowiedzialna


za upewnienie się, że zespół podąża za
pol. Scrum Master
zachowaniami, zasadami i wskazówkami
scrumowymi. Jest to facylitator
upewniający się, że wszyscy grają według
tych samych zasad zdefiniowanych przez
Scruma. Scrum Master wyjaśnia nie tylko
zespołowi, ale także interesariuszom, jak
rzeczy są robione. Scrum Master zapewnia
warunki zespołowi, by mógł on skupić się
na właściwej pracy.

ang. Scrum Product Rola w Scrumie. Właściciel Produktu (PO)


Owner jest odpowiedzialny za maksymalizowanie
wartości produktu. Oznacza to, że
pol. Właściciel
Właściciel Produktu zna biznes oraz
Produktu
klienta i definiuje historyjki użytkownika,
które mają znaczenie dla biznesu oraz
klienta, a wstrzymuje inne wymagania.
PO jest jedyną osobą odpowiedzialną
za utrzymanie Backlogu Produktu. PO
upewnia się, że historyjki użytkownika
spełniają kryteria Definicji Gotowości
(m.in. wymagania są poprawnie opisane),
Backlog Produktu jest odpowiednio
zpriorytetyzowany pod kątem wartości
biznesowej, a przejrzysta komunikacja
między Zespołem Deweloperskim a
biznesem jest osiągnięta.

15
Pojęcie Opis
ang. Scrum Roles Zespół Deweloperski, Scrum Master,
Właściciel Produktu
pol. Role w Scrumie

ang. Scrum Team Rola w Scrumie. Multydyscyplinarny zespół,


który pracuje nad zadaniami ustalonymi
pol. Zespół
na początku Sprintu. Każda umiejętność
Deweloperski
potrzeba do dostarczenia Potencjalnego
Wydania Przyrostu (wynik Sprintu) znajduje
się w Zespole. Zazwyczaj Zespół składa
się z członków, których umiejętności
pozwalają definiować, rozwijać, testować,
wdrażać, utrzymywać oraz komunikować
aspekty produktu. Członkowie Zespołu
samoorganizują się i ciągle usprawniają
ich proces. Biorą odpowiedzialność za to,
jak rzeczy poruszają się do przodu. Typowy
Zespół Deweloperski składa się od 3 do 9
członków.

ang. Sprint Określenie Scrumowe – ustalona ilość


czasu, podczas której aktywności na
pol. Sprint
Backlogu Sprintu są wykonywane. Sprinty
zazwyczaj posiadają stała długość jednego
lub dwóch tygodni, ale spotykane są
również dłuższe okresy (maksymalnie
jeden miesiąc). Skracanie Sprintu oznacza
również krótsze Planowanie, Doskonalenie
Backlogu Produktu, Planning Poker,
Retrospektywę Sprintu, a także maleje
liczba tematów do dyskusji.

16
Pojęcie Opis
ang. Sprint Backlog Określenie Scrumowe – zbiór elementów z
Backlogu Produktu, które zostały wybrane
pol. Sprint Backlog
do Sprintu zawierające zadania potrzebne
do dostarczenia nowych funkcjonalności
na koniec Sprintu (np. aktywności związane
z rozwojem, przeglądem, testowaniem
itd.). Backlog Sprintu zawiera wewnętrzną
prognozę Zespołu Deweloperskiego
dotyczącą nadchodzącego przyrostu.

ang. Story Mapping Story Mapping jest angażującą


aktywnością, podczas której wszystkie
pol. Story Mapping
osoby zaangażowane w proces budują
Backlog Produktu na ścianie.

ang. Story Mapping yy Mniejsze ryzyko w budowie produktu,


Benefits ponieważ pętla zwrotna od
pol. Zalety Story klienta jest wbudowana w proces
Mappingu projektowania

yy Zaangażowanie klienta, ponieważ


system jest projektowany, by
zaspokoić jej/jego potrzeby

yy Szybszy początek projektu dzięki


usunięciu niekończących się
wstępnych sesji projektowych

yy Szybki zwrot z inwestycji, ponieważ


podstawowa wersja produktu jest
dostępna dla klienta we wstępnym
etapie

17
Pojęcie Opis
ang. Task Classification Ćwiartki Klasyfikacji Zadań zostały
Quadrant zdefiniowane przez Charlesa Perrow.
Metoda determinacji, czy zadania mają
pol. Ćwiartki
potencjał to bycia zautomatyzowanymi.
Klasyfikacji Zadań
Ćwiartki wyznaczone są przez dwa
wymiary: analizowalność i zmienność.

1. Zmienność zadań jest definiowana


przez liczbę wyjątków względem
standardowej procedury w aplikacji
stworzonej w danej technologii.

2. Analizowalność zadań jest


definiowana jako zakres, w którym,
gdy napotkany jest wyjątek, są znane
metody analityczne, by sobie z nim
poradzić.

ang. Team Określenie Scrumowe – na koniec każdego


Retrospective sprintu Zespół sprawdza, co poszło dobrze
i niedobrze, dzięki czemu mogą poszukiwać
pol. Retrospektywa
nowych metod usprawnień swojej pracy.
Sprintu
Jest to istotny aspekt Scruma, by ciągle
udoskonalać swój sposób pracy.

ang. Transportation Typ marnotrawstwa spowodowany


potrzebą transportu (np. lodówka jest
pol. Transport
zlokalizowana daleko od zlewu). W
kontekście rozwoju oprogramowania może
to oznaczać konieczność przełączania się
między zadaniami przez ludzi, którzy są
przypisani do wielu projektów. Najszybszym
sposobem, by wykonać dwa zadania, jest
robić je po kolei, a nie równolegle.

18
Pojęcie Opis
ang. Value Stream Określenie Lean. Mapowanie Strumienia
Mapping Wartości (VSM) jest narzędziem, by
zdobyć wgląd w przepływ wartości w
pol. Mapowanie
procesie i może zostać wykorzystane do
Strumienia Wartości
zidentyfikowania aktywności dodających
wartość i aktywności niedodających
wartości. Dzięki tej świadomości możliwa
jest optymalizacja całego procesu.

ang. Waiting Typ marnotrawstwa polegający na tym,


że ktoś musi czekać na następne zadanie
pol. Oczekiwanie
(np. spowodowane nadprodukcją), by
je ukończyć. Zazwyczaj, czekanie jest
spowodowane wąskim gardłem w procesie
albo poprzez nieregularne spotkania i
momenty przekazywania pracy. Opóźnienia
zaburzają ciągłość w procesie.

ang. Waste Określenie Lean. Lean definiuje 8 typów


marnotrawstw:
pol. Marnotrawstwo
Defects (Braki/Defekty), Overproduction
(Nadprodukcja), Waiting (Oczekiwanie),
Non-Utilized Talent (Niewykorzystany
Talent), Transportation (Transport),
Inventory (Zapasy), Motion (Zbędny Ruch) i
Overprocessing (Zbędne Przetwarzanie).

ang. Woodward Kiedy procesy mogą być wysoce


Technology Typology zaprogramowane i zautomatyzowane,
ich wynik będzie przewidywalny i
pol. Typologia
ustandaryzowany. Zautomatyzowane
Technologii
procesy są powtarzalne, a koszt wykonania
Woodwarda
procesy jest zminimalizowany.

19
© 2018 - DevOps Agile Skills Association

All rights reserved. No part of this publication may be published,


reproduced, copied or stored in a data processing system or circulated
in any form by print, photo print, microfilm or any other means without
written permission by DASA

www.devopsagileskills.org

20

You might also like