Jaka jest rola Tech Leada w Delivery?

O tym, że Tech Lead w Delivery programuje – wiemy wszyscy. Ale czy ma również inne obowiązki? Kto tak właściwie odpowiada za rezultaty? O tym (i nie tylko) pomówimy na łamach dzisiejszego wydania.

Rola lidera technicznego w Delivery

W przeszłości, obszar Delivery był postrzegany głównie jako zadanie administracyjne, zarządzane przez Project Managera. Ten często nie był w ogóle techniczny.

Roli lidera technicznego w ogóle nie było, bo po co? Architektura przychodziła z góry, plan przychodził z góry. Czasami taka rola pojawiała się chwilowo, ale ograniczała się jedynie głównie do kontroli jakości produkowanego kodu.

Jednak, podobnie jak w przypadku Discovery, rewolucja w podejściu do tworzenia produktów cyfrowych znacząco zmieniła tę perspektywę. Współcześnie:

• Podejmowanie decyzji architektonicznych zostaje oddelegowane do zespołu produktowego. Architekci stają się członkami zespołów jako liderzy techniczni (lub przechodzą w rolę Staff Engineerów i pomagają podejmować decyzje)

• Project Manager stał się Product Managerem, który ma większą odpowiedzialność za kierunek rozwoju produktu. Z drugiej strony, przez to nie działa już tak mocno w ramach samego dostarczania. I tę właśnie rolę zwykle przejmuje lider techniczny.

Lider techniczny pracuje w o wiele szerszym zakresie – dba na cały proces dostarczania. Chcemy się upewnić, że rozwiązanie jest dostarczane szybko, a rezultat jest wysokiej jakości (czymkolwiek ta jakość jest dla interesariuszy).

Zrozumienie zakresu Delivery może być różne w ramach zespołu – przykładowo ktoś może myśleć, że jego wrzucenie kodu do PR Review, to już jest koniec 😉A dzieje się w temacie o wiele więcej. Warto tutaj zacytować autorów książki „Continuous Delivery" Jez Humble i David Farley:

Done means “released”. This implies ownership of a project right up until it’s in the hands of the user and working properly. There’s none of this “I’ve checked in my code, so it’s done as far as I’m concerned”.

Dlatego też rozpoczniemy od przedstawienia o czym mówimy, mówiąc o Delivery.

Proces Delivery

Tak jak w poprzednim newsletterze, warto rozpocząć od wizualizacji. Poniżej znajdziesz to, jak widzę przykładową tablicę Delivery:

Czy poniższe obszary brzmią znajomo?

• Ready to pull – zadania czekające na rozpoczęcie, to one spływają z Discovery.

• Analysis – dodatkowa analiza i planowanie skoncentrowane pod to rozwiązanie.

• Development – prace programistyczne, testerskie, UI i na wytypowanych uprzednio danych.

• Validate – walidacja rozwiązania w środowisku Staging.

• Deploy – faktyczne wdrożenie na środowisko Prod.

• Post-merge – dokonfigurowanie na produkcji i usuwanie potwierdzonych feature flag.

Najważniejsze jest to, że proces Delivery obejmuje wszystkie działania:

• od rozpoczęcia pracy nad wstępnym pomysłem rozwiązania,

• do uruchomienia końcowego rozwiązania dla klienta na środowisku produkcyjnym.

Ta struktura może się różnić w każdym zespole. I to lider techniczny będzie odpowiedzialny za wspólne wypracowanie, jaka będzie struktura docelowa. Dodatkowo, w zależności od zespołu zostaną Ci przydzielone różne odpowiedzialności, którymi faktycznie trzeba będzie zarządzać (bazując np. na Definion of Done).

Ok, podstawy mamy już z głowy. W kolejnych punktach przejdziemy przez poszczególne etapy procesu Delivery, by przedyskutować jakie elementy są tam kluczowe z punktu widzenia Tech Leada:

• Planowanie

• Dostarczanie

• Po wdrożeniu

Planowanie

Nie będzie chyba nadmiernym uproszczeniem, jeśli powiem, że zwykle pracujesz w Scrumie (czasem pseudo, ale jednak). Więc masz też na pewno wydzielony moment planowania zadania. I to jest właśnie idealny czas, by przeprowadzić kluczowe działania, które usprawnią proces faktycznego dostarczania.

