Kategorie
Nerd Management video

Pomóż zespołowi dowozić więcej i szybciej! Teoria Ograniczeń w praktyce – Wywiad z Konradem Otrębskim – Nerd Management #97

Konrad opowie nam o tym, że prawdziwy konkret i prawdziwie trudne rzeczy leżą nie w Scrumie, ale w tym, jak radzimy sobie z wąskimi gardłami w naszej pracy i jakich narzędzi i metodyk możemy do tego użyć. 

Prawie wszyscy jesteśmy agile i używamy Scruma (według raportu Badanie Społeczności IT 2022 Bulldog job). Tylko czy nam to się udaje? Przeważnie jesteśmy świadomi niedoskonałości Scruma, ale gdybyśmy tylko go dobrze wdrożyli, gdybyśmy robili wszystko zgodnie z Scrum Guide…

W dzisiejszym odcinku naszym gościem jest Konrad Otrębski – developer (PHP, Java, Terraform), tech lead, codzienny praktyk Test-Driven Development, Trunk-Based Development oraz Domain-Driven Design. Jest zwolennikiem WIP, Kanban, kultury DevOps oraz Theory of Constraints.

Konrad opowie nam o tym, że prawdziwy konkret i prawdziwie trudne rzeczy leżą nie w Scrumie, ale w tym, jak radzimy sobie z wąskimi gardłami w naszej pracy i jakich narzędzi i metodyk możemy do tego użyć. 

Z tego odcinka dowiesz się:

  • Jak wykorzystać najlepsze praktyki z przemysłu do usprawnienia procesów w IT?
  • Dlaczego rola Testera Manualnego nie ma większego sensu?
  • Gdzie najczęściej zatykają się nasze procesy?
  • Kiedy Scrum będzie Ci przeszkadzać?
  • Jak przejść od 3 do 150 wdrożeń na proda miesięcznie przy małym zespole?
  • Czym tak naprawdę jest DevOps i skąd to się wzięło?

i wiele więcej 🙂

Agenda

00:00 – Intro
00:57 – Wprowadzenie
02:26 – Wywiad z Konradem Otrębskim
03:02 – Czy Scrum to najlepsza metodologia wytwarzania oprogramowania?
04:08 – Czym jest Teoria ograniczeń (Theory of Constraints)?
06:25 – Gdzie Teoria Ograniczeń jest wdrażana w praktyce?
08:56 – Jak szukać wąskich gardeł w procesach?
11:37 – Jak wykorzystać Teorię ograniczeń w IT?
13:13 – Co z Teorią Ograniczeń ma wspólnego DevOps?
15:13 – Jakie ograniczenia możemy znaleźć u siebie?
18:38 – Czy potrzebni testerzy manualni w zespole?
20:55 – Przykłady naprawy ograniczeń w naszej branży
22:13 – Czym jest Trunk-based development?
24:41 – Skąd czerpać wiedzę na temat Teorii Ograniczeń?
28:16 – Od czego zacząć wdrażanie ToC u siebie?
29:35 – Cycle Time i Lead Time jako jedne z ważniejszych metryk, którą warto mierzyć
31:44 – Gdzie możecie spotkać Konrada?
32:31 – Co jest nie tak z tym Scrumem?
35:07 – Podsumowanie

Wersja do słuchania

.

Linki

Lektury obowiązkowe

Lektury uzupełniające

Ciekawe wystąpienia na kanale Pawła Schmidta

W komentarzach do odcinka dostaliśmy kilka dodatkowych materiałów:

Transkrypcja odcinka

[00:00:57.730] – Paweł
Witajcie w Nerd management, z tej strony Paweł Rekowski i Krzysztof Rakowski. W dzisiejszym odcinku Krzychu zaprosił gościa aby porozmawiać o teorii ograniczeń. Krzychu powiedz nam z kim będziesz rozmawiał i o co tak naprawdę chodzi?

[00:01:12.850] – Krzysztof
Rzucę wiele takich słów kluczowych, żebyście mogli sobie wyrobić zdanie o czym będziemy rozmawiać. Dzisiaj zaprosiłem Konrada Otrębskiego, jak sam o sobie mówi, jego największe osiągnięcie w karierze to ewolucja zespołu produktowego z poziomu trzech deployment na produkcję w miesiącu do stu pięćdziesięciu. Czyli już możecie się domyślać, że będziemy rozmawiać nie tylko o teorii ograniczeń, która jest ciekawym zagadnieniem, ale również o DevOps, o Test Driven Development, Trunk Based Development, Domain Driven Design, o całej kulturze związanej z DevOps chociażby.

[00:01:51.070] – Krzysztof
Konrad jest przeciwnikiem Scruma, więc to też poruszymy i to jest też bardzo ciekawy temat. Ale przede wszystkim kanwą naszego spotkania jest Teoria Ograniczeń – Theory of Constraints.

[00:02:03.460] – Krzysztof
I co ważne, to po nagraniu stwierdziliśmy z Konradem, ze nie wyczerpaliśmy zdecydowanie tematu, więc już teraz zapraszam Was, żebyście sobie zapisywali pytania, pisali w komentarzach, wysłali do nas na maila, bo umówiliśmy się z Konradem, że musimy zrobić dogrywkę. Musimy jeszcze raz się spotkać i nagrać drugą część.

[00:02:24.770] – Paweł
No to nie przedłużając lecimy.

[00:02:26.680] – Krzysztof
Cześć Konrad, dziękuję, że przyjąłeś zaproszenie do naszego podcastu.

