My only concern is that when I try to explain this, nobody understand
what "metaphor" means.
Not exactly.
We usually start a new project identifying the major constrains (for
example security, fine grained user permission and easy to add plugin
modules for a CMS) and then we try to figure out how it could work.
In that case (the cms) we came out with the "truck metaphor" -> a gwt
client generate "cargo trucks" that go to the server where an official
will check for all the right credentials and then let them pass to the
correct store, where the truck can show its request to the store
manager, who fill the truck with the content and send it back to the
gwt client.
Once we did a walking skeleton of this, we were sure it can really
work and we started the real development. Every time we need to add
new modules or new feature to the software we go back to the original
metaphor and we enrich it with other actors and places.
Originally we thought about using it only as start, but 2 years have
passed and we're still using it when brainstorming. Moreover we used
other metaphors for all the new projects we started since then.
cheers
Uberto
Best regards,
Edmundo
> Gesch�ftsf�hrer: Henning Wolf, Jens Coldewey
On Mon, Dec 6, 2010 at 18:15, uberto <ubert...@gmail.com> wrote:
....
> We as team are using a metaphor to describe the very high level
> architecture for all our projects.
>
> My only concern is that when I try to explain this, nobody understand
> what "metaphor" means.
assuming your target group is software developers, how about:
a higher level language which is an abstraction of your software.
even if you don't visualize it literally, a metaphor is a kind of
mental visualization.
my interpretation or extrapolation of Tom Wujec on visualization
(http://www.ted.com/talks/tom_wujec_on_3_ways_the_brain_creates_meaning.html)
is that when you visualize something, and when several people use and
interact with the visualization over time as a focus of work, they
effectively create a higher level language.
i was diving into this when thinking about Kanban boards, which is
meant to reflect your real process, and evolve and be interacted with
over time, and be a central point of work for a team.
but i think it applies to metaphors, too - especially when evolved and
interacted with over time, as you describe about your truck metaphor
in your team.
so in my opinion you have created a language for communicating much
more effectively about the software.
maybe your metaphor, with all the details you have added to the story
as you have enriched it, is even a DSL of sorts for your specific team
and software.
regards,
ingvald
My only concern is that when I try to explain this, nobody understand
what "metaphor" means.