logotyp inwedo
blank blank blank blank

Ścieżki Rozwoju Deweloperów


Rzemiosło programistyczne w Inwedo oznacza troskę nie tylko o to, co robi oprogramowanie, ale też jak jest zbudowane. Jest stylem tworzenia kodu i sposobem pracy w zespole. Jest zgodne z (wywodzącym się z ruchu Agile) manifestem Software Craftsmanship.

Aby ułatwić rozwój ścieżki kariery przygotowaliśmy szkielet i ramy, które pozwolą każdej osobie w firmie na wzrost kompetencji, a tym samym zdobywanie nowych ról i awansu. W swoim założeniu szkielet:

  • określa możliwe poziomy, role i odznaki dla deweloperów,
  • pokazuje, do jakich ról technicznych może awansować członek zespołu,
  • wyjaśnia, jakie kompetencje musi posiadać dana osoba, aby awansować na wyższy poziom lub dostać odznakę dla danej roli;

Skuteczne ramy rozwoju zapewniają zespołowi jasność i dają poczucie znaczącego postępu. Tworząc ścieżki kariery chcieliśmy zapobiec poczuciu stagnacji i niezrozumienia. Nazwy odznak i stanowisk utrzymane są w terminologii “kosmicznej” aby utrzymać spójność z identyfikacją Inwedo.

Domeny Rozwoju

  • Client-Side Web Development, gdzie jako wysokopoziomowe technologie można wyróżnić:
    • Angular
    • React
  • Server-Side Web Development, gdzie jako wysokopoziomowe technologie można wyróżnić:
    • .NET Core / .NET
    • Node.js
  • DevOps

Mobile Web Development oraz Client-Side Desktop development są obecnie poza zakresem działań Inwedo i nie wchodzą w obszary zainteresowań.

Ścieżki rozwoju

  • Space Engineer czyli eksperta dziedzinowego, który docelowo nadaje kierunek rozwoju domeny w Inwedo. Posiada doskonałe umiejętności programistyczne zarówno w zakresie tworzenia, jak i wyjaśniania oprogramowania i produktów. Ciągle kształtuje swoje umiejętności komunikacyjne, gdyż jego praca polega na docieraniu, słuchaniu i destylowaniu informacji;
  • Solar Seeker, dewelopera, który nie ogranicza się do jednego języka programowania lub jednego stosu technologii/domeny. Jest on “poliglotą programistycznym”. Solar Seeker nie jest ekspertem w konkretnym języku programowania, ale swobodnie posługuje się wieloma z nich. Wie, jak poruszać się po różnych stosach, aby rozwiązać większość wyzwań technologicznych, na które się natknie;

Obranie danej ścieżki nie oznacza konieczności trzymania się jej do samego końca. Ścieżkę rozwoju można zmienić w dowolnym momencie, jeżeli uznamy to za stosowne.

Poziomy deweloperów

W ramach ścieżek rozwoju wyróżniamy następujące poziomy:

  • Poziom 1 – Spacecraft Engineer
  • Poziom 2 – Spaceship Pilot
  • Poziom 3 – Spacewalker
  • Poziom 4 – Galaxy Explorer
  • Poziom 5 – Universe Explorer

Każdy z poziomów posiada odpowiednią punktację, która to wpływa na nasze “Salary Formula”. Oprócz samego poziomu, który definiuje naszą wiedzę, doświadczenie i odpowiedzialność możliwe są do zebrania dodatkowe odznaki. Czym są? Opis znajdziesz poniżej?


Dodatkowe odznaki:

W ramach rozwoju wewnątrz Inwedo możliwe do uzyskania są dodatkowe odznaki. Odblokowują się one na konkretnym poziomie naszego doświadczenia. Pierwsze z nich dostępne są na poziomie “Spaceship Pilot”. Zalicza się do nich:

  • Moon Analyst 
  • Space Station Architect 
  • Black Holes Explorer 
  • Ambasador

Odznaki te posiadają dodatkową punktację, która wpływają na Salary Formuła. Dlatego warto jest je “odblokować” w ramach dodatkowych atutów, które przydadzą się nie tylko w codziennej pracy.

