Na prośbę kilku czytelników bloga publikuje treść artykułu mojego autorstwa zamieszczonego w najnowszym numerze kwartalnika Quale. Jak zwykle zapraszam do lektury i pozostawiania komentarzy….

Powiedzenie dzisiaj o organizacji, że jest zwinna (ang. agile) nie jest trudne, ale bycie „naprawdę agile” wymaga z pewnością sporego wysiłku. Wiele organizacji nadal transformuje siebie i swoje procesy w stronę metodyk zwinnych, ostatnio coraz mocniej na znaczeniu zyskuje również eliminowanie strat z koncepcją Lean na czele. Aby nie być gołosłownym, chciałbym przytoczyć ciekawe dane, które usłyszałem podczas zeszłorocznej konferencji Agile Management. Patrząc na rynek europejski, najwięcej projektów zwinnych ok. 80% ogółu robi się na rynku brytyjskim, na drugim biegunie z ok. 25% znajduje się rynek niemiecki. A jak myślicie gdzie w tym zestawieniu znajdujemy się my, otóż Polska plasuje się z wynikiem ok. 50%. Czy to dużo czy mało? Spróbujmy sami sobie odpowiedzieć na to pytanie. Chciałbym zainteresować Was kwestią doboru praktyk i narzędzi w projektach zwinnych, aby praca zespołu była wydajna a zarazem dostarczała na co dzień tzw. fun. Należy mieć na uwadze, iż wiele decyzji dotyczących wyboru narzędzi trzeba podjąć we wstępnej fazie trwania projektu, zanim zaczniemy pisać kod, ponieważ determinują one późniejsze zależności lub zwyczajnie na dalszych etapach może okazać się, że na zmiany jest już za późno. Oczywiście chciałbym przy tym zaznaczyć, że nie ma jednego magicznego zestawu narzędzi, który będzie idealnie pasował do wszystkich rodzajów projektów, jednakże postaram się, aby każdy z Was mógł znaleźć tu coś wartościowego dla siebie.

Po pierwsze: Repozytorium Kodu Źródłowego

Narzędzie do kontroli wersji kodu oraz synchronizowania zmian poszczególnych członków zespołu nie jest oczywiście czymś unikalnym w projektach zwinnych, jest tak samo ważne we wszystkich metodykach, ale piszę o nim, ponieważ bez niego zespół nie będzie w stanie normalnie pracować. Mówiąc o zespole mam na myśli developerów implementujących nowe funkcjonalności, testerów badających konkretne zmiany w nowych rewizjach kodu czy osobę odpowiedzialną za przekazanie wersji do klienta, ewentualnie wdrożenie na produkcję. Co warto zaznaczyć, narzędzie niekoniecznie musi służyć wyłącznie do wersjonowania kodu. Z praktyki wiem, iż można wersjonować inne rzeczy takie jak: skrypty testowe, dokumentację, testy automatycznie, itd. W momencie, kiedy decydujemy się na wersjonowanie dodatkowych rzeczy zależnych od wersji kodu, musimy pamiętać, aby je w logiczny sposób skorelować z kodem. Zazwyczaj robi się to poprzez nadawanie tagów. Nadajemy ten sam tag odpowiedniej wersji kodu oraz korespondującym z nią plikom testów automatycznym, dokumentacji, itd.
Najpopularniejszymi narzędzi tego typu są:

• Subversion (SVN) – darmowy, prosty w instalacji system kontroli wersji, zbudowany na podstawie systemu CVS. Dodatkowo łatwo integruje się ze zintegrowanymi środowiskami programistycznymi, wspiera Continous Integration (o tym w dalszej części) oraz ma wiele innych zastosowań, które znajdziecie na stronie produktu.
• Git – darmowy, rozproszony system kontroli wersji. Początkowo zbudowany przez Linusa Torvaldsa do wsparcia rozwoju Linuxa. Aktualnie wspiera wiele systemów operacyjnych.
• Bazaar – darmowy, łatwy w obsłudze system kontroli wersji, zbudowany całkowicie od nowa z uwzględnieniem pewnych ograniczeń SVN.

Po drugie: Zintegrowane środowisko developerskie (ang. IDE)

