[projekty] Metodyki Agile w rozwoju aplikacji mobilnych (cz. 2)

Zasady programowania ekstremalnego, metodyki oddającej w najlepszym chyba stopniu założenia AGILE, są bardzo proste i łatwe do wdrożenia w Twoich projektach. Oficjalna strona XP prezentuje kilka schematów wg których powinno się prowadzić projekt. Według mnie, na początku nie warto się nimi bardzo precyzyjnie kierować (w końcu to AGILE), tylko przyjąć trzy ważne zasady zarządzania projektami:

1. Zbuduj niewielki zespół
2. Utrzymuj stały kontakt z klientem
3. Publikuj często kolejne kawałki programu

Dlaczego tylko tyle? Od metodyki chciałoby się oczekiwać czegoś więcej, a najlepiej automatu zapewniającego sukces każdego projektu. Oczywiście można dołożyć więcej reguł, ale być może na początek trzy powyższe wystarczą.

Niewielki zespół to założenie najłatwiejsze do spełnienia, ponieważ aplikacje mobilne zazwyczaj są systemami dużo mniejszymi niż odpowiedniki komputerowe. W konsekwencji tworzą je kilkuosobowe zespoły. UWAGA! W projekcie mogą pojawić się podwykonawcy, np. niezależne studio graficzne. To również członkowie zespołu. Nigdy nie zlecaj prac na zasadzie „zleć i zapomnij”.  Dobrym przykładem na pracę zespołową z podwykonawcą była kooperacja przy rozwoju gry Football Tactics. Dzięki włączeniu Olmeka Creation House do zespołu, mogliśmy stworzyć bardzo dobre warunki współpracy pomiędzy grafikami, programistami, a projektantami gry i oczywiście zespołem zarządzającym (wtrąceń z PMBoK i PRINCE2 trudno czasem uniknąć J ). Gdyby komunikacja z grafikami była ograniczona do wymiany informacji przez pośrednika, zapewne narazilibyśmy się na duże opóźnienia i wiele nieporozumień.

Utrzymywanie stałego kontaktu z klientem nie zawsze jest łatwe, ponieważ czasem trudno określić kto jest klientem. Jeżeli tworzy się system na zamówienie, to nie ma z tym większego problemu. Warto tylko zatroszczyć się o to, żeby od samego początku po stronie klienta znalazła się zaangażowana i komunikatywna osoba, która będzie szybko dostarczać niezbędnych informacji. W przypadku aplikacji mobilnych nie tworzonych on demand, potencjalnych klientów trzeba sobie stworzyć. Przy pracy nad Football Tactics, gdzie potencjalnym klientem są zróżnicowani użytkownicy smartfonów i tabletów z całego świata, stworzyłem grono testerów składające się z kobiet i mężczyzn w różnym wieku, pracujących w różnych zawodach. Zapewniali oni feedback podobny do tego, który daje kontakt z klientem. Oczywiście prowadzone były też testy wewnątrz zespołu projektowego, ale miały zupełnie inny charakter.

Najtrudniejszą z zasad jest częste publikowanie działających fragmentów aplikacji. Tego przy Football Tactics nie udało się zrobić. Publikowaliśmy nieregularnie, a aktualizacje kodu były nieproporcjonalne. Co gorsza nie planowaliśmy dokładnie co ukaże się w kolejnej wersji. Były to kardynalne błędy, które kosztowały nas wiele czasu i błędów w programie. Gdyby udało się pracować w systemie jedno – dwu tygodniowym i wypuszczać dobrze zaplanowane aktualizacje, projekt zakończylibyśmy dużo szybciej. Rygor częstych aktualizacji ma co najmniej trzy zalety:

1. Motywuje do pracy dając odczuwalny deadline (odległe terminy nie motywują)
2. Nie zniechęca do pracy, ponieważ wymaga tworzenia niewielkich części programu
3. Pozwala na częste testowanie i szybkie wyłapywanie błędów

Najlepszym znanym mi przykładem stosowania XP w praktyce jest rozwój narzędzia Construct2 przez Scirra. Warto zajrzeć na ich stronę, żeby zobaczyć jak znakomicie komunikują się ze swoimi klientami i potencjalnymi klientami, jak często aktualizują aplikację (100 aktualizacji w 2 lata) i w jak małym zespole pracują.

Konkluzja – spróbuj zastosować zaproponowane zasady w kolejnym projekcie i po jego zakończeniu podsumuj plusy i minusy takiego podejścia do zarządzania.

Linki:

Olmeka Creation House – www.olmeka.pl

Scirra – www.scirra.com