Jaką metodykę pan woli?

Ostatnio, na pewnej rozmowie, w pewnej ważnej sprawie, dostałem takie właśnie pytanie: „A jaką metodykę pan woli, agile czy ciężką?”. Chyba jednak nie udzieliłem oczekiwanej odpowiedzi, bo powiedziałem mniej-więcej: „a taką, która działa”. Co prawda, moja wypowiedź była trochę dłuższa i trochę bardziej łagodna, ale sens był właśnie taki. Dziś więc będzie o tym co jest lepsze, agile czy ciężkie metodyki, a w zasadzie o tym, że takie porównanie nie ma sensu bez określenia kontekstu w którym działamy.

Zacznijmy od tego czym się różnią metodyki? Prosta sprawa – jedne są fajne a drugie nie. Bardziej na serio – od pewnego czasu bycie agile jest modne, a praca w ciężkiej metodyce jest passe. Ci którzy „robią” w Scrumie są cool a inni są nie cool¹, nic więc dziwnego, że teraz nikt nie chce RUPa, wszyscy chcą być zwinni. Z drugiej strony są grupy, które z politowaniem patrzą na tych niezdyscyplinowanych, chaotycznych-elastycznych i dumnie wracają do pisania swoich DTD, BRD, SRD, Planów, ASów, Studies i serii innych bardzo ważnych dokumentów². Właśnie: grupy. Tu dochodzimy do jednego z powodów od których skuteczność działania metodyki zależy – od ludzi i zadania. To czy coś zagra zależy od tego kto gra. Orkiestra symfoniczna czy muzyk klasyczny nie wykaże się przy metalu (chyba że jest z Finlandii, ma długie włosy i należy do Apocalyptica).  Podobnie, dowolne narzędzie zadziała tylko wtedy, gdy będzie dostosowane do swojego użytkownika: jego umiejętności, cech ale też problemu: jakie jest zadanie, jakie są ograniczenia. Metodyka musi być więc dostosowana do zespołu i  zadania – musi się zgrywać z ich charakterem, podejściem do pracy, wielkością zespołu³, ograniczeniami i złożonością projektu a nawet rozmieszczeniem „geograficznym”⁴.

Otoczenie

Jeżeli mówimy o zespole, można spojrzeć trochę szerzej i przyjrzeć się także otoczeniu projektu, a właściwie rodzajowi kontraktu między zespołem a klientem, odbiorcą systemu. Czy pozostaje to bez znaczenia dla przyjętej metodyki? Zdecydowanie nie, sposób współpracy między wykonawcą a zamawiającym ma bardzo duże znaczenie dla przyjmowanej metodyki. Odbiorca, w takiej lub innej formie, ma wpływ na pracę. Znaczenie ma tu charakter klienta – kim jest, czym się zajmuje – w skrócie: inaczej na współpracę będzie patrzył i innego rodzaju współpracy będzie wymagał dział techniczny, inaczej dział typu HR, marketing, a całkiem inaczej dział zajmujący się sprzedażą. Duży wpływ ma także rodzaj powiązania między klientem a wykonawcą- pracując w jednej firmie programista i przyszły użytkownik będą raczej dążyli do tego samego⁵, zaś pracując dla różnych instytucji, zamawiającego i dostawcy, cele mogą być różne, dogranie też może być różne.

Technologia

Skoro wiemy już kto i dla kogo pracuje, skupmy się na tym czym pracuje, czyli jakiej używamy technologii. Dziwne, nie? Przecież nie ma znaczenia w czym piszemy, metodyka powinna dać się zastosować tak samo. Jednak po bliższym przyjrzeniu się, widać że niektóre technologie bardziej nadają się do jednego rodzaju metodyk inne do drugiego. Co prawda, trzymając się obecnego programistycznego mainstreamu (java, .net, php), poruszamy się wśród technologii raczej zwinnych, czyli takich które łatwo się „wdrażają” w metodykę agile – po prostu model programistyczny jest mniej-więcej podobny. Mimo podobieństw można zauważyć spore różnice – bo tu się łatwiej prototypuje, a tam bardzo prosto jest zrobić testy jednostkowe. A kiedy uwzględnimy jeszcze dodatkowe technologie bardziej specjalistyczne, takie jak narzędzia webowe, narzędzia specjalistyczne (ESB,BPM,BI), robi się jeszcze trudniej. Dlaczego warto spojrzeć na technologię? Weźmy dla przykładu różne railsowe narzędzia jak Ruby on Rails czy Grails. Zrobienie w nich prototypu jest banalnie proste, szybkie i mało kosztowe, po co więc zużywać energię na rysowanie projektów GUI, analizowanie przepływu sterowania, skoro można łatwo zrobić wstępną wersję i dopracowywać. Lepiej poświęcić czas dobremu testowaniu takich aplikacji. Z drugiej strony – jeżeli przebudowujemy całą warstwę integracji to opieranie się na user stories bez szczegółowego projektu procesów, struktur danych, planów awaryjnych i opieraniu się na „zmiennym zakresie” może doprowadzić do ogromu problemów.