Funkcje w zespole

Dodatkowo w ramach pracy nad projektem, w obrębie zespołu oraz całej firmy możliwe są do przejęcia funkcje dające wpływ na projekt/y i kształtowanie zespołu/ów:

  • Lider Techniczny – funkcja ta jest możliwa do przyjęcia na poziomie “Spaceship Pilot” i nie jest funkcją stałą i może ulegać zmianie wraz z trwaniem lub zmianą projektu. Jest niezależna od ścieżek rozwoju i dostępna dla osób, które chcą rozwijać swoje umiejętności zarządzania zespołem.
  • Rekruter Techniczny osoba, która wspomaga dział HR i HOD w rekrutacji, prowadzi spotkania z kandydatami, przygotowuje zadania rekrutacyjne i weryfikuje wiedzę techniczną kandydatów oraz ich dopasowanie do firmy pod względem osobowości. Rekruterzy techniczni powinni być zawsze ze sobą zsynchronizowani by wyniki określania poziomu zawsze były miarodajne.
  • Wycenoznawca – osoba, która wspomaga dział Sprzedaży podczas weryfikacji założeń nowych projektów. Jest w stanie zapoznać się z zapytaniem ofertowym, zebrać potrzebne informacje np. o technologiach, możliwych sposobach wykonania, preferowanej technologii, zaproponować rozwiązanie, wstępnie wycenić projekt, oraz co ważne dopytać dział sprzedaży lub klienta o rzeczy, które mogą mieć wpływ na wstępną wycenę.

Opis domen rozwoju i standardów w nich obowiązujących

Praca w Inwedo obowiązuje według standardów opisanych w naszym Ways Of Working.

Rola każdego dewelopera realizowana jest przez wykonywanie (programowanie, tworzenie i rozwijanie) z należytą starannością zadań technicznych. Uwzględniają one wachlarz prac programistycznych takich jak:

  • projektowanie rozwiązania,
  • analizowanie zgłoszeń,
  • dbanie o jakość,
  • opieka powdrożeniowa;

Kim jest deweloper w Inwedo

Oprócz opisanych wcześniej prac programistycznych każdy deweloper niezależnie od poziomu jaki reprezentuje:

  • powinien realizować prace zgodnie ze standardami i najlepszymi praktykami w duchu ciągłego rozwoju ze szczególnym uwzględnieniem potrzeby komponentyzacji i modularyzacji realizowanych rozwiązań, tak aby umożliwić dzielenie się swoimi osiągnięciami,
  • stosuje się do Ways of Working,
  • minimalizuje dług techniczny, dostrzega potrzeby usprawnień z punktu widzenia jakości, bezpieczeństwa czy wydajności,
  • pisze testy,
  • pisze czysty kod,
  • jest otwarty na:
    • konstruktywną dyskusję dotycząca tworzonych przez niego rozwiązań, nowoczesne technologie,
    • rozwój,
    • naukę,
    • nowe rozwiązania
    • nowe metodyki;
  • pozytywnie odnosi się do realizacji stawianych celów,
  • samodzielnie organizuje swój czas i przestrzeń pracy;

Dodatkowo w ramach każdej z domen obowiązują dodatkowe standardy, których należy się trzymać.

Standardy dla Client-Side Web Development

Programiści Client-Side Web Development projektują wszystko to, co użytkownik witryny widzi i z czym wchodzi w interakcję.

Client-side deweloperzy wykorzystują swoje umiejętności kodowania do tworzenia atrakcyjnych wizualnie, funkcjonalnych i pomocnych aplikacji internetowych i dynamicznych stron internetowych.

