Zwinne praktyki w budowaniu serwisów internetowych - wywiad z Wojciechem Ehrenfeldem

Krzysztof Bednarz: Kiedy po raz pierwszy Grupa Onet zadecydowała, że chce używać zwinnych metod wytwarzania oprogramowania?

Wojciech Ehrenfeld: Mniej więcej trzy lata temu, kiedy zauważyliśmy, że budowanie nowych, niejednokrotnie innowacyjnych produktów w za pomocą ITIL, czy metod waterfallowych jest problematyczne, zaczęliśmy szukać rozwiązania, które mogłyby nam pomóc w tych bolączkach. Zainteresowaliśmy się metodykami, takimi jak Agile czy Scrum, dotyczącymi zarządzania IT i rozpoczęliśmy  ich wdrożenie oczekując dużych usprawnień w naszej pracy.
Wcześniej pracowaliśmy w dwóch całkowicie niezależnych silosach, czyli w pionie developmentu i w pionie utrzymania. Po jakimś czasie podjęliśmy decyzję o połączeniu zespołów. Dodatkowo, zamiast przewidywania, że coś wydarzy się za pół roku, albo rok, jak jest to w ramach prowadzenia projektów w modelu waterfallowym, przeszliśmy na zwinną metodykę i zaczęliśmy planować pracę w cyklach dwutygodniowych. W modelu Scrum sprinty trwały dwa tygodnie, co wcale na samym początku nie oznaczało, że te projekty były zdecydowanie szybciej realizowane. Jednak ich zaletą było to, że z tygodnia na tydzień mniej więcej wiedzieliśmy, w jakim punkcie pracy jesteśmy.

KB: Jak Agile i Scrum są postrzegane wśród pracowników?

WE: Dzisiaj po blisko 3 latach temat Agile jest postrzegany jak najbardziej pozytywnie, m.in dlatego że jesteśmy już zaawansowani w stosowaniu Scrum i DevOps i widać wiele efektów zmiany, którą podjęliśmy. Nie można również ukrywać, że warunkiem koniecznym do przeprowadzenia zmiany organizacyjno-procesowej była także duża zmiana w technologii. Stało się nią stworzenie  platform technologicznych, u nas rozumianych jako produktów, nad których utrzymaniem i rozwojem mogli pracować nasi pracownicy.

KB: Jakie w takim razie były pierwsze reakcje programistów, gdy pojawiły się nowe metodyki?

WE: Pierwsze reakcje są naturalne, jak za każdym razem kiedy chcemy dokonać dość dynamicznej i gwałtownej zmiany. Z jednej strony pojawiały się obawy przed zmianą, a z drugiej dominowało zaciekawienie, ponieważ wszyscy zdawali sobie sprawę, że model w jakim wtedy pracowaliśmy zupełnie się wyczerpał. Widać było, że żadne drobne optymalizacje nie były w stanie go uzdrowić. Mieliśmy duże nadzieje na znalezienie sposobów rozwiązania bardzo wielu bolączek, zarówno działu IT, dotyczących prowadzenia projektów, ale z drugiej również bolączek biznesowych.
W zwinnych metodykach łatwiej możemy wprowadzić zmiany w budowanym produkcie. Widząc rozwój jego funkcjonalności i mając ciągły kontakt z odbiorcą, możemy korygować go w każdym momencie. Zupełnie inaczej wyglądała ta sprawa w przeszłości, gdy gotowy produkt wdrażany był po roku i dopiero wtedy biznes zaczynał mieć do niego uwagi i chęć wprowadzania poprawek. Nie ukrywajmy również, że robienie produktów na rok następny jest obecnie trudne, bo rynek bardzo się zmienia.

KB: Czy pamięta pan jakieś negatywne reakcje swoich pracowników, przez które trzeba było przejść, przełamać tych ludzi, pokazać im dobrą stronę nowych metod pracy?

WE: Przyznam się, że nie pamiętam żadnych drastycznych przykładów związanych z tym wdrożeniem. Pomimo tych wszystkich obaw, pomimo nowego rodzaju pracy, który pojawił się w zespołach utrzymaniowych i developerskich, wszyscy byli zaciekawieni, w jaki sposób można te problemy rozwiązać. Duża rolę odegrali również managerowie którzy w odpowiedni, miękki sposób namawiali do otwartości na tę zmianę. Niewielu pracowników zostało całkowicie na nią zamkniętych. Osoby ze strony utrzymaniowej widziały jak bardzo ta metoda ma szansę pomóc w ich pracy, ponieważ w przypadku awarii nie będą pozostawieni sami sobie, a z drugiej strony developerzy widzieli realną szanse na szybsze wdrożenia, na bliższą współpracę w rozwiązywaniu m.in. architektonicznych rozwiązań.
Pierwszy okres pracy z nową metodyką był trudny z jednego powodu. Na zespoły DevOPS spadła z dnia na dzień stosunkowo duża odpowiedzialność. Z jednej strony pojawił się mocno oczekiwany wpływ na rozwój i utrzymanie produktu, ale z drugiej strony, kiedy zabrakło  zestawu procedur i menadżerów kierujących ich pracą, niedojrzałe zespoły miały problemy i zauważyliśmy, że produkty w pierwszym etapie, wcale nie były lepiej utrzymane, ani specjalnie lepiej się nie rozwijały.

