Loading ...
Sorry, an error occurred while loading the content.

Re: [agile-usability] design or requirements was: RE: Re: Subtle User Intera...

Expand Messages
  • PaulOldfield1@aol.com
    (responding to Jeff) And for others, sorry, this is a bit of an epic. I think it s worth writing, but feel free to differ. ... I ve had this discussion
    Message 1 of 3 , Aug 2, 2006
    • 0 Attachment
      (responding to Jeff)
       
      And for others, sorry, this is a bit of an epic.  I think it's worth
      writing, but feel free to differ.
       
      >
      style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I think I understand the basics pretty well – although the fuzziness
      > of the real world doesn’t seem to be well represented in the crisp
      > edged ovals of a UML: diagram.
       
      I've had this discussion several times, and that's a useful
      observation nobody has made before.  (I'd dig out the old e-mails
      if I hadn't lost them in a disk crash...).  Yes, a Use case expects
      a crisp edge, a well-defined boundary to the system, at least
      by the time we finish writing it.  With user stories this edge starts
      fuzzier; we don't get the crisp definition until the acceptance
      tests are written if we use a typical agile approach.
       
      > I think in the picture you’re sketching with words below you draw
      > the business worker pointing to the usecase as inside the system
      > oval.
       
      We have nested ovals; the 'business worker is outside the inner
      oval but inside the outer oval.  The outer oval represents the business
      and all its systems (manual and automated).  The inner oval
      represents the IT system; specifically that IT system we are building.
      For an enterprise model, the outer oval could contain many nested
      ovals. So the business worker is inside the business but outside
      the IT system.
       
      > Does that imply that deciding who the workers are and what they
      > do is part of the design of the system?
       
      It's part of the design of the outer oval - it is business design, but
      not IT system design.  Remember, the two ovals represent
      different systems, that are nested.  So this is design of the outer
      system.
       
      > And does that make that the responsibility of the developer?
       
      I assume here you are talking about the developer of the IT system,
      in which case, no.  Not unless this developer is also doing
      business process engineering.
       
      > Or is supporting specific workers to use the system to do specific
      > tasks part of the requirements of the system?
       
      Part of the requirements of the inner system, the IT system, Yes.
       
      > what about the specific steps of the tasks and the specific user
      > interactions of the tasks?  Are those things designed?  By who?
      >  Agile customers or developers?  And how much of that design
      > happens after the story card is introduced, and how much
      > happened before it was written?
       
      If the steps in the Business Worker's tasks are totally manual,
      then they are solely the responsibility of the Business Designer
      (or equivalent).  If they are automated, then they become a
      requirement on the inner, IT system.  Negotiating the requirement
      is best done by collaboration between the designers of the two
      systems and the person who is going to have to use the system;
      possibly with a few other roles thrown in.  Of course, these roles
      can be combined in various ways.  The user of the IT system might
      also be acting as designer of the business system, for example.
       
      > It’s that tagging a thing as a requirement that makes me bristle. 
      > It smacks of waterfall thinking – hints at irrevocable immutable
      > decisions – seems to suggest that that since they’re requirements,
      > they aren’t questionable.  But, I think my allergy to the word
      > requirement is my own problem.  ;-)
       
      I hear what you're saying, and agree with the sentiment.  Yet
      at some point, the decision becomes (relatively) irrevocable,
      immutable.  The trick is to ensure this doesn't happen until
      they don't need to be questionable - until all questions have
      already been asked and answered.  Even when working with
      Use cases we can ensure the conversations that need to happen
      have happened before the use case is 'done'... provided we
      don't get a PM who demands sign off before he will sanction
      commencement of design  :-(   User stories are *expected* to
      have the card, conversation, confirmation lifecycle.
       
      > ... low precisions like “customer enters album title in search
      > box to see a list of albums that match the title” to very high
      > precision like “place a 40 x 40 pixel image of the album cover
      > next to album listing in the search return.”  
       
      I immediately think "search box" is design.  Leave it for the
      conversation.  As for the high precision example, I'd need to
      ask a few questions to find out what is wanted; that's
      almost all solution.  It might turn out to be the right solution;
      ideal for what the user wants.  Yet we could choose to accept
      these stories as-is, because they are placeholders for a
      conversation.
       
      <aside>
      > ... no one’s buying UML diagrams [unless you work for Accenture].  
      They've moved on from powerpoint, then?  ;-)
      </aside>
       
      In reality, things like whether to show a representation of the album
      cover are open to negotiation.  We tell the business what's feasible
      and what it costs; they tell us what they need, which of the
      feasible options they prefer after consideration of the cost, and
      what priority to put on this compared to their other requirements.
      It doesn't matter where the ideas come from; a good idea is a
      good idea from any source.
       
      As to when to make the decision - the best time is just in time.
      If we make the decision any earlier two significant things come
      in to play.  First, we may get better information later.  Second,
      we need to record the decision because we aren't going to
      act on it straight away.  Okay that isn't strictly true, but we can
      only hold a few decisions in memory.
       
      > Hope I didn’t get to edgy with those opinions.  ;-)
       
      Not by my reckoning.
      Thanks.
       
      Paul Oldfield
       
       
    Your message has been successfully submitted and would be delivered to recipients shortly.