Ekstremalna jakość

O eXtreme Programming wiadomo tyle, że to ciekawy koncept i choć się sporo o tym u nas mówi, to nikt w praktyce XP nie stosuje. Okazuje się, że to nieprawda. W krakowskim ośrodku rozwojowym oprogramowania amerykańskiego koncernu Sabre za pomocą metodologii XP budowane są najważniejsze systemy tej firmy.

O eXtreme Programming wiadomo tyle, że to ciekawy koncept i choć się sporo o tym u nas mówi, to nikt w praktyce XP nie stosuje. Okazuje się, że to nieprawda. W krakowskim ośrodku rozwojowym oprogramowania amerykańskiego koncernu Sabre za pomocą metodologii XP budowane są najważniejsze systemy tej firmy.

Peryferie Krakowa, dawny budynek drukarni, obecnie rozbudowany i przemieniony w "business park", w którym swoją siedzibę ma wiele firm, w tym kilka z branży IT. Wśród nich polski oddział Sabre Holdings - duże otwarte wnętrza, zaaranżowane z użyciem wyraźnych, żywych kolorów. Prawie sami młodzi ludzie siedzą przy połączonych ze sobą biurkach, wszyscy mają laptopy. Nie ma sztywnych godzin pracy ani wyczuwalnej korporacyjnej hierarchii; jak ktoś chce, może zabrać ze sobą laptopa i pracę skończyć w domu.

"Mamy tu amerykańską, dość luźną kulturę zarządzania i nasi pracownicy bardzo sobie to cenią" - mówi Peggy Rosenthal, szefowa krakowskiego ośrodka, zresztą jedyna tutaj osoba z Ameryki. Ci pracownicy to w znakomitej większości absolwenci informatyki na Uniwersytecie Jagiellońskim, Akademii Górniczo-Hutniczej i Akademii Ekonomicznej. "W ostatnie wakacje zorganizowaliśmy dla chętnych studentów letnie praktyki. Wiemy już, że wielu z nich będzie u nas pracować" - twierdzi Peggy Rosenthal. Podobnie w tym roku firma będzie prowadzić program praktyk dla kilkunastu studentów krakowskich uczelni.

Obecnie w Krakowie pracuje sto kilkanaście osób, ale zespół w 2006 r. ma zwiększyć się do ok. 250. "Nie planowaliśmy tego od samego początku. Nasze doświadczenia były jednak tak dobre, że zdecydowaliśmy się szybko rozwijać ośrodek w Krakowie" - mówi Mark Meader, wiceprezes Sabre International w Dublinie. Obecnie jest to drugie co do wielkości i znaczenia miejsce na świecie, w którym Sabre rozwija swoje systemy (kilka lokalizacji w USA i Europie - w sumie ponad 3 tys. programistów).

"Czynnik finansowy ma tutaj drugorzędne znaczenie, liczyła się przede wszystkim znakomita jakość pracy polskich informatyków. Ta inwestycja już się nam spłaca" - dodaje Mark Meader (pracownicy są wynagradzani w zależności od trzech nakładających się czynników - osiągnięcia zakładanych na początku roku indywidualnych dla każdego celów, wyników finansowych działu oraz wyników samej korporacji).

Krakowskie specjalizacje

Ekstremalna jakość

Peggy Rosenthal, szefowa krakowskiego ośrodka Sabre Holdings

Sabre realizuje obecnie zakrojoną na dużą skalę migrację z systemów mainframe na otwarte środowisko klient/serwer i Web Services. Wśród starej kadry Sabre w Stanach Zjednoczonych, przyzwyczajonej do środowiska mainframe, brakowało wystarczających kompetencji do szybkiego przenoszenia aplikacji na platformę otwartych systemów. To właśnie okazało się atutem lokalizacji w Krakowie.

Sabre rozwija swoje produkty w trzech podstawowych grupach. Pierwsza z nich to oprogramowanie dla linii lotniczych, do czego w Krakowie dedykowany jest ok. 40-osobowy zespół, który właśnie bazuje na eXtreme Programming. Druga grupa to aplikacje i systemy dla biur podróży, a trzecia tzw. Travel Data Warehouse, czyli hurtownie danych. Na potrzeby projektów budujących oprogramowanie pod klienta firma Sabre zaadaptowała IBM-owy Rational Unified Process, modyfikując go przy współpracy z firmą konsultingową Valtech, tak aby wspierał pełny cykl życia projektu - od zbierania wymagań począwszy, aż po wdrożenie produktu u klienta, z zachowaniem najlepszych elementów iteracyjnego rozwoju oprogramowania. Nowa metodologia to Agile Unified Process (AUP).

