True Solutions

Praktyki XP

W poprzednim wpisie przedstawiłem część podstawowych praktyk XP. Poniżej ciąg dalszy.

Scenariusze

Trudno napisać duża aplikację, nie rozbijając jej na mniejsze moduły. Najlepiej mieć przygotowany plan działania, który przypomina z jak dużym zadaniem mamy do czynienia, ile pozostało nam czasu oraz pomoże określić, która funkcjonalność jest naprawdę konieczna, a która może zostać zaimplementowana w późniejszym czasie. (w praktyce okazuje się, iż często wyłącznie programistom/projektantom wydaję się, że dana funkcjonalność jest niezbędna – z drugiej strony łatwo pominąć coś, co może mieć kluczowe znaczenia dla klienta).

Metodyka XP sugeruje podział zadań na scenariusze, które zawierają treść zadania, nadany tytuł oraz szacowany czas wykonania. Tak przygotowane zadania można pokazać zarówno szefowi programistów jak i klientowi, pozwalając im wybrać te scenariusze, które z ich punktu widzenia wydają się najbardziej istotne. Co ciekawe, jak twierdzi Kent Beck:

… umieszczenie opisów (scenariuszy – przyp. autora) w komputerze zamiast na ścianie w znaczący sposób ogranicza ich użyteczność.

Cykl tygodniowy

Kiedy na pierwszym roku studiów pracowałem w ZUSie (wytrzymałem tam rok i kilka dni, jednak pozwoliło mi to w przyszłości docenić fakt, że można pracować robiąc to co się lubi), nie czułem potrzeby cotygodniowych zebrań informacyjnych w miejscu pracy. Jednak od momentu, kiedy zacząłem pracować z Wiktorem jako True Solutions, potrzeba cotygodniowego określenia aktualnej i przyszłej pozycji projektu okazuje się nieodzowna i wręcz źle się czuję, gdy raz na tydzień nie zadam pytania “jak wygląda aktualnie nasz plan”.

Początkowo Beck proponował, aby cykl trwał dwa lub trzy tygodnie. Jednak doświadczenie pokazało, iż najbardziej naturalnym cyklem pracy jest praca od poniedziałku do piątku. Cotygodniowe zebranie (zazwyczaj w poniedziałek) powinno zająć się następującymi sprawami:

• podsumowaniem poprzedniego tygodnia i określenie, czy wywiązaliśmy się z zaplanowanych na poprzedni tydzień zadań,
• wybranie kolejnych scenariuszy do implementacji,
• podział scenariuszy na konkretne zadania i szacowanie ich kosztu.

Pomimo, iż planowanie nie generuje bezpośrednio kodu i może się wydawać straconym czasem, pozwala lepiej “czuć” projekt. Należy jednak pamiętać, iż planowanie to tylko kierunek w którym działamy, a nie faktyczne działania. Trafnie skomentował to nieżyjący już guru współczesnych metod zarządzania, Peter F. Drucker:

Plany to tylko dobre chęci, chyba że natychmiast przekształcają się w ciężką pracę.

Cykl kwartalny

Cykl ten pozwala spojrzeć na projekt z dalszej perspektywy i ocenić, czy suma pojedynczych cykli tygodniowych daje pożądany przez nas efekt. Cykl kwartalny związany jest z:

• identyfikacją wąskich gardeł,
• usuwaniem błędów,
• planowaniem tematów (bardziej ogólnych scenariuszy) na najbliższy kwartał,
• wyborem scenariuszy do realizacji oraz
• określaniem ogólnego stanu projektu w kontekście całej firmy.

Między cyklem tygodniowym a kwartalnym występuje zależność, która jest wyrażana przez jedną z zasad XP, o której pisałem wcześniej – zasada samopodobieństwa. Jak więc łatwo zauważyć, reguły opisujące XP są spójne i wzajemnie się przenikają.

Opcjonalność

Planowanie pozwala nam określić, jak wybrany projekt będzie się rozwijał. Opcjonalność można określić jako parametr, pozwalający nam na pewien margines manewru. Pozwala on nam w przypadku braku czasu przesunąć mniej istotne zadania na kolejny cykl tygodniowy (bądź kwartalny, oczywiście jeżeli projekt powstaje pod konkretne zamówienie, po konsultacjach z klientem).

Opcjonalność może przybierać różne formy – doskonałym przykładem jest firma Google, która pozwala pracownikom 20% czasu pracy poświęcić na dowolny projekt, którym są zainteresowani. Jest to tak zwana “zasada 20 procent“, która pozwoliła powstać takim aplikacjom jak GMail, Google News czy AdSense

Co dalej?

W kolejnej części opiszę resztę podstawowych praktyk extreme programming.

(c.d.n.)

Dodaj ten wpis do:

wykop del.icio.us