Inwedo dla Client-Side Web Development przyjmuje następujące standardy dla wszystkich poziomów:

  • projekty realizujemy w architekturze modularnego monolitu:
    • [Przyglądamy się] Modularyzacja na poziomie dedykowanych bibliotek,
    • Webpack bundle optimization;
    • [Przyglądamy się] Modularyzacja na poziomie dedykowanych bibliotek,
    • Webpack bundle optimization;
    • [Przyglądamy się] Modularyzacja na poziomie dedykowanych bibliotek,
    • Webpack bundle optimization;
  • [wdrażamy] realizowanie funkcjonalności w postaci prostych bibliotek, które można współdzielić między projektami poprzez wydzielenie do osobnych paczek(package’y),
  • Unit and Integration Testing,
  • [przyglądamy się] Domain Driven Design,
  • stosujemy Design Systems
    • silna komponentyzacja (strukturalna i funkcjonalna),
    • Variable-based Sass stylesheets,
    • multiple screen resolution handling;
  • store management:
    • NgRX,
    • NgXS,
    • state services;

Standardy dla Server-Side Web Development

Programiści Server-Side Web Development piszą kod, aby przesyłać dane pomiędzy stronami/aplikacjami i serwerami.

Programiści projektują, budują i utrzymują kod po stronie serwera, który umożliwia taką wymianę danych. Programiści Server-side Web Development pracują “za kulisami”, upewniając się, że wszystko działa tak, jak powinno na serwerach aplikacji.

Inwedo dla Server-Side Web Development przyjmuje następujące standardy dla wszystkich poziomów:

  • projekty realizujemy w architekturze modularnego monolitu
    • [przyglądamy się] architektura mikroserwisowa;
  • [wdrażamy] realizowanie funkcjonalności w postaci prostych bibliotek, które można współdzielić między projektami poprzez wydzielenie do osobnych DLL,
  • Unit and Integration Testing,
  • [wdrażamy] Domain Driven Design,
  • API interfaces
    • REST / RESTful,
    • [przyglądamy się] GraphQL,
    • [przyglądamy się] gRPC;
  • CQS (Command Query Separation),
  • stosujemy narzędzia architektury rozproszonej:
    • Serverless (Azure Functions, XaaS, np. Database as a Service),
    • Message Queuing Systems;

Standardy dla DevOps

Inżynier DevOps wprowadza i zarządza procesami, narzędziami oraz metodologiami w celu zrównoważenia potrzeb w całym cyklu życia oprogramowania, od kodowania i wdrażania po konserwacje i aktualizacje.

Metodyka DevOps polega na ujednoliceniu i automatyzacji procesów, a inżynierowie DevOps odgrywają kluczową rolę w łączeniu kodu, utrzymaniu aplikacji i zarządzaniu aplikacjami. Wszystkie te zadania wymagają zrozumienia nie tylko cykli życia oprogramowania, ale także kultury DevOps, jej filozofii, praktyk i narzędzi.

Inwedo dla DevOps przyjmuje następujące standardy dla wszystkich poziomów:

  • Continuous Delivery,
  • Continuous Integration,
    • static code analysis,
    • dynamic code analysis: Integration and Unit Testing,
    • [wdrażamy] E2e testing;
  • [cel] Continuous Development,
  • [cel] Trunk Based Development,
  • monitoring:
    • application,
    • infrastructure,
    • alerting,
  • cloud computing & containerization,
  • [cel]: Infrastructure as a Code,
    • ARM Templates / AWS Cloud Formation / Terraform / Ansible;

Ścieżki rozwoju

Każda ze ścieżek zawiera w sobie poziomy. Informacja o tym, że ktoś jest na danym poziomie oznacza konieczność posiadania wszystkich umiejętności wyszczególnionych na listach z danego i poprzedniego poziomu. Ilość lat doświadczenia jest czysto orientacyjna i ma pomóc w ocenie kandydata podczas rozmowy kwalifikacyjnej.

Ścieżka Space Engineer (per domena)

Space Engineer to ekspert dziedzinowy, który docelowo nadaje kierunek rozwoju domeny w Inwedo. Posiada doskonałe umiejętności programistyczne zarówno w zakresie tworzenia, jak i wyjaśniania oprogramowania i produktów. Ciągle kształtuje swoje umiejętności komunikacyjne, gdyż jego praca polega na docieraniu, słuchaniu i destylowaniu informacji.

Poziom 1 – Spacecraft Engineer