[00:02:31.930] – Konrad
Cześć, dzięki za zaproszenie.

[00:02:34.840] – Krzysztof
Jest taka opinia, ze Scrum to jest najlepsze rozwiązanie dla software developmentu, tylko po prostu my nie potrafimy go poprawnie wdrożyć. To jest taki święty Graal, za którym gonimy i gdyby tylko nam się udało tego Scruma dobrze dobrze zrealizować, dobrze wdrożyć do wtedy byśmy osiągali świetne wyniki. A problem jest w nas, bo nam się nie udaje. Nie słyszałem, żeby jakiś zespół działał w idealnym Scrumie i był z niego zadowolony. Czy tak jest?

[00:03:02.690] – Konrad
Wiesz co moim zdaniem tutaj jest… Jest to prawda, ale jest to też nieprawda. Ja uważam, że dobre porównanie do Scruma to jest koszykówka. I w tym kontekście, jeżeli można by powiedzieć, że nie wygraliśmy meczu koszykówki, bo nie potrafiliśmy założyć dżinsów przed meczem. Czy ja osobiście uważam, że Scrum nie wnosi żadnej wartości, a w pewnych miejscach jeszcze nas spowalnia jako zespół. To prawdopodobnie teraz dla słuchacza może brzmieć: z jakiej choinki ten pan się urwał i polećcie mi dilera, który go zaopatruje. Ja bym proponował, żebyśmy sobie najpierw trochę kontekstu zbudowali. Jeśli chodzi o np. teorię ograniczeń, o której dzisiaj chcemy mówić, a potem możemy wrócić do tego pytania, jak się ma do tego Scrum?

[00:03:52.440] – Krzysztof
Powiedziałeś hasło Teoria Ograniczeń. Niektórzy z nas może coś o tym wiedzą, może słyszeli, może nie, ale załóżmy, że nie za bardzo, nie za dużo o tym wiemy. Więc powiedz prosto w ogóle co to jest ta Teoria Ograniczeń? Skąd to się wzięło i czemu to dla nas może być wartościowe?

[00:04:09.090] – Konrad
Teoria Ograniczeń to jest… ona się nazywa teorią, ale tak naprawdę to jest praktyka, która jest stosowana na całym świecie. Najbardziej znana jest z firm produkcyjnych, które produkują jakieś dobra, z fabryk i tak dalej, z zakładów. I tę teorię opracował i nazwał pan Eliahu Mosze Goldratt. To jest taki izraelski naukowiec. I ta teoria jest popularna za sprawą między innymi takiej książki, którą on napisał. Książkę się nazywa „The Goal”, polskie tłumaczenie to jest „Cel”. I ona została napisana w 1984 roku, czyli będziemy mieć teraz niedługo czterdziestkę za niecałe dwa lata. I w tej teorii chodzi o to, że może posłużę się przykładem: jeżeli mamy przykładowo fabrykę, jest to np. huta i produkuje jakieś tam rury, to tę rurę najpierw trzeba pociąć, zespawać, wypiaskować, później jeszcze pomalować i poczekać, żeby wyschła.

[00:05:12.160] – Konrad
Teoria Ograniczeń mówi, że nasze przedsiębiorstwo będzie produkować tyle rur ile jest w stanie to wąskie gardło w tej fabryce obsłużyć. Czyli jeżeli np. na piaskowaniu będziemy w stanie wyprodukować dwie rury na godzinę, to nie ważne, że panowie na stacji gdzie się maluje te rury są w stanie obsłużyć 10 rur na godzinę, bo i tak jesteśmy ograniczeni tym wąskim gardłem.

[00:05:37.480] – Konrad
Czyli trochę tak jakby nie ważne jaka jest duża rura miejska w wodociągach, tyle wody jesteśmy w stanie nalać do garnka ile nam pozwala nasz kran u nas w mieszkaniu.

[00:05:51.220] – Konrad
Tym w skrócie jest Teoria Ograniczeń. To o co tutaj chodzi, to żeby znaleźć jakie to jest ograniczenie u nas w przedsiębiorstwie i sprawić, żeby na tym ograniczeniu, czyli np. na właśnie maszynie piaskującej, przepustowość pracy była większa.

[00:06:09.100] – Krzysztof
Wspomniałeś, że to jest teoria, ale to jest taki koncept, który jest stosowany, prawda? Teraz mówimy o różnego rodzaju przedsięwzięciach przemysłowych, wytwórczych, ale tam to jest stosowane, jest wdrażane i działa?

[00:06:25.780] – Konrad
Tak jest stosowane z sukcesami dosłownie na całym świecie. Na polskim podwórku ja osobiście polecam pana Pawła Schmidta i śledzić jego działania. To jest pan, który prowadzi taką firmę, która się zajmuje ToC i on ma kanał na YouTubie, gdzie jest bardzo dużo. On prowadzi w ogóle takie konferencje dość często, kilka razy w roku takie konferencje face to face. Teraz najbliższa ma być chyba we Wrocławiu na początku grudnia i tam jest bardzo dużo takich przykładów z polskiego podwórka zastosowań ToC w praktyce.