Zakładam, że w ramach tego etapu korzystamy z architektury rozwiązania oraz podziału zadań na mniejsze z procesu Discovery.

Usprawnienia Techniczne

W ramach dowożenia danego rozwiązania dotykasz wielu różnych obszarów systemu. Jest więc szansa na to by równolegle z danym zadaniem usprawnić nieco sam system. Jest to zbliżone do zasady Boy Scout Rule:

Można na przykład:

• Poprawić nazewnictwo,

• Zmienić strukturę klas,

• Dodać wymaganą abstrakcję,

• Usunąć nieużywany kod.

Część z tych zagadnień może być jednak bardzo kosztowna. Dlatego to zwykle na Tech Leadzie spoczywa odpowiedzialność oceny, czy rzeczywiście mamy przestrzeń na usprawnienia.

Aspekty jakościowe

W ramach procesu planowania trzeba również zadbać o odpowiednie aspekty jakościowe. W feworze dostarczania deweloperzy i deweloperki zapominają nierzadko o szczegółach związanych między innymi z:

• Zapewnianiem jakości,

• Obserwowalnością,

• Metrykami biznesowymi,

• Wielojęzykowością.

Możesz więc zadać zespołowi pytania tego typu:

• Jakie przypadki brzegowe trzeba obsłużyć? Jak je będziemy testować?

• W jaki sposób będziemy obserwować procesy?

• Które metryki trzeba zmienić i jakimi danymi?

• O jakich tłumaczeniach należy pamiętać?

To rozwinie samo zadanie, ale jednocześnie da Ci pewność, że zespół dostarczy kompletne rozwiązanie na produkcję.

Zależności

Niekiedy zadania, którymi zarządzasz, zależą od innych zespołów produktowych. Niekiedy od zespołów nie produktowych – tłumaczenia, kontent. Jednak te zadania też muszą być odpowiednio zrealizowane, by zagwarantować sukces.

Dlatego też w ramach dowodzenia zespołem trzeba odpowiednio wcześnie poinformować wszystkie podmioty o swoich zadaniach i uzgodnić priorytety oraz terminy.

Warto też określić kto wewnątrz zespołu będzie koordynował pracę teamu zależnego. Bez takiej osoby:

• Monitorowanie pracy i potencjalnych opóźnień w zespołach zależnych nie będzie realizowane, bo każdy będzie się skupiał na pracy wewnątrz.

• Zespoły zależne nie będą wiedziały do kogo się zwrócić z problemem i nie będą nic pisać lub będą pisać losowo do ludzi niezwiązanych z kwestią.

Zaplanowanie prac

Gdy wszystko powyżej mamy już za sobą, trzeba jeszcze oczywiście zaplanować faktyczne dostarczenie prac. Ale nie martw się, bo i Tutaj mam dla Ciebie garść porad:

1. Ryzyka najpierw

W ramach Discovery zdefiniowaliśmy ryzyka. Część z nich można było zaadresować jeszcze w ramach tego kroku. Ale inne można zweryfikować dopiero podczas Delivery.

Tym ryzykiem chcesz się zająć najpierw. Im wcześniej dane niebezpieczeństwo się zmaterializuje, tym masz większą szansę by coś z nim faktycznie zrobić zanim narobi kłopotów.

2. Vertical slices

Dla większego rozwiązania, staraj się dostarczać je za pomocą pionowych części. Chcemy upewnić się, że rozwiązania będą dostarczane w formule end-to-end. Nie ma nic bardziej dołującego, niż dostarczenie wszystkich warstw i odkrycie na końcu, że się nie łączą.

Tutaj polecam wykorzystać metaforę krojenia ciasta, lub metaforę hamburgera od Gojko Adzica:

3. Zrównoleglanie pracy

Kiedy mamy za sobą podział na pionowe części, to możemy zacząć dzielić po kwestiach technicznych. W ramach tego podziału możemy natomiast się skupić na tym by jak najszybciej zrealizować dany wertykał.

Co można robić równolegle:

• Pisać frontend i backend.

• Pisać API, logikę biznesową i strukturę bazy.