Zwykle mniej niż 2 lata doświadczenia w swojej domenie

  • Poziom 1
    • ścieżka rozwoju rozwijana jest w sposób indywidualny wspólnie z mentorem do osiągnięcia samodzielności, tj. osiągnięcia poziomu Spaceship Pilot,
    • praca Spacecraft Engineera wymaga dokładnej analizy, więc jego kod wielokrotnie wraca na etapie code review,
    • biegle porusza się w podstawach technologii, ale zaawansowane koncepcje i struktury wymagają dodatkowego omówienia,
    • mimo, że na ogół stosuje standardy i wzorce określone w projekcie zdarzają się odstępstwa, które wymagają komentarza na etapie code review;
    • wykonuje konkretne, ściśle zdefiniowane zadania techniczne;

Poziom 1+

  • realizuje powtarzalne, rutynowe działania;

Poziom 2 – Spaceship Pilot

Zwykle 2-5 lat profesjonalnego doświadczenia w swojej domenie

  • Poziom 2
    • w codziennej pracy (na ogół) nie wymaga dokładnego omówienia metod realizacji zadania,
    • w czasie Code Review nie pojawiają się krytyczne niedociągnięcia (niezgodne ze standardami),
    • od czasu do czasu zdarza się potrzeba zmiany implementacji czy wskazania innej metody na rozwiązanie problemu,
    • samodzielnie realizuje konkretne, jasno określone zadania biznesowe,
    • z łatwością podąża za podejściami i wzorcami zastosowanymi w projekcie,
    • jest samodzielny w diagnostyce zgłaszanych błędów,
    • stosuje metody prewencji aby zminimalizować ryzyko ponownego wystąpienia błędu;
  • Poziom 2+
    • jasno i zwięźle komunikuje zagadnienia techniczne, algorytmiczne, architekturalne,
    • proponuje iteracyjne rozwiązania i usprawnienia;

Poziom 3 – Spacewalker

Zwykle 5-8 lat profesjonalnego doświadczenia w swojej domenie

  • Poziom 3
    • charakteryzuje go samodzielność (chociaż nie boi się prosić o pomoc Designera) w realizacji funkcjonalności począwszy od potrzeby biznesowej i pomysłu, poprzez projektowanie, wykonanie, weryfikację, wdrożenie aż do opieki nad dostarczonym featurem,
    • w czasie Code Review sporadycznie zdarzają się pojedyncze uwagi,
    • aktywnie udziela się w Code Review innych Developerów,
    • potrafi wskazać i uzasadnić rozwiązanie zadania,
    • charakteryzuje się dogłębną wiedzą w swojej domenie. dysponuje szerokim, wachlarzem rozwiązań (technologii) dobierając je właściwe do potrzeby;
  • Poziom 3+
    • kieruje pracami mającymi na celu realizację zgodnie ze standardami złożonych, (wieloetapowych) funkcjonalności – modułów w swojej domenie;
    • niezależnie od Lidera Technicznego pomaga w pracy deweloperom z poziomu 1 – Spacecraft Engineers – i pokazuje im konkretne zadania techniczne (zarówno ich identyfikację, jak i sposób wykonania), które powinni wykonać aby zrealizować postawione cele biznesowe,
    • niezależnie od Lidera Technicznego pomaga w pracy deweloperom z poziomu 2 – Spaceship Pilots – i naprowadza ich na sposoby realizacji poszczególnych zadań biznesowych, podsuwa pomysły, algorytmy, biblioteki, etc.;

Poziom 4 – Galaxy Traveler

Zwykle 8-12 lat profesjonalnego doświadczenia w swojej domenie

  • Poziom 4
    • jego pracę charakteryzuje autonomiczność, a zarazem chętnie korzysta z wsparcia,
    • dzieli się swoim doświadczeniem,
    • charakteryzuje się specjalistyczną wiedzą w różnych technologiach ze swojej domeny,
    • rozwiązuje problemy techniczne o dużej złożoności algorytmicznej lub dotykających obszarów z różnych domen,
    • wykazuje doświadczenie w rozwiązywaniu problemów wydajnościowych i optymalizacyjnych w dużych projektach (co najmniej 6-miesięcznych),
    • w pełni potrafi zarządzać, projektować i utrzymywać podsystemy/proste systemy;
  • Poziom 4+
    • wspiera Universe Explorer w budowaniu profesjonalnych standardów dla całej organizacji poprzez wspieranie zespołów w ich wdrażaniu,
    • wykazuje co najmniej 12-miesięczne doświadczenie w kierowaniu pracami projektowymi realizowanymi zgodnie ze standardami w swojej domenie,
    • kieruje pracami całego zespołu, stawia cele i wspiera w ich realizacji,
    • wdraża usprawnienia i automatyzuje obszary dotyczące codziennej pracy swojej i zespołu;

