Kto z nas nie słyszał o metodykach agile? Kto z nas nie chciał kiedyś którejś z nich spróbować? Ileż razy czytaliśmy agile manifesto, myśląc „to mogłoby być coś dla mnie”?

Jeżeli podpisujesz się pod powyższymi pytaniami, czytaj dalej. Jeżeli nie słyszałeś o agile, to przeczytaj najpierw koniecznie powyższe agile manifesto. Jeżeli pracowałeś już w agile – czytaj dalej, aby przekonać się, jak to jest pracować w agile dla Królowej.

Agile przedstawiane jest jako podejście rozwiązujące większość problemów dostarczania oprogramowania dla naszych klientów. Kim bowiem jesteśmy my – programiści? Czyż nie charakteryzujemy się właśnie tym, że tak wielu wśród nas pasjonatów? Czy wielu znamy księgowych, którzy w wieku 7 lat pomagają rodzicom składać zeznanie roczne? Albo prawników którzy przed ukończeniem 10 roku życia piszą pierwsze pismo przedsądowe? Być może tacy są, ale cytując znany autorytet współczesnego internetu „ja takich nie znam”. Dla nas – programistów – pierwszy kalkulator napisany w Basicu, zanim jeszcze przeczytaliśmy pierwszą szkolną lekturę, to chleb powszedni.

A co idzie w ślad pasji? Co powoduje, że chce nam się codziennie wstać z łóżka, przyjść do pracy i „dostarczać”? Dlaczego wbrew terminom, naciskom, a nierzadko kłótniom i niesnaskom staramy się dostarczyć nie tylko kod, który działa, ale też jest skalowalny, wydajny, testowalny, łatwy do przeczytania i zrozumienia, słowem taki, z którego możemy być potem dumni? Każdy ma swoją odpowiedź na te pytania, moja jednak brzmi: bo lubimy i zrobimy wiele, by lubić swoją pracę.

I do takich właśnie ludzi kierowany jest agile. Poza wieloma aspektami korzystnymi z punktu widzenia biznesowego, jest to metodyka, która ma uczynić pracę programisty dużo lepszą. Ma sprawić, że będzie ją lubił, a dzięki temu pracował na 100% swojej wydajności. Z tego powodu wielu programistów myśli (myślałem tak i ja), że kiedy trafią już do projektu agile, to czeka na nich sielanka. Niech główną myślą tego artykułu będzie jednak, że tak nie jest. Prawdziwe agile, to dużo, dużo pracy, ale „totally worth it!”

5 listopada 2012 r. rozpocząłem śniadaniem w hotelu nad Tamizą w małej miejscowości pod Londynem. Zaraz potem wyruszyłem do biura naszego klienta realizującego politykę „digital by default” wprowadzaną przez brytyjski rząd w jego departamentach i komórkach w całym Zjednoczonym Królestwie. Nasza menedżer projektu wprowadziła nas do biura klienta i zapoznała z zespołem, z którym miało nam przyjść pracować przez kolejne trzy miesiące. Oczekiwano od nas pracy zwinnej (polskie określenie na Agile). Pierwsze kilka dni, jak zawsze, zajęło nam zaaklimatyzowanie się, zestawienie środowiska programistycznego, wstępne zapoznanie z realiami operacyjnymi klienta, jak i samymi założeniami projektu. Z technologiami open-source obejmującymi OpenGeo suite, Scalę oraz Play! framework zapoznaliśmy się już wcześniej – albo w ramach innych projektów, albo też w ramach skill-up* przygotowującego do naszego projektu.

W naszym zespole pracowało czterech programistów, jeden solution architect (czyli lider technologiczny), project manager, product owner, grafik, specjalista domenowy oraz kilka osób od strony klienta, które dostarczały wymagania. Najważniejszą z tych osób był product owner, czyli człowiek delegowany przez klienta do opieki nad projektem, ustalania priorytetów zadań i wszelkich kwestii formalnych. Jest to również jedyna osoba po stronie klienta (choć niekiedy tę rolę może pełnić kilka osób) będąca członkiem głównego zespołu – tzw. core team. Nie da się przecenić istotności product ownera dla zespołu, bo sukces wielu projektów dyktowany jest jego dostępnością i zaangażowaniem. To właśnie dzięki niemu możliwa jest praca w ramach Agile – zamiast edytować dokument z wymaganiami i tygodniami czekać na jego zatwierdzenie, udajemy się do product ownera, który od razu przekazuje nam wiążącą decyzję. W naszym przypadku product owner miał pełne uprawnienia, jak i stuprocentowe zaangażowanie w nasz projekt przez 40 godz. w tygodniu – lepiej być nie mogło!

Tego wszystkiego dowiedzieliśmy się w poniedziałek. Natomiast już w czwartek rozpoczęliśmy pierwszy sprint. Sprintem nazywamy okres ustalonej długości (w naszym przypadku był to tydzień), w którym zespół realizuje określone na początku sprintu cele. Inne nazwy to timebox albo iteration. W metodyce Scrum jest to jednak zawsze sprint.

Czym jest Agile, czym jest Scrum?

Krótko: Agile to podejście lub nawet filozofia rozwijania oprogramowania (i nie tylko), która opisuje założenia i ogólniki. Scrum zaś to konkretna implementacja Agile.

W Agile odchodzimy od podejścia typu waterfall, w którym kolejne fazy rozwoju projektu następują po sobie. Zamiast tego fazy nakładają się na siebie i w prawie każdym momencie projektu jesteśmy w więcej niż jednej fazie. Umożliwia to elastyczne podejście do zmiany wymagań, które jest zasadnicze w projektach dostarczających oprogramowanie, jako że nasz klient nie ma możliwości z góry określić, czego od nas chce (często jest to prawie tak samo trudne, jak sama realizacja zadania). Dlatego dużo bardziej praktyczne jest podejście, w którym zgadzamy się na partnerskie poszukiwania wymagań wraz z realizacją designu** i implementacji, do szczegółów wymagań można wrócić nawet po rozpoczęciu testów, kiedy to też wciąż postępuje spora część implementacji. Nasz projekt (zamiast na waterfallowe fazy) podzielony jest więc na iteracje, a każda z nich ma inną domieszkę domen lub dyscyplin (domena lub dyscyplina to test, requirements, implementation itd. czyli wszystko to, co wcześniej było fazami). Udział każdej z dyscyplin w poszczególnych iteracjach układa się w charakterystyczne wykresy.

Scrum to jedno z podejść do Agile, stosowane powszechnie w Kainos. Czym jest Scrum? Kiedyś na jednej z rozmów kwalifikacyjnych usłyszałem, że wszystkim. Że czasami ratuje życie. Skąd ta opinia? Pracowałem w Scrumie tylko raz, ale nigdy przedtem, ani nigdy potem nie pracowałem w warunkach, w których wydajność programistów byłaby tak wysoka. Scrum zawiera konkretne artefakty i procesy oraz zalecenia, które umożliwiają pracę Agile. Jednym z elementów Scrum jest planning poker.

Ale o tym napiszę więcej w kolejnym poście :)

* Podnoszenie swoich umiejętności z danej dziedziny wspierane przez firmę Kainos w czasie godzin pracy.

** Przepraszam, ale nie ma dobrego polskiego odpowiednika tego słowa – słowo „projekt” go nie oddaje.