W ostatnich latach informatycy, zmęczeni tradycyjnymi metodykami inżynierii systemów, które są trudne, złożone i nie zawsze gwarantują uzyskanie dobrego efektu, coraz częściej szukają rozwiązań "na skróty". Do takiej kategorii należy niewątpliwie Extreme Programming (XP), opisane w artykule Kusząca jazda bez trzymanki (CW nr 40/2000). Z tego samego pnia wyrasta Agile Modeling - nowa metoda modelowania systemów informatycznych. Przyświecają jej prostota, użyteczność, zorientowanie na cel i akcent położony na komunikację.

U podstaw Agile Modeling (AM) tkwi założenie, że rzeczy proste powinny pozostać proste. Modele, które można określić mianem "zwinnych" (bo tyle znaczy słowo agile), przydatne są w rozwiązywaniu umiarkowanie skomplikowanych i dość typowych problemów w informatyce. A że przede wszystkim z takich problemów składa się praca w firmie software'owej, AM często pokrywa się z codziennymi praktykami stosowanymi w wielu przedsiębiorstwach i zespołach, w tym także w Polsce.

Zwinne modelowanie

W pewnym sensie Agile Modeling można nazwać antymetodyką. Duch AM to duch prostoty i zdrowego rozsądku, powstało ono bowiem w odpowiedzi na "ciężkie", trudne, przepełnione formalizmami i kładące duży nacisk na dokumentację metodyki analizy i projektowania obiektowego. Unified Modeling Language oraz Unified Process - notacja i metodyka stworzone przez trzech "wielkich" obiektowej inżynierii oprogramowania (Grady Booch, Ivar Jacobson, James Rumbaugh) - są złożone, opisują je opasłe tomiska, kursy trwają tygodniami, a efekty nie zawsze są zbliżone do oczekiwanych. "Zwinne modelowanie" to kolejna próba znalezienia odpowiedzi na kryzys inżynierii oprogramowania. To próba pokonania go drogą na skróty.

Manifest

Podstawowe założenia Agile Modeling zawarto w tzw. Agile Manifesto. Jest on krótki i zwięzły, warto więc przytoczyć go w całości.

"Odkrywamy nowe drogi w rozwoju oprogramowania poprzez tworzenie go i pomaganie innym w tworzeniu.

ale te po lewej cenimy wyżej".

Równie ważna co treść manifestu jest lista jego sygnatariuszy. Znajdują się na niej takie nazwiska, jak Kent Beck (twórca i popularyzator Extreme Programming), Ward Cunningham (jeden z autorów metody kart CRC, twórca Wikipedii), Martin Fowler (autor wielu książek z dziedziny inżynierii oprogramowania) Robert C. Martin (autor książek, współtwórca metodyki Martin-Odell), Steve Mellor (specjalista od obiektowości, współtwórca metodyki Schlaer-Mellor), Dave Thomas (jeden z autorów i popularyzator Smalltalka).

Szczególnie zaskakuje silna reprezentacja osób, które na początku lat 90. współtworzyły i popularyzowały modne wówczas metodyki analizy i projektowania obiektowego (OOA&D). Oznacza to, że osoby te obserwując, jak działają te metodyki w praktyce, doszły do wniosku, że łatwo o niewłaściwe ich zastosowanie i wtedy zamiast pomagać w inżynierii systemów informatycznych - przeszkadzają. Stąd też idea Agile Modeling.

Filozofia Agile Modeling

Agile Modeling składa się z trzech zasadniczych elementów: wartości, zasad i praktyk. Każdy z nich ma charakter uniwersalny i stosuje się do każdej części tworzenia oprogramowania: inżynierii wymagań, analizy, architektury i projektu.

Pięć wartości tworzących AM to: komunikacja, prostota, informacja zwrotna (feedback), odwaga i pokora. Komunikacja nie bez powodu jest pierwsza: Agile Modeling, podobnie jak Extreme Programming (XP), na pierwszym miejscu stawia interakcję. Chodzi zarówno o interakcję w zespole pracującym nad rozwiązaniem, jak i inter-akcję z użytkownikiem końcowym. Prostota to także wartość dobrze znana informatykom, choć uczciwie trzeba przyznać, że wiele metodyk i notacji (np. UML) jest bardzo zawikłane. Celem twórców AM jest, by model był zrozumiały dla wszystkich uczestników procesu tworzenia oprogramowania: informatyków, menedżerów i użytkowników. Pamiętajmy o manifeście - w AM komunikacja i właśnie informacja zwrotna są ważniejsze od poprawności. Odwaga i pokora, z pozoru przeciwstawne, dotyczą modyfikacji modelu: AM zaleca, aby zmian dokonywać ze śmiałością, ponieważ każdy informatyk powinien z pokorą zakładać, że jest omylny, jego wiedza jest niekompletna i popełnia błędy.