Programowanie zwinne - praktyka

No i stało się. Zostałem przymuszony do napisania czegoś, czego nie planowałem. Po wpisie o ekstremalnym programowaniu przyszła pora na opisanie rzeczywistych przykładów prowadzenia projektów. Tytułem wstępu - opisze trzy projekty, prawdziwe, "dziejące się". Pierwszy z nich to aplikacja back-officowa, służąca do agregowania sprzedawanych produktów (przede wszystkim), komunikacji z innymi działającymi aplikacjami oraz czymś ala intranet. Druga to aplikacja typu "pasaż handlowy". Aplikacja służy do zbierania (różnymi kanałami) ofert sprzedaży różnych dostawców oraz umożliwia zakup bezpośrednio na stronie. Ostatnia, trzecia aplikacja to moduł do istniejącej i działającej aplikacji. Moduł ten (kadrowo-płacowy) jest jednak tak skomplikowany i rozbudowany, że traktuje go osobno. Ten pierwszy pisany jest w metodyce scrum, drugi dopiero przechodzi na scruma, trzeci był tupu "kompletna aplikacja".

Scrum

Aplikacje typu backoffice są moim zdaniem najtrudniejszymi w pisaniu. Pisze się zawsze dla "kolegi z pracy" i nie można takiego skierować na palmę w celu prostowania bananów. Mimo wszystko działamy po tej samej stronie umowy o pracę. Trzeba każdego dopieścić. Przy tworzeniu tej aplikacji działa równolegle inna, która służy do zgłaszania błędów i zachcianek. Klientów reprezentuje podczas estymacji kilka osób (kierownicy działów IT, rozwoju, działu z którego najczęściej korzysta się z aplikacji). Sprint jest teoretycznie trzytygodniowy, ale podzielony jest na trzy etapy. Pierwszy "podcykl" obejmuje wprowadzanie nowych funkcjonalności, kończy się buildem. Drugi, to tzw. tydzień maintenance`owy. Polega on na naprawie błędów, które pojawiły się w aplikacji po ostatnim bulidzie. Błędy, które wymagają dużych nakładów pracy rozwiązywane są przy kolejnym buildzie. Ostatni tydzień polega rozwiązywaniu problemów i błędów, które są w aplikacji od dłuższego czasu, ale nie są na tyle krytyczne, by poprawiać je w tygodniu mainteneance`owym. Dodatkowo tydzień ten może być przeznaczony na dopieszczanie kodu, ewentualnie wprowadzanie własnych rozwiązań. Ostatni tydzień - trzeci build.

Przykład tej aplikacji to doskonały okaz lekkiej modyfikacji metodyki pracy pod konkretny projekt. Teoretycznie sprint powinien kończyć się buildem, tutaj mamy trzy buildy w każdym sprincie. Sposób ten (z jasnymi i oczywistymi wadami) jest związany głównie z tym, że core aplikacji jest od dawna ukształtowany, ale kolejne modyfikacje funkcjonalności znacząco wpływają na niego. To z kolei spowodowane jest przede wszystkim częstymi zmianami polskiego prawa (zwłaszcza kwestie fakturowania), a także... no cóż tu dużo mówić... brakiem konsekwencji u klienta.

Wkrótce scrum

Druga aplikacja jest własnością firmy, która do tej pory korzystała z usług firm outsourcingowych, jednak zdecydowała się na stworzenie własnego zespołu. Warte nadmienienia jest to, że firma nie była zadowolona z sposobu prowadzenia aplikacji, który używał własnej metodyki. Metodyka ta (zdaje się nienazwana) zakładała build aplikacji za każdym razem, gdy nowa funkcjonalność została wprowadzona, ale na zasadzie "nie bierzemy odpowiedzialności za kompatybilność".

Zespół w początkowej fazie, która nie była jeszcze scrumowa, zapoznawał się z istniejącą aplikacją. Do aplikacji dołączona była dokumentacja typu PHPDoc. Zgodnie z ustaleniami z zarządem aplikacja będzie realizowana w sprintach 1 miesięcznych, natomiast klientami będą tylko trzy osoby - prezes firmy, szef marketingu oraz (na czas estymacji) osoba odpowiedzialna za SEO. Po estymacji SEOwiec wraca na swoje miejsce w zespole. W zespole pracuje tester, który na bieżąco sprawdza poprawność wprowadzonych funkcjonalności. Tester też odpowiedzialny jest za modelowanie danych oraz optymalizację zapytań.