W odróżnieniu od XP, które obejmuje zasadniczo sam proces tworzenia kodu, AUP wspiera również zbieranie i uściślanie wymagań, projektowanie, prototypowanie i wdrożenie rozwiązania u klienta. Zgodnie z podejściem AUP projekt jest podzielony na następujące po sobie cztery fazy: rozpoczęcie (Inception), rozwinięcie (Elaboration), budowę (Construction) oraz wdrożenie (Transition), jednak w ramach każdej z faz występują częste, krótkie iteracje, w których przeplatają się uściślanie wymagań, projektowanie, kodowanie i testowanie.

Droga do ekstremum

Ekstremalna jakość

Andrzej Kubicz, menedżer z działu Sabre Airline Product Development w Krakowie

Tworzenie oprogramowania w krakowskim ośrodku Sabre dla linii lotniczych bazuje dość ściśle na kanonicznych zasadach eXtreme Programming. To przede wszystkim jego budowa w małych iteracyjnych krokach, często kolejne wersje (co 2-3 miesiące), specyfikacja funkcji w postaci "scenariuszy", pisanych (biznesowym) językiem zrozumiałym dla klienta (odbiorcy), które muszą być na tyle proste, by dało się je zakodować, przetestować i zintegrować w czasie nie dłuższym niż 2 tygodnie; testy automatyczne i akceptacyjne w ramach iteracji, przygotowywane przed samym kodowaniem, praca w parach i często rotacje w ramach par, dążenie do upraszczania kodu (ma on realizować tylko wskazane funkcje potrzebne w danym czasie) czy codzienne spotkania "na stojąco" (o tej samej porze, nie dłużej niż kwadrans - tutaj chodzi o to, by każdy mógł powiedzieć, co zrobił, co będzie robił dzisiaj, na co istotnego chciałby zwrócić uwagę, z czym miał problem). "Programowanie w parach ma tę istotną zaletę, że jest doskonałym narzędziem transferu wiedzy, dlatego staramy się często w parach umieszczać mniej i bardziej doświadczonych pracowników" - mówi Andrzej Kubicz, menedżer z działu Sabre Airline Product Development w Krakowie.

W eXtreme Programming bardzo ważną rolę odgrywa komunikacja werbalna i dążenie do uwzględniania punktu widzenia klienta (odbiorcy) tworzonej aplikacji czy systemu przez cały proces jej powstawania. Na zasadach wewnętrznego konsultingu działa w krakowskim ośrodku Sabre dedykowany zespół zajmujący się optymalizacją interfejsu użytkownika pod względem wygody jego wykorzystania.

Niektóre zasady XP trudno jednak od razu zaakceptować i szybko przyswoić, zwłaszcza wśród doświadczonych programistów. "To nigdy nie jest łatwe ani natychmiastowe. Człowiek ma zawsze wątpliwości i opory przed akceptacją podstawowych założeń eXtreme Programming. Sam byłem na początku bardzo sceptyczny. Widząc jednak, jak skuteczne jest to rozwiązanie, dość szybko udało mi się je pokonać" - twierdzi Andrzej Kubicz.

Obawy na ogół zawsze dotyczą obniżenia produktywności (bo dwóch programistów cały czas pracuje nad tym samym fragmentem kodu, choć mogliby w tym czasie robić dwie różne rzeczy). Jednak przecież produktywność to dobry kod, o możliwie niskiej liczbie błędów, realizujący wyznaczone funkcje, a nie jak najwięcej linijek kodu. Pozornie więc zmarnowany czas jest odzyskiwany z nawiązką w lepszym kodzie, na usuwanie błędów z którego trzeba poświęcić znacznie mniej czasu. Co więcej, praca w parach sprawia, że z każdym fragmentem kodu może utożsamiać się dwóch programistów - ta redundancja w przypadku pojawienia się nieprzewidzianych kłopotów ludzkich staje się trudną do przecenienia formą zabezpieczenia. "Jednym z podstawowych założeń XP jest to, że programowanie lepiej wychodzi wtedy, gdy się to robi w grupie, niż indywidualnie. Jesteśmy dowodem, że rzeczywiście tak jest" - dodaje Andrzej Kubicz. Tutaj właśnie bardzo przydaje się luźna kultura korporacji, będąca dobrą podstawą do rozwoju komunikacji społecznej wśród pracowników.

