Kapituły, czyli jak stworzyć samorganizujące się działy IT

Scrum? Waterfall? Co rusz słychać wyższość jednej metodyki wytwarzania oprogramowania nad drugą. Wyjdźmy jednak poza schemat i zadajmy sobie pytanie. Czy istnieje inny sposób na organizację zespołów i przepływu informacji? Czy jesteśmy w stanie rozszerzyć możliwości metodologii wytwarzania oprogramowania tak, aby zespoły deweloperskie wykonały swoje zadania na czas i zarazem przekazały wiedzę innym zespołom? Dzisiaj opiszę podejście zwane kapitułą.

Piotr Czech. Konsultant w firmie VLOG, gdzie wspiera rozwój oprogramowania u klientów. Budował systemy oparte o RODO oraz mobilne systemy telemetryczne zbierające i przetwarzający dane o kierowcach w celu obniżenia ubezpieczeń, między zadaniami na poprawianie bugów. Entuzjasta podejść architektonicznych w systemach oraz budowania wydajnych rozwiązań opartych o platformę .NET poprzez eksplorację nowych technik oraz uczenie innych… i gonienie ich, jeśli nie przykładają się do kodu.

Metodologie

Oprogramowanie powinno być wydajne, tanie i łatwe w utrzymaniu, więc na bazie doświadczeń powinniśmy stworzyć system (metodologię lub proces), który ułatwi nam dostarczenie wartości dodanej, jednak często dzieje się to z marnym skutkiem.

Dla średnich i dużych projektów według raportu chaosu waterfall sromotnie przegrywa walkę ze scrumem. Dla małych projektów jest to w miarę wyrównana walka. Według Jeffa Sutherlanda i jego książki pt. “Scrum. Czyli jak robić dwa razy więcej, dwa razy szybciej” przeciętny zespół pracuje 400% wydajniej w scrumie w porównaniu do waterfall, a dla elitarnych zespołów ten współczynnik rośnie do 800%.

Waterfall

Waterfall nazywam “schodami do piekła”, im dłuższy projekt tym głębiej schodzisz, aby napić się herbatki z diabłem. Przyjmuje się zasadę, że każdy etap to tak zwana “10”, czyli powrót do poprzedniego etapu i naprawa go kosztuje 10 razy tyle, co zaplanowaliśmy i jest liczbą wykładniczą 10. w zależności od ilości kroków w tył.

Scrum

Scrum w odróżnieniu od waterfall bazuje na iteracji, w której w krótkim czasie dostarczamy działającą funkcjonalność, zarazem mając informację zwrotną od klienta czy rozwiązanie spełnia jego standardy.

Najważniejsze w tej całej układance jest Product Backlog oraz rola Product Ownera, który definiuje co ma być zrobione, aby dostarczyć biznesowi jak największą wartość, ponieważ to on (tj. Product Owner) jest potrzebą, którą trzeba zaspokoić.

Dzięki takiej wiedzy zespół może usiąść do planowania najbliższego wydania i zbudować sprint, z którego zadania będą pobierane.

Sprint trwa od 1-4 tygodni, gdzie codziennie odbywa się Daily Scrum(DS), które służą, aby odpowiedzieć na trzy pytania:

1. Co zrobiłem wczoraj?

2. Co będę robił dzisiaj?

3. Jakie mam problemy?

Zespół ma 15 minut na odpowiedzenie na te wszystkie pytania z osobna. Po skończeniu sprintu następuje pytanie czy wszystko udało się dowieźć w czasie, czyli następuje Sprint Review.

Zadania, których nie udało się wykonać trafiają ponownie do backloga i następuje jego rewizja z zespołem i biznesem, następnie zespół przechodzi retrospektywę, w której wymienia się doświadczeniami co można poprawić, a co zostawić w dotychczasowej pracy.

Z każdym sprintem zespół mierzy swoją prędkość dzięki czemu Product Owner wie jaka jest moc przerobowa zespołu i tak dostosowuje swój backlog, żeby dostarczyć jak najwięcej według ilości wyrobionych punktów na zespół.

O cały proces dba Scrum Master czyli służebny lider, który usuwa kłody, które napotyka zespół i doszkala ich z podejścia zwinnego.

Im dłuższy sprint tym bardziej przypomina on waterfall, ponieważ faza “planowania” często się przeciąga i zespół traci 2-3 dni ze sprintu, aby w ogóle coś zaplanować. Dla wielu firm jest to zbyt dużo, aby robić to cotygodniowo, więc wydłużają sprint.

Im krótszy okres sprintu tym większa dyscyplina musi panować w zespole, ponieważ wymaga to bycia szybkim i skutecznym, tak jak w jednostkach specjalnych, gdzie zespół operatorów jest jednością, samo dotarcie takiego zespołu trwa przeważnie 5-7 lat, odruchy w tym zespole są bezwarunkowe.

Oferty pracy z

Kapituły

Przechodząc do sedna tego artykułu, czym są kapituły? Nie jest to metodologia, więc nie jest ważne jaki proces wytwórczy posiadamy w firmie. Kapituły są zespołami, które nie mają odzwierciedlenia w strukturach firmy, można je nazwać oddolną inicjatywą danej specjalizacji lub grupy osób.

