• Author: Dominik Zalewski
• Published in: SDJ Extra – Zespół przede wszystkim

Nie będzie to książkowy artykuł o tym jak trudno wdrożyć Scrum w firmie stosującej przez ostatnie 20 lat tradycyjne metodologie rozwoju oprogramowania. Nie będzie to też artykuł o tym co to jest sprint (iteracja), ‘scrum master’ oraz retrospekcja.

Będę starał się opisać w jaki sposób zaadoptowaliśmy metodologię Scrum do naszych własnych potrzeb, w jaki sposób nasi klienci milcząco tę metodologię przyjęli, jak pomógł nam w tym produkt IBM o nazwie Rational Team Concert oraz jak musieliśmy pomóc sobie sami.

Wprowadzenie

Poniedziałek rano. Najbardziej nielubiany przeze mnie czas spędzony w pracy. Ale to nie dlatego, że skończył się weekend. To dlatego, że przede mną tak zwane ‘raportowanie czasów’. Ja i mój zespół zajmujemy się głównie konsultingiem SAP. W tym świecie przyjętą normą jest przesyłanie wspomnianych raportów z końcem każdego tygodnia. Polega to po prostu na przesłaniu listy czasów spędzonych nad rozwiązywaniem problemów klientów.

Organizując pracę z naszymi klientami nie mieliśmy nigdy problemów z wdrożeniem zwinnych metodologii takich jak Scrum. A to dlatego, że w świecie SAP normą jest chaos. Niestety pozwolenie sobie na przyjęcie go bez ograniczeń zazwyczaj skutkuje utratą klienta po pierwszym miesiącu współpracy. Klienci nie wymagają niczego oprócz dwóch rzeczy:

• tygodniowego raportu czasu pracy oraz
• periodycznych telekonferencji przez telefon (czasami jest to raz na tydzień, a czasami codziennie).

Po naszej stronie pozostaje zorganizowanie sobie pracy i zarządzania zadaniami w ten sposób aby tygodniowy raport czasu pracy był wiarygodny.

Tak naprawdę, kiedy pierwszy raz usłyszałem o Scrum zacząłem się zastanawiać, czy to nie jest po prostu nazwanie tego procesu, który konsultanci SAP stosowali od lat. Oczywiście jest w tym zdaniu dużo przesady. Chciałem jednak tym dosyć mocnym stwierdzeniem pokazać, że wcześniej opisana przeze mnie specyfika pracy z klientami SAP miała już dwa podstawowe filary metodologii Scrum zaszyte w sobie:

• klienci chcieli sie komunikować często i wszelkie swoje wymagania defniować (i zmieniać) werbalnie przez telefon – brak dokumentacji, często zmieniające się wymagania,
• klienci chcieli wiedzieć za co płacą, aby móc kontrolować ten proces (w odróżnieniu od otrzymania na koniec miesiąca faktury z jedną pozycją: ‘Godziny konsultingu’ w wymiarze XX).

Klienci sami z siebie byli świadomi, iż nie są w stanie jasno przed rozpoczęciem całego procesu zdefiniować swoich wymagań i tym samym oszacować kosztów i pracochłonności. Tak jak w zwinnych metodologiach, chcieli oni po prostu uruchomić ten proces i kontrolować go na każdym kroku. Nie mieliśmy więc tego problemu, który pojawia się zazwyczaj przy wdrażaniu Scrum, tzn. że proces ten jest wygodny dla programistów, lecz bardzo niewygodny dla księgowych.

Modelowanie procesu

Kluczowymi dla nas decyzjami związanymi z modelowaniem procesu współpracy z naszymi klientami były odpowiedzi na następujące pytania:

• jakich darmowych narzędzi możemy użyć,
• na jakie płatne narzędzia pozwala nasz budżet,
• jakie narzędzia musimy napisać sami?

Szybko zorientowaliśmy się, iż proces który modelujemy bardzo dobrze obrazuje Rycina 1.

Rycina 1: Model procesu