[00:06:58.030] – Konrad
Przykładowo mamy tam, z takich moich ulubionych, jest huta w Ostrowcu Świętokrzyskim, która zatrudnia ponad tysiąc ludzi. Jest przedsiębiorstwo takie z niemieckim kapitałem firma, która produkuje opakowania. Są zastosowania ToC w sprzedaży. Był też pan np. którego firma ociepla dachy. A mój ulubiony przykład sprzed dwóch miesięcy z Poznania, byli państwo, których firma zajmuje się produkcją rur giętych. Przykładowo w autobusach są rury, których się trzymamy, gdy nimi jeździmy. I tam – trochę będę przejaskrawiał – ale generalnie zostało wdrożone, tj. ci państwo odnaleźli ten bottleneck, która maszyna u nich w zakładzie jest tym constrainem i można powiedzieć, że zabrali pracownikom taboret, na którym panowie pracujący przy tej maszynie odpoczywali. I to spowodowało wzrost przepustowości całego zakładu o kilkadziesiąt.

[00:08:00.060] – Konrad
Czyli magia Teorii Ograniczeń polega na tym, że… to samo się działo w hucie w Ostrowcu Świętokrzyskim… magia polega na tym, że te pierwsze ograniczenia i ten ogromny, duży wzrost produkcji się osiąga z praktycznie zerowym nakładem inwestycyjnym. Chodzi o to, żeby tylko znaleźć to ograniczenie i je zaatakować.

[00:08:22.950] – Krzysztof
Tutaj dodam dygresję dla naszych słuchaczy i widzów, że wszystkie książki, o których Konrad wspomina, wszelkie inicjatywy, kanały, itd. umieścimy oczywiście jako linki na stronie tego odcinka, żebyście mogli się do tego odnieść.

[00:08:38.070] – Krzysztof
To o czym mówisz, to brzmi tak bardzo prosto: znaleźć te wąskie gardło, dowiedzieć się co tam można zrobić, żeby zwiększyć przepustowość i już – mamy jakieś rezultaty, które zwiększają wydajność produkcji. Ale czy to faktycznie jest takie proste? Jak szukać tych wąskich gardeł?

[00:08:56.280] – Konrad
To jest proste i nie jest proste jednocześnie. To znaczy takim najczęstszym problemem w tego typu firmach, przedsiębiorstwach jest to, że jest bardzo duży Work In Progress. Czyli to jest taki przysłowiowy – nie widać podłogi, materiały są w fabryce, w hali pod sufit i nie wiadomo gdzie jest ten bottleneck, ten constraint.

[00:09:21.330] – Konrad
I to się osiąga ograniczając Work In Progress, czyli ograniczając liczbę zamówień, którą w danej chwili mamy przetwarzaną. Są na to pewne techniki, którymi się dopatruje gdzie jest ten bottleneck, gdzie jest ten constraint. I później próbuje się sprawić, żeby praca szła szybciej na tym właśnie ograniczeniu.

[00:09:43.860] – Konrad
Taki klasyk to jest właśnie pytanie dlaczego ta maszyna nie pracuje, gdy ludzie mają lunch. To jest taki klasyk. Jednym z takich popularnych działań jest sprawienie, żeby kiedy pracownicy idą na lunch na tym ograniczeniu, to żeby byli zastąpieni przez kogoś innego. I to już sprawia, że efekt jest osiągany w ciągu dosłownie jednego dnia.

[00:10:05.640] – Konrad
Ale tak jak powiedziałeś, jest to trudne dlatego, że ludzie boją się zmiany. Więc tutaj sobie przypominam właśnie ten przykład z tej huty w Ostrowcu Świętokrzyskim. Bo co się okazuje wdrażając ToC? I okazuje się, że na ograniczeniu robota musi iść pełną parą. Ale wszyscy inni już nie muszą pracować pełną parą. A wręcz przeciwnie – prosi się ich o to, żeby nie pracowali, kiedy nie trzeba. I tam się okazało, że ludzie się bali. Najzwyczajniej w świecie się bali nie pracować, bo myśleli, że zostaną zwolnieni. I to było trudne przekonać ludzi do zmiany, że nic im nie grozi. Więc czynnik ludzki najczęściej jest trudny, co jest też popularne u nas w IT, że tak naprawdę się okazuje, że to IT to nie jest programowanie, tylko psychologia.

[00:10:53.700] – Krzysztof
No właśnie, to chciałbym, żebyśmy tak jak tutaj zaproponowałeś, przeszli już z takiego poziomu, który jest dla nas abstrakcyjny w dużej mierze, czyli właśnie rozwiązania przemysłowe – na software development. Czyli żebyśmy wrócili do tego problemu, tego zagadnienia, które zasygnalizowałem na początku. Prawie wszyscy pracujemy w Scrumie i wydaje nam się, że to jest taka najlepsza metoda, najlepszy sposób pracy. I w takim razie w jaki sposób stosuje się Teorię Ograniczeń w software developmencie? I z drugiej strony oczywiście czemu Twoim zdaniem jest to lepsze niż to, jak pracujemy do tej pory?

[00:11:38.100] – Konrad
Teoria Ograniczeń w takim klasycznym ujęciu to właśnie to jest to spojrzenie na przedsiębiorstwo jak na fabrykę, gdzie ta linia produkcyjna i poszczególne stacje, przy których się coś robi z produktem. I chodzi o to, że tę Teorię Ograniczeń stosuje się do wszystkich tzw. operations. Np. nie tylko produkcja, ale też np. sprzedaż, administracja. Np. są zastosowania ze szpitali z właśnie software developmentu. Czyli operations, praktycznie każde przedsiębiorstwo jest naprawdę taką firmą, która się kwalifikuje do tego tzw. operations.