Przykładowo mamy firmę, w której istnieje pięć zespołów, gdzie na każdy zespół przypada dziesięć osób. Trzy deweloperskie (A, B, C) oraz dwa wsparcia (D, E). Żaden z wyżej wymienionych zespołów nie jest kapitułą. Kapitułą nazywamy zespół architektów i polega to na tym, że z zespołu A, B i C wydzielamy jednego członka, który będzie uczestniczył w spotkaniach takiej grupy.

Przykładowe zadania kapituły architektów:

1. Propagowanie dobrych praktyk programistycznych w zespołach.

2. Tworzenie szkieletu architektury, który każdy zespół musi przestrzegać.

3. Tworzenie zasad i standardów kodowania.

4. Rozwiązywanie problemów wydajnościowy i problemów ze skalowalnością projektów

5. Prowadzenie konsultacji i eliminacja przeszkód związanych z architekturą w zespołach.

Przykładowe zadania kapituły wdrożeniowców:

1. Definiowanie procesu od wytworzenia kodu do wdrożenia na produkcję.

2. Egzekwowanie standardów zdefiniowanych przez architektów za pomocą CI/CD.

3. Udrażnianie procesu i “przepływu” kodu.

4. Automatyzacja procesów wdrożenia.

5. Konsultacje i dokształcanie zespołów.

Przykładowe zadania kapituły R&D:

1. Redukcja długu technologicznego.

2. Znajdowanie rozwiązań automatyzujących tworzenie kodu.

3. Prowadzenie projektów PoC(Proof of Concept).

4. Definiowanie zakresu narzędzi używanych w firmie.

5. Konsultacje i dokształcanie zespołów.

6. Tworzenie wspólnych bibliotek.

Przykładowe zadania kapituły administratorów:

1. Tworzenie środowisk.

2. Automatyzacja tworzenia środowisk.

3. Konsultacje i dokształcanie zespołów.

4. Udrażnianie środowisk.

Przykładowe zadania kapituły testerów:

1. Definiowanie sposobu przeprowadzania testów.

2. Współpraca z kapitułą wdrożeniowców przy egzekwowaniu testów w procesie CI/CD.

3. Konsultacje i dokształcanie zespołów.

4. Automatyzacja procesu i tworzenie wspólnych bibliotek razem z kapitułą R&D.

Przykładowe zadania kapituły analityków:

1. Wymiana wiedzy nt. projektów prowadzonych w firmie(zależnych od siebie biznesowo).

2. Definiowanie sposobu przeprowadzania analiz i zbierania informacji.

3. Definiowanie zbioru narzędzi oraz materiałów przydatnych przy tworzeniu historyjek.

Mając członka zespołu w każdej kapitule przepływ informacji i rozwiązań jest natychmiastowy. Jeśli dany zespół wymyśli rozwiązanie, które się sprawdza lub rozwiązuje problem natychmiast trafia do każdego zespołu i idąc dalej, projektów, które rozwija dany zespół.

Dzięki takiemu podejściu odpowiedź podczas codziennego scruma na pytanie “Jakie mam problemy?” jest natychmiastowa oraz zgodna ze wszystkimi zespołami w danej firmie, ponieważ propagowanie wiedzy jest jasno zdefiniowane i każdy członek zespołu wie kto przynależy do jakiej kapituły.

Każda kapituła jest niezależna, jednak w wielu miejscach zakres obowiązków się zazębia lub wchodzi w zadania innej kapituły. Warto, więc tak tworzyć zespoły, aby były samowystarczające i zarazem dało się wydzielić osobę, która będzie uczestniczyć w kapitule.

Jako, że są niezależne, członkowie sami definiują ile czasu potrzebują, przeważnie wystarczy 3-5 h na osobę w ciągu miesiąca, aby zająć się tematami zdefiniowanymi przez grupę. Co ważne, kapituły są dobrowolne, więc dobrze jakby tworzyły je osoby, które chcą robić coś więcej niż tylko klepanie CRUD’ów.

Duży profit jest również podczas wdrażania nowego członka zespołu, ponieważ wiedza jest spisana w ramach kapituły i czas przechodzenia między projektami w firmie jest minimalny, gdyż każdy aspekt jest ustandaryzowany, więc wygląda podobnie dla każdego projektu.

Sam osobiście doświadczyłem tego procesu i jego działania, gdy dostałem podczas wdrożeniu do firmy zadania na 120h. Analityk wliczył do tego czas adaptacji i zrozumienia projektu, które miałem skończyć przed rozpoczęciem kolejnego sprintu. Zadania zostały ukończone w 72h wliczając w to czas onboardingu, otrzymania, konfiguracji sprzętu i środowiska, jednak faktycznie zostały ukończone w 37h. Wnioski zostawię Tobie, drogi czytelniku, czy ten system sprawdzi się u Ciebie.

A tymczasem, do następnego!

Zobacz też

growth hacks 5 zasad pisania w R dla każdego data scientista

Zdjęcie główne artykułu pochodzi z unsplash.com.