Sławomir Czerwiński

Przedkładanie jednostek i interakcji między nimi nad procesy i narzędzia jest pierwszym z założeń manifestu zwinności. Reguła brzmi bardzo profesjonalnie, ale na pierwszy rzut oka raczej nie jest zrozumiała. Może przełożę to na najprostrzy język:

jednostki i interakcje

to ludzie i ich współpraca oraz wzajemne relacje,

procesy i narzędzia

to sposoby działania i sprzęt czy też oprogramowanie wykorzystywane w pracy.

Przykład 1

Pracowałem kiedyś w zespole, gdzie wprowadzono złożone procesy dotyczące zgłaszania błędów. Ich celem było zwiększenie kontroli nad realizacją zadań powierzanych programistom.

Narzędziem wykorzystywanym w tym procesie był specjalnie przygotowany formularz, wypełniany przez sprzedawców. Zawierał on informację o module zawierającym błąd, dzięki czemu kierownik mógł w łatwy sposób wskazać osobę odpowiedzialną za realizację każdego zgłoszenia. Innym istotnym elementem był priorytet, pomagający w ustaleniu kolejności wykonywania zadań.

Wyniki wdrożenia nowych procedur były dość oczywiste. Zgłoszenie pojawiało się u programisty miesiąc po wypełnieniu formularza i często było sformułowane w sposób kompletnie niezrozumiały. Za każdym razem musiałem spędzić kilka minut na rozmowie ze sprzedawcą, żeby dowiedzieć się o co tak naprawdę chodzi. Do tego wszystkie pojawiające się zgłoszenia miały najwyższy priorytet.

Zdarzyło się raz, że jeden sprzedawca poprosił mnie o poprawienie drobnego błędu (5 minut pracy), który w znacznym stopniu utrudniał pracę użytkownikom. Formularz był już dawno wypełniony i oczekiwał na przekazanie do właściwego wykonawcy.

Ponieważ błąd był oczywisty, postanowiłem go poprawić od razu. W ten sposób, dzięki współpracy i dobrym relacjom, rozwiązaliśmy istotny problem tydzień przed tym, jak dotarło do mnie zgłoszenie błędu.

Przykład 2

Przez większość liceum i studiów miałem jednego kolegę, z którym realizowaliśmy wszystkie projekty (poza jednoosobowymi). Mimo iż nie prowadziliśmy żadnej dokumentacji, nie ustalaliśmy żadnego sposobu pracy i często zmienialiśmy narzędzia programistyczne, to realizowaliśmy nasze zadania niezwykle sprawnie.

Na jednym z fakultetów byłem sam, więc współpracownika na laboratoria otrzymałem „z przydziału”. Od razu omówiliśmy zagadnienie, wybraliśmy narzędzia i podzieliliśmy pracę.

Kolegi nie znałem wcześniej i nie miałem z nim innych wspólnych zajęć. Poza tym na laboratoriach pojawił się 3–4 razy w ciągu całego semestru. W końcu – nie wiedząc, czy mój współpracownik nie zrezygnował z fakultetu – zrobiłem wszystko sam (na tyle, na ile dałem radę) i oddałem do oceny.

Ostatnie zajęcia ograniczały się do wystawienia ocen. Mój kolega (który niespodziewanie pojawił się) tylko zrobił kwaśną minę, gdy usłyszał: „3”.

Na szczęście nigdy więcej nie musieliśmy razem pracować.

Aspekt finansowy

Częstym przejawem przeceniania narzędzi jest inwestowanie ogromnych pieniędzy w środowisko programistyczne – szczególnie gdy pracownicy otrzymują niskie pensje.

Znakomite narzędzia dostarczane przez takie firmy jak Microsoft czy Borland mogą znacznie przyspieszyć i ułatwić rozwój oprogramowania, ale nie zastąpią dobrych programistów. Gdy profesjonaliści odejdą (widząc, ile zarabiają ich koledzy ze studiów, pracujący dla konkurencji), a przy komputerze pozostaną jedynie amatorzy-entuzjaści, to produkty firmy stracą sporo na jakości.

Z drugiej strony istnieją darmowe technologie (GNU C++, PHP, Java), które wprawdzie nie posiadają narzędzi do „programowania” myszką, ale pozwalają zaoszczędzić pieniądze na pensje, szkolenia i sprzęt dla pracowników.

Jak nie ma młotka, to Pan Edek wbije gwóźdź choćby kamieniem, ale małpa z młotkiem – model XT-5000 z celownikiem LCD i systemem antywstrząsowym – może tylko narozrabiać.

Podsumowanie

Dobra współpraca między pracownikami pomaga przyspieszyć pewne działania i pozytywnie wpływa na jakość produktu. Jednak nie można całkowicie zapomnieć o procesach i narzędziach. Gdybym całkowicie pomijał procedury z przykładu 1, ryzykowałbym, że ktoś inny zacznie realizować te same zadania. Mogłoby się też zdarzyć, że zgłoszenie nie wynika z błędu w programie, lecz z nieprawidłowego użytkowania programu lub złego rozumienia idei systemu.

Z mojego doświadczenia wynika, że czasami można oprzeć prostrzy projekt o jednostki i interakcje, pomijając kwestię procesów i narzędzi, ale przywiązywanie dużej wagi do procesów i narzędzi przy jednoczesnym zaniedbywaniu jednostek i interakcji prowadzi do całkowitej katastrofy.