[00:12:16.920] – Konrad
I chodzi tutaj o to, że nawet jeżeli siedzimy sobie wszyscy ciepło w biurze, a nie na jakiejś tam hali produkcyjnej, to to, co my robimy, można ułożyć, zwizualizować właśnie w postaci takiej linii produkcyjnej. Przykładowo ktoś wpada na pomysł ficzerów, potem jakiś UX-owiec to projektuje, potem programista to koduje backendowiec, frontendowiec, potem jest jakiś code review, a potem to ląduje na produkcji. Więc można to ułożyć w linię produkcyjną. I ToC ma tutaj zastosowanie, bo też możemy odnaleźć ten bottleneck, ten constraint i sprawić, żeby praca szła, postępowała szybciej przez naszą linię produkcyjną. W skrócie to o to tutaj chodzi.

[00:12:59.270] – Krzysztof
To powiedz mi, czy możesz – żebyśmy sobie lepiej to wyobrazili – czy możesz nam podać jakieś przykłady w zespołach deweloperskich, gdzie mogą występować te bottlenecki? Gdzie je zobaczyłeś, gdzie te usprawnienia można było wdrożyć? Czy masz takie przykłady, które możecie podzielić?

[00:13:15.050] – Konrad
Wydaje mi się, że nie poruszyłem jednej kwestii, bo tak naprawdę ToC zaaplikowane do świata IT ma swoją nazwę. I tą nazwą jest DevOps. Ale DevOps nie rozumiane jako pan administrator z lat 90., który dzisiaj pisze infrastrukturę w Terraformie, tylko DevOps właśnie rozumiane w takiej postaci, w jakiej to pojęcie zostało ukute, bo ono zostało ukute w 2009 roku, czyli 13 lat temu. Jest taka prezentacja, ona jest dostępna w internecie, z firmy Flickr i tam właśnie to pojęcie zostało ukute, gdzie złamano to ograniczenie, ten problem istniejący między programistami a operations i połączono te zespoły. Czyli wzięto pana takiego typowego admina, włożono go do zespołu deweloperskiego. I się okazało, że nagle taki Flickr jest w stanie robić 10 deploymentów na produkcję dziennie. I wtedy to pojęcie zostało ukute. I w tym kontekście należy je rozumieć jako to ToC zaaplikowane do IT.

[00:14:22.330] – Konrad
I teraz to jest taki problem. No bo tak jak mamy problem z nazywaniem testów – każdy inaczej rozumie co to są testy integracyjne, każdy inaczej rozumie, co to są testy end to end, czy to będą testy Selenium, UI, itd. Mamy problem z definiowaniem rzeczy. I tu jest tak samo z tymi pojęciami dotyczącymi flow. Tak jak w innej części Polski się inaczej nazywa przepitkę, zapojkę, i tak dalej. Ale cel jest ten sam. Cel jest taki, żeby była fajna impreza i żeby na drugi dzień nie było kaca. Może to nie jest najlepsze porównanie, ale te wszystkie rzeczy w stylu Continuous Delivery, Continuous Deployment, DevOps, Extreme Programming mają ten sam cel. Żeby dużo, szybko, sprawnie, tanio, bez bugów dostarczać. Ale różnie się nazywają, ale mniej więcej dotyczą tego samego.

[00:15:12.370] – Konrad
I teraz takie przykłady klasyczne z tych ograniczeń, które my możemy spotkać u nas w zespole, to jest to, czy na przykład żebym ja sobie zmienił ustawienia IP w sieci czy w infrastrukturze, to czy ja mogę zrobić to sam, czy muszę czekać, muszę zakładać ticket i czekać miesiąc, aż zrobi to jakiś tzw. devops, admin innego zespołu? Czy ja mogę sam zrobić deployment jako mid czy junior developer? Czy może muszę poczekać na seniora, czy muszę poczekać na jakiegoś tam QA, który mi to zazieleni itd. To są takie klasyki. Czy deployment robi się automatycznie? Czy ja muszę to robić sam ręcznie przez dwie godziny? To są takie przykłady klasyczne, najpopularniejszych ograniczeń istniejących w działach IT.

[00:16:02.830] – Krzysztof
No właśnie, czyli to nie jest tylko to, że robota się gromadzi gdzieś tam. To, co często się zdarza, to jest to, że developerzy tam coś kodują, a potem testerzy muszą się przegryźć przez to i mają to inventory tych zadań… Tak dobrze używam terminu z ToC? Mają dużo tych tasków, przez które muszą się przegryźć i to się tam gromadzi. Ale z tego co mówisz to nie wyłącznie jest to, że właśnie przed jakimiś pracownikami się, przed ich stanowiskiem pracy, takim wirtualnym, gromadzą zadania do zrobienia, ale to też jest kwestia usprawniania procesów i szukania, gdzie są takie organizacyjne utrudnienia czy organizacyjne jakieś blokady, które powodują, że pracownikom jest ciężej zrealizować cele, które np. mogliby sobie sami zrobić albo zespół mógł sobie sam zrobić.

[00:16:53.380] – Konrad
Tak, to znaczy jeżeli chodzi ci o to, że przykładowo możemy mieć deployment skrypt napisany, który sprawia, że deployment to jest kwestia deploy.sh prod enter w terminalu, jednej komendy i on się zadzieje w ciągu minuty-dwóch. Tak. Jeżeli chodzi o to, czy np. mamy te polityki, o których teraz tutaj wspomniałeś, czy np. czy mamy testy automatyczne, czy musimy czekać na QA, czy musimy sprawdzać coś przez dwie godziny i się upewnić, czy nasza zmiana nie rozwala nic w kodzie, czy może możemy sobie odpalić testy automatyczne? To tak, jak najbardziej o to tutaj chodzi.

