Kultura inżynieryjna Spotify. Jak radzą sobie z problemami związanymi z rozwojem?

Zaktualizowaliśmy ten tekst dla Ciebie!
Data aktualizacji: 22.01.2024
Autor aktualizacji: Piotr Merynda

Spotify zmęczyło się tym i próbuje rozwiązać problemy związane z procesem rozwoju oprogramowania. Na szczęście dla nas chętnie dzielą się swoimi wnioskami.

Dlaczego musimy wprowadzać zmiany w naszej rutynie pracy?

Ile razy zmagałeś się z na wpół dopracowanymi wymaganiami, które zostały ci rzucone pomimo niewielkich lub żadnych konsultacji? Ile razy nie mogłeś wydać nowej wersji swojego kodu lub utknąłeś z irytującymi narzędziami z powodu zależności od innych zespołów? To tylko cząstka problemów trapiących przeciętnego programistę każdego dnia. Ale czy można coś z tym zrobić? Cóż, nie dowiemy się, dopóki nie spróbujemy, prawda? Spotify zmęczyło się tym i próbuje rozwiązać te problemy. Na szczęście dla nas chętnie dzielą się swoimi wnioskami.

Organizacja zespołu i pracy

Wszyscy znamy Scruma. Jest tak popularny, że niektórzy ludzie mają tendencję do akceptowania go jako jedynego słusznego sposobu postępowania. Ale czy zawsze jest on optymalny? Co jeśli coś nam nie pasuje, ale zmiana tego byłaby wbrew zasadom Scruma? Wydaje mi się, że odpowiedź na to pytanie brzmi: „Zasady to dobry początek, ale łam je, gdy zajdzie taka potrzeba”. Znaczenie tego zdania jest takie, że trzymanie się zasad Agile działało dla nich lepiej niż trzymanie się sztywnych praktyk Scrum. Wymyślili nawet nową terminologię, która lepiej wyrażała ich idee.

Tak więc Scrum Master został przemianowany na Agile Coach, ponieważ nie sugeruje to, że jest on kimś, kto zapewnia przestrzeganie frameworka Scrum. Nową rolę można opisać bardziej jako przywódcę służebnego niż mistrza procesu, dzięki czemu członkowie zespołu są wspierani, ale nie temperowani i ograniczani.

Przyjrzyjmy się teraz zespołowi Scrum, który w uniwersum Spotify nazywany jest Autonomous Squad. Dlaczego więc autonomia była tak ważna, że stała się częścią nazwy? W przeciwieństwie do wielu innych firm, które ograniczają opcje swoich zespołów scrumowych za pomocą stałych zależności modułów, wymagań i narzędzi. Spotify wyznacza swoim zespołom tylko ogólne cele i pozwala im wymyślić, jak należy to zrobić. Biorąc pod uwagę tę swobodę, rozwój staje się szybszy, ponieważ większość decyzji można podejmować lokalnie, a mniejsze ograniczenia są dodatkową motywacją dla członków zespołu.

Co jednak, gdy opracowany musi być projekt całego systemu? Kto powinien to zrobić? Cóż, jesteśmy przyzwyczajeni (przynajmniej ja jestem), że takie wymagania są nam stawiane odgórnie w postaci nowego API, może jakichś komunikatów lub jeszcze czegoś innego. W idealnym świecie wszystko, co musimy zrobić, to zaimplementować je i być wdzięcznym, że jakiś projektant systemu lub architekt zdefiniował je dla nas. Ale czy posiadanie kogoś takiego jest zawsze korzystne? Nie zrozum mnie źle, nie mówię, że ci ludzie wykonują swoją pracę źle, ale raczej, że są na innym poziomie w hierarchii i czasami spowalniają lub nawet zatrzymują komunikację między zespołami. Niepotrzebne zależności wprowadzone w ten sposób są trudniejsze do wyeliminowania, ponieważ nie wpływają na projektantów i mogą być postrzegane jako dodatkowa praca. Zakładam, że wiesz już do czego zmierzam. Tak, w Spotify zespoły są wewnętrznie i zewnętrznie samoorganizujące się. Współpracują ze sobą, aby znaleźć najlepsze rozwiązanie. Zadaniem liderów jest informowanie zespołów o tym, jaki problem należy rozwiązać i dlaczego. Celem jest utrzymanie luźno powiązanych zespołów, ale silnie dopasowanych, tak aby mogły osiągać długoterminowe cele bez wchodzenia sobie w drogę.