Kolumna (A) przedstawia zaplanowany sprint, czyli w skrócie listę zadań które należy zrealizować. Kolumna (B) to wykaz czasu pracy w podziale na programistów wraz z opisami co w danym przedziale czasu zostało zrealizowane. Kolumna (C) pozwala kontrolować proces. Zawiera ona tzw. ‘burndown chart’ (część (C1)), czyli zapożyczony ze Scrum sposób wizualizacji pracy, która została jeszcze do wykonania. Natomiast w części (C2) widzimy raport dla klienta zawierający czasy w podziale na rozplanowane w kolumnie (A) zadania. W dalszej części opiszę każdą z kolumn ryciny 1 szczegółowo.

Standardowe narzędzia

Na rynku jest dostępnych wiele płatnych I bezpłatnych narzędzi do zarządzania zadaniami. W zasadzie problem zarządzania zadaniami jest tak stary, iż wydawałoby się że wystarczy użyć jednej z popularnych wyszukiwarek internetowych aby znaleźć narzędzie odpowiednie dla naszych potrzeb. Jednakże problem pojawia się jeżeli zaczynamy te narzędzia rozpatrywać przez pryzmat rozszerzalności, integrowalności i elastyczności – słowem względem czegoś co obecnie etykietuje się modnym akronimem SOA (Service Oriented Architecture). Odpowiedzi na takie pytania jak:

• (a) czy będę miał programy klienckie dostępne zarówno na platformie Linux jak I Windows,
• (b) czy programy klienckie będą dostępne pod dowolną przeglądarkę internetową,
• (c ) czy strona serwerowa jest uruchamiana na dowolnej platformie,
• (d) w jaki sposób mogę nowe narzędzie zintegrować z narzędziami już używanymi w firmie,
• (e) jaki jest koszt zakupu takiego rozwiązania,

powodują ograniczenie naszego wyboru do zaledwie kilku narzędzi, a w dalszej częsci tego tekstu będę starał się przekonać Iż w zasadzie do jednego – Rational Team Concert. Wymagania (a)-(c ) RTC spełnia bezapelacyjnie. To na czym chciałbym się skupić, to wymaganie (d). Jednak zanim przejdę do szczegółów, porównam najpierw RTC z innymi narzędziami, które również były brane przez nas pod uwagę, nie dlatego że były lepsze względem kryteriów (a)-(d), lecz ze względu na, nie da się ukryć bardzo ważne, finansowe kryterium (e). Systemy zarządzania zadaniami, które rozpatrywaliśmy, to: Mantis, Jira oraz RTC. Wszystkie z nich, oprócz RTC, były polecone przez zaprzyjaźnione firmy w których były używane z powodzeniem. Naturalne było zweryfikowanie ich przydatności jako sprawdzonych narzędzi względem jeszcze wtedy przez nas nieznanego nowego narzędzia RTC.

O produkcie o nazwie Mantis wiedziałem już w zasadzie od około 7 lat. Jednakże znałem go jako ‘system śledzenia błędów’. Pomyślałem jednak, iż w tak długim okresie czasu mógł on ewoluować do czegoś bardziej ogólnego. Podczas jego testów okazało się jednak iż w zasadzie nadal jest on systemem śledzenia błędów I tylko tym. Brak w nim wsparcia dla planowania iteracji. Trochę mniej istotnym dla programistów, a jednak zauważalym mankamentem jest to iż interfejs WWW pochodzi w zasadzie z poprzedniej epoki.

Jedynym plusem, który widzieliśmy w tym systemie to fakt iż miał on wbudowaną funkcjonalność automatycznej rejestracji czasu pracy. Jest ona zrealizowana w następujący sposób. Programista klikajać na zadanie powoduje pojawienie się jego szczegółów na ekranie. Tam też znajduje się przycisk ‘Start’ oraz ‘Stop’. Wciśnięcie przycisku ‘Start’, a następnie ‘Stop’, powoduje dopisanie zmierzonego interwału czasu jako oddzielny wpis czasu pracy przypięty do zadania. Jest to rzecz, której brakuje zarówno w produkcie Jira jak i RTC. Co więcej, jest to funkcjonalność którą musieliśmy sami wyemulować integrując nasze autorskie narzędzie z RTC (o czym później). Mimo wszystko jednak funkcjonalność ta zaimplementowana w systemie Mantis pozostawia wiele do życzenia. Jest to powiązane z wcześniej wspomnianym faktem, iż interfejs WWW pochodzi z XX, a nie XXI wieku. Ze względu na to, iż nie jest tam używany AJAX, osoba obsługująca zadanie jest zmuszona do pozostania na tej samej stronie w przeglądarce. Jakakolwiek próba sprawdzenia listy zadań lub przeszukania historycznych wpisów powoduje iż jesteśmy wyrzuceni ze strony rejestracji czasu pracy I tym samym proces rejestracji przestaje działać.