[00:17:32.350] – Konrad
Natomiast to co jest istotne to to, że zawsze w każdej organizacji, zespole jest jakieś ograniczenie. Bo gdyby go nie było, to firma by zarabiała jutro miliard dolarów dziennie. Chodzi o to, że zawsze jest jakieś ograniczenie i to jest OK. I chodzi o to tylko, żeby to kontrolować, czyli odnajdywać te ograniczenia, usprawnić pracę. Potem to ograniczenie może się przesunąć gdzieś indziej i znowu to ograniczenie trzeba odnaleźć i usprawnić pracę.

[00:17:58.960] – Konrad
Czyli przykładowo zaczynamy np. właśnie od takich podstawowych rzeczy: czy mamy deployment skrypty automatyczny i trzymamy politykę że ja jestem self-service jako programista, że mogę zrobić coś sam, nie muszę czekać na admina z innego zespołu. No a potem możemy się już zabierać za testy, bo to też jest dość popularne, że po prostu testów się nie pisze w zespołach.

[00:18:20.380] – Krzysztof
Tutaj dotknę jednego tematu, który się pojawił w Twoim bio. Czyli jesteś przeciwnikiem instytucji QA, bardzo mnie ciekawi – z racji tego, że trochę już tutaj wspomnieliśmy o testerach, o pisaniu testów. Jeżeli mógłbyś wyjaśnić to podejście, to co to znaczy, że jesteś przeciwnikiem instytucji QA?

[00:18:38.500] – Konrad
Posłużę się może takim przykładem. Wyobraźmy sobie, że jedziesz na kebaba i zamówiłeś… Jakiego zamawiasz kebaba?

[00:18:44.560] – Krzysztof
Ja przeważnie biorę w cienkim i sos pół na pół.

[00:18:51.160] – Konrad
Sos pół na pół, cienki. OK. I zamówiłeś tego kebaba i okazuje się, że dostałeś na grubym, sos ostry i jeszcze ci nie dali surówki.

[00:18:57.640] – Krzysztof
No to byłbym rozczarowany.

[00:19:00.430] – Krzysztof
Przeważnie dodatkowe mięso biorę, a jakbym nie dostał dodatkowego mięsa to byłbym jeszcze bardziej niezadowolony.

[00:19:05.110] – Konrad
Dokładnie, nie. I potem wracasz do tego pana, który ci kebaba zrobił i on rozkłada ręce i mówi, że to nie jest jego wina, bo tutaj powinien być QA, a go nie ma. To obrazuje istotę tej mojej myśli. Często się zdarza, to już miałem do czynienia z takimi sytuacjami, że QA potrzebuje popatrzeć w 5 sekund, żeby zobaczyć, że to nie o to chodziło, że programista po prostu olał sprawę i nie zrobił tego co trzeba. Więc chodzi mi o to, że ta instytucja takiego typowego testera manualnego sprawia, że zwalamy trochę tę pracę na kogoś innego. A to jednak my jesteśmy programistami i my mamy największe kompetencje, żeby ocenić czy coś jest zrobione dobrze lub nie.

[00:19:50.930] – Konrad
A druga sprawa, drugi aspekt tego problemu jest taki, że ogrom tego co robi taki klasyczny tester manualny można pokryć testami automatycznymi. I do tego to się sprowadza, czyli testy i intencje, motywacje, dyscyplina, dbałość programisty.

[00:20:09.720] – Krzysztof
Tak, zdecydowanie. Zwłaszcza, że jeżeli programista nie zwala nazwijmy to tej odpowiedzialności za to, że to jest dobrze wykonane na testera, tylko staramy się, żeby ten produkt, który wytwarzamy, był dobrej jakości, to wtedy te osoby odpowiedzialne za jakość mogą zajmować się zupełnie innymi rzeczami niż wyłapywanie chociażby oczywistych błędów, że coś jest zrealizowane niezgodnie z tym co zamawialiśmy.

[00:20:34.770] – Krzysztof
Wracając z tej dygresji, to mógłbyś podać jakieś przykłady z życia wzięte, ale już z naszej dziedziny IT, które pozwalają nam sobie wyobrazić, że Teoria Ograniczeń jest możliwa do zastosowania, działa i przynosi wartość w takich zespołach, takich branżach jak my pracujemy.

[00:20:55.840] – Konrad
Tak, tych przykładów jest jest bardzo dużo. Jeżeli by słuchaczy to interesowało, ja polecam taką konferencję DevOps Days, tam jest bardzo dużo ciekawych informacji i w ogóle ludzi, którzy się pojawiają na tej konferencji, siedzą mocno w temacie i dla nich tego typu rzeczy są taką normą dnia codziennego. Z mojego podwórka, z mojego doświadczenia ja najbardziej jestem dumny z tego co się udało swego czasu osiągnąć w Tagvenue, to jest taki start-up, wtedy startup, teraz to już jest firma, która jest obecna na pięciu kontynentach, prawie 100 osób zatrudnia, ale dalej zatrudnia tylko 5 programistów. I to jest coś jak taki booking.com, ale do rezerwowania miejsc (venues) na eventy. No i tam zaczynaliśmy z takiego poziomu, że robiliśmy 3 deploye na produkcję w miesiącu. Czyli odjeżdżał ten pociąg releasowy, QA wszystko sprawdzał itd. Potem się okazywało, że mamy bugi w tym kodzie, który był na tym release branchu, ale świadomie to deployowaliśmy, itd. Stopniowo wprowadzając te zmiany udało nam się po roku-dwóch osiągnąć taki poziom, kiedy zrobiliśmy 150 deploymentów na produkcję w miesiącu, zespół 5 programistów.

