Kolega podesłał mi ostatnio bardzo ciekawy link: http://builder.com.com/5100-6374_14-5121760.html. Autor artykułu proponuje swoista kartę praw programowania ekstremalnego, listę zasad ściśle (wedlug autora Steve’a Hayes) definiujących projekt/zespół XP. Zasady te zostały podzielone na trzy części: prawa klienta, prawa programisty i wreszcie prawa managera.

Przyjrzyjmy się tym zasadom:

Prawa klienta:

1. Klient ma prawo planowania na dużą skale (na wysokim poziomie abstrakcji) zarówno w ujęciu kosztów jak i priorytetów.
2. Klient ma prawo do ustalania priorytetów w realizacji projektu dla danej iteracji.
3. Klient musi widzieć postęp prac nad projektem w postaci działającej aplikacji po pierwszej iteracji (oczywiście chodzi o szkielet aplikacji), oraz w postaci kolejnych funkcjonalności dodawanych w każdej kolejnej iteracji.
4. Klient ma prawo uaktualniać harmonogram (zarówno dobry jak i zły) tak szybko jak tylko informacje wpływające na to uaktualnienie są dostępne.
5. Klient ma prawo zmienić zdanie (wymagania), przy czym nie powinien ponosić niebotycznych kosztów tych zmian.
   

Prawa programisty:

1. Programista ma prawo szacować (estymować) czas pracy nad danym problemem i to oszacowanie musi być szanowane przez pozostałych członków zespołu.
2. Programista ma prawo/obowiązek uczciwie informować o postępie prac.
3. Programista ma prawo/obowiązek dostarczać rozwiązania o najwyższym standardzie przez cały czas.
4. Programista ma praw/obowiązek wiedzieć jakie są priorytety dalszych prac (wiedzieć co należny wykonać w kolejnym kroku).
5. Programista ma prawo zadawać pytanie z dziedziny biznesowej projektu gdy tylko takowe się pojawia.

Prawa managera:

1. Manager ma prawo do całościowej oceny kosztów i rezultatów musi jednak brać pod uwagę ze takowa ocena nie jest w 100% pewna i oddająca stan rzeczywisty.
2. Manager ma prawo przesuwać ludzi pomiędzy projektami bez ponoszenia zawrotnych kosztów.
3. Manager ma prawo/obowiązek do comiesięcznych raportów z postępu prac oraz pomocy klientowi w ustalaniu ogólnych priorytetów.
4. Manager ma prawo anulować projekt, pozostając z pracującym systemem oddającym dotychczas poniesione (zainwestowane) koszty.

Przeanalizujmy wiec prawa klienta dokładniej:

