Pod koniec czerwca miałem przyjemność powiedzieć kilka słów na konferencji Integracja Systemów Informatycznych GigaCon 2011.
Z pozostałych prelekcji najbardziej zainteresowała mnie ta przeprowadzona przez pana Jarosława Żelińskiego. Zresztą sam prelegent w jednym z pierwszych zdań stwierdził, że będzie ze mną polemizował (moja prezentacja była wcześniej), czego potem raczej nie robił. Choć sam główny temat jego prelekcji nie był może z punktu widzenia osób tworzących systemy IT odkrywczy, to wszelkie dygresje były bardzo ciekawe, ale … w większości trudno się mi było z nimi zgodzić. I pewnie dlatego były dla mnie ciekawe.
Od tamtego czasu stałem się stałym czytelnikiem blogu pana Żelińskiego. Chciałbym się podzielić kilkoma spostrzeżeniami do treści tam prezentowanych.
Zacznę od drobnej złośliwości. W maju, jako że sięgnąłem też do starszych wpisów, autor napisał: „[…] ja już wyrosłem ze społecznych źródeł wiedzy jakim jest Wikipedia i przytoczę definicję z książek mających konkretnego autora […]”. A dzisiaj czytam, jak autor krytykuje praktyki Agile … czerpiąc wiedzę na ich temat z tego społecznego źródła wiedzy. Kończąc złośliwość dodam adresując to do autora, że Wiki i Wikipedia to nie to samo i mają się do siebie tak ja klasa do obiektu. :P
To moje łapanie za słówka pokazuje jednak pewien problem. Pan Żeliński lubi zaczynać myśl od „nie jestem wrogiem Agile”, by potem jasno swoją wrogość do tych idei przedstawić. A z wrogością często bywa tak, że jest ona skierowana do czegoś, czego się do końca nie zna.
Z czerwcowej konferencji zapamiętałem pan Żeliński ostrzegał przed zwinną (Agile) integracją, która miałaby polegać na tym, że programistom daje się dostęp do bazy danych a ci (bez jakiegokolwiek zastanowienia) z nowego kodu z takiej bazy korzystają. Co to ma wspólnego z Agile? Otóż idee Agile nie mówią o tym jak ma wyglądać architektura oprogramowania, tylko jak powinien/może wyglądać proces tworzenia oprogramowania. W tradycyjnych (starych) metodykach analityk czy projektant też mógłby programistom przekazać (raczej nakazać), że mają w identyczny sposób taką integrację wykonać. Tyle tylko że, w przeciwieństwie do metodyk zwinnych, od źle wykonanej analizy czy złego projektu nie byłoby wtedy odwrotu, bo przecież zdaniem pana Żelińskiego dobry programista nie dyskutuje z projektantem.
Oczywiście tak jak wiele osób programujących mówi, że stworzony przez nich kod programu jest bezbłędny, dokładnie przetestowany a niuanse platformy mają w jednym palcu, tak i analityk może powiedzieć, że opracowany (odkryty) przez niego model dokładnie opisuje rzeczywistość, jest przetestowany a samą dziedzinę rozumie doskonale. Megalomania albo pokora – wybór należy do ciebie. Błąd można popełnić zawsze. Jednak w tradycyjnych metodykach błąd w analizie jest dużo bardziej kosztowny niż błąd w kodzie programu.
Ten problem dostrzega również pan Żeliński pisząc w innym z wpisów, że „źle wykonana analiza przeciętnie podnosi koszty dwukrotnie a bywa, że znacznie więcej”. Z tym że jego rozwiązanie widzi w bardziej rozbudowanej fazie analizy, co ilustruje diagramem z „kosztowną pętlą odkrywania wymagań”. Jako źródło podana jest firma IBM. Mamy więc tzw. argument przez odwołanie się do autorytetu. Znana firma zrobiła badania (zrobiła?) i z nich wynika założona teza. Bardzo dobry argument… do czasu aż autorytet zmienia zdanie. Bo rozwiązaniem problemów z kosztami wynikająymi ze słabej analizy nie jest (już?) według firmy IBM wydłużanie jej czasu przed fazą implementacji, tylko stosowanie zwinnych (agile) metodyk i choćby w takim kierunku zmierza sztandarowy zestaw produktów tej firmy wspierających proces tworzenia oprogramowania – IBM Rational.
W zasadzie to może błędnie napisałem, że nasz “autorytet” zmienił zdanie? Może zrobił dokładnie odwrotnie? Bo metodyki zwinne nie polegają na likwidacji fazy analizy, jak wydaje się sam to rozumieć a sugerować innym pan Żeliński, tylko na maksymalnym możliwym jej wydłużeniu, czyli … na cały czas trwania projektu. Scott Ambler (chief methodologist for Agile at IBM Rational) napisał kiedyś, że “analiza jest tak ważna dla praktyków Agile, że robimy ją każdego dnia”. Temu służą planowania, stand-up meetingi. Po to zwinny zespół winien być wielofuncyjny, czyli posiadać więdzę i umiejętności w pełnym zakresie wymaganym do tworzenia oprogramowania, w tym również umiejętności analityczne. Nie są one jednak skupione w pojedyńczych, wyizolowanych osobach, które na dodatek innych przydatnych umiejętności nie mają. Agile to nie brak tak lubianych przez pana Żelińskiego diagramów UML, tylko wykorzystanie ich do przekazywania i uspójniania wiedzy, kiedy jest taka potrzeba, a nie jako (podstawowa) forma komunikacji z zamawiającym oprogramowanie.
I w tym miejscu odeślę do dość już leciwego źródła http://www.agilemodeling.com/essays/agileAnalysis.htm<