[00:22:08.520] – Konrad
Udało nam się to osiągnąć właśnie wprowadzając wiele różnych małych zmian. Takim najbardziej kontrowersyjnym i popularnym jest Trunk Based Development, zwany też Continuous Integration, czyli praca bez branchy. My w ogóle nie pracowaliśmy tak, to jest moja codzienność od tamtych czasów, że w ogóle nie pracuję na branchach, Wszystko puszuje się na master, po czym odpalają się testy automatyczne, które powinny przejść w kilka minut. A potem odpala się deployment skrypt i kod, kiedy ja sobie robię, wychodzę sobie po kawę, kod jest deployowany na produkcję. Ja z testów mam taką pewność, że nawet nie muszę zaglądać na stronę główną, żeby zobaczyć czy wszystko jest okej, bo po prostu ufam tej mojej baterii testów i mogę pracować dalej.

[00:22:55.920] – Konrad
Więc w tym świecie praca wygląda tak, że ja jako programista mam otwarty jeden ticket, pracuję nad nim kilka godzin, może dzień, może dwa. Wrzucam commit jeden, drugi, trzeci, piąty. Wypluję ficzer na proda. W ciągu godziny dostaję zazielenienia z code review od kolegi programisty. Jeszcze może, jeżeli mamy w zespole tego QA, to może się temu przyjrzeć QA, który jest wniebowzięty dlatego, że nie musi testować 50 ficzerów podczas release, tylko jeden, więc wie co się zmieniło. Biznes jest wniebowzięty dlatego, że kontroluje sytuację. Wie, że ryzyko rozwalenia tej produkcji jest niskie. Widzi postęp prac. Ja godzinę po tym jak skończyłem pracować nad tym ficzerem biorę kolejny ficzer. Tak wygląda w skrócie ta rzeczywistość.

[00:23:47.630] – Konrad
Nie ma merge conflictów, kończę dzień pracy z czystą głową itd. Itd. No i to się osiąga dzięki właśnie automatycznym deployment skryptom, to dzięki tej technice pracy nie na branchach, dzięki testom automatycznym.

[00:24:00.620] – Krzysztof
To co mówisz to pozwala lepiej połączyć tę Teorię Ograniczeń z huty stali czy z innych ośrodków przemysłowych do naszego świata: Trunk Based Development, testy automatyczne, CI/CD, limitowanie work in progress to są te pojęcia, z którymi mamy do czynienia.

[00:24:18.770] – Krzysztof
I Teraz chciałbym jeszcze Ciebie zapytać o to w ogóle skąd się możemy uczyć Teorii Ograniczeń w kontekście naszym? Ja wiem, że to jest taki zapoczątkowany przez Elyahu Goldratta trend, że te książki, które się pisze, to są takie historie. To nie są suche podręczniki. To jest na pewno fajne źródło wiedzy, ale nie tylko. Co możesz polecić?

[00:24:41.330] – Konrad
Na pewno polecam właśnie książki Goldratta, czyli „The Goal” – „Cel”. Później „It’s not luck”, to jest część druga tej samej historii i na pewno „Critical chain”. One są też dostępne jako audiobooki. Polecam też książkę „Phoenix Project”, która jest remakiem, to jest remake „The Goal”, czyli panowie, którzy napisali „Phoenix Project” dogadali się po prostu z panem Goldrattem i napisali… To jest ta sama historia, ona się zgadza chyba tam co do 170 strony jest, żeby oddać cześć panu Goldrattowi, oni ułożyli fabułę w identyczny sposób. Czyli jeżeli się czyta „Phoenix Project”, to ma się wrażenie, że to jest plagiat „The Goal”. Ale to jest właśnie zaaplikowanie tego wszystkiego do świata IT. Tam jest historia nie z fabryki, tylko ze świata IT? To jest na pewno książka, którą polecam.

[00:25:31.640] – Konrad
I kolejną rzeczą to jest nie polecam książki „Accelerate”. W sensie książka „Accelerate” jest fajna, jeżeli ktoś potrzebuje, że tak powiem pomachać nią szefowi żeby jakoś kupił tę ideę, że ja nie spadłem z krzesła i że naprawdę to działa. To do tego może być dobra książka „Accelerate”. Ale ja osobiście polecam „DevOps Handbook” z tego samego wydawnictwa, bo to jest biblia… Po pierwsze tłumaczy koncept. Robi i nawiązania m.in. do Goldratta i ToC, po drugie jest zbiorem wielu referencji, dodatkowych źródeł, do których możemy zajrzeć, a po trzecie jest skarbnicą takich potencjalnych ograniczeń, które możemy mieć w zespole. Te, które dzisiaj już wspominaliśmy: deployment skrypt, polityka firmy czy np. hands-offy. Czyli, że w naszym flow potrzeba bardzo dużo dotknię. Dotknięć w cudzysłowie pracowników, żeby coś mogło trafić na produkcję. Np. nie wiem, 2-3 code reviews, zanim w ogóle coś będzie mogło być zdeployowane na produkcję czyli dotknięcie QA itd. Itd. Te wszystkie rzeczy można wyeliminować i sprawić, że to flow jest płynne i szybciej dostarczamy. Polecam bardzo mocno książkę „DevOps Handbook”.

[00:26:45.560] – Krzysztof
To jest bardzo fajna metafora, o której mówisz, z tym dotykaniem, bo to pozwala sobie wyobrazić ile jest takich niepotrzebnych czasami punktów styku.