Sama aplikacja jest stosunkowo prosta, ale zespół nastawiony jest na kreatywne działania i sam sobie bywa klientem. Umowa z zarządem firmy zakłada premie za każdy zamknięty w terminie sprint, oraz konsekwencje finansowe w przypadku braku terminowego builda. Zespół składa się z grafika (freelancer, ale usidlony, tzn. nie zwykł odmawiać, jest terminowy i solidny), programistów backendowych i frontendowych w liczbie czterech (dwóch pierwszych pisze core aplikacji w PHP, dwóch kolejnych odpowiedzialnych jest za szablony i część aplikacji w CSS i JS [dobra, bez żartów - w JQuery]). Tester, jak już wspomniałem modeluje także dane, SEOwiec czaruje z treścią strony itp. Do tego wszystkiego Scrummaster, który jest równocześnie szefem działu. Na jego głowie, poza aplikacją jest także dbanie o ciągłość pracy zespołu, serwerownie itp.

Gdy piszę ten tekst, drugi build się zbliża wielkimi krokami. Pierwszy głównie optymalizował kod, sprawiał, że strona była czytelna, a serwer nie dostawał czkawki przez fatalne zapytania do bazy.

Wersja "pod klucz"

Aplikacji w tym kraju typu "kadrowo-płacowe" jest od groma. Część z nich naprawdę dobra i droga, część w sam raz dla "małych firm", część totalnie nie nadająca się do pracy. Te dobre i drogie mogą takie być z dwóch powodów - mają dobre zespoły, a nasz ustawodawca dba o to, żeby co roku mieli co robić. Tymczasem ile kadrowych, tyle przyzwyczajeń i "a w poprzedniej pracy to było fajniejsze". Dlatego zarząd firmy zdecydował się stworzyć zespół, dać mu bardzo realny termin i wymagać od zespołu stworzenia aplikacji "na wymiar".

Jak już pisałem MKP jest tylko modułem do istniejącej aplikacji. Jak się okazało, aplikacja już w tej chwili zawiera prawie wszystkie dane potrzebne do prowadzenia rejestru kadrowo płacowego. Brakował tylko szczegółów (typu RCP) oraz samego modułu do zarządzania już wprowadzonymi danymi. Zespół zdecydował się na stworzenie rdzenia aplikacji w języku c#. Całość podzielono na kilka etapów (rozliczenia comiesięczne, rozliczenia coroczne, sytuacje jednostkowe [zwolnienia, przyjęcia do pracy itp.]). Całość powinna komunikować się z istniejącymi rozwiązaniami (przede wszystkim Płatnik).

Aplikacja w pierwszej kolejności została rozplanowana. Kilkadziesiąt roboczogodzin zostało poświęconych na stworzenie grafów aplikacji (mistrz od UML i Enterprise Architect z ogromną wiedzą o ZUS się przydał). Po procesie planowania rozpoczęły się pracę nad tworzeniem core`u aplikacji równocześnie z interfejsem. Po stworzeniu tych części rozpoczęto żmudne i długie łączenie aplikacji w całość. Po 11 miesiącach prac aplikacja zeszła z developerskiego środowiska na "preprodukcyjny", gdzie została sprawdzona przez zespół kadrowych w warunkach bojowych. Ostatni miesiąc (i trochę) zespół spędził na poprawkach.

Od samego początku tworzenia aplikacji zespołowi przyświecał cel, by ich aplikacja była jak najbardziej elastyczna pod względem założeń, które naprawdę co roku ulegają zmianie. I o dziwo wszystko zdaje się działać zgodnie z tym założeniem. Już za 4 miesiące będzie pewnie okazja by sprawdzić opcję rollercaster.

Podsumowanie

Niestety nie mogę napisać bardziej szczegółowo o wszystkich tych aplikacjach. Jednak mam nadzieję, że już po tych kilku szczegółach widać - powodzenie wprowadzenia metodyki pracy zależy od charakteru projektu. A idąc dalej, wszelkie gotowe metody pisania aplikacji są tylko wzorami, które należy dostosować do własnych potrzeb. Nie ma gotowych, idealnie dopracowanych metodyk. Do wszystkiego jednak można dojść, wystarczy słuchać się wzajemnie i korzystać z wynalazku cywilizacji - kompromisu.