Poziom 5 – Universe Explorer

Zwykle powyżej 12-15 lat profesjonalnego doświadczenia w swojej domenie

  • Poziom 5
    • charakteryzuje go spojrzenie na obszar ponad projektowy/ogólnofirmowy,
    • aktywnie poszukuje obszarów do usprawnienia, proponuje i wdraża rozwiązania wspierające całą organizację,
    • definiuje standardy i dobre praktyki w organizacji,
    • napędza innowacje i chęć do eksperymentowania odważnie konfrontując rozległe problemy,
    • wspiera, motywuje, uposaża w narzędzia zespoły we wdrażaniu nowych rozwiązań,
    • wspiera Spacewalkerów w rozwiązywaniu stojących przed nimi problemów, naprowadzając i dzieląc się kontekstem,
    • projektuje algorytmy, zwracając uwagę na wydajność, stabilność, bezpieczeństwo;
  • Poziom 5+
    • nadaje kierunek rozwoju domeny w całej organizacji, wnosząc nowe podejścia czy świeże spojrzenie,
    • analizuje trendy i bada rynek pod względem aktualnych standardów;

Ścieżka Solar Seeker

Realizując tę ścieżkę developer rozwija się w kolejnych domenach/technologiach wiodących realizując w nich Ścieżkę Space Engineera. 

Jednak w przypadku wybrania kolejnych ścieżek w technologiach wiodących, każda kolejna “warta” jest w punktacji przyznawanej w “Salary Formula” o połowę mniej niż poprzednia.


Odznaki

W ramach rozwoju wewnątrz Inwedo możliwe do uzyskania są dodatkowe odznaki. Odblokowują się one na konkretnym poziomie doświadczenia. Zalicza się do nich:

Moon Analyst 

Dostępny na poziomie Spaceship Pilot, Spacewalker, Galaxy Traveler i Universe Explorer

  • wspiera na co dzień product ownera w bezpośrednim kontakcie z klientem,
  • analizuje informacje dostarczane przez klienta, szczególną uwagę zwracając na ich wpływ na bieżące funkcjonalności systemu,
  • identyfikuje luki logiczne, brakujące zależności, wpływ nowych funkcjonalności na aktualną logikę na etapie projektowania rozwiązania (przed rozpoczęciem developmentu),
  • komunikuje się w prosty i zwięzły sposób, rozumiejąc, że ostateczne zdanie ma klient,
  • proponuje rozwiązania, usprawnienia przedstawiając różne warianty, a zarazem wskazując na implikacje wynikające z każdego z tych wariantów, przekazuje swoje rekomendacje wraz z uzasadnieniem,
  • dokumentuje ustalenia, dbając o możliwość odtworzenia rozumowania dlaczego zostały podjęte takie a nie inne decyzje,
  • proponuje nowe funkcjonalności – usprawnienia, optymalizacje, automatyzacje na podstawie aktualnego wykorzystania systemu;

Space Station Architect 

Dostępny na poziomie Spacewalker, Galaxy Traveler i Universe Explorer

  • projektuje architekturę rozwiązań obejmując projekty w różnych domenach,
  • projektuje interfejsy komunikacyjne dbając o bezpieczeństwo, wydajność i rzetelność/stabilność projektu,
  • projektuje infrastrukturę wysokopoziomową (integracje pomiędzy różnymi usługami), jak i niskopoziomową (współzależności pomiędzy poszczególnymi modułami),
  • dokumentuje projekty/plany w zwięzły, prosty i zrozumiały sposób,
  • monitoruje i rozlicza realizację projektów architektonicznych,
  • sprawnie reaguje na zmieniające się potrzeby, ograniczenia,
  • aktywnie poszukuje obszarów wymagających optymalizacji,
  • projektuje iteracyjne zmiany pozwalające na stabilną migrację z jednej architektury do drugiej z zachowaniem kompatybilności wstecznej;

