poniedziałek, 30 lipca 2007

Dostosowywanie metodyk

Alistair Cockburn we wspomnianej już książce ""Agile Software Development" zawarł bardzo ciekawy rozdział na temat metodyk jako takich: co to jest metodyka, jakie są jej wymiary, jakimi parametrami można ją opisać itp. Jednym z ciekawszych spostrzeżeń jest to, że warunkiem aby zastosowany zbiór metod/zasad został uznany za metodykę jest pozytywna odpowiedź na pytanie "czy jakbyś teraz robił coś nowego to zrobiłbyś to w ten sam sposób?". Pozytywna odpowiedź na to pytanie oznacza, że w ramach danej dziedziny został uzyskany stan wiedzy, który pozwolił na stworzenie uniwersalnego zbiory metod i zasad pracy. Zbiór ten jest uniwersalny oczywiście w pewnym zakresie zastosowań - zwykle dość wąskim. Tym niemniej ważne jest, że zasady te są na tyle uniwersalne, że da się je zastosować po raz drugi w podobnym problemie i jednocześnie na tyle dobre, że chce się je zastosować po raz drugi. Oczywiste jest, że dopracowanie się takiego zestawy zasad nie jest możliwe za pierwszym razem. Zbiór metod i zasad zwykle musi być parę razy poprawiony zanim osiągnie na tyle wysoką jakość aby móc być stosowanym bez modyfikacji do różnych zastosowań.

I tutaj dochodzimy do zwinnego zarządzania projektami. Aspektem bardzo często podkreślanym w kontekście zwinnego zarządzania projektami jest to, że ta metodyka pozwala na inkrementacyjne dostosowywanie produktu do wymogów klienta. Mniej oczywistą konsekwencją stosowania krótkich iteracji jest możliwość dostosowania stosowanych metod i reguł do środowiska w którym jest realizowany projekt. Oraz ich bardzo szybkiej modyfikacji w celu osiągania coraz to lepszych wyników. Metody są na wysokim poziomie utrzymywane przez ramy zwinnego zarządzania projektem, ale oprócz tego w każdej organizacji występuje masę reguł działania właściwych tylko i wyłącznie dla danego miejsca. Mowa tu zarówno o procesach organizacyjnych (jak rezerwujemy sale konferencyjne, czy i gdzie możemy powiesić na ścianie raporty prac) jak i regułach zachowania się w danej kulturze firmy (w jakiej formie mamy się kontaktować z klientem, jak często kierownik musi raportować, kto o czym ma być informowany, etc.). Dotarcie się takich reguł zajmuje chwilę. Przy dużych projektach, długich cyklach produkcyjnych raz popełniony błąd można poprawić zwykle przy następnym projekcie, czyli za około kilka miesięcy. W przypadku projektów zwinnych następna okazja do poprawki będzie za kilka tygodni najdalej. W ten sposób szybciej zarówno zespół projektowy jak i cała firma może nauczyć się współpracować w środowisku projektowym. Możliwe jest też znacząco szybsze wejście na "wysokie obroty" i dostarczanie wartości dla klienta bez zaprzątania sobie głowy niedostosowanymi do realiów zasadami pracy.

Warunek do osiągnięcia tego jest jeden: porządnie zrobione retrospekcje po każdej iteracji zarówno pod kątem produktu jak i organizacji pracy.

2 komentarze:

saddist pisze...

Pana blog muszę przyznać jest niezwykle ciekawy. Szczegolnie dla mnie jako dla początkującego informatyka (4 rok studiów), który w przyszłości właśnie projektowaniem/analizą/zarządzaniem projektami chce się zajmować :)

Szymon pisze...

Bardzo dziękuję za te słowa. W ramach ustalania zasad proszę tylko o pomijanie "Pan". Na imię mam Szymon i chciałbym, żebyśmy się tutaj wszyscy do siebie zwracali po imieniu.