1. Klient ma prawo planowania na dużą skale (na wysokim poziomie abstrakcji) zarówno w ujęciu kosztów jak i priorytetów.
   Ten punkt większej dyskusji nie wymaga, to dość oczywiste iż to klient decyduje co chce osiągnąć, ile możne zapłacić za dane rozwiązania oraz co jest dla niego najważniejsze. Problemy pojawiają się niestety przy tworzeniu rozwiązań nie “szytych na miarę” – aplikacji tworzonych nie dla konkretnego klienta. Wprowadza się wtedy tzw. klienta wewnętrznego (z ang. on site customer: http://www.agilemodeling.com/…/activeStakeholderParticipation.htm), niestety sprawa kosztów i priorytetów troszkę się wtedy komplikuje, ale z doświadczenia wiem, iż troszkę dobrej woli i trzymania się pewnych zasad pozwala osiągnąć sukces.
2. Klient ma prawo do ustalania priorytetów w realizacji projektu dla danej iteracji.
   Jak wszyscy wiedza – podstawowa jednostka czasu w metodologii Agile jest iteracja. Podstawowe planowanie dotyczy tejże właśnie. To prawo jest szczególnym przypadkiem ogólnej sytuacji przedstawionej powyżej. Według mnie należny jednak dodać iż klient ma oczywiście ostateczne słowo co do priorytetów kolejnej iteracji, ale nie koniecznie powinien takie decyzje podejmować bez konsultacji z zespołem pracującym nad projektem, wręcz nie jest nie wskazane takowe działanie. Pewne decyzje mogą być podyktowane racjami technicznymi projektu i następstwami pewnych, w języku informatycznym “nisko poziomowych” decyzji. Priorytety te mogą również być uzależnione od zasobów dostępnych w danej iteracji – w końcu informatycy tez biorą urlopy albo chorują – jakkolwiek inaczej myśleli by managerowie projektów i klienci – to się nie zmieni . Więc dość oczywiste jest, iż tylko współpraca na wszystkich poziomach pozwala na osiąganie sukcesów.
3. Klient musi widzieć postęp prac nad projektem w postaci działającej aplikacji po pierwszej iteracji (oczywiście chodzi o szkielet aplikacji), oraz w postaci kolejnych funkcjonalności dodawanych w każdej kolejnej iteracji.
   Jedna z zalet prawidłowo stosowanej metodologi Agile jest praktycznie natychmiastowa gotowość to uruchomienia systemu np. w celu prezentacji postępu, demonstracji wraz z posiadaniem wiedzy na temat aktualnych ułomności systemu – tak, tak, stosując prawidłowo Agile jest się w stanie dokładnie określić co w danym momencie nie działa tak jak powinno i w jakim stanie jest projekt. Dobry zespół XP powinien tylko czytając logi ostatniej kompilacji (build’u) być w stanie ocenić stan i zaprezentować klientowi działający projekt. O niektórych informacjach dotyczących projektu powinno się wiedzieć nawet wcześniej, stad popularne w Agile tzw. information radiators (http://www.agileadvice.com/archives/2005/05/information_rad.html). Założeniam metodologi jest iż każda iteracja powinna wieńczyć się kolejna wersją sprawnego systemu.
4. Klient ma prawo uaktualniać harmonogram (zarówno dobry jak i zły) tak szybko jak tylko informacje wpływające na to uaktualnienie są dostępne.
   W prawidłowym projekcie Agile to klient decyduje o harmonogramie, oczywiście jak wspomniałem wcześniej nie znaczy to iż nie może swoich decyzji opierać na konsultacjach z zespołem realizującym projekt. Klient może dokonywać zmian w harmonogramie tak szybko jak tylko informacje wpływające na te zmiany są mu dostępne. Sama nazwa metodologi – “Agile” oznacz zwinność – czyli łatwe dostosowywanie się zespołu i projektu do zmiennych wymagań, zgodnie z oczywistym stwierdzeniem, zawartym z resztą w “Agile Manifesto” – iż wymaganie funkcjonalne i niefunkcjonalne podlegają zmianą i błędnym jest twierdzenie iż da się je kompleksowo zdefiniować przed przystąpieniem do realizacji projektu, a już na pewno nie jest to osiągalne w praktyce.
5. Klient ma prawo zmienić zdanie (wymagania), przy czym nie powinien ponosić niebotycznych kosztów tych zmian.
   Jak już zarysowane zostało w poprzednim paragrafie – Agile powstała między innymi w celu sprostania zmienności wymagań, wcześniejsze metodologie często błędnie zakładają iż wymagania się nie zmieniają, lecz jak pokazuje praktyka, wymagania ewoluują wraz z projektem. Zdolność adaptacji projektu do zmiennych wymagań nie oznacza jednak bynajmniej braku kosztów takich zmian, zawsze pewny nakład pracy i środków będzie wymagany, sedno jednak w tym, że Agile pozwala te koszty zredukować do minimum oraz zmiany przeprowadzić w bardzo krótkim czasie.

Prawa programisty:

1. Programista ma prawo szacować (estymować) czas pracy nad danym problemem i to oszacowanie musi być szanowane przez pozostałych członków zespołu.
   W mojej ocenie to jedna z najważniejszych zasad projektu prowadzonego w ramach metody Agile, niestety z doświadczenia wynika, iż to również zasada najczęściej łamana.
   Częstym błędem jest próba estymacji “kartek” (z ang. cards – czyli opisu pojedynczej funkcjonalności – user story – na karteczce, patrz: http://www.agilemodeling.com/artifacts/userStory.htm) przez osoby inne niż programiści faktycznie wykonujący (implementujący) daną funkcję. Do takich zaniechań według mnie prowadzić mogą:
   • błędne mniemanie iż programiści mają na celu estymowanie zadań powyżej ich faktycznej pracochłonności – nie wykluczone iż w pewnych sytuacjach może być to prawdą, lecz sedno sprawy leży w tym, by tak motywować zespół oraz wypracować w nim poczucie odpowiedzialności za projekt by taka sytuacja nie miała miejsca. Brak zaufania w zespole gwarantuje jedynie porażkę całego projektu;
   • niewłaściwe, zbyt ogólnikowe i zbyt rozległe definiowanie wymagań w postaci “kartek” (user stories), które powoduje błędy w estymacji wynikłe z niemożności dokładnego i szybkiego przeanalizowania wymaganych czynności prowadzących do realizacji danego wymagania;
   • pomijanie w estymacji zagadnień TDD (testowania) oraz wpływu realizacji zadania na obecne testy;
   • poświęcenie zbyt małej ilości czasu na analizę zadania i wyciągania wniosków nie popartych analizą bieżącego stanu projektu;

   Sedno sprawy leży w tym, by tak zdefiniować zadanie (user story) by głęboka wiedza techniczna odnośnie projektu wspomagana w miarę potrzeby dodatkową analizą biznesową pozwoliła trafnie ocenić czas wykonania zadania.
   Z reguły w projektach Agile większe błędy estymacji popełnia się na początku projektu, wynika to oczywiście z normalnego procesu “uczenia” się w trakcie projektu i wyciągania wniosków z poprzednich estymacji.

2. Programista ma prawo/obowiązek uczciwie informować o postępie prac.
   Podpunkt ten wyraźnie zaznacza iż programiście nie tylko wolno informować – ale wręcz ciąży na nim obowiązek informowania o postępie prac. Postęp ten śledzi się w czasie codziennych spotkań (tzw. stand-up) oraz w czasie planowania iteracji.
3. Programista ma prawo/obowiązek dostarczać rozwiązania o najwyższym standardzie przez cały czas.
   Również ten podpunkt mówi zarówno o prawie jak i obowiązku – programista ma po pierwsze obowiązek dostarczyć optymalne rozwiązanie na miarę jego umiejętności oraz zasobów mu dostępnych, ale nawet ważniejsze jest to iż ma prawo do dostarczenia takowego rozwiązania. Praktycznie w każdym projekcie informatycznym, w związku z złożonością takich projektów wymagane są ustępstwa na koszt jakości by dostarczyć rozwiązanie na czas i w określonym budżecie – grunt to pozwolić programistom przedstawić ich racje oraz uszanować ich zdanie dotyczące jakości projektu. Szczególnie zaniedbywane jest to w przypadku jakości nie widocznej dla klienta. Stąd częste w praktyce Agile iteracje polegające na refaktoringu kodu, zwiększaniu pokrycia kodu testami oraz na redefiniowaniu niektórych aspektów technicznych projektu.
4. Programista ma praw/obowiązek wiedzieć jakie są priorytety dalszych prac (wiedzieć co należny wykonać w kolejnym kroku).
   Kolejny punkt, który według mnie nie powinien ograniczyć tylko do określenia prawo. Również w tym przypadku wyraźnie należy zaznaczyć, że wiedza na temat priorytetów dalszych prac jest nie tylko należna programiście, ale jest ona obowiązkiem programisty. To, że programista ma prawo wiedzieć o priorytetach, a w konsekwencji o kolejności wykonywanej pracy nie podlega dyskusji. Obowiązek posiadania takowej wiedzy pozwala unikać sytuacji, w których, z chwilowego braku osób odpowiedzialnych za planowanie na wyższym poziomie prace zostają wstrzymane, bądź narastają opóźnienia.
5. Programista ma prawo zadawać pytanie z dziedziny biznesowej projektu gdy tylko takowe się pojawia.
   Gdy bym miał zamiar uszeregować opisywaną listę według hierarchii ważności – ten element z pewnością znalazł by się w okolicach jej szczytu. Praktyka doskonale pokazuje, że nawet pomimo dogłębnej analizy zagadnienia związanego z danym wymaganiem sprecyzowanym w postaci “user story” (zazwyczaj w trakcie planowania iteracji – “planning game”) , w trakcie implementacji pojawia się wiele pytań szczegółowych – ba, bardzo często zdarza się iż należy ponownie rozważyć dane zagadnienie i poszerzyć zakres jego analizy – co często wiąże się z koniecznością ponownej estymacji zadania. Jako iż Agile zaleca, by definicje zadań w postaci kartek (“cards”) były jak tylko możliwie granularnymi (słowotwórstwo własne ale mam nadzieję, że wiadomo o co chodzi), opóźnienia związane z oczekiwaniem na odpowiedź odnośnie problemów biznesowych związanych z danym zadaniem mogą w znacznym stopniu przełożyć się na ogólne opóźnienie zakończenia iteracji. Punkt ten dotyka również zupełnie innej kwestii – nie tak widocznej na pierwszy rzut oka – jest nią wybór osoby (osób), która będzie stanowiła “pierwszą linię pomocy”, pomost pomiędzy biznesem a technologią. Pierwsza trudność to to, iż osoba ta musi wszechstronnie rozumieć zarówno programistów jak i stronę biznesową projektu/firmy. Poza tym musi być osobą umiejącą przekazać wiedzę a przede wszystkim osobą o dużej cierpliwości, gdyż pytania zadawane będą jej bardzo często i będzie się zdarzało iż będą to pytania na które już wcześniej odpowiedzi zostały udzielone. Pozytywne relacje między taką osobą a zespołem programistów mają znaczenie, którego nie można nie doceniać.

Na koniec skupię się na prawach menadżera:

1. Manager ma prawo do całościowej oceny kosztów i rezultatów musi jednak brać pod uwagę ze takowa ocena nie jest w 100% pewna i oddająca stan rzeczywisty.
   To stwierdzenie nie wymaga szerszego komentarza – nie jest ono również unikatową cechą metodologi Agile. Manager projektu szacuje koszty i zdaje raport z postępu prac.
2. Manager ma prawo przesuwać ludzi pomiędzy projektami bez ponoszenia zawrotnych kosztów.
   Agile daje z samego założenia takie prawo managerowi – a mówiąc dokładniej daje mu taką możliwość. Jedną z cech charakterystycznych tej metodologi jest niedopuszczanie do specjalizacji w zespole, każdy z członków zespołu powinien poruszać się sprawnie pomiędzy modułami aplikacji i orientować się w możliwie jak najszerszy i jak najbardziej kompetentny sposób w projekcie.
3. Manager ma prawo/obowiązek do comiesięcznych raportów z postępu prac oraz pomocy klientowi w ustalaniu ogólnych priorytetów.
   Kolejne stwierdzenie, które nie wydaje się być specjalną nowością, warte podkreślenia jednak jest iż projekty Agile pozwalają w oparciu o takie raporty elastycznie kierować projektem i dostosowywać go do warunków zewnętrznych.
4. Manager ma prawo anulować projekt, pozostając z pracującym systemem oddającym dotychczas poniesione (zainwestowane) koszty.
   Każdy spotkał się chyba z anulowanym projektem informatycznym, przyczyn takich posunięć może być tysiące – jednak Agile daje unikatową możliwość anulowania projektu, pozostawiając jego twórców z działającym systemem funkcjonalnym na miarę dotychczas zainwestowanych środków i popełnionych błędów, jeżeli zespół potraktuje poważnie choćby tak prostą wytyczną, iż każde zdefiniowane w postaci “kartki” zadanie musi zostać pokryte odpowiednim testem akceptującym i zespół wyrobi w sobie bardzo rygorystyczne podejście, niedopuszczające do niepozytywnego wyniku jakiegokolwiek z testów, łatwo będzie wyznaczyć obiektywny stan zamykanego projektu.

Podsumowanie:

W ramach podsumowania powiem tylko jedno – wydrukować powyższą listę na formacie przynajmniej A3 i powiesić w dobrze widocznym miejscu.