Black Holes Explorer

Dostępny na poziomie Spacewalker, Galaxy Traveler i Universe Explorer

  • mentoruje pozostałych deweloperów,
  • określa indywidualną ścieżkę dla Spacecraft Engineers,
  • prowadzi (co najmniej 2 razy do roku) szkolenia dla całej organizacji,
  • świeci przykładem w stosowaniu wzorców i podejść, jest autorytetem dla całej organizacji w swojej domenie,
  • analizuje potrzeby rynku oraz aktualne trendy przekuwając je w nowe standardy do wdrożenia,
  • jest prekursorem nowych bibliotek, podejść,
  • wdraża, przygotowuje proof of concept, snippety kodu ułatwiające innym deweloperom wprowadzenie nowych praktyk,
  • aktywnie kontrybuuje do repozytorium bibliotek\komponentów wykorzystywanych w organizacji;

Ambasador 

Dostępny na poziomie Galaxy Traveler i Universe Explorer

  • sprawia, że jego/jej wiedza i umiejętności są widoczne poza firmą dzięki różnym wydarzeniom (np. uczestniczy jako prelegent w konferencjach czy wydarzeniach, prowadzi swojego bloga/vloga),
  • jest znany w środowisku jako ekspert (np. tworzy raporty, buduje społeczność, kontrybuuje w projektach Open Source),
  • wspomaga tworzenie lub sam tworzy treści techniczne na bloga Inwedo;

Appendix

