Marta Bartnicka, Agenor Hofmann-Delbor
Agile software development (programowanie zwinne) to grupa metod wytwarzania oprogramowania opartego na programowaniu iteracyjno-przyrostowym, powstałe jako alternatywa do tradycyjnego modelu kaskadowego (waterfall). Najważniejszym założeniem agile jest obserwacja, że wymagania odbiorcy (klienta) często ewoluują podczas trwania projektu. Pojęcie zwinnego programowania zostało zaproponowane w 2001 w Agile Manifesto.
Model lokalizacji oprogramowania Agile, czyli tzw. zwinny, wydaje się najlepiej dopasowany do potrzeb współczesnego rynku: oprogramowanie powstaje po kawałeczku, a tłumaczenia muszą nadążać (rysunek 1).
Model ten zakłada ciągły cykl przepływu pracy i jest stosowany, gdy:
- zlokalizowana wersja musi być dostępna niemal natychmiast, z czasem projektów liczonym w dniach (czasem nawet godzinach!), a nie tygodniach lub miesiącach;
- oprogramowania będzie testowane w wielu językach i dostarczane równocześnie na wiele rynków;
- klient może zmodyfikować wymagania względem produktu w trakcie jego tworzenia;
- bardzo istotny jest czas dotarcia do klienta.
Model Agile współgra z koncepcją Continuous Delivery polegającą na (niemal) ciągłym wdrażaniu zmian do produktu. Najlepszym przykładem są aplikacje dla urządzeń mobilnych, w których trudno wręcz zauważyć nowe wersje; nasz smartfon po prostu co jakiś czas pobiera aktualizację, a apka zaskakuje nas kolejnymi ulepszeniami. Analogicznie wygląda to dla wielu aplikacji dostępnych przez WWW: ich producent nie ogłasza nowej wersji, tylko po prostu zmienia wygląd i funkcjonalność portalu.
Agile a lokalizacja
Warto pamiętać, że pod względem procesów, metodyki pracy i użycia technologii branża lokalizacyjna jest zwykle parę lat do tyłu w stosunku do branży IT. Najlepszym dowodem na to jest fakt, że programiści metodykę Agile (a właściwie różne metodyki spełniające jej założenia) znają od roku 2001. To wówczas uznano, że w dużym zespole z bardzo tradycyjnym podejściem do zarządzania projektami trudno wprowadzać szybkie zmiany, których oczekuje klient końcowy — przełożone na bardziej jednoznaczne z perspektywy programistów zapisy w postaci zaktualizowanej listy wymagań i specyfikacji produktu. Aby skuteczniej i szybciej reagować na takie sytuacje, część obowiązków kierownika projektów musiało przejść do roli programisty. Agile ma w założeniu sprawiać, że małe zespoły programistów będą gotowe na częste zmiany wymagań i będą w stanie samodzielnie zarządzać swoją codzienną pracą. Minusem, ale i nieodzowną konsekwencją Agile jest to, że programiści w zespołach skupiają się na komunikacji i realizowaniu zadań, ale niekoniecznie spędzają wiele czasu na dokumentowaniu tego, co tworzą.
Metodyka Agile będzie więc w znacznym stopniu przygotowywać zespół na zmiany w projekcie, nawet jeśli wystąpią na późniejszym etapie pracy. Kluczem do jej skutecznego stosowania jest nacisk na jakość kodu i organizację pracy — można powiedzieć, że dzięki tej metodyce oprogramowanie powstaje szybciej, ale też zwiększa się wpływ ewentualnych błędów programisty na projekt. Aby zatem przeciwdziałać długofalowym konsekwencjom, wszelkie inspekcje wymagań i aktualizacje wydań oprogramowania są przeprowadzane znacznie częściej niż w stosowanych dawniej metodykach wytwarzania oprogramowania.
Zmiany w sposobie produkcji oprogramowania siłą rzeczy muszą wpłynąć na to, jak pracują dzisiejsze firmy lokalizacyjne i tłumacze. Zrozumienie tych konsekwencji sprawi, że dzisiejsze realia tysięcy małych i coraz bardziej rozdrabniających się projektów na rynku nie są specjalnie zaskakujące.
Agile a testy
Model Agile ma też poważne konsekwencje dla testowania. Przesyłanie materiału do tłumaczenia w małych kawałeczkach oznacza najczęściej, że narzędzia generujące podgląd ekranów nie mogą się wykazać. Cała weryfikacja tego, co wyjdzie po złożeniu tych kawałeczków, przechodzi więc na testera. Co więcej, za każdym razem do testów trafiają tylko nowe i zmienione fragmenty interfejsu, które zostaną wmontowane w interfejs wcześniej przetłumaczony (i przetestowany), a więc — z założenia — niepodlegający zmianom. Scenariusze testowania muszą więc coraz więcej mówić o tym, jak dotrzeć do danego kawałeczka i gdzie NIE zaglądać, bo coraz więcej materiału jest poza zakresem testów. Komunikacja testerów z programistami coraz bardziej skupia się na tym, czego NIE sprawdzać w danej rundzie testów lokalizacji.
W praktyce można realizować to na przykład w ten sposób, że tester dostaje źródłowe zrzuty ekranów z zaznaczonymi fragmentami podlegającymi testowaniu. Jeśli na ekranie zlokalizowanym znajdzie błąd w tym obszarze, to powinien go zgłosić lub poprawić. Jeśli jednak znalazłby coś poza tym obszarem, to… no cóż, w zasadzie powinien to zignorować, chyba że błąd jest naprawdę wielkiej wagi. Liczba godzin pracy testera jest skalkulowana tak, że nie uwzględnia zapuszczania się w obszary poza zadanym zakresem.
Cóż więc może pójść źle?
Może się okazać, że wydzielenie materiału do testów wcale nie jest proste, a co więcej — na styku starego i nowego tłumaczenia pojawiają się niespójności.
Weryfikując na przykład polską wersję przedstawionego ekranu (rysunek 2), tester nie powinien zwracać uwagi na teksty spoza ramki. W założeniu ma więc tylko sprawdzić, że nazwy działań do wykonania (tłumaczenia fraz „Complete”, „Invalidate”…) i odpowiadających im stanów (przetłumaczone „Done”, „Invalid”…) wyświetliły się we właściwym języku, mieszczą się w swoich kolumnach i są w formie gramatycznej zgodnej z nagłówkami tych kolumn. Jeśli w ten sposób tester (pół)świadomie przeoczy literówkę poza zakresem ramki, to pół biedy; prawdopodobnie nie przyniesie to większej szkody dla ostatecznego wyglądu i działania aplikacji. Gorzej będzie, jeśli tłumaczeniem „Name” okaże się „Nazwisko”, bo z wcześniejszych porcji lokalizowanego pliku nie wynikało, że powinna to być „Nazwa”.
Drugim rodzajem ryzyka wynikającego z testowania w trybie Agile jest brak czasu na wykonanie pełnego cyklu działań opisanego wcześniej: testy — poprawki — ponowne testy. W tym modelu pracy zdarza się coraz częściej, że testerzy nie będą mogli zweryfikować poprawek wprowadzonych w danej rundzie projektu; przesyłają raport, pliki zostają na jego podstawie poprawione i ponownie wkompilowane w produkt, po czym produkt ten trafia już do użytkowników. Najczęściej jest dzięki temu lepszy niż przed testami, ale czasami okazuje się, że poprawka nie wyszła tak, jak planowano.
Jeszcze inny efekt uboczny metodyki Agile występuje, kiedy harmonogramy tłumaczenia i testowania nie są poprawnie zsynchronizowane — czyli nie udaje się w porę dorzucić do produktu ostatnio przetłumaczonych zasobów, co daje na przykład taki efekt (cytat z raportu testera):
Po 48 godzinach testowania: 12% scenariuszy testowania wykonane z błędami. Produkt raczej nie nadaje się do sprzedaży, gdyż część ekranów jest w 50% po angielsku. Przyszedł właśnie do tłumaczenia pakiet, który mógłby rozwiązać ten problem, ale development każe nam zamknąć testy już dzisiaj, a tłumaczenie dosłać jutro.
Nie ma się jednak co obrażać na Agile
Dostarczanie oprogramowania w trybie Continuous Delivery to kierunek przyszłościowy, coraz chętniej obierany przez producentów i zarazem oczekiwany przez coraz bardziej niecierpliwych odbiorców. Branża lokalizacyjna może więc jedynie dostosować się do tego, co dzieje się w świecie programistycznym.
Warto też dostrzegać plusy — coraz więcej narzędzi generuje pliki do lokalizacji w formatach takich jak XLIFF, a coraz więcej środowisk programistycznych ma wbudowane automatyczne mechanizmy internacjonalizacji oprogramowania. Choć praca tłumacza na coraz bardziej pokawałkowanym materiale jest trudna i niewdzięczna, to strona techniczna takiej lokalizacji stwarza coraz mniej problemów.
Jak jednak rozsądnie odnaleźć się w nowych realiach z etapem testowania? Wydaje się, że pozostaje jedynie coraz skuteczniejsze planowanie testów z założonym marginesem czasu (oraz funduszy) na poprawki. Choć działamy tu niemal „na styk”, a więc w najbardziej ryzykowny sposób z perspektywy zarządzania projektami, to przynajmniej jesteśmy w stanie czerpać doświadczenia z podobnych projektów programistycznych, a i w lokalizacyjnych szybko gromadzimy doświadczenie.
Tekst (po niewielkich zmianach) pochodzi z książki „Programiści i tłumacze”.