Rodzaj projektu

W końcu najważniejsze – co robimy, co ma być efektem pracy, w jakie problemy rozwiązujemy. Różnica między projektem kolejnego portalu społecznościowego a systemem realizującym transakcje finansowe online jest dostrzegalna gołym okiem.  W przypadku portalu społecznościowego w zasadzie ciężko określić jakiś proces biznesowy, nie mówiąc już o ścisłych detalach wymagań. Dla systemu transakcyjnego proces biznesowy będzie zapewne ściśle zdefiniowany do najdrobniejszego szczegółu jeszcze przed rozpoczęciem budowy oprogramowania. Jaki rodzaj metodyki do którego rodzaju projektu pasuje jest raczej oczywiste.

Jeszcze na koniec taki dodatkowy parametr, nazywam go unikalnością projektu. Jeżeli problem, który stoi przed zespołem jest nowy, zespół jest świeży lub pracuje pierwszy raz na poważnie w danej technologii to mamy  do czynienia z unikalnym projektem. Na drugim końcu skali jest zespół który tłucze seryjnie identyczne, lub bardzo podobne, produkty w tej samej technologii. Ponieważ przy rozpoznaniu, poruszamy się trochę po omacku to warto być bardziej zwinnym, a jeżeli pracujemy przy taśmie to warto skorzystać z poprzednich doświadczeń i się trochę usztywnić.

Podsumowanie

Dobra, tyle parametrów – ale jak zdecydować się na ich podstawie? Co gdy zespół luzaków pracuje dla klienta zewnętrznego nad twardym projektem, realizowanym w miękkiej technologii, robiąc kolejny egzemplarz? Przede wszystkim, pomijając prawdopodobieństwo takiego zdarzenia – czy są to właściwi ludzie wykonujący odpowiednią pracę? Może to nie jest projekt dla tego zespołu, może lepiej wykorzystają swoje cechy i możliwości gdzie indziej? Czy technologia została na pewno dobrana do problemu? Czy sposób porozumienia z klientem jest dopasowany do projektu(albo odwrotnie)? To naprawdę warto rozważać przed przystąpieniem do pracy. Jeżeli jednak wszystkie te przemyślenia zostały poczynione i nadal mamy problem z wyborem, to przechodzimy do następnego kroku – strojenie metodyki. Czyli w zasadzie do złożenia własnej metodyki.

Tak, wg. mnie żadna metodyka wzięta prosto z półki nie jest odpowiednia. Dostosowanie jej do konkretnego przypadku jest niezbędne, jednak musi być przeprowadzone z głową i konsekwentnie. To  nie może być zlepek dowolnie wybranych praktyk i reguł ale współgrająca razem całość. Mówiąc o przypadku mam na myśli nie tylko firmę/dział/zespół ale konkretny projekt. Metodyka powinna być dopasowana do tego jednego zestawu ludzie+technologia+klient+cel projektu. Oczywiście, po kilku wspólnych rozgrywkach zespół wypracuje szablon metodyki, który między poszczególnymi projektami będzie różnił się niewiele, najczęściej zapewne parametrami, ale nadal nie powinien być stosowany bezrefleksyjnie do każdego następnego zadania.

Pozostał właściwie jeden problem – czym się tak naprawdę różnią metodyki, czyli co znaczy zwinne i ciężkie? To jednak całkiem inna historia.