Podsumowując możliwości systemu Mantis muszę stwierdzić iż narzędzie to z naszego punktu widzenia nie rokuje szans na wykorzystanie w nowoczesnej infrastrukturze informatycznej. Brak możliwości wykorzystania go w infrastrukturze typu SOA oraz przestarzałość interfejsu graficznego definitywnie skreśla jego szanse na wdrożenie.

Produkt Jira był podobnie jak RTC nieznanym przez nas produktem. Za zweryfikowaniem jego przydatności przemawiały bardzo dobre materiały umieszczone na stronie producenta. Filmy wideo pokazujące możliwości tego narzędzia dowodzą iż narzędzie jest wprost przystosowane do wsparcia Scrum. Co więcej, porównanie cen licencji Jira oraz RTC, wskazuje na system Jira jako na faworyta. Ponadto Jira ma wtyczkę dla Eclipse, pozwala na pisanie własnych rozszerzeń oraz integrację z SVN.

Zanim zdołaliśmy się zabrać za weryfikację i testy tego narzędzia, zostaliśmy włączeni w projekt u klienta który już systemu Jira używał. Mogliśmy więc jego przydatność sprawdzić w praktyce. Szybko zorientowaliśmy się, że wtyczka do Eclipse jest przereklamowana podobnie jak integracja z SVN. Można odnieść wrażenie iż produkt jest podzielony w zasadzie na dwie części. Moduł przeglądarkowy służy do zarządzania zadaniami, natomiast wtyczka do Eclipse służy jedynie zarządzaniu kodem źródłowym i rzekomej integracji z SVN.
Głównym interfejsem użytkownika okazał się być interfejs przeglądarkowy, dość mało intuicyjny zresztą. Ale to co najbardziej irytuje w tym systemie to jedynie dwupoziomowa glębokość zależności rodzic-dziecko przy budowaniu zależności między zadaniami. Żadnych innych zależności (‘duplikuje’, ‘jest powiązane z’) nie da się tam zbudować. Natomiast zmiana przypisania rodzic-dziecko to kwestia przejścia przez 4 ekrany ‘czarodzieja’ (ang. wizard). Wtyczka Eclipse próbuje śledzić jakie zadanie jest wykonywane przez programistę i na tej podstawie dołączać wygenerowane automatycznie wpisy do logów SVN tak, aby można było powiązać zadanie z kodem źródłowym. Według mnie jednak nie można stwierdzić iż ta integracja została pomyślnie zaimplementowana i w prawdziwym projekcie infromatycznym jest bezużyteczna.

Biorąc pod uwagę powyższe dwa zasadnicze niedociągnięcia w systemie Jira, stwierdziliśmy iż nie będziemy poświęcali czasu na zweryfikowanie rozszerzalności tego systemu, gdyż przeprowadzone dotąd testy dyskwalifikowały to narzędzie do naszych potrzeb.

Narzędzie Rational Team Concert było od samego początku faworytem w naszych testach. A to z uwagi na fakt iż mieliśmy z nim wcześniej do czynienia. Ja, ucząc jeszcze na uniwersytecie i prowadząc zajęcia dotyczące produktów IBM zaznajomiłem się z jego możliwościami dość dobrze. Ponadto dwóch moich pracowników napisało prace magisterskie na jego temat. Jednakże były to warunki akademickie, w których nie musieliśmy brać pod uwagę czysto komercyjnych aspektów takich jak na przykład cena rozwiązania. Poniżej zacznę od wymienienia wszystkich cech RTC tak aby porównanie z systemem Mantis oraz Jira było pełne.

