TheTarPit

Agile Modeling

Kiedy pierwszy raz zetknąłem się z pojęciem Agile Modeling spotkałem różne mniej lub bardziej rozbudowane wprowadzenia czy też próby skrótowego przedstawienia tego pojęcia (choć niejako z definicji skrótowo przedstawić się go nie da), w tym również poniższą listę:

When Are You Agile Modeling?

1. Your customers/users are active participants in your requirements and/or analysis modeling efforts.
2. Changing requirements are welcomed and acted upon accordingly - there is no "requirements freeze".
3. You are working on the highest priority requirements first, as prioritized by your project stakeholders, and in turn focusing on highest risk issues as work progresses.
4. You are taking an iterative and incremental approach to modeling.
5. Your primary focus is on the development of software, not documentation or the models themselves.
6. You are modeling as a team where everyone's input is welcome.
7. You are actively trying to keep things as simple as possible - You are using the simplest tools available to you and creating the simplest model(s) that do the job.
8. You are discarding most, if not all, of your models as development progresses.
9. Customers/business owners make business decisions, developers make technical decisions.
10. The content of your models is recognized as being significantly more important than the format/representation of that content.
11. How you will test what you are describing with your model(s) is a critical issue being continually considered as you model.

Pierwsza rzecz, która mnie w tym uderzyła, to realność i zdrowy rozsądek. To cechy, które w czymkolwiek, co usiłuje być metodologią modelowania czy projektowania systemów informatycznych, są zazwyczaj mocno deficytowe. Co więcej — styl pracy, jaki przez kilka ostatnich lat wyewoluował w zespole, w którym przyszło mi pracować, uwzględnia co najmniej 10 z tych 11 punktów. Intuicja? Przypadek?

Główna zaleta modeli, które można określać jako "agile" ("sprawny", "zręczny", "zwinny") daje się sformułować banalnie prosto:

Agile models are more effective than traditional models because they are just barely good enough, they don't have to be perfect.

Na pierwszy rzut oka może się wydawać, że to sankcjonowanie bylejakości, niedbałości lub modelowania czy projektowania "po łebkach". Jednak wypełnienie wszystkich zasad i praktyk AM nie jest wbrew pozorom wcale takie łatwe czy oczywiste. Przede wszystkim wymaga to zrozumienia prawdziwych celów i powodów poszczególnych aktywności występujących w projekcie. A po drugie wymaga szczerej chęci Zrobienia Tego Dobrze, po to, żeby powstał dobry system, a nie tylko ładny projekt.

Tak naprawdę z punktu widzenia doświadczonego zespołu pojęcie AM to tylko sprytne nazwanie czegoś, co jest po prostu przejawem zdrowego rozsądku i praktyką, do której chcąc nie chcą w końcu się dochodzi. Jednak mimo to potrafię sobie wyobrazić mnóstwo ludzi (jakimś dziwnym trafem przeważnie z kręgów kierowniczych), dla których taka "metodologia" będzie znacznie łatwiej akceptowalna niż lekko enigmatyczne pojęcie "realizmu" i "dobrej roboty inżynierskiej"...

Komentarze

Brak komentarzy do tego wpisu.