Przy XP kłopot mogą sprawiać tzw. superprogramiści, czyli wybitne jednostki, zdolne do pracy z nieporównanie lepszą wydajnością niż reszta zespołu. "Oni są dobrzy w znajdowaniu nowych metod i nowych rozwiązań. By ich nie stracić, trzeba dla takich osób znaleźć w zespole odpowiednie miejsce" - uważa Peggy Rosenthal.

W całej krakowskiej załodze Sabre pracuje tylko 6 kobiet, a wśród nich tylko jedna programistka. "W Stanach wygląda to inaczej, gdzie liczba mężczyzn i kobiet jest zrównoważona. Decyduje o tym znacznie wyższy odsetek etatów nietechnicznych" - dodaje Peggy Rosenthal.

Statystyczna redukcja błędów

Nie bez powodu przykład Sabre postrzegany jest jako historia sukcesu elastycznych technik programowania. Firma chwali się statystykami, które obrazują, jak w dużym stopniu udało się jej poprawić jakość wytwarzanego oprogramowania.

Ciekawym przykładem mogą być tutaj wieloletnie doświadczenia Sabre Airline Solutions związane z rozbudową systemu AirFlite Profit Manager, służącego do modelowania i prognozowania obciążenia samolotów należących do floty danego przewoźnika. Realizacja 8 wersji tego systemu z wykorzystaniem tradycyjnych metodologii opóźniła się o 4 miesiące, bowiem testy końcowe wykazały istnienie ponad 300 krytycznych błędów. Mało tego - gdy zaczęły się testy akceptacyjne prowadzone przez klienta, w ciągu zaledwie 3 dni znaleziono 26 kolejnych błędów, zaś dalsze testowanie prowadzone wspólnie przez Sabre i klienta doprowadziło do lokalizacji następnych 200 defektów w oprogramowaniu. Wesoło nie było, tym bardziej, że klient nie krył swego poirytowania zaistniałą sytuacją.

Z drugiej strony, nie było to wszakże nic zaskakującego - oprogramowanie w końcu liczyło ponad pół miliona linii kodu i taka liczba błędów w żaden sposób nie przekraczała statystycznego odsetka dla całego tworzonego oprogramowania (Watts Humprey, guru od spraw jakości oprogramowania z Software Engineering Institute, ocenia, że komercyjne oprogramowanie, w chwili gdy pojawia się na rynku, ma w sobie od 1 do 8 błędów na każdy tysiąc linii kodu).

Te problemy były jedną z przyczyn daleko idących zmian, jakie firma Sabre przedsięwzięła w obszarze wytwarzania oprogramowania. Jako jedna z pierwszych - bo już w 2001 r. - tak dużych organizacji twórczo wykorzystała techniki programowania ekstremalnego (eXtreme Programming). Z wielkim sukcesem, bowiem istotnie wzrosła nie tylko produktywność deweloperów, ale również jakość ich pracy. Dział Airline Solutions, który przeszedł na metodologię XP, ma w swojej ofercie ponad 70 aplikacji, składających się łącznie na 13 mln linii kodu, co stwarza wystarczająco dużą bazę do porównań statystycznych. A liczby mówią tutaj same za siebie.

Wersja 10 wspomnianego Profit Managera, wprowadzona na rynek w 2002 r., w ciągu 2 pierwszych miesięcy użytkowania ujawniła obecność zaledwie 10 błędów (do tej pory znaleziono ich mniej niż 100). Co prawda nowa wersja była napisana w Javie, obecnie podstawowym języku wykorzystywanym przez Sabre Airline Solutions (poprzednio był to C/C++), jednak przedstawiciele tej firmy sukces przypisują nie Javie, ale właśnie wyborowi metodologii XP. Korzyści finansowe były ogromne - przede wszystkim wyraźnie spadła liczba deweloperów obsługujących pojedynczego klienta firmy, który wdrożył u siebie system. Co więcej, w innym projekcie, którego znaczącą częścią była przebudowa interfejsu użytkownika na interfejs webowy, choć przejście na XP odbyło się w połowie trwania projektu, to od razu zaobserwowano wzrost wydajności programistów o ponad 40%.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200