[00:26:54.350] – Krzysztof
Jeszcze taka książka, która podobała mi się i przyjemnie mi się ją czytało to jest „Rolling Rocks Downhill” Clarka Chinga, to jest też taki pan, który się specjalizuje w Agile i ToC, więc też oczywiście linki do tych wszystkich książek i nie tylko damy Wam na stronie tego odcinka.

[00:27:12.410] – Konrad
Jeżeli mogę coś jeszcze się wtrącić, to chcę raz jeszcze polecić te wykłady z tego co robi Paweł Schmidt, dlatego, że tam można naprawdę zobaczyć i dotknąć dosłownie tego, jeżeli się nawet pojedzie na takie wydarzenie, tych ludzi, którzy to wdrożyli i zobaczyć, że to nie jest tylko w książkach, tylko to naprawdę ludzie praktykują. Więc to to też polecam, mimo że to nie jest nasza domena, to nie jest domena IT, ale pokazuje, że to jest jak najbardziej możliwe otwiera oczy.

[00:27:41.240] – Krzysztof
No i po lekturze tych książek można sobie w łatwy sposób trochę tłumaczyć te pojęcia z oryginalnej teorii ograniczeń na nasz kontekst.

[00:27:49.640] – Krzysztof
Powiedz mi proszę, co nasi widzowie, co nasi słuchacze, których zainteresowała Teoria Ograniczeń, chcieliby się więcej dowiedzieć albo może zacząć coś wdrażać w swoich zespołach? Co mogą zrobić jako pierwsze kroki, kiedy wrócą do swoich zespołów, żeby robić coś lepiej, robić coś w duchu Teorii Ograniczeń. Może pomyśleć nad zrzucaniem kajdanów Scruma, o których mówiłeś kilkakrotnie.

[00:28:16.190] – Konrad
Poza oczywiście zgłębianiem tej wiedzy, podstaw, o których tutaj wspomnieliśmy. Na pewno warto sobie zwizualizować ten proces, czyli narysować w postaci na przykład Kanban boardu, jak działa ta nasza zespołowa fabryka? Jakie mamy etapy pracy, od pomysłu aż do dostarczenia na produkcję. No i później trzeba się zastanowić, gdzie jest ten bottleneck i spróbować go zaatakować. To można zrobić na wiele sposobów. Jednym sposobem jest to, że dopatrujemy się tego, gdzie tak jak wspomniałeś, gdzie to inventory pod sufit, czyli przed którym etapem prac jest to bardzo duże work in progress, zalega praca. I tam prawdopodobnie jest bottleneck. I wtedy trzeba już te bottlenecki konkretne atakować.

[00:29:05.960] – Konrad
Teraz drugą techniką, która nam ułatwia dopatrzenie się tego jest po prostu z dnia na dzień wprowadzenie limitu na work in progress. Czyli jeżeli teraz mamy otwarte 50 ticketów, to nie otwieramy kolejnego ticketu, dopóki np. o połowę nie spadnie nam ta liczba. Czyli np. wprowadzamy sobie limit na poziomie 50% – czyli 25. Dopiero jak uporamy się z tymi 25, to dopiero wtedy możemy otworzyć kolejny ticket.

[00:29:35.780] – Konrad
Powinniśmy zacząć mierzyć też cycle time, bo to jest taka istotna metryka w tym świecie DevOps i ToC. Czas od kiedy programista… są różne definicje tego, ale możemy przyjąć, jedną z definicji to jest – zaczynamy mierzyć, gdy programista zaczyna pracować nad ficzerem, a kończymy mierzyć, gdy ficzer jest na produkcji.

[00:30:00.230] – Konrad
Inną metryką jest lead time. Tutaj zaczynamy mierzyć wcześniej. Zaczynamy mierzyć, kiedy stwierdzamy, że będziemy chcieli pracować nad tym ficzerem, czyli on wskakuje do tej kolumny „to do”. Jeżeli mielibyśmy to porównać do pizzerii, to lead time zaczynamy mierzyć, gdy klient dzwoni z zamówieniem. Cycle time gdy pan od pizzy zaczyna to zamówienie robić, zaczyna lepić pizzę, rzucać kawałki na nią, a kończymy mierzyć, gdy pizza wyjeżdża z pizzerii, albo gdy jest realnie do klienta dostarczona.

[00:30:32.600] – Konrad
I chodzi o to, żeby ten nasz cycle time, czy lead time, bez względu na to, co mierzymy, spadał. Bo wtedy właśnie, jeżeli dzisiaj on wynosi trzy miesiące, czyli ja wpadłem na pomysł, on za 3 miesiące będzie na produkcji, to to jest średnio agile, prawda? Tutaj teraz dotykamy tego, co to właśnie jest to agility. Ale jeżeli UXowiec czy jakiś tam product manager wpadł na pomysł na ficzer przedwczoraj, a on jutro jest na produkcji. No to to jest agility, to jest konkret.

[00:31:05.810] – Konrad
A dlaczego to się dzieje? Dlatego, że mam mały work in progress, mam testy automatyczne, mam deployment skrypt, umiem pracować bez branczy itd. To wynika z tych wszystkich różnych małych konkretów. Kończymy właśnie z agility w postaci takiej, że ktoś wpadł na pomysł na ficzer przedwczoraj czy przedwczoraj dostaliśmy feedback z produkcji, jutro jest wdrożony.

[00:31:27.950] – Krzysztof
Bardzo dziękuję Konrad za podsumowanie Teorii Ograniczeń dla naszych widzów i naszych słuchaczy. Powiedz mi proszę, co robisz, co publikujesz, gdzie można Ciebie znaleźć, gdzie można Ciebie spotkać, bo wiem, że jesteś aktywnym prelegentem na konferencjach i innych wydarzeniach.