KB: Czy wykorzystują państwo narzędzia Lean IT, takie jak fizyczne tablice Kanban?

WE: Wykorzystujemy dwa modele. Z jednej strony są tablice Kanban, na których w „analogowy” sposób pracownicy prezentują swoją pracę, dokumentują realizację i postęp swoich tasków. Ale z drugiej strony również jest system elektroniczny. Opieramy się na Jirze, w której można raportować zadania oraz śledzić przeróżne elementy pracy zespołu  jego performance, itd.

KB: Czy możemy przedstawić liczby porównujące czas trwania projektów przed i po wdrożeniu Agile?

WE: Wbrew pozorom nie chciałbym zaczynać od liczb. Z jednego powodu, te liczby były dominującym elementem dokumentującym wszystkie działania zespołu w ramach praktyk PM-owych i ITIL-owych. Oczywiście, to wcale nie znaczy, że należy unikać pomiarów przeróżnych KPI w pracy IT, ale warto popatrzyć na to trochę szerzej, nie tylko przez pryzmat liczb. Liczby, oczywiście, są nadal ważne, ale w starych metodykach chyba trochę za bardzo zaciemniały pracę IT. Mimo wszystko IT to ludzie, a nie tylko dziewiątki i procenty.
          Jako największą zaletę stosowania zwinnych metodyk, powiązanych oczywiście z wspólną pracą w ramach zespołów DevOps, jest to że działy IT zaczynają się identyfikować ze swoimi produktami. Programiści mają świadomość, że nie odstawią go po skończeniu, tylko uczestniczą w jego życiu od początku aż do momentu kolejnej zmiany. Tego nie da się w żaden sposób wyrazić w cyfrach, natomiast jest to klucz do realnego pójścia na przód. Sami wszyscy wiemy, jak w wielu organizacjach pracownicy nie tylko działów IT, ale też działów produktowych nie są dumni z wykonywanych zadań oraz efektów swoich działań. Po prostu traktują to jako zwykłą pracę, czasami trochę „do 15-stej”. W związku z tym realna zmiana tej świadomości i ostatecznie, przywiązanie do produktu, obserwowanie jego rozwoju i rynkowego sukcesu oraz chęć jego polepszania przynoszą bardzo wyraźne efekty.

Nie ma również co ukrywać, że bardzo ogromną zaletą stosowania tych metod jest dużo lepsza kontrola nad projektem. Wcale nie musi to oznaczać, że ostateczne funkcjonalności produktu są wykonywane dużo szybciej niż w projektach waterfallowych. Są projekty waterfallowe, które w dobrych organizacjach mogą toczyć się bardzo precyzyjnie, pokazując również dobry sposób współpracy z biznesem, ale wiemy jak proza życia często wygląda. W zwinnych praktykach biznes, czyli Product Owner, który pracuje w ramach zespołu scrumowego, żyje z teamem IT oraz z produktem na każdym etapie jego rozwoju. To jest przeogromna zaleta dla obu stron. Po pierwsze, na bieżąco odbiorca ma feedback, wie co dzieje się w projekcie, wie w jaki sposób może go planować, czy ma opóźnienie, w jaki sposób może tym zarządzać. Natomiast zespół IT, widzi na każdym bezpośredni sygnał od strony biznesu, jeśli funkcjonalności, dostępność lub jakość nie odpowiadają założeniom klienta.
            Ale żeby nie było tak zupełnie bez liczb to zestawimy ze sobą dwa produkty: nasz pierwszy serwis VOD, który robiony był blisko trzy lata temu, z obecnym, który został udostępniony w lipcu. Produkcja pierwszego trwała około 6 kwartałów, czyli około półtorej roku. Obecna wersja serwisu VOD Onet, która nie jest tylko i wyłącznie zmianą szaty graficznej, ale naprawdę bardzo głęboką zmianą back-end'u włącznie z systemem DRM, systemem wyświetlania, przechowywania danych, została wytworzona w ciągu czterech miesięcy. To ogromne przyspieszenie jest oczywiście wynikiem zmiany naszych procesów, ale również rewolucji technologicznej, której owocem było stworzenie platform IT, tak bardzo ułatwiających prace programistom.

KB: Sześciokrotnie szybciej przy tej samej ilości osób pracujących przy projekcie?

WE: Stwierdziłbym nawet, że ilość osób pracujących przy tym projekcie dzisiaj jest mniejsza niż przedtem. Pewną cechą scrumowych zespołów jest to, że są one mniejsze w porównaniu do wielkich, kilkunasto-, kilkudziesięcioosobowych zespołów waterfallowych. W ramach takich zwinnych praktyk wielkie zespoły niespecjalnie się sprawdzają. Zespół dziesięcioosobowy, to jest już zespół duży. Mniejsze zespoły, przy takich dobrych, nazwijmy to demokratycznych zasadach i realną identyfikacją z produktem, mogą naprawdę szybko realizować swoje zadania i mogą również łatwo skręcać w przypadku wymaganych zmian.
Sześciokrortny uzysk jednak nie jest możliwy bo w kalkulacji należy uwzględnić również czas który został poświęcony wcześniej na budowę i utrzymanie platform IT – jest to jednak inwestycja która zwraca się z każdym kolejnym budowanym serwisie.