Zasad (principles) AM jest więcej niż reguł i trudno wszystkie je opisać. Oto jednak najważniejsze i najciekawsze. Niewątpliwą nowością jest to, że Agile Modeling zakłada tworzenie wielu rozwiązań dla jednego problemu. Zamiast upierać się - jak wiele istniejących metodyk - że istnieje jedno, "poprawne" rozwiązanie danego zadania, AM zaleca tworzenie wielu rozwiązań i wybór najwłaś-ciwszego poprzez dyskusję w zespołach i konsultację z użytkownikami końcowymi. Istotnym zaleceniem AM jest gotowość do zmian, a raczej oparcie całego tworzenia modelu na zmianie. W zespołach kierujących się tą zasadą nie ma "własności" elementu modelu. Jeżeli ktoś zaprojektował fragment systemu, nie oznacza to, że każda zmiana w tym fragmencie powinna "przejść przez ręce" autora. Przeciwnie, Agile Modeling zakłada, iż każda osoba, w odpowiedzi na istniejące wymaganie, może zmienić fragment systemu, jeżeli tylko przyniesie to korzyść całości. Warto też wymienić jeszcze jedną zasadę, bardzo prostą i logiczną, ale kluczową: celem modelowania jest działające oprogramowanie. Inżynierowie nie mogą o tym zapominać, np. modelując cechy, dla których wybrany język programowania nie ma wsparcia. Celem AM jest ten konkretny, projektowany system. "Pierwszoplanowym celem (...) jest stworzenie działającego programu, (...) nie zaś dodatkowej dokumentacji, dodatkowych praktyk zarządzania ani nawet modeli. Każde działanie, które nie prowadzi prosto do tego celu, jest wątpliwe i powinno być unikane" - piszą autorzy Agile Modeling. Jakże różne jest to podejście od szacunku dla ponownego użycia (re-use), obecnego od wielu lat w większości popularnych metodyk.

Zbiór zaleceń zwanych także praktykami wynika z dwóch poprzednich - jest po prostu ich skonkretyzowaniem. Znajdziemy tam takie praktyki, jak: rysuj proste modele, używaj kartek i tab-licy przed narzędziami CASE, buduj model przyrostowo, udowodnij go za pomocą kodu (tylko to, co da się zaprogramować, jest możliwe). Nie brakuje tam jednak praktyk odbiegających od ducha swobody i zdrowego rozsądku, który przenika całe Agile Modeling. Na przykład twórcy metody nalegają, aby wszelkie zewnętrzne styki oprogramowania (m.in. API komponentu) były specyfikowane bardzo dokładnie, bez cienia dwuznacz- ności. Zaleca także ścisłe określanie kluczowych wymagań systemu, ponieważ od tego zależy cała reszta , np. jeżeli system ma przetwarzać dziesięć tysięcy transakcji dziennie, to nie można sobie go "z fantazją" zaprojektować na sto.

Agile Modeling, w odróżnieniu od bodaj wszystkich metodyk, nie ma własnej notacji. Autorzy piszą wprost, że użytecznych notacji jest dostatecznie wiele i są one dostatecznie dopracowane, aby powoływać do życia jeszcze jedną. Szczególną uwagę poświęcają najpopularniejszej z nich, Unified Modeling Language (UML). W eseju Be Realistic about UML Scott W. Ambler napisał, że UML nie zawiera jednorodnej, zintegrowanej, prostej i zrozumiałej notacji każdego dla Ű Ű kluczowych elementów oprogramowania: reguł biznesowych, modeli interfejsu użytkownika, fizycznych modeli danych. Oderwanie UML od języka programowania, argumentuje Ambler, jest w istocie nie zaletą, ale wadą, ponieważ nie jest możliwe proste przeniesienie projektu do programu (np. kompletne generatory Javy czy C++ dla kodu wraz z dobrymi generatorami XML dla formatów danych).

Agile Modeling, wg słów jego autorów, nie opisuje kompleksowego procesu tworzenia oprogramowania. Koncentruje się na efektywnym modelowaniu, ale nie zawiera wskazań dotyczących zarządzania projektem, wdrożenia i innych istotnych elementów procesu. W tych aspektach autorzy pozostawiają użytkownikowi ich metody wiele swobody, ale w jednym są konkretni: zalecają, aby do programowania używać Extreme Programming, ponieważ filozofie AM i XP są podobne. Podobieństwom tym warto poświęcić więcej uwagi.

Agile Modeling a Extreme Programming

Podobieństwa widoczne są już na poziomie zasad i wartości. W Extreme Programming są cztery wartości (prostota, komunikacja, testowanie, śmiałość). Trzy z nich znajdują się także w Agile Modeling, a czwartej - testowanie - nie stosuje się do modeli, tylko do kodu.

Podobna filozofia przyświeca pracy nad rozwiązaniami. Tu i tam akcentuje się pracę zes- połową, w ścisłej współpracy z końcowymi użytkownikami. Tu i tam nie ma ograniczeń w modyfikowaniu części modelu bądź fragmentu kodu stworzonego przez innego informatyka. Zarówno XP, jak i AM traktują zmianę jako istotną, nieusuwalną cechę wymagań i do tego dopasowują proces. I tu, i tam nie traktuje się dokumentacji i jej aktualności z przesadną uwagą. Choć nie jest już ona uznana za zbędną - jak doradzał Kent Beck w fundamentalnej pozycji Extreme Programming Explained - to jednak twórcy Agile Modeling radzą nie przejmować się jej aktualnością. Zamiast tego bardziej przydaje się czytelny kod, który lepiej dokumentuje projekt.

Można więc podsumować, że Agile Modeling to skutek tego, że "ekstremalni programiści" zdali sobie sprawę, iż przed pisaniem kodu warto pomyśleć i naszkicować to, co chce się programować, choćby dlatego by skutecznie porozumiewać się z innymi.