• Tworzyć testy na podstawie struktury API.

• Konfigurować obserwowalność i metryki.

Dla danego wertykału powinno się dać utworzyć podział tak, aby naraz pracowały nad nim 2-3 osoby.

Delegowanie zadań

Czy powinna się tym zająć najmocniejsza osoba? Czy może ktoś się powinien na tym uczyć? Tego rodzaju kompromisami warto zająć się jeszcze na etapie planowania.

Dzięki temu będziesz mógł lepiej zarządzić kompromisem, a dzięki temu zyskasz:

• Szybsze dostarczenie.

• Zwiększenie poziomu wiedzy w zespole.

Dostarczanie

Kiedy przeszliśmy przez planowanie to możemy dostarczać!

Skup się na tym, najszybciej dostarczyć wartość dla ostatecznego klienta. Jednocześnie nie podejmuj decyzji, które mogą długofalowo wpłynąć negatywnie na sam system.

Jedna istotna uwaga:

Rolą lidera technicznego jest zadbanie by sam proces dostarczania przebiegł sprawnie. Nie jest nią samodzielne pisanie danego rozwiązania (chociaż oczywiście będziesz to robić).

Mówię o tym, ponieważ łatwo się zapomnieć i wpaść w wir implementacji. Efekt? Nasza część zostanie dostarczona perfekcyjnie, ale wszystko dookoła polegnie. Nie o to chodzi.

Lider techniczny dba zarówno o terminowość, jak i jakość rozwiązania. Ale wykonuje to przez odpowiednią współpracę całego zespołu, a nie tylko swoje implementacje.

O czym więc pamiętać, patrząc na problem z tej perspektywy?

Pomoc w ramach decyzji architektonicznych

Gdy implementujemy rozwiązanie to często zachodzi pokusa by skorzystać z dodatkowego API, czy zrobić połączenie do bazy innego modułu. Nie było tego na początku w planach, ale co nam przecież szkodzi? Błąd.

W ramach programowania wprowadzamy już i tak masę dodatkowej złożoności i łamiemy założenia architektoniczne. A to oczywiście zwiększa dług technologiczny.

Jako lider techniczny musisz dbać o to, by członkowie zespołu rozumieli:

• Jakie decyzje programistyczne niosą za sobą wpływ architektoniczny.

• Jakie są konsekwencje takich decyzji dla szerszego życia produktu i organizacji.

Podczas dostarczania takie informacje można wyjaśniać np. podczas Code Review. Wtedy zwracamy uwagę na odstępstwa od schematu architektury.

Szczupłe dostarczanie

Czyli praktyki Lean Developmentu zastosowane w praktyce.

Twoim celem jest optymalizacja faktycznego dostarczania – aby zadziało się możliwie jak najszybciej. Chcesz też uniknąć typowych strat wewnątrz procesu dostarczania:

• Tworzenie zbyt dużego rozwiązania, które ostatecznie nie jest wykorzystywane.

• Wykonywanie Code Review zbyt późno i wprowadzanie w efekcie zbyt wielu zmian naraz.

• Zbyt dużo zwrotek do poprzedniego etapu prac – np. z powodu błędów przez brak współpracy pomiędzy developerami i inżynierami jakości.

• Czekanie na inną rolę zespołową, by podjęła pracę.

Aby uniknąć takich strat możesz wykorzystać praktyki Lean:

• Ograniczanie pracy w toku: Pomaga to w utrzymaniu skupienia zespołu na zadaniach krytycznych i poprawia przepływ pracy.

• Zarządzanie przepływem, a nie ludźmi: Skupia nas na jak najszybszej realizacji pracy, zamiast dbać o 100% utylizacji możliwości członków zespołu.

• Unikanie marnotrawstwa przez np. dążenie do eliminacji zbyt późnych Code Review, przeprowadzanie testów wraz z developmentem by szybko odkrywać defekty, zrównoleglanie pracy.

Stopniowe wdrażanie

Dostarczanie zmian w małych jest kluczowe dla uniknięcia problemów związanych ze zbyt dużymi wdrożeniami. Tylko jak to zrobić?

Musisz oddzielić wdrożenie od uruchomienia:

Dzięki tej prostej zmianie, wdrożenie nie będzie równało się już wydaniu. To zaś przyniesie kilka istotnych korzyści. Pozwoli:

• Unikać problemów z dużymi mergami.

• Testować rozwiązanie o wiele szybciej.

• Wdrażać, nawet jeśli brakuje pewnych informacji np. translacji dla danego kraju.

Kilka praktyk wartych rozważenia w ramach tego podejścia to:

• Feature Toggles / Feature Flags: Jesteśmy w stanie przetestować zmianę flagując daną funkcję. To pozwala sprawdzić w małej skali, jak się ona zachowuje i poprawiać już przy kolejnych wdrożeniach.

• Dark Launching: Wdrażana funkcja jest uruchamiana, ale jej wyniki są ignorowane.

• Keystone Interface: Wdrażana funkcja działa na produkcji, ale nie wykonuje widocznych zmian dla użytkownika.

• Canary Release: Chcemy zacząć od uruchomienia funkcji dla małej grupy użytkowników. Będziemy ją dalej otwierać, gdy potwierdzimy, że działa odpowiednie.

Warto rozpocząć nawet od prostych i manualnych flag, by szybko zrealizować główne założenia rozwiązania.

Dbanie o jakość od początku

Odpowiedzialnością lidera technicznego jest dbanie, by jakość była od początku do końca uwzględniona w ramach dostarczania. Jak to zrobić? Pomaga tutaj cytat z książki Implementing Lean Software Development: From Concept to Cash:

Quit depending on inspection to find defects and start building quality into products while they are being built.

Krótko mówiąc, jakość to coś co się wdraża, a nie coś, co się sprawdza. Inaczej kończysz z długotrwałymi poprawkami i ciągłymi zwrotkami.

Kilka porad, jak to robić dobrze:

1. Developerzy znają kryteria jakościowe

Przy opracowywaniu każdego zadania powinny być od razu określane kryteria jakościowe, jakie kod powinien spełniać. Czy mówimy o wydajności, odporności na błędy, czy obserwowalności. Jest to jeden z kryteriów, na podstawie których weryfikujemy odbiór danego zadania.

Chcemy sprawić, by myślenie o jakości było proste – informacje powinny być łatwodostępne i czytelne dla każdego realizatora.

2. Wspólna praca nad testami

Nie ma czynnika bardziej pogarszającego proces dostarczania niż przerzucenie się odpowiedzialnością testy automatyczne pomiędzy grupami. Odpowiedzialność za jakość staje się wtedy jednostkowa, zamiast dotyczyć całego zespołu.

Jeśli w ramach projektu współpracują osobne role, to powinny one i tak spójnie współpracować nad jakością rozwiązania. Tylko wtedy szybko będziemy adresowali takie problemy jak:

• Niedziałające scenariusze.

• Braki w API

• Mockowanie danych.

We wczesnych stadiach projektu nie należy to do zadań łatwych. Dlatego rola lidera technicznego jest kluczowa, aby usprawniać tę współpracę.

3. Jakość jako kryterium zakończenia

Jako lider techniczny byłeś niejednokrotnie w sytuacji, gdzie padło hasło „To dodamy tą jakość później". I to nigdy nie nadchodziło. Dlaczego? Dla nikogo nie było to istotne.

Jako lider techniczny musisz dać do zrozumienia, że jakość jest aspektem, bez którego nie można zakończyć danego projektu. Bez tego łatwo rzucić się w wir dorzucania coraz to kolejnych funkcji.

Praca nad aspektami jakościowymi idzie o wiele szybciej, gdy robimy to małymi partiami per każde rozwiązanie np. pojedyncze logowanie obserwowalności. Jeśli o tym zapomnimy, późniejszy koszt poprawy jakości będzie liczony w miesiącach.

Po wdrożeniu

Udało Ci się uniknąć najpoważniejszych błędów i z sukcesem wdrożyć rozwiązanie na produkcję. Czy to jednak koniec pracy lidera technicznego i pora, by otworzyć szampana? Wstrzymajmy się z tym jeszcze przez chwilę.