Interesujące nas trzy główne aspekty RTC to zarządzanie zadaniami, kontrola kodu źródłowego oraz możliwość integracji. Do zarządzania zadaniami mamy do dyspozycji wersję oprogramowania działającą w przeglądarce lub klienta Eclipse. Odwrotnie niż w systemie Jira, tutaj nacisk położony jest na klienta Eclipse, co oznacza iż wszystkie funkcjonalności dostępne są z poziomu Eclipse, a tylko niektóre z poziomu przeglądarki internetowej. Jest to zrozumiałe, gdyż trudno sobie wyobrazić wersjonowanie kodu źródłowego działające w przeglądarce (chociaż używając HTML5 nie jest to niemożliwe). Nie chciałbym jednak wprowadzać czytelnika w błąd. Przeglądarkowa wersja modułu zarządzania zadaniami jest w pełni funkcjonalna i może być używana zamiennie z klientem Eclipse do codziennej pracy. Powodem dla którego IBM naprawdę postarał się o funkcjonalność obydwu interfejsów jest licencjonowanie. Licencje z dostępem jedynie przez przeglądarkę (dla testerów, managerów) są po prostu tańsze.
Zarządzanie zadaniami jest bardzo intuicyjne i elastyczne. Mamy do dyspozycji wiele różnych widoków w zależności od roli odgrywanej w projekcie (manager, programista). Co najważniejsze mamy możliwość bardzo dogłębnej konfiguracji. Nie skłamę jeżeli powiem, że do tej pory nie udało mi się zgłębić nawet połowy możliwości RTC w tym zakresie.

Zarządzanie kodem źródłowym w RTC, to bajka dla programisty przyzwyczajonego do SVN. Rational Team Concert posiada również integrację z SVN, ale dla nowych projektów naprawdę gorąco polecam moduł SCM (Source Code Management) wbudowany w RTC. Już po tygodniu używania SCM zauważyliśmy bardzo miłą rzecz. Funkcjonalność rozwiązywania konfliktów przy zatwierdzaniu kodu źródłowego jest zaimplementowana o niebo lepiej niż w SVN. Kiedy moi programiści byli zmuszeni do powrotu do SVNa w innym, nowym projekcie, już na drugi dzień słyszałem narzekanie na czas jaki należy poświęcić na scalanie w SVN. Jeszcze inną wyróźniającą SCM cechą jest organizowanie zmian w repozytorium kodu źródłowego w zbiory (ang. change sets). Pozwala to na powiązanie zmian w kodzie źródłowym z zadaniami oraz na wybiórczą aktualizację kodu źródłowego. Obydwie te rzeczy są niemożliwe lub bardzo trudne do osiągnięcia stosując integrację z SVN.

Integracja istniejących narzędzi z RTC jest również bardzo łatwo osiągalna. RTC posiada zbiór bibliotek napisanych w języku Java nazywanych ‘Plain Java Client Libraries’, dzięki którym można z poziomu kodu źródłowego uzyskać dostęp do RTC jako usługi. Przykłady zastosowania dostępu do RTC przez API opiszę w rozdziale ‘Integracja narzędzi’.

Podsumowując porównanie trzech narzędzi, bezapelacyjnie naszym faworytem jest Rational Team Concert. Zwięzłe porównanie cech trzech produktów opisanych w tym paragrafie przedstawiłem w Tabeli 1.

Tabela 1: Porównanie Mantis, Jira oraz RTC

Autorskie Narzędzie

Wybór RTC jako podstawowego narzędzia używanego w naszym procesie obsługi klientów pozostawił nadal otwartą kwestię rejestracji czasu pracy (kolumna (B) z ryciny 1). Jedyne wsparcie jakie daje RTC w tym zakresie, to możliwość przechowywania sumy czasów spędzonych nad zadaniem. Jest to przedstawione na Rycinie 2.

Rycina 2: Przechowywanie czasu pracy w RTC