[00:31:44.600] – Konrad
Tak, występuję na konferencjach, gdzieś tam staram się występować właśnie na konferencjach, więc tam można mnie zobaczyć. Coś tam wrzucam na LinkedIn, to jest jeśli chodzi o tę moją obecność w social mediach czy w naszej społeczności. Więc zapraszam na mojego LinkedIn. Można tam zacząć śledzić. I myślę nad wskrzeszeniem mojego bloga i może nawet otwarciem jakiegoś kanału na YouTube. Ale jeżeli to się wydarzy, to na pewno będę o tym informował na LinkedIn. Na co dzień zajmuję się, prowadzę taki butikowy software house, no i zajmuję się też doradztwem we wdrażaniu właśnie tego typu flow, czyli przechodzeniu na te wyższe poziomy flow. Jeżeli ktoś jest zainteresowany, to też zapraszam, żeby się połączyć na Linkedin.

[00:32:32.050] – Krzysztof
Zapomnieliśmy jeszcze odnieść się do tego, co powiedzieliśmy na samym początku, o czym dyskutowaliśmy w pierwszych minutach naszego wywiadu, czyli o kwestii Scruma, którego Konrad jest zagorzałym przeciwnikiem. No to Konrad, Jak to jest z tym Scrum?

[00:32:48.040] – Konrad
Mój problem, główny problem ze Scrumem jest taki, że te wszystkie praktyki, o których dzisiaj mówiliśmy deployment skrypty, umiejętność pisania testów, najlepiej Test Driven, zmiany, które mogą boleć organizacje, bo np. chcemy się pozbyć instytucji QA, chcemy zmienić polityki w firmie, że np. ja mogę sam zrobić deployment na produkcję przed code review, że mogę sam zmienić ustawienia sieci nie czekając na jakiegoś tam admina z innego zespołu. To to są rzeczy trudne. I to są konkrety. To agility, o którym o którym mówiliśmy: wczoraj wpadłem na pomysł, jutro deployuję to na produkcję.

[00:33:26.080] – Konrad
I mój punkt jest taki, że Scrum bez tych wszystkich konkretów jest niestety niczym sam w sobie. Natomiast te wszystkie konkrety bez Scruma to jest ogromna wartość. To jest mój problem. Wracając do przykładu z koszykówki, to wyobraźmy sobie takiego Michaela Jordana, któremu ktoś mówi, żeby na dzisiejszym wystąpieniu założył właśnie te spodnie, dżinsy i on pewnie dalej wygra ten mecz koszykówki. Może się będzie zastanawiał, czemu mu każemy w spodniach dżinsowych grać. No i tutaj chodzi o to, że ten Scrum on może jakoś tą wartość wnosić, może nas inspirować do pozytywnych rzeczy, ale na pewnym poziomie, jeżeli jest się na pewnym poziomie flow, właśnie na poziomie takich 150-200 deploymentów na produkcję per zespół, to w ogóle się zapomina o tym Scrumie. W ogóle nie chce się za bardzo w to wchodzić i zaprzątać sobie tym głowy. Ale tutaj już odchodzimy od definicji Scruma w stylu Scrum Guide, a wchodzimy w bardzo dużo teorii, których narosło wokół Scruma. Ale zostańmy przy tym, że po prostu Scrum sam w sobie bez tych konkretów nie wnosi żadnej wartości. A te wszystkie konkrety, o których mówiliśmy bez Scruma, są same w sobie dużą wartością i złotem.

[00:34:51.130] – Krzysztof
I to jest bardzo fajne podsumowanie. Pracujmy nad tym, żeby usprawniać te konkrety, a nie szlifować coś, co jest jakąś poboczną kwestią, jakimiś zadaniami, które robimy tylko po to, żeby sobie wypełnić czas w kalendarzu. I to jest bardzo fajne podsumowanie tego tematu. Bardzo dziękuję.

[00:35:06.730] – Konrad
Dzięki.

[00:35:07.600] – Paweł
Jak mówiłeś na początku to był mega wartościowy wywiad i tutaj dużo ciekawych rzeczy się pojawiło, także wielkie dzięki za super wywiad.

[00:35:16.910] – Krzysztof
Tak, i koniecznie zajrzyjcie na stronę odcinka, bo Konrad wrzucił nam naprawdę bardzo dużo materiałów, również takich, o których nie mówiliśmy w odcinku, ale które warto po prostu przeczytać. I tak jak wspomniałem na samym początku, jeżeli macie jakiekolwiek pytania, chcielibyście rozszerzyć temat, zadać pytania Konradowi, to zróbcie to, bo będziemy się umawiać na kolejny odcinek.

[00:35:40.030] – Paweł
Super! A jeżeli chcecie być na bieżąco, to koniecznie zapiszcie się do newslettera na stronie nerd.managment/newsletter. Dzięki temu będziecie na bieżąco z naszymi odcinkami. Dostaniecie bezpośrednio od nas powiadomienia o tym, że pojawiliśmy się już w internetach, a pojawiamy się co wtorek o 8:00, ale również czekają tam na Was dwa specjalne bonusy, czyli polecane książki i checklisty, które możecie wykorzystać w swojej pracy, do których gorąco zachęcamy.

[00:36:08.400] – Paweł
I cóż, widzimy się już za tydzień. Także dzięki wielkie za dziś. Trzymajcie się! Cześć!