Metodyka, którą wybraliśmy rozpoczynając pracę nad Yawpem, nazywa się Extreme Programming i jest to podejście na polskim rynku praktycznie nieznane. W rodzimej literaturze informacje na jej temat są szczątkowe, również polski internet dostarcza w tej kwestii jedynie podstawowe fakty. My sami poznaliśmy Extreme Programming podczas rocznego stażu w Stanach Zjednoczonych, który odbywaliśmy w 2012 roku w firmie Menlo Innovations w Ann Arbor, w stanie Michigan.
Menlo Innovations to firma dowodzona przez Richa Sheridana, jednego z najbardziej znanych przedsiębiorców w stanie Michigan, orędownika zwinnego podejścia do tworzenia oprogramowania oraz twórcy wysoko ocenianej książki dotyczącej kultury pracy w firmie IT pt. “Joy Inc”. Samo Menlo Innovations to zatrudniająca kilkadziesiąt osób firma, tworząca oprogramowanie dla takich przedsiębiorstw jak BD, Domino’s Pizza czy University of Michigan. Pracując tam przez rok poznaliśmy Extreme Programming wraz ze wszystkimi jego wadami i zaletami.
Extreme Programming jest metodyką stworzoną przez Kenta Becka, jednego z ewangelistów Agile’a oraz twórcy frameworka JUnit. Metodyka Extreme Programming zakłada, że jeśli jakaś praktyka lub metoda jest dobra, sensowna i sprawdza się w praktyce, powinniśmy wynieść ją na najwyższy, ekstremalny poziom. Czyli:
1. Jeżeli uważamy, że wzajemne sprawdzanie kodu jest dobre, powinniśmy robić to cały czas (programowanie w parach).
2. Jeżeli uważamy, że testowanie kodu jest dobre, powinniśmy robić to cały czas i na każdym poziomie projektu (testy jednostkowe i testy funkcjonalne).
3. Jeżeli dbanie o wygląd kodu jest dobre, będziemy się tym codziennie zajmować (refactoring).
4. Jeżeli prostota jest dobra, zawsze będziemy tworzyć system w najprostszy możliwy sposób, tak aby działał zgodnie z aktualnymi wymaganiami.
5. Jeżeli testy integracyjne są ważne, będziemy integrować i testować system kilka razy dziennie (ciągła integracja).
6. Jeżeli krótkie iteracje są dobre, sprawimy, że będą naprawdę krótkie.
Kent Beck wspominając początki Extreme Programming, mówi, że gdy pierwszy raz myślał o powyższych praktykach, miał w głowie deskę rozdzielczą, na której znajdowały się pokrętła, a każde pokrętło oznaczało jedną praktykę. Znał każdą z nich i wiedział, że każda z nich działa dobrze, ale co stałoby się, gdybyśmy wszystkie pokrętła podkręcili do granic możliwości w tym samym czasie? Tym właśnie jest Extreme Programming – podkręceniem wszystkich pokręteł do ekstremalnego poziomu.
Kent Beck zdecydował się na eksperyment – podczas pracy w Chryslerze wprowadził Extreme Programming do projektu, którym zarządzał. Jak sam przyznaje, był lekko zaskoczony, ale wszystko zadziałało perfekcyjnie. Odkrył wtedy, że zestaw metod – znany odtąd jako Extreme Programming – był stabilny, przewidywalny i elastyczny.
Gdy zaczynaliśmy pracę nad Yawpem, dobrze pamiętaliśmy jak doskonale Extreme Programming sprawdzało się w projektach, w których pracowaliśmy podczas naszej amerykańskiej przygody, więc wybór tej metodyki był dla nas całkowicie naturalny. Projekt tworzony przez dwie osoby rządzi się jednak swoimi prawami. Jesteśmy ograniczeni dostępnym czasem (obaj wciąż pracujemy na pełen etat w korporacjach), nie mamy sztywnych deadline’ów ani nie ma nad nami klienta, który regularnie oczekuje dostarczania nowych funkcjonalności. Jak sobie poradziliśmy w tym środowisku i jak udało nam się wdrożyć Extreme Programming w codzienną startupową rzeczywistość?
Po pierwsze zadbaliśmy o samodyscyplinę. Będąc jednocześnie twórcą oraz klientem projektu, bardzo łatwo o rozluźnienie i brak właściwego rygoru pracy. Dlatego już na samym początku zdecydowaliśmy, że pracować będziemy w bardzo krótkich, tygodniowych iteracjach zakończonych weryfikacją postępów dokonanych przez ostatni tydzień.
Każdą iterację zaczynamy od wybrania zadań, nad którymi będziemy pracować przez najbliższy tydzień. Pierwszym problemem, z którym musieliśmy się na tym etapie zmierzyć był czas do zaplanowania. Ze względu na fakt, że poza pracą nad Yawpem mamy szereg innych obowiązków (m.in. praca na pełen etat w korporacji), czas, który poświęcamy pracy nad projektem w każdym tygodniu jest różny. Zdecydowaliśmy się więc planować 60 godzin pracy na tydzień (po 30 godzin na osobę).
Jest to nasze absolutne minimum i staramy się, by zadania zaplanowane na te 60 godzin faktycznie zostały wykonane. Gdy czasem jednak zarwiemy kilka nocy więcej i popracujemy dłużej, problemu nie ma – bierzemy wtedy na warsztat zadania z puli oznaczanej w Extreme Programming jako “Pull Ahead”. Są to zadania dodatkowe, które fajnie byłoby zrobić, ale które mogą spokojnie poczekać na swój czas.
Aby łatwiej zilustrować czas potrzebny do zaimplementowania wymaganych funkcjonalności, wykorzystujemy arkusze papieru, reprezentujące jeden tydzień pracy. W naszym przypadku przyjęliśmy, że kartka formatu A4 oznacza 30h, tydzień więc to dwie takie kartki. Również każde user story, które dodajemy do projektu zapisujemy na podobnej kartce. Zasady są proste:
- zadanie zajmujące całą kartkę A4 to zadanie wycenione na 30h,
- zadanie zapisane na kartce A4 złożonej na pół to zadanie wycenione na 15h,
- zadanie zapisane na kartce A4 złożonej trzykrotnie to zadanie wycenione na 5h,
- zadanie zapisane na kartce A4 złożonej czterokrotnie to zadanie wycenione na 2h,
- w przypadku gdy zauważamy, że zadanie wymaga więcej niż 30h pracy, dzielimy je na mniejsze.
Dzięki temu planując dwa – trzy tygodnie naprzód, możemy z łatwością rozłożyć wszystkie potrzebne zadania na stole i dobrać ilość jak najlepiej odpowiadającą naszym możliwościom. Gdy już zaplanujemy iterację, przechodzimy do szczegółowej analizy poszczególnych zadań. Na tym etapie pojawiają się już konkretne pomysły dotyczące implementacji. Wyjątkowy duży nacisk kładziemy tutaj na spójność z już istniejącą architekturą oraz możliwość łatwego rozszerzania kodu.
I teraz następuje najważniejszy punkt całego procesu – kodowanie. Extreme Programming wyraźnie mówi, że pisanie kodu może odbywać się tylko w parach. Jak nietrudno się domyślić, tutaj napotkaliśmy największe problemy. W idealnym świecie obaj mielibyśmy dokładnie te same obowiązki, taki sam harmonogram dnia i każdego popołudnia spotykalibyśmy się i wspólnie tworzyli kod. W życiu jednak należy potrafić zaadaptować się do panujących warunków, które najczęściej od ideału są bardzo dalekie.
Zdecydowaliśmy się więc na według nas optymalne w tym przypadku rozwiązanie – jeżeli tylko mamy taką możliwość, spotykamy się w dwójkę i razem piszemy kod. Jeżeli jednak jest to niemożliwe, pracujemy nad zadaniami oddzielnie, ale nigdy nie umieszczamy kodu w repozytorium nie robiąc wcześniej wzajemnego code review. Dzięki temu nieustannie kontrolujemy wzajemnie jakość kodu oraz mamy świadomość tego co dzieje się w każdym aspekcie projektu.
Ta naturalna propagacja wiedzy powoduje, że każdy z nas może usiąść do dowolnego fragmentu kodu i w ciągu kilku minut wdrożyć się w niego na tyle, by poprawić błąd lub dodać nową funkcjonalność. Do code review wykorzystujemy funkcjonalność Pull Requestów dostępną na BitBucket.org.
W Extreme Programming ogromny nacisk położony jest na kompleksowe testowanie kodu. Zdajemy sobie doskonale sprawę, jak istotne dla powodzenia projektu są testy, więc nie zaniedbujemy tego elementu. Większość kodu pokrywamy testami jednostkowymi, tworzymy również scenariusze testów integracyjnych, którymi sprawdzamy czy poszczególne elementy systemu właściwie ze sobą współgrają.
Każdą iterację kończymy spotkaniem podsumowującym ostatni tydzień pracy. Siadamy wtedy razem z najnowszą wersją aplikacji i weryfikujemy każde user story, które w tej iteracji zakończyliśmy. Pozwala nam to upewnić się, że to co dostarczyliśmy zgadza się z założeniami przyjętymi na początku oraz wykryć ewentualne błędy, które przeoczyliśmy na wcześniejszym etapie.
Wdrożenie Extreme Programming w czystej formie – zwłaszcza w dwuosobowym startupie – nie jest zadaniem łatwym. Wymaga to bowiem całkowitej zmiany kultury pracy oraz wyjątkowej samodyscypliny. Jak już wspomnieliśmy wcześniej, nieidealna rzeczywistość również jest w tym aspekcie ograniczeniem. Ale nawet gdy wydaje nam się, że wprowadzenie Extreme Programming do naszego projektu jest zadaniem karkołomnym lub wręcz niemożliwym, warto pomyśleć o wzbogacenie obecnego sposobu pracy o elementy znane z tej metodyki.
Przede wszystkim mamy tu na myśli odważniejsze korzystanie z programowania w parach i położenie większego nacisku na testowanie. Pamiętać należy również, że każdy projekt i każdy zespół jest inny, a dostosowywanie metodyki pod konkretne warunki i szybkie reagowanie na zmiany jest rozwiązaniem, którego w zarządzaniu projektem należy szukać. To nie ślepe podążanie za regułami wyznaczonymi przez jakąkolwiek metodykę jest prawdziwą sztuką w świecie IT, a bycie zwinnym i elastycznym. Bycie agile.
–
Autorzy tekstu:
Kamil Brzeziński, Michał Godycki
Twórcy aplikacji Yawp, platformy bazującej na geolokalizacji, wykorzystującej sztuczną inteligencję w celu ułatwiania komunikacji między ludźmi w najbliższym otoczeniu. 5 kwietnia 2017 roku Yawp zaczął działać pod skrzydłami programu Startup School, firmowanego przez Y Combinator w San Francisco.