Wybór środowiska developerskiego często narzuca nam technologia, w której chcemy budować oprogramowanie. W projektach zwinnych jednym z wymagań, o których należy pamiętać jest to, by środowisko developerskie integrowało się z narzędziem do kontroli wersji. Ma to przeciwdziałać problemom wersjonowania oraz integracji kodu tworzonego przez poszczególnych członków zespołu. W większości organizacji wybór IDE jest z góry określany przez technologie. Dobrą praktyką jest utrzymywać jeden rodzaj platformy w całym zespole (w projektach Java może to być np. Eclipse). Wówczas mamy możliwość lepszej współpracy, dzielenia się wiedzą, łatwiej też przyjdzie nam sprawdzenie technik programowania w parach czy przeglądów kodu, jeśli się na nie zdecydujemy. Wiele z takich platform ma rozbudowany system dodawania pluginów (dodatków), które rozszerzają środowisko developerskie funkcjonalnie i technicznie. Równie istotne, co pisanie nowego kodu jest przeglądanie i refactoring starego (do dyspozycji mamy statyczne analizatory kodu, które bez kompilacji zwrócą listę potencjalnych zagrożeń i błędów w kodzie).
Najpopularniejsze środowiska developerskie to:

• Eclipse i NetBeans używane w projektach wykorzystujących technologie i język programowania Java.
• Visual Studio używanie w projektach wykorzystujących technologie Microsoft
• IntelliJIDEA – komercyjne zintegrowane środowisko programistyczne dla Javy, Androida, Scala i wielu innych języków.

Po trzecie: Narzędzie do tworzenia buildów

W projektach zwinnych każdy z zespołów musi mieć możliwość częstego i szybkiego weryfikowania jakości swojej pracy. Bardzo istotne jest to, aby zespół wiedział, jak szybko przetworzyć dostarczony kod w wykonywalny plik czy gotową do testów aplikację. W zespołach, w których pracowałem bądź aktualnie pracuję, wykorzystuje się do tego narzędzia ANT lub Maven w celu zbudowania wykonywanej wersji projektu. Te narzędzia łatwo współdziałają ze zintegrowanymi środowiskami developerskimi oraz narzędziami do testów automatycznych. Idąc krok dalej docieramy do narzędzi, które pozwalają zautomatyzować proces tworzenia buildów. Continuous Integration (CI), bo o nim mowa, jest jedną z kluczowych praktyk zespołów zwinnych. Z koncepcją CI wiąże się potrzeba szybkiego feedbacku w reakcji na wprowadzoną zmianę. W kilku słowach, polega to na zestawieniu automatycznego procesu budowania produktu, puszczeniu na nim automatycznych testów potwierdzających jakość zastosowanych rozwiązań i zwróceniu wyników w postaci raportu. W pełni zautomatyzowany proces jest kluczem do sukcesu, dlatego dobierając narzędzia ważne jest, aby wszystkie wcześniej opisane komponenty współpracowały z wybranym rozwiązaniem CI. Przykładem darmowych narzędzi tego typu jest Hudson/Jenkins. Sprawnie działający proces CI jest kluczowy dla powodzenia projektu, wobec czego rekomenduję go opracować i ewentualnie zestawić przed rozpoczęciem developmentu.

Po czwarte i ostatnie: Testy jednostkowe

W przypadku tego typu praktyki istotne jest to, aby podjąć decyzję na starcie i zacząć tworzyć testy jednostkowe od samego początku trwania developmentu. Podejmując decyzję później, w trakcie realizacji kolejnych iteracji, narażamy się na niepowodzenie i frustrację zespołu, który będzie musiał przejrzeć i pokryć testami napisany już wcześniej kod. Testy jednostkowe wymagają pewnego nakładu pracy, jednakże pamiętajmy, że z jednej strony dostarczają testowalny kod a z drugiej budują podwaliny pod testy na kolejnych etapach tworzenia oprogramowania. Nie bez znaczenia jest fakt, iż błędy znalezione na tym etapie nie są powielane w późniejszych fazach projektu, przez co kosztują zespół i projekt relatywnie najmniej. Narzędzia do pisania testów jednostkowych zależą od języka programowania, w których tworzymy produkt. Najpopularniejsze to Junit dla Javy i Nunit dla .Net. Również kod reprezentujący GUI powinien być testowany wcześniej, na przykład przy pomocy TestNG lub SWTBot.

Podsumowując, narzędzia wybierajmy świadomie, dobrze wiedząc, czego od nich oczekujemy. Wybór odpowiednich rozwiązań typu Continuous Integration, procesu tworzenia buildów i automatyzacji testów ma wspierać zespół przez dostarczanie informacji zwrotnej tak szybko, jak to możliwe. Zespoły, które nie podejmą przemyślanych decyzji we właściwym momencie, mogą mieć trudności, co może prowadzić do frustracji, złej atmosfery pracy bądź w skrajnych przypadkach przyczynić się do niepowodzenia projektu.