Re: Tools was Re: [AM] A small success and a large irony

At 10:18 AM 2/12/2004 -0600, Scott P. wrote:
><snip>
>| >
>| >Post-its are a great tool.  Our UI designers use them extensively.  On
>| >the other hand, I can make text boxes in Visio as fast as I can make
>| >Post-its, I can move them around as easily, they remain sticky forever
>|
>| That's nice, but are you working with your stakeholders when you're
>| doing that.
>---
>
>Again, it can be either.  However, the UI modeling is usually done in
>the user experience team, which works with customers and end users.

Ah, I see.  You don't have direct access to the stakeholders so you're 
compensating with tools.



>---
>| >(unlike Post-its), and [the killer] I can mail the result to somebody
>| >else, or print it in different sizes, or clone it as a base for
>| >exploring a variation, or put it under version control so I can remember
>| >the steps that led to the current state...
>|
>| That's nice too, but you lose the value of inclusiveness with the
>| post-its.  Make the trade-offs that are best for your team.
>---
>
>How do you use inclusiveness, assuming you're doing this collaboratively
>and making the results visible?

The stakeholders can actually do the modeling if you're using simple tools 
and techniques.  Improves communication and the chance that you do the 
right thing.  Then the developers can build them something and show them 
very quickly.



>| >---
>| >
>| >As noted elsewhere, I think the agility should have occurred in
>| >designing the screens and flows, which should happen before you go to
>| >code.
>|
>| Yes, spending a couple of minutes doing so makes sense.
>---
>
>In our case it's more like months, overall, by the time you've laid out
>enough interaction to be useful and set and reviewed up user testing
>sessions.  Obviously, consumer devices are different from software
>that's used internally in a more narrowly-constrained task.

Yes, I suppose it's harder if you're developing physical items, but I bet 
you could get the feedback time down if you wanted to.



>---
>|
>| >("time lost waiting" surely is offsetting some manual
>| >process that would probably take longer, "migration costs" should be
>| >compared with costs of manual translation, "maintenance of the model" is
>| >only a cost if you choose to maintain it,
>|
>| If I'm not choosing to maintain it then I'd toss it away.  There'd also be
>| little motivation in this case for me to use a complex tool, unless it
>| generated code for me.
>---
>
>If the complex tool is effective, it should make the modeling faster
>than doing it on paper.

You'd think that, but it doesn't actually seem to be the case in practice.


>  That should be part of defining what makes a
>tool effective.  It should be easier/faster to draw UML diagrams in a
>good tool than by hand - if it isn't, then it may not be a good tool.

The tool needs to supply other benefits, such as code generation, ... to 
make it worth while.



<snip>

- Scott 

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------