Nawet po wdrożeniu wciąż pozostaje kilka rzeczy do zrobienia. I niestety zespół o tym często zapomina, ponieważ po wdrożeniu uważamy, że nasz trud skończony (#ŁotewscyChłopi)

Monitorowanie

Przede wszystkim uruchomienie nie oznacza, że nowe rozwiązanie działa prawidłowo. Zwykle nawet z odpowiednimi alertami może zdarzyć się coś, co ominie naszą sieć bezpieczeństwa. A zwykle nawet takich alertów nie ma.

Co więc monitorować po wdrożeniu? Zwróć uwagę na:

• Wykorzystane zasoby infrastrukturalne,

• Występujące błędy,

• Dłużej trwające procesy,

• Stopień odrzuceń procesów, nawet jeśli nie zgłasza błędów,

• Wybrane wskaźniki biznesowe.

O ile doświadczeni developerzy będą wiedzieli na co patrzeć, tak dla tych świeższych w temacie, będzie to czarna magia. I tutaj Tech Lead musi zadbać o adekwatne wyrównanie poziomu wiedzy w zespole.

Dokonfigurowanie

W bardziej rozbudowanych systemach, zdarza się jeszcze, że wdrożenie dotyczy dodatkowych opcji konfiguracyjnych. I to nie tyle wdrożenie się tu liczy, co uruchomienie samej konfiguracji.

Uruchamiając dane rozwiązanie po raz pierwszy, warto szczególną uwagę zwrócić na niedopuszczenie do zrzucenia tej odpowiedzialności na zespół biznesowy. Co się może zdarzyć, jeśli to zaniedbamy? Najczęściej:

• Zespół biznesowy i tak wraca do nas, po kilku dniach lub tygodniach, w momencie, gdy my już zapomnieliśmy o co chodzi.

• Zespół biznesowy konfiguruje coś w błędny sposób, a produkcja umiera.

Słowem, lider techniczny dba również o to by odpowiednio uruchomić – całe rozwiązanie powinno działać i nie generować dodatkowego zamieszania.

Sprzątanie po sobie

Przy stopniowym wdrażaniu często dochodzi do sytuacji, że rozwiązanie działa, ale nie optymalnie, bądź sam kod nie jest w dobrej jakości. Ale ta sytuacja jest tak naprawdę OK – dostarczyliśmy wartość, a teraz możemy posprzątać.

Dawno temu Kent Beck powiedział:

Make it work, Make it right, Make it fast

Na tym właśnie polega idea refactoringu – poprawiamy kod, bez zmiany jego zachowania. Warto też pamiętać by posprzątać feature flagi. Część z nich została przetestowana i nie jest już potrzebna. Bo flagi się łatwo wdraża, ale równie łatwo zapomina o nich posprzątać. I to ty, jako lider techniczny, musisz za to wziąć odpowiedzialność.

Dokumentacja

Dokumentacja to temat, z którym mało kto się lubi. Jednocześnie brak dokumentacji to przepis na projektową katastrofę.

Jakie rodzaje dokumentacji mogą pełnić kluczową rolępod względem używania produktu? Zwróć uwagę na:

• Architektury – ADR, diagramy, modele bazy,

• Interfejsów API – kontrakty synchroniczne lub asynchroniczne,

• Sposobów używania – nagrania, opisy jak wykorzystywać rozwiązanie,

• FAQ i baza wiedzy – najczęściej zadawane pytania dotyczące produktu,

• Procesy dostarczania – jeśli zmieniliśmy nasz sposób pracy.

Mało kto skupia się na tym aspekcie pracy. I zwykle lider techniczny tworzy praktyki, by to się jednak działo. Np. tworząc rotującą rolę, która dba o dokumentację. Może i nikt tego nie lubi, ale jedna osoba per sprint chyba da radę się przemóc. 😃

Podsumowanie

Tylko łącząc te 3 obszary będziesz w stanie kompleksowo koordynować pracę zespołów technicznych. A to pozwoli Ci naprawdę rozwijać produkt, a nie tylko dostarczać kod.

W kolejnym wydaniu zajmiemy się wszystkim dookoła – Maintenance. Poruszymy tematy takie jak procesy CI/CD, błędy i dług techniczny czy ogólną obserwowalność.

I standardowe pytanie do Ciebie – czy jakiś temat pominąłem? Daj znać w odpowiedzi 🤔