W dolnej części ryciny widzimy właściwość ‘Time Remaining’ przechowywaną po prostu jako standardowy atrybut przypięty do zadania. Programista spędzając powiedzmy 1h nad zadaniem dzisiaj i 2h nad zadaniem jutro, winien sam zaktualizować ten atrybut odejmując od bieżącej wartości jednego dnia 1h, a drugiego dnia 2h. Wszyscy wiemy jak skorzy są programiści w ogólności do utrzymywania spójnej informacji w ten sposób. Finansowanie naszej organizacji zaleźy przede wszystkim od dokładności tego właśnie procesu. Nie mogliśmy pozostawić tak dużej luki w naszym procesie. Co więcej, dokładność planowania iteracji oraz tzw. ‘burndown chart’ który jest jądrem procesu Scrum, również zależą bezpośrednio od dokładnej rejestracji czasu pracy. Dlatego też zdecydowaliśmy się na napisanie własnego autorskiego narzędzia służącego temu celowi.

Nasza lista wymagań wyglądała następująco:

• (a) aplikacja winna działać z poziomu przeglądarki internetowej
• (b) musi być możliwa rejestracja czasu pracy bez podłączenia do sieci
• (c) musi być możliwa integracja z RTC ale także z innymi systemami typu ‘task engine’

Ponieważ nie chcieliśmy wiązać naszego narzędzia bezpośrednio z RTC lub żadną inną platformą, dlatego też zdecydowaliśmy się na wymaganie (a). W szczególności nasz system nie wymaga w ten sposób instalacji np. Eclipse aby działać. Zostawia to pewną niedogodność dla programistów, którzy pracując w Eclipse chcieliby z poziomu tego środowiska rejestrować czas pracy. Wymaganie (b) wynikało z faktu, iż czasami praca z naszymi klientami wymaga udania się do budynku zewnętrznej organizacji, gdzie z uwagi na wymogi bezpieczeństwa, nie mamy nieograniczonego dostępu do internetu. Często również pracujemy w tunelu (VPN) lub po prostu w drodze (pociąg). Ze względu na fakt, iż rozwój własnych narzędzi jest z założenia kosztowny, chcieliśmy mieć możliwość jak największej elastyczności tak aby móc to narzędzie w przyszłości integrować z innymi platformami i sprzedawać. Dlatego zdecydowaliśmy się na wymaganie (c).

Rycina 3: Timekeeper

Rycina 3 przedstawia podstawowy widok naszego narzędzia, które nazwaliśmy ‘Timekeeper’. Zasadniczo składa się ono z trzech części. W prawej górnej częsci widzimy bieżącą listę zadań do wykonania. Dla naszych potrzeb mamy skonfigurowane pobieranie zadań z RTC, jednakże system nie jest ograniczony jedynie do RTC (więcej o tym w rozdziale ‘mozliwosci przyszlego rozszerzania’). Zadanie takie można przeciągnąć na pulpit, który znajduje się w dolnej części prawej strony ekranu. Czyniąc tak powodujemy wyświetlenie się szczegółów zadania na pulpicie oraz, co ważniejsze, rozpoczynamy proces automatycznej rejestracji czasu spędzonego nad zadaniem. Objawia się to pojawieniem się nowego wpisu w lewej częsci – kalendarzu – który to wpis będzie co 5 minut aktualizowany tak długo jak zadanie zostaje na pulpicie. Jeżeli skończymy pracę nad zadaniem, należy przycisnąć ‘Stop’ na pulpicie i wpis w kalendarzu przestanie się aktualizować.

Integracja narzędzi

Oprócz interfejsu użytkownika, który opisałem w poprzednim punkcie, w systemie Timekeeper uruchomione są również procesy/usługi działające w tle. Zgodnie z wymaganiem (b) aplikację można używać w trybie offline. Wydawać by się mogło iż wymagania (a) oraz (b) wykluczają się. Jednakże obydwie funkcjonalności udało nam się zaimplementować z użyciem ‘Google Gears’, który w niedługiej przyszłości ma być zastąpiony implementacjami zgodymi z HTML5. Oznacza to, że tworzone w kalendarzu wpisy przechowywane są po stronie przeglądarki internetowej w małej bazie danych na dysku w profilu użytkownika. Wpisy te muszą być synchronizowane z serwerem. Co każde 5 minut z pozmiomu przeglądarki wyzwalna jest synchronizacja wpisów lokalnych z serwerem.

