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

| From: Scott Ambler<[email protected]>
| Date: Fri, 13 Feb 2004 15:37:25 -0500
| 
| At 10:18 AM 2/12/2004 -0600, Scott P. wrote:
| >| >
| >| >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.
---

huh?  The people doing the UI do have access to the customers and end
users (note that in our line they're different people - wireless
companies are customers, end users are individuals who buy through
wireless companies).  The reason for using tools is because it makes the
modeling faster and better.

That's not to say that we don't do tool-less ideation with carriers and
end users, too ("draw how you think this should work"); that's just a
different point in the cycle.

---
| 
| >---
| >| >(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 above, the caarriers and end users we talk do do provide input, in
various forms.  But drawn representations of screens are way faster to
produce than coded ones.  Note, also, that we don't usually have
hardware we could run code on, anyway, at this stage (the hardware
lifecycle is about as long as the software lifecycle - we're often using
processors that have only been promised for the planned delivery date
and in-chip (non-flashable) ROMs for some functionality, and the cases,
keypads, etc., alsoo take longer than the software that supports them).
We use simulators for software development, but for user testing they're
less effective than paper protptypes - too unlike the real form factor
and too slow.

---
| >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.
---

Again, huh? You resist using tools even when they're easier and faster
than doing the models by hand?

scott
-- 
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il  61820  
e-mail:	[email protected]	fax:	217-384-8550
phone:	217-384-8589	cell: 217-433-6114	pager: [email protected]

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
--^----------------------------------------------------------------