Przyczynkiem do powstania tego bloga była moja dyskusja z przyjacielem, który w branży IT siedzi od ponad dwóch dekad. W międzyczasie był programistą, architektem systemów, analitykiem biznesowym, PM-em i przedsiębiorcą prowadzącym wieloosobową firmę. Pewnie jeszcze coś by dodał.

Nasza rozmowa dotyczyła faktu, że następuje coraz większe rozdrobnienie specjalizacji w branży IT. Jest to wypadkową rozwoju technologii informatycznych, ale komplikuje realizowanie projektów, rozwijanie produktów i usług.

Człowiek od wszystkiego

Kiedyś programista był istnym omnibusem IT: architektem, projektantem, grafikiem, frontendowcem, backendowcem, testerem, devopsem, project managerem – szumnie nazywał sam siebie panem Informatykiem. Z łatwością dało się osiągnąć tę interdyscyplinarność, o którą teraz tak zacięcie, w postaci ukierunkowania na tzw. T-shaped skills, walczymy w zespołach wytwarzających produkty. Powrót do źródeł? Domyślam się, że poza plusami takiego podejścia, miało ono też swoje minusy. Notoryczny brak czasu, przemęczenie, a co za tym idzie – spadek jakości dostarczanego rozwiązania. Jako były redaktor wiem, jak ciężko jest poprawiać samego siebie. Nie widzi się błędów we własnym tekście, w tym wypadku – w kodzie. Ciężko też wpaść na alternatywne rozwiązanie bez bodźca, jakim często jest rozmowa z drugą osobą.

Takiego omnibusa informatyka przyrównałabym do nauczyciela bez określonej specjalizacji (poza tym, że jego dziedziną jest IT), posiadającego wiedzę ogólną. Im jednak uczeń starszy, tym coraz więcej wokół niego nauczycieli o określonych specjalizacjach, aby mógł poszerzać swoją wiedzę w różnych dziedzinach, aż w końcu zdecyduje się, którą z nich pogłębi. Tak też było i jest z rozwojem technologii informatycznych. Najpierw wszyscy mieli wiedzę ogólną, teraz każdy jest w czymś wyspecjalizowany.

Wysyp specjalizacji

Dawniej technologie informatyczne nie rozwijały się w takim tempie, jak teraz. Można było ogarniać dobre praktyki z każdego zakresu w dziedzinie IT. Obecnie, gdyby jedna osoba miała znać nowinki ze wszystkich obszarów, nie miałaby czasu na pracę. W każdej specjalizacji istnieje wiele alternatyw, z którymi należy być na bieżąco, aby nie wypaść z obiegu oraz aby programować rozwiązania bezpieczne i dobrej jakości. Oliwy do ognia dolewają sami wymyślający i rozwijający poszczególne frameworki (ramy postępowania), co tylko pogłębia podział na specjalizacje oraz rozleniwia co poniektórych programujących. Co bardziej zajęci mają tendencje do sięgania po framework, bo nie chce im się szukać rozwiązania dla określonego problemu. Zwiększa to tym samym tworzoną aplikację o całą zależność, nawet jeżeli programista potrzebuje tylko ułamka jej dostępnych funkcji. Czy to optymalne? Czy mnogość frameworków jest w ogóle optymalna? Mam czasami wrażenie, że wąż zjada własny ogon.

W efekcie, na rynku nie szuka się już ani informatyków, ani programistów. Teraz szuka się programistów od frontendu (specjalizacja). Co więcej, teraz szuka się programistów od frontendu specjalizujących się w określonym frameworku JavaScript: React, Angular, Vue.js (podspecjalizacja), itd. Zamiast inżyniera devopsa (specjalizacja) coraz częściej szuka się eksperta od kubernetesów czy dockerów albo eksperta do utrzymania konkretnej platformy (podspecjalizacja). Technologie już nawet nie idą do przodu, one biegną. Granulacja postępuje. Każdy finalnie specjalizuje się tylko w jakimś wycinku programistycznego ekosystemu, w jakiejś podspecjalizacji. Wszystko świetnie, tyle że na koniec dnia żadna z tych osób samodzielnie nie jest w stanie dostarczyć wartości klientowi.

Konieczna jest praca zespołowa.

Jak pracować?

W toku tych zmian ludzie z branży IT szukali optymalnego rozwiązania, jak realizować potrzeby klientów, dbać o jakość i brać odpowiedzialność za produkt. Szukali metod na zwiększenie prawdopodobieństwa, kontrolowanie ryzyka i dostarczanie szybciej i częściej tego, czego potrzebuje klient.

The nature of the beast is that software requirements rarely change; what changes is our awareness of them, and our grasp of their implications.

Jesse Watson

Zauważyli też, że notorycznie przerywa się im w pracy, co nie pozwala interdyscyplinarnym zespołom wytwórczym skupić się na konkretnej robocie. Programiści mieli dość mikrozarządzania, niekompletnych i niejasnych wymagań, nierealistycznych harmonogramów, ciągłych statusów postępu prac i bezproduktywnych spotkań oraz managerów koordynujących ich prace. Bo koordynacja wygląda czasami jak zabawa w głuchy telefon. Chcieli, jako eksperci, mieć przypisanego do produktu jednego przedstawiciela biznesu oraz samemu decydować o tym, jak projektować rozwiązania, aby były lepiej dostosowane do potrzeb klienta.

Empiryczny Scrum

Z tego tytułu w 1995 roku zebrali sprawdzone praktyki i przedstawili Scruma. Pozwala on wytwarzać, dostarczać i utrzymywać złożone produkty i usługi w oparciu o ciągłe usprawnianie zarówno rozwijanego produktu, jak i samego procesu wytwarzania oprogramowania. Scrum odciążył zespoły programistyczne od ciągłego kontaktu z interesariuszami (osobami, które wpływają na produkt lub w jakiś sposób produkt ma wpływ na nie), których nadmierna aktywność istotnie zaburzała prace zespołu. Ciągłe i chaotyczne uszczegóławianie wymagań w toku prac zmniejszało efektywność procesu wytwórczego, co finalnie wpływało na niezadowolenie samych klientów.

Od tego też miejsca swój początek ma ten blog (brzmi jak scena z „Było sobie życie”). Pojawiła się wtedy rola Scrum Mastera, który wspiera zespół w dostarczeniu oczekiwanego rezultatu (outcome), nie przyjmując funkcji kontrolno-dyrektywnej. Rola ta od początku istnienia (Scrum kończy w tym roku 25 lat!) ewoluowała.

Z uwagi na różnie rozumiany zakres odpowiedzialności, rola Scrum Mastera budzi nadal wiele kontrowersji i bywa niejasna. Na blogu będę opisywać, jak ja rozumiem tę rolę.