Pomimo naszych najlepszych starań niektóre zmiany będą miały wpływ na kilka modułów lub systemów i bardzo prawdopodobne, że zwlekanie innych zespołów w pewnym momencie nas zablokuje. Z mojego doświadczenia wynika, że rzadko dochodzi do porozumienia w kwestii modyfikacji kodu innych zespołów. Ale w Spotify każdy komponent repo nie jest przechowywany jako cenny skarb, do którego dostęp mają tylko wybrani. Wolą, aby wszystko odbywało się w bardziej otwarty sposób, gdzie każdy może wprowadzać poprawki, gdy właściciele mają ważniejsze rzeczy do zrobienia. Wyobraźmy sobie teraz taką sytuację, w której kilka zespołów pracuje nad tą samą funkcjonalnością. Zespół 1 jest odpowiedzialny za wyszukiwarkę, a zespół 2 pracuje nad listą wyświetlającą wyniki. Ta nowa funkcjonalność wymaga pewnych modyfikacji w funkcji fillSearchResultsList, ale zespół 2, który jest właścicielem listy, opóźnia tę zmianę.

class SearchResultsList {

    // ...
    public void fillSearchResultsList() {
        // ...
        someMagicSwtitch(false); // needs to be changed to "true"
        // ...
    }
    // ...
}

W wielu firmach zespoły byłyby zmuszone czekać i spamować skrzynki pocztowe łajdaków niekończącymi się przypomnieniami.

Ale w Spotify zespół 1 może po prostu wprowadzić zmianę i poprosić zespół 2 o review. Takie podejście przyspiesza pracę i pomaga rozpowszechniać wiedzę.

Organizacja firmy

Spotify ma tendencję do tworzenia wspólnot interesów, a nie formalnych struktur. Wspólnota może więc skupiać wszystkich ludzi, którzy pracują w tym samym miejscu. Kolumny we wspólnocie to zespoły, które zostały wyjaśnione wcześniej. Każdy wiersz reprezentuje kapitułę, która jest tworzona w oparciu o obszar kompetencji, taki jak Agile Coaching, tworzenie stron internetowych i tak dalej. Również liderzy kapituł są formalnymi menedżerami dla innych członków i nie zmieniają się podczas przełączania zespołów. Ostatnią rzeczą są gildie, które można opisać jako luźno powiązaną społeczność interesów. Gildie gromadzą i dzielą się wiedzą w określonej dziedzinie. Każdy może dołączyć lub opuścić gildię, ponieważ zazwyczaj są one reprezentowane jako listy mailingowe, tablice postów itp.

Publikowanie zmian

Aby utrzymać tę dobrze naoliwioną maszynę, każdy zespół musi być w stanie często publikować swoje zmiany, nie martwiąc się zbytnio o wpływ, jaki może to mieć na resztę systemu. Częste i małe publikacje mają kilka zalet, takich jak szersze testowanie nowego kodu, błędy są łatwiejsze do zlokalizowania i nie powstrzymują innych zmian przed publikacją. Aby to osiągnąć, Spotify całkowicie zmieniło swojego klienta desktopowego, który wcześniej był tylko jedną dużą monolityczną aplikacją, a teraz jest w zasadzie przeglądarką internetową zbudowaną na Chromium Embedded Framework. Rozbicie klienta na wiele mikrousług pozwoliło im na skalowanie bez utonięcia w morzu pracy nad wydaniem kodu.

Podsumowanie

To co opisałem w powyższym artykule to tylko część innowacyjnych działań jakie mają miejsce w firmie Spotify. Moim zdaniem to świetnie, że są gotowi popełniać błędy i ponosić ich koszty dla lepszego jutra.  Myślę, że powinniśmy wyciągnąć z tego lekcję, aby nie akceptować rzeczy, które spędzają nam sen z powiek i spróbować coś z nimi zrobić. Oczywiście niektóre zmiany będą zbyt kosztowne do przeprowadzenia, ale z każdym nowym projektem jest szansa na odwrócenie sytuacji. Więcej informacji na temat kultury inżynieryjnej Spotify można znaleźć pod tym linkiem.

Źródła

https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

http://www.startuptalky.com/wp-content/uploads/2017/02/Company-Culture-Matters-Heres-Why3-950×509.png