Michał Wierucki, CSO w Allegro, a wcześniej kierownik zespołu infrastruktury PayU CEE, przedstawiając podczas Kongresu ItSMF zasadność zainteresowania szczupłymi technikami (Lean Management) w IT pokazał drogę od niezorganizowanego zarządzania rozwojem portalu – poprzez PSO, ITIL, APM, SCRUM, Kanban – do DevOps. Podkreśla on znaczenie współpracy i odejście od struktury działów, które wzajemnie się zwalczały.
Gdy Michał Wierucki zaczynał pracę w Allegro obowiązywał „stary świat”, w którym informacje w projekcie wymieniano albo poprzez mail, albo w trybie tzw. chodzonym. Szło się do innego członka projektu i rozmawiało o tym, co należy zrobić. „Działaliśmy wówczas jeszcze jak typowy start-up” – wspomina.
Krótka historia zmian w zarządzaniu projektami
Dopiero w 2008 roku w Allegro wprowadzono metodologię zarządzania projektami poprzez Project Support Office (PSO). Wówczas projekty prowadzone były zgodnie z modelem kaskadowym (waterfall). Podzielono także wszystkich deweloperów na grupy zajmujące się rozwojem i utrzymaniem. Kolejne zmiany nastąpiły, gdy wdrożono zbiór najlepszych praktyk ITIL wykorzystywanych w zarządzaniu informatycznym wsparciem procesów biznesowych. „Doprowadziło to do tego, że zaczęliśmy mierzyć efektywność prac zespołów deweloperskich” – mówi Michał Wierucki. To wciąż jednak było podejście waterfall’owe.
Wśród zespołów DevOps w Allegro znajduje się wiele takich, które udostępniają innym „standardowe” usługi, takie jak: Hadoop, Database-as-a-Service, chmurę publiczną, czy portal do tworzenia serwerów wirtualnych. Każdy może sam sobie „wyklikać” to, co jest mu potrzebne do zrealizowania projektu. Każda interakcja poza zespół jest nieprzewidywalna i może być zagrożeniem, doprowadzić do opóźnienia.
Po 2011 roku wprowadzono zwinne metodyki prowadzenia projektów (agile) oparte o SCRUM. Warte podkreślenia jest to, że procesy ITIL’owe nadal działają w świecie agilowym. Nowe metody prowadzenia projektów wprowadzono w pierwszej kolejności w zespole deweloperskim. Tymczasem dział zajmujący się utrzymaniem infrastruktury pozostał niejako z boku wciąż działając w modelu kaskadowym. Pracownicy tych działów także jednak chcieli zmieniać sposób pracy, działać wg zwinnych metodyk prowadzenia projektów. W ich przypadku zdecydowano się na metodykę Kanban. Kolejnym etapem było połączenie obu grup w zespoły DevOps. Ten proces nadal trwa. Jest kilka zespołów DevOps ale nie wszystkie są samodzielne – transformacja jest w toku.
Budowa API do usług IT dla innych zespołów
„Wcześniej mieliśmy do czynienia z silosami, dziś zespoły współpracują ze sobą. To najważniejsza cecha wpływająca na popularność koncepcji DevOps. ‘Sztywne’ dotąd podziały na zespoły – sieciowców czy bazodanowców – przestają mieć znaczenie . Powstają zespoły usługowe, np. Database-as-a-Service. Do tradycyjnych zespołów zajmujących się infrastrukturą dołączyli w Allegro deweloperzy, którzy tworzą front end, API dla programistów z innych zespołów” – opowiada Michał Wierucki.
Wśród zespołów DevOps istnieje wiele takich, które udostępniają innym „standardowe” usługi, takie jak: Hadoop, Database-as-a-Service, chmurę publiczną, czy portal do tworzenia serwerów wirtualnych. Wszystko po to, aby było jak najmniej blokad ograniczających prace zespołów, aby każdy z nich był w jak najmniejszym stopniu zależnym od innych. Każdy może sam sobie „wyklikać” to, co jest mu potrzebne do zrealizowania projektu. „Każda interakcja poza zespół jest nieprzewidywalna i może być zagrożeniem, doprowadzić do opóźnienia. Tego chcemy uniknąć” – tłumaczą przedstawiciele Allegro. „Dodatkowo raz na kwartał przeprowadzamy przegląd zrealizowanych projektów. Dzięki temu wiemy, co się udało, a co wymaga poprawy. Wyciągamy wnioski na przyszłość. Szukamy pozytywnych i negatywnych aspektów. Uczymy się” – dodają.
W dużych organizacjach rośnie popularność zwinnych metodyk prowadzenia projektów. Choć – jak przyznaje Michał Wierucki – nie wszystko da się zrobić w agile. „Na każdy projekt patrzy się jednak przez pryzmat zysków, a to wymusza uzyskiwanie znacznie wcześniej informacji na temat postępów w projekcie i jego efektów” – wyjaśnia. Ale używając różnych metodyk trzeba być czujnym. „Kiedyś, przez dwa lata prowadziliśmy projekt związany z rozwojem infrastruktury pod nowy serwis. Pod koniec tego okresu okazał się być niepotrzebny, taka funkcjonalność przestała być potrzebna w efekcie zmian na rynku, które w tym czasie nastąpiły” – wspomina.
Nie wprowadzamy od razu dużych rozwiązań, tylko pojedyncze funkcjonalności, krok po kroku. Nie kupujemy też od razu całej, potrzebnej infrastruktury fizycznej, tylko pokazujemy poszczególne funkcjonalności na serwerze wirtualnym, często wynajętym jako usługa cloud computing.
Rozwój funkcjonalności i infrastruktury krok po kroku
Dziś w Allegro określone są cele cząstkowe. Rozwijamy jakąś funkcjonalność, testujemy nowe rozwiązanie, sprawdzamy, czy jest OK. Dopiero gdy dana funkcjonalność się sprawdzi, dalej inwestujemy w ten projekt. „Nie wprowadzamy od razu dużych rozwiązań, tylko pojedyncze funkcjonalności, krok po kroku. Nie kupujemy też od razu całej, potrzebnej infrastruktury fizycznej, tylko pokazujemy poszczególne funkcjonalności na serwerach wirtualnych, często wynajętych jako usługa cloud computing” – dodaje.
W projektach agile – zwłaszcza w zespołach DevOps-owych – sztywne formuły nie działają. „Stawiamy na współpracę. Ważne jest inwestowanie w najlepszych, pracowanie z ludźmi, bo to od nich zależy nasz sukces” – podkreśla Michał Wierucki. Lean IT, agile, zespoły DevOps – niosą za sobą zmiany kultury organizacyjnej. Polega to przede wszystkim na przekazywaniu sobie informacji zwrotnej, informacji o tym, czy to, co robimy jest dobre. To także rezygnacja z robienia dużych, monolitycznych rozwiązań, na rzecz małych, atomowych tworów, nad którymi pracują niewielkie zespoły odpowiedzialne za każdy aspekt projektu.
„Wiem, co robię i co inni robią w projekcie. Każdy z nas zna efekty swoich działań. Polegamy na wzajemnych relacjach, co pozytywnie wpływa na atmosferę w pracy. Wszyscy pracujemy dla tego samego klienta końcowego. W zależności od potrzeb możemy przenosić osoby z projektu do projektu, gdy firma tego potrzebuje” – mówi Michał Wierucki.
Lean IT, agile, zespoły DevOps – niosą za sobą zmiany kultury organizacyjnej. Polega to przede wszystkim na przekazywaniu sobie informacji zwrotnej, informacji o tym, czy to, co robimy jest dobre. To także rezygnacja z robienia dużych, monolitycznych rozwiązań, na rzecz małych, atomowych tworów, nad którymi pracują niewielkie zespoły.
Najważniejsze korzyści z takiego podejścia, które wymieniają przedstawiciele Allegro – to oszczędności kosztów związanych z wdrożeniami nowych rozwiązań i rozwojem serwisów, a także poczucie, że prowadzone projekty mają sens. Prowadzenie w ten sposób projektów pozwala także ograniczać stratę czasu w przypadku, gdy zmienią się jego założenia, albo gdy okaże się, że w ogóle nie jest on już potrzebny.
Ścisła współpraca Product Ownera z zespołem DevOps
W Allegro to Product Owner decyduje jakie produkty są wdrażane, bo wie czego potrzebuje firma i rynek. „Product Owner jest przedstawicielem biznesu, ale jednocześnie jest częścią zespołu. Jest więc łatwo dostępny na co dzień. Obok niego jest Scrum Master i zespół developerski. To zmniejsza liczbę pomyłek, bo wszystkie strony projektu na bieżąco ze sobą rozmawiają” – opowiada Michał Wierucki.
Niektóre zespoły DevOps – których w Allegro jest kilkadziesiąt – co jakiś czas wymieniają się Scrum Maserami. To pozwala im dzielić się doświadczeniami i zdobytą w czasie projektów wiedzą. Zespoły te mają także dużą swobodę w tym, w jaki sposób się zorganizują. Wiedzą co muszą „dowieźć” na koniec sprintu, ale w jaki sposób to zrealizują to już ich sprawa. Stąd tak ważne są dobre relacje pomiędzy członkami zespołów DevOps. Muszą wierzyć, że uda się zrealizować założone cele. „Upraszczając można powiedzieć, że w Allegro tak naprawdę nie zawsze istnieje granica między byciem kierownikiem a byciem członkiem zespołu. Kierownik bowiem nie decyduje o przyznawaniu poszczególnych zadań, to jego członkowie podejmują te decyzje. Stoją za tym dwie idee. Pierwsza to samoorganizacja – to zespół scrumowy decyduje o tym kto zrobi jakie zadanie, nie wyznacza tego kierownik. Druga to spłaszczenie hierarchii – na open space kierownik siedzi z zespołem i współpracuje jak „normalna” osoba, blisko dla wszystkich, którzy potrzebują kontaktu z nim” – mówi Michał Wierucki.
Niektóre zespoły DevOps – których w Allegro jest kilkadziesiąt – co jakiś czas wymieniają się Scrum Maserami. To pozwala im dzielić się doświadczeniami i zdobytą wiedzą. Zespoły te mają także dużą swobodę w tym, w jaki sposób się zorganizują. Wiedzą co muszą „dowieźć” na koniec sprintu, ale w jaki sposób to zrealizują to już ich sprawa.
Zdaniem Michała Wieruckiego, opisywane podejście sprawdza się w Allegro i z pewnością warto korzystać z doświadczeń innych, ale nie da się wdrożyć strategii DevOps z „książki”, czy bazując 1:1 na doświadczeniach innej firmy. Trzeba ją wcześniej zaadoptować do własnej organizacji – wybrać najlepsze cechy i dostosować do potrzeb firmy i pracujących w niej osób. „Zespoły, które pracują muszą tego chcieć, ludzie muszą widzieć zyski z tego typu organizacji pracy. Potrzebują też na bieżąco informacji zwrotnej. Muszą mieć świadomość, że o wszystkim można porozmawiać, że nie będą musieli „tłamsić” w sobie frustracji. Dzięki temu ludzie chętniej sobie pomagają. Gdy coś im nie odpowiada mogą zawsze ze sobą porozmawiać” – podsumowuje.
Na co uważać zmieniając sposób prowadzenia projektów- • Przystosuj i zastosuj – nie rób kalki.
- • Nie skupiaj się na formie tylko na treści.
- • KPI, SLA i umowy są na wypadek wojny, ale pamiętaj, czego nie mierzysz, nie możesz udoskonalać.
- nie powinniśmy skupiać się dowiezieniu poszczególnych KPI, które same w sobie nic nie dają, ważniejsza jest ich korelacja a najważniejsze zadowolenie klienta.
- • W firmie nie ma klientów, klientów ma organizacja.
- • SCRUM to nie tylko planowanie najbliższego sprintu.
- • Wprowadzaj zmiany w całej organizacji – samotne wyspy nie usprawnią organizacji.
- • wspólne cele wszystkich działów,
- • szybsza pętla informacji zwrotnej,
- • burzenie murów w organizacji,
- • szybka reakcja na zmianę rzeczywistości,
- • transparentność,
- • odpowiedzialność,
- • łatwiejsze wykrywanie wąskich gardeł.
- • 1999 – 2007 – „Manufaktura”
- • 2008 – Zarządzanie Projektami PSO
- • 2009 – ITIL (nadal żywy :D)
- • 2011 – Scrum, Podział Infrastruktury na produkty
- • 2012 – APM
- • 2012 – Kanban
- • 2013 – DevOps
