Prezentujemy studium przypadku trzyletniego projektu budowy zespołów DevOps w Onet.pl zaprezentowane na 6. Kongresie itSMF. Szczegółowo opisaliśmy stojące przed organizacją wyzwania, osiągnięte KPI oraz proces dostosowania do tej zmiany organizacyjnej architektury systemów Onet.pl.
„Wierzymy, że technologia stanowi naszą przewagę konkurencyjną. Jesteśmy zwinną organizacją zorientowaną na produkt, a za nami stoją innowacyjni ludzie pracujący w Onet DreamLab, a także stosowane procesy i infrastruktura dwóch centrów danych” – zaczął swoją prezentację Marek Kowal, dyrektor Departamentu IT w Onet.pl podczas 6. Kongresu itSMF. „Cztery lata temu uznaliśmy jednak, że klasyczny podział na administratorów i deweloperów – uwięzionych w silosach swoich zespołów – ogranicza nas, a co ważniejsze – ogranicza biznes w realizacji nowych projektów” – dodał.
Zapraszamy na 7 Kongress itSMF, który odbędzie się 11-12 września w Warszawie. Partnerem medialnym Kongresu jest magazyn ITwiz.Rok 2010: organizacja nastawiona na projekty, nie produkty
W roku 2010 spośród 250 osób zatrudnionych w Departamencie IT Onet.pl 65% pracowało, jako programiści i testerzy (Development), a 35% jako administratorzy (Operations). Projekty były zaś prowadzone zgodnie z metodykami kaskadowymi, czyli najpierw zdefiniowanie i zatwierdzenie projektu, a potem jego planowanie, realizacja, kontrola i zakończenie.
„’Już’ po pół roku mieliśmy serwis, który mogliśmy zaprezentować zarządowi. Wówczas okazywało się jednak, że po 6 miesiącach nie na wiele się przyda, bo pomysł był innowacyjny w trakcie jego zgłoszenia, a nie jest już, gdy serwis wreszcie powstał. To generowało dodatkowe poprawki w oddawanych projektach” – opowiada Marek Kowal. „Do tego dochodziły ‘standardowe’ problemy związane z jednoczesnym utrzymaniem trzech założonych parametrów – czasu, budżetu i jakości. Gdy kończył się budżet i zbliżał termin, następowały naciski na deweloperów na szybkie zakończenie prac kosztem jakości. Wtedy protestowali administratorzy, którzy nie chcieli wypuścić na rynek systemu, bo miał za dużo błędów” – dodaje.
Jak twierdzi Marek Kowal, problemem był fakt, że organizacja deweloperska była nastawiona na projekty, a nie produkty, i w efekcie działała zgodnie z mottem „oddać i zapomnieć”, aby móc zająć się nowym projektem. Tymczasem potencjalne awarie usuwały już nowe osoby – administratorzy, albo członkowie innych zespołów developerskich.
Rok 2011: w kierunku zwinnego zarządzania
Konieczne zmiany Onet.pl zaczął więc od developmentu. Postanowiono zakończyć z podziałem na silosy kompetencyjne i stworzyć zespoły zajmujące się poszczególnymi produktami, takimi jak: stroną główną Onet.pl, serwisami zumi.pl i sympatia.pl oraz wieloma serwisami tematycznymi. „Komunikat był jasny: prowadzicie projekty, ale odpowiadacie za konkretne produkty, które Wam podlegają” – mówi Marek Kowal. Zdecydowano się na prowadzenie projektów deweloperskich wg metodologii SCRUM. „Jak się okazało, największym wyzwaniem nie było nauczenie pracy w SCRUM’ie developerów, lecz biznesu, który musiał nauczyć się zupełnie nowego sposobu definiowania, prowadzenia i odbierania projektów” – opowiada Marek Kowal.
Główne zalety podziału na zespoły produktowe to:• Mniej awarii. Jak coś zepsujesz, to sam musisz to naprawiać, więc development bardziej zwracał uwagę na jakość tworzonego kodu.
• Przyspieszenie dostarczania nowych produktów. Zwykle projekt nie trwa dłużej niż 3 miesiące, wcześniej często było to nawet 9 miesięcy. Przykładem ilustrującym zmianę jest fakt, że nowy serwis wiadomości – odpowiadający za 20% ruchu Onet.pl – został zbudowany w zaledwie 2 miesiące.
Pojawiły się jednak zagrożenia z tym związane:• Kilkaset wdrożeń dziennie.
• Problemem stała się spójności architektury. Pojawiły się wyspy produktowe, każdy zespół mógł sam tworzyć rozwiązanie, w tym architekturę, często rozwiązując na nowo te same problemy.
• Administratorzy potrafili usunąć coraz mniej usterek – zgłaszane im problemy często musiały być przekazywane deweloperom.
• Biznes przestał rozumieć, czemu potrzebny jest zespół wsparcia, skoro część problemów rozwiązują administratorzy, a część zespoły deweloperskie.
• Część organizacji działa zwinnie (SCRUM), pozostała wg metodyk ITIL.
„Aby rozwiązać te problemy uznaliśmy, że potrzebna jest nowa rola w zespole – Master of Service, odpowiedzialna za koordynację kluczowych procesów ITIL w zespole SCRUM” – twierdzi Marek Kowal. „Jednak administratorzy także chcieli być bardziej zwinni. Spróbowali SCRUM, ale często nie dało się go zastosować ze względu na zbyt dużą liczbę nieprzewidywalnych działań. Sprawdził się jednak KANBAN. Każdy zespół administratorów ma dziś zapełnioną różnego koloru karteczkami tablicę KANBAN” – dodaje. W IT powstały zwinnie działające dwie linie – projektowa i utrzymaniowa.
Rok 2012: pierwsze podejście do DevOps
„Wówczas jednak usłyszeliśmy o koncepcji DevOps łączącej rozwój i utrzymanie. Postanowiliśmy więc zburzyć ścianę dzielącą deweloperów i administratorów. Test DevOps przeprowadziliśmy na usłudze poczty elektronicznej dla użytkowników Onet.pl. Stworzyliśmy pierwszy, wspólny zespół, siedzący razem, mający wspólne cele, wspólnie planujący działania” – opowiada Marek Kowal.
Więcej w numerze ITwiz 3/2014, z którego pochodzi ten artykuł.