Lista zadań również przechowywana jest w lokalnej bazie przeglądarki, dzięki czemu jest możliwe jej wyświetlenie również gdy nie mamy połączenia z interentem. Lista ta jest odświeżana na żądanie i powoduje pobranie z RTC listy otwartych zadań do wykonania. Szczegóły tego interfejsu będą opisane w rozdziale ‘jazz-task’.
Kolejnym procesem jest proces synchronizacji wpisów w kalendarzu z RTC (pole ‘Time Remaining’ na rycinie 2). Po stronie serwera naszej aplikacji uruchomiony jest scheduler, który wyzwala co noc przepisywanie czasów z kalendarza do RTC. Wykonywane jest wtedy grupowanie względem numeru zadania, tak aby uzyskać sumaryczny czas spędzony nad zadaniem. Proces ten będzie opisany w rozdziale ‘jazz-feedback’.

Do integracji z RTC użyliśmy bibliotek ‘Plain Java Client’ dostępnych standardowo z RTC. Postaram się teraz przybliżyć jak proste jest użycie tych bibliotek przy integracji niezależnych narzędzi z RTC. Pokażę to na przykładzie użytych przez nas w aplikacji Timekeeper obiektów z tych bibliotek.

Rycina 4: Logowanie z użyciem PJCL

Rycina 4 przedstawia kod potrzebny do uruchomienia komunikacji z RTC. W linii (37) oraz (62) używamy obiektu TeamPlatform aby zainicjować i zakończyć pracę z obiektami biblioteki PJCL. W liniii (57) oraz (61) widzimy logowanie i wylogowywanie się z repozytorium. Dostarczenie hasła i użytkownika to odpowiedzialność zaimplementowanego in-line obiektu ILoginHandler. Natomiast adres samego repozytorium RTC podajemy w linii (40). Mając tak zainicjowane połączenie możemy przystąpić do pracy z usługami RTC.

jazz-task

Stworzony przez nas moduł ‘jazz-task’ pozwala na pobranie z RTC bieżącej listy otwartych zadań dla konkretnego użytkownika systemu Timekeeper.

Rycina 5: Uruchomienie zapytania do RTC

Istotny dla artykułu fragment kodu został przedstawiony na Rycinie 5. Uruchomienie tego kodu spowoduje wypisanie na ekranie tytułów wszystkich zadań w obszarze projektowym ‘gj-timerec’, które zwróci zapytanie ‘Open assigned to me’.
W liniach 105-108 pobrana zostaje referencja na obszar projektu. W liniach 114-117 pobieramy wszystkie współdzielone zapytania z obszaru projektu RTC. Następnie iterujemy po nich (linia 119) szukając otwartych zadań przypisanych do programisty (linia 120). W lniach 122-123 uruchamiamy znalezione zapytanie, aby następnie pobrać wszystkie zadania zwrócone z tego zapytania (linie 125-127). W lnii 128 drukujemy tytuł pojedynczego znalezionego zadania.

jazz-feedback

Moduł sprzężenia zwrotnego pozwala na aktualizację czasów z systemu Timekeeper to RTC, tak by można było dalej w RTC korzystać z funkcjonalności raportowania oraz monitorowania procesu wytwarzania oprogramowania.

Rycina 6: Aktualizacja zadania w RTC

Używane przez na API zostało zamieszczone na rycniach 6 oraz 7. Uruchomienie kodu z ryciny 6 oraz 7 spowoduje zaktualizowanie czasu pracy nad zadaniem o numerze 1002 do 2 roboczogodzin. W lniach (73)-(74) następuje pobranie zadania o numerze 1002. Linie (79)-(80) to prezentowany już wcześniej sposób na pobranie referencji do obszaru projektu. Następnie w linii (82) pobieramy referencję na atrybut ‘czas spędzony nad zadaniem’ w obszarze projektu. Aby zaktualizować zadanie, należy posłużyć się konstrukcją podaną w lnii (85), która w rzeczy samej jest bardzo podobna do uruchomienia oddzielnego wątku w Javie. Zadanie aktualizacji musimy uruchomić w ten sposób ze względu na wielodostępowość RTC i możliwość wystąpienia konfliktu przy aktualizacji.

Rycina 7: Aktualizacja zdania w RTC, cd.