Opis lidera technicznego

  1. Jest liderem i menadżerem technicznym projektu
  2. Rozmawia z ludźmi i kieruje ich rozwojem w projekcie
  3. Kieruje się wartościami firmy i szerzy je dalej wśród zespołu
    1. jest wzorem dla pozostałych deweloperów, stąd powinien postępować modelowo od trackowania po pisanie kodu wysokiej jakości, bo inni wtedy uznają to za standard, “skoro on tak robi, to ja też mogę”
  4. Dostarcza realną wartość dla klienta a także:
    1. rzuca wyzwania (np. oglądając makiety, oglądając projekty graficzne, podpowiadając funkcjonalności ułatwiające korzystanie z systemu)
    2. podnosi jakość w projektach
      1. testy jednostkowe, e2e, integracyjne
      2. jakość kodu
      3. standardy
      4. dokumentacja projektu
      5. niedopuszczanie do wycieków pamięci
      6. pilnowanie PR
      7. spełnianie oczekiwań i wymagań klienta i zainteresowanych stron oraz na tworzeniu produktu, który spełnia te potrzeby i nadaje się do zamierzonego użytku
      8. jakość osiąga poprzez planowanie, projektowanie i wbudowywanie jej w produkt lub proces od samego początku.
      9. jakość jest planowana, a nie tylko kontrolowana.
      10. zarządzanie jakością i doskonalenie procesów opiera się na ciągłym cyklu planuj-wykonaj-sprawdź-działaj
    3. motywuje
      1. zrozumienie problemu jeżeli członkowie zespołu są mało aktywni
      2. każda osoba ma inne zainteresowania, a zadania, które odpowiadają ich preferencjom, utrzymają ich motywację.
    4. rozumie i przewiduje potrzeby swoich klientów
    5. ustala priorytety projektów zgodnie z potrzebami klientów
    6. pomaga w planowaniu i realizacji
  5. Skupiają się na technicznej stronie wizji i celów klienta, aby pomóc wprowadzić w życie funkcje w zaawansowanej technologicznie, funkcjonalnej aplikacji.
  6. Jest słowny, dotrzymuje terminów, a jeżeli coś idzie nie tak zawczasu informuje o tym zespół i PO
  7. Jest obecny:
    1. TL musi być na każdym daily
    2. jeżeli nie może być o danej godzinie należy zmienić czas wydarzenia
    3. TL ma być obecny przy CR (później może nie być czasu na na zmiany koncepcji),
    4. planning
    5. refinement.
  8. Jest odpowiedzialny
    1. za cały zespół
    2. za koordynację prac
    3. za rozmowy z klientem
    4. za techniczne przygotowanie projektu do startu:
      1. terminowe dostarczenie informacji technicznych i estymat do raport z Warsztatów Discovery,
      2. dostarczenie wspólnie z zespołem do PO informacji czego potrzebujemy od klienta przed startem projektu,
      3. zaplanowanie i wdrożenie wspólnie z zespołem tego, co musimy wykonać po naszej stronie
    5. za ciągła komunikację, dostarczanie informacji i raportowanie do PO
    6. za wybór lub wysłuchanie członków zespołu by uzyskać jak najlepsze rozwiązanie problemu
    7. za tłumaczenie rzeczy technicznych
    8. pomoc zespołom ustrukturyzować pracę, często dostarczaną przez PO, oraz rozwiązać problemy koordynacyjne
    9. utrzymanie tempa i rytmu pracy – Kiedy zespoły nie są zsynchronizowane całość ich działań jest zagrożona. Można to porównać do gry w kosza. Jeżeli wszystko jest zsynchronizowane wiesz, że gdy rzucisz piłkę, inny członek zespołu ją odbierze i zagra nią dalej. Co się dzieje, gdy go nie ma? Gdy wiemy, że że go tam nie będziesz tam rzucać piłką, tylko zagrasz sam lub znajdziesz zastępstwo.
    10. ustala z zespołem wizję techniczną. Współpracuje z zespołem, aby ją aktualizować, rozwijać i przekształcać w realne rozwiązania.
    11. rozmawia i dyskutuje z PO o tym co jest NTH, a co nie jest NTH jeśli chodzi o kod, ale też funkcjonalności,
    12. realne estymaty czasowe, a najlepiej to pracować na story pointsach
    13. zbudowanie pipeline’ów tak aby wdrożenie następowało planowo
    14. zna działanie systemu minimum na poziomie ogólnym i jest w stanie powiedzieć z czego wynikają jakieś założenia, szczególnie na spotkaniach z klientem,
  9. Prowadzenie swojego zespołu zgodnie z wartościami firmy. Oczywiście przez większość czasu, członkowie zespołu podążają za wartościami bez interwencji. Jednakże, niektóre rodzaje problemów sprawiają, że programiści omijają podstawowe zasady. np:
    1. nie można dopuścić do podejścia “jakoś to będzie”, “zrobimy później” (oczywiście dopuszczalne jest przeniesienie do backlogu na później część funkcjonalności o ile to jest w zgodzie z PO)
    2. niekończenie zadań
    3. odpuszczać testów
    4. odpuszczanie PR
    5. jasność Business Value – brak pewności, że produkt rozwiązuje właściwy problem
    6. brak ciągłego zbieranie informacji zwrotnej
  10. Wsparcie PO
    1. także w kontaktach z klientem
    2. pozyskiwanie przez TL od klienta technicznych elementów niezbędnych do wykonania zadań (np. dostępów, zapytań bazodanowych),
    3. wykrywanie zagrożeń
    4. dzielenie się wiedzą
    5. dawać poczucie tego, że projekt jest stabilny, PO musi czuć się bezpiecznie pracując z TLem także pod względem synchronizacji zespołów
    6. ma być responsywny,
    7. spotyka się raz na jakiś czas z PO, aby zatrzymać się i porozmawiać o tym jak się ma projekt, jak idzie współpraca, nad czym trzeba popracować w zespole, co trzeba zmienić.
  11. Efektywne i aktywne szukać rozwiązań – czasem efektywniej jest wrzucić pytanie na techa, zrobić brainstorm z innymi TLami, niż szukanie rozwiązania samemu
  12. Odpowiedzialność i dostępność
  13. Trzeba pamiętać o wzlotach np. podczas prototypowania i upadkach, które pojawiają się często w okolicach procesu wdrożenia lub oddania produktu. Wówczas utrzymanie tempa jest trudne dla członków zespołu.
Dołącz do nas
arrow-up icon