Jaka jest rola Tech Leada w Delivery?2024-03-22Cześć! 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 newsletteru. Jak zwykle czekają również na Ciebie najciekawsze newsy z ostatniego 2-tygodnia. A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 Inżynierska prasówkaTym razem rozpoczynamy od prawie że filmowej historii, w której typowy programista dostaje rachunek na prawie pól miliona złotych 🤯 A później napięcie już tylko rośnie.
Rola lidera technicznego w DeliveryW 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:
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:
Dlatego też rozpoczniemy od przedstawienia o czym mówimy, mówiąc o Delivery. Proces DeliveryTak jak w poprzednim newsletterze, warto rozpocząć od wizualizacji. Poniżej znajdziesz to, jak widzę przykładową tablicę Delivery:
Czy poniższe obszary brzmią znajomo?
Najważniejsze jest to, że proces Delivery obejmuje wszystkie działania:
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:
PlanowanieNie 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 TechniczneW 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:
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ścioweW 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:
Możesz więc zadać zespołowi pytania tego typu:
To rozwinie samo zadanie, ale jednocześnie da Ci pewność, że zespół dostarczy kompletne rozwiązanie na produkcję. ZależnościNiekiedy 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:
Zaplanowanie pracGdy 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:
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:
DostarczanieKiedy 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:
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 architektonicznychGdy 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:
Podczas dostarczania takie informacje można wyjaśniać np. podczas Code Review. Wtedy zwracamy uwagę na odstępstwa od schematu architektury. Szczupłe dostarczanieCzyli 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:
Aby uniknąć takich strat możesz wykorzystać praktyki Lean:
Stopniowe wdrażanieDostarczanie 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:
Kilka praktyk wartych rozważenia w ramach tego podejścia to:
Warto rozpocząć nawet od prostych i manualnych flag, by szybko zrealizować główne założenia rozwiązania. Dbanie o jakość od początkuOdpowiedzialnoś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:
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:
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żeniuUdał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) MonitorowaniePrzede 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:
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. DokonfigurowanieW 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:
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 sobiePrzy 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ł:
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ść. DokumentacjaDokumentacja 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:
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. 😃 PodsumowanieTylko łą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 🤔 📧 Prześlij dalejDzięki, że doczytałeś(aś) do końca. 😊 Wszystkie poprzednie wydania newslettera są dostępne tutaj. Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję. A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się. Polecam się na przyszłość!  "Inżynierskie podejście do produktów cyfrowych." P.S. Co myślisz o tym newsletterze? Odpisz :) |
