Czy na skróty zawsze jest bliżej?

Filozofia Agile Modeling dla wielu informaty- ków na pewno brzmi znajomo. Wiele codziennych praktyk polskich firm informatycznych kropka w kropkę pokrywa się z zalecanymi przez AM. Projektują zwięźle, stosują własne metody wypracowane przez praktykę zamiast formaliz-mów, nie przesadzają z dokumentowaniem i preferują papierowe szkice zamiast narzędzi CASE.

Charakterystyczne są wyznaczniki "zwinności modelu". Nie mają nic wspólnego z techniką czy notacją, ale przede wszystkim z celami modelowania. Według autorów metody, modele takie są: skuteczne, zrozumiałe, dostatecznie dokładne, spójne, proste. Czyż nie to można właśnie powiedzieć o praktycznych modelach, z których korzystają na co dzień informatycy w swoich firmach? Nie muszą być poprawne, byleby działały.

Osoba doświadczona w inżynierii oprogramowania ma jednak wiele wątpliwości dotyczących AM. Po pierwsze, "luźne" podejście do formalizmów i wyraźny akcent położony na komunikację to poniekąd sprzeczne cele. Aby informatycy mogli ze sobą rozmawiać - a tym bardziej, jeżeli mają rozmawiać z klientami - konieczny jest wspólny język. Wspólny język zaś wymaga wspólnego rozumienia koncepcji reprezentowanych przez model. Jeżeli analityk naszkicuje na tablicy kwadrat połączony z dwoma trójkątami, mając na myśli klasę i dwa jej egzemplarze, podczas gdy jego słuchacze zobaczą tam obiekt i jego dwa interfejsy, to cała dalsza komunikacja jest bezcelowa. Dlatego brak sformalizowanej notacji jest wadą, a nie zaletą Agile Modeling.

Druga wątpliwość dotyczy pracy zespołowej. Agile Modeling zapewne sprawdza się w kilku- osobowych zespołach, które są zgrane, sporo już razem przeszły, a ich członkowie ufają sobie. Nie zawsze ma się tak komfortową sytuację w firmie informatycznej. Często zespoły są duże, a obok doświadczonych inżynierów w ich skład wchodzą osoby dopiero terminujące w trudnym rzemiośle informatycznym. Czy można zrobić z nich dob-rych, rygorystycznych wobec siebie i krytycz-nych wobec programu fachowców, jeżeli nie zaszczepi się im żelaznych reguł konstrukcji oprogramowania (np. nie stosuj skoków, nie polegaj na niejawnych konwersjach danych, zwalniaj obiekty w odwrotnej kolejności niż je powołałeś do życia), które pokolenia informatyków wypracowały przez ostatnich trzydzieści lat?

Trzecia wątpliwość dotyczy tego, czy nie mamy do czynienia z pseudonauką opartą na pseudo-wiedzy. Jeżeli porównać inżynierię oprogramowania np. z inżynierią budowlaną, przekonamy się, że rzekomy "balast" formalizmów jest fundamentem każdej dziedziny inżynierii. Czy fakt, że "ciężkie" metodyki często nie przynoszą spodziewanych efektów, powinien być argumentem za ich odrzuceniem czy raczej doskonaleniem?

A poza tym rób, co chcesz

Filozofia św. Augustyna czasami jest zawierana w jednym zdaniu: "Kochaj, a poza tym rób, co chcesz". Gdyby przez analogię chcieć zawrzeć Agile Modeling w jednym zdaniu, brzmiałoby ono: "Myśl, a poza tym rób, co chcesz". Zalecenia zamiast ścisłych reguł, wartości zamiast notacji, weryfikacja przez użytkowników i automatyczne testy zamiast standaryzacji... wszystko to brzmi obiecująco, ale niesie pewne zagrożenie. Aby dobrze stosować AM, potrzeba wiele doświadczenia nabytego w... tradycyjnym modelowaniu. Tak jak pianista, który musi perfekcyjnie opanować gamy i etiudy, zanim zacznie nowatorskie interpretacje klasyków, tak i informatyk powinien najpierw solidnie poznać formalne metody inżynierii oprogramowania i zdobyć doświadczenie, by dopiero potem iść na skróty. Nikt nie namawia uczniów młodszych klas w szkole muzycznej do jazzowych jam sessions, nikt też nie powinien namawiać świeżych adeptów informatyki do stosowania Agile Modeling.

Autorzy metodyki piszą, że AM nie jest przeznaczona dla każdego. Zdecydowanie jest to prawda. Metoda raczej jest przeznaczona dla doświadczonych informatyków, zgranych zespołów i firm o dużej kulturze organizacyjnej w informatyce.

Stosowanie pewnych wartości, zasad i praktyk Agile Modeling będzie jednak przydatne dla informatyków - nawet jeśli zastosują je obok formalnej metodyki. Warto poczytać o tej nowatorskiej metodzie, spojrzeć na nią krytycznie i... może zaczerpnąć z niej to i owo.