Rycina 7 przedstawia w jaki sposób programiści PJCL uwolnili nas od zarządania wielodostępowością w RTC. Wszystko co musimy uczynić chcąc wykonać operację modyfikacji zadania to rozszerzyć klasę WorkItemOperation. Zadba ona o pobranie najnowszej wersji zadania, wysłanie naszych zmian na serwer oraz potencjalne scalenie zmian z ewentualną modyfikacją która mogła nastąpić równolegle. Nasz kod aktualizujący jest wolny od tych wszystkich szczegółow i ustawia jedynie pożądaną przez nasz wartość atrybutu za pomocą zwykłego settera (linia (149)).

Możliwość przyszłego rozszerzania (SOA)

Sposób w jaki udało nam się zintegrować RTC z naszą infrastrukturą i autorskim narzędziem (Timekeeper) daje nam bardzo dużą elastyczność. Jest to szczególnie istotne w dzisiejszych czasach, kiedy zmiany w komponentach oprogramowania używanych w firmie często wymuszane są raz na parę lat.

Dla porównania, firma z którą wpółpracujemy od wielu lat używa zarówno do rejestracji czasu pracy, zarządzania zadaniami oraz raportowania czasu do klientów jednego narzędzia. Jest to autorskie narzędzie wytworzone wewnętrznie ponad 10 lat temu. Obecnie firma ta bardzo chętnie wymieniłaby przynajmniej część tego rozwiązania na nowsze. Niestety jednak wokół tego monolitu jest skonfigurowanych tyle zależnych narzędzi, że zadanie to jest praktycznie niewykonalne.

Dla odmiany, nasza infrastruktura zawiera teraz oddzielne komponenty do zarządzania zadaniami i rejestracji czasu pracy. Raportowanie jest jeszcze w fazie rozwoju, ale można je również uważać za oddzielny komponent. Gdybyśmy chcieli w przyszłości wymienić silnik zarządzania zadaniami, możemy to zrobić fazowo:

• najpierw dodając nowy silnik zarządzania zadaniami do narzędzia rejestracji czasu pracy (Timekeeper) – w tym momencie dwa silniki zarządzania zadaniami działają równolegle
• potem stopniowo doimplementowywać zależne od silnika zadań interfejsy
• na koniec usunąć powiązanie ze starym slinikiem.

Podobnie możemy postąpić z dowolnym innym komponentem w naszej infrastrukturze. Dzięki temu nasze rozwiązanie jest nie tylko aktualne dzisiaj, ale również będzie aktualne w przyszłości.

Przykładem może być sprzęg z systemem SAP nad którym obecnie pracujemy. Podobnie jak RTC jest silnikiem zadań, również za taki silnik może służyć system SAP z wdrożonym modułem obslugi HR. Aby nasze narzędzie współpracowało z SAP wystarczy abyśmy zaimplementowali odpowiedniki serwisów jazz-task oraz jazz-feedback dla SAP. Kiedy skończymy pracę nad tymi modułami będziemy mieli możliwość rejestracji czasu pracy dla RTC oraz SAP oddzielnie, lub współbieżnie w jednej instacji systemu Timekeeper.

Podsumowanie

Jesteśmy zespołem programistów nie uznającym kompromisów jeżeli chodzi o jakość i elastyczność wytwarzanego oprogramowania. Problem rejestracji czasu pracy, z którym się zmierzyliśmy okazał się dużo bardziej skomplikowany niż się spodziewaliśmy. Zachowując otwarty umysł udało nam się wykorzystać najnowsze technologie (RTC, GWT, Google Gears), zaosczędzić ile się tylko dało używając standardowych komponentów (RTC) oraz sporo się nauczyć modelując proces w którym uczestniczymy na codzień.

Dzięki narzędziu Timekeeper otrzymaliśmy możliwość dokładnej rejestracji czasu pracy. Jest to zasadnicze dla zachowania dobrych stosunków z klientami. Narzędzie RTC dostarczyło nam wszystkich funkcjonalności związanych z planowaniem oraz monitorowaniem procesu wytwarzania oprogramowania.

Kończąc niniejszy artykuł chciałbym tym samym podziękować firmie IBM za udostępnienie tak doskonałego i elastycznego narzędzia jakim jest RTC. Bez niego moje nielubiane poniedziałkowe poranki trwałyby zapewne do wtorku.

Dominik Zalewski