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

Re: top down, or bottom up?

Expand Messages
  • Jeff Patton
    Hmm... I m not sure I d disagree with anything you and Josh have said. In my original post, I sorta glossed over how I d normally do things. I do definitely
    Message 1 of 36 , Apr 22, 2005
    • 0 Attachment
      Hmm... I'm not sure I'd disagree with anything you and Josh have
      said.

      In my original post, I sorta glossed over how I'd normally do
      things. I do definitely identify identify users and goals first...
      then really do "porpoise" back and forth between user goals and what
      I hear or observe they're doing to look for design opportunities or
      evidence that they're doing things that don't seem to support those
      goals. The user tasks we brainstorm are part of those little "what
      they're doing" bits.

      Aviva, in Karen's class we did gather lots of little details and
      cluster them to identify those user goals - along with information
      about how they did things. I really heard Karen beat the "bottom up
      drum" while in the class. Josh, you were sitting in on the class I
      took from Cooper where we did a similar thing - that is gathered lots
      of little details during interviews them looked for commonalities. I
      saw both approaches working mostly bottom up. Yes, in both
      approaches we reconciled details captures with user goals.... and
      actually in both cases we validated what users "self reported" goals
      might have been with the activities we saw/heard them do.

      So, I'm contrasting this messy gather-lots-of-facts-correlate-and-
      look-for-patterns approach to Alistair's start at the top with
      the "self reported" or "employer furnished" user goals and work your
      way down.

      So Aviva and Josh - I'm hearing you both say "top down" - but I think
      you're lieing. ;-) I think you both would gather lots of little
      details, including details about current workflow, and then work
      bottom up to validate user goals.

      Reading your posts is framing this better in my head. A couple posts
      from now I might consider my first one a little stupid... ;-)

      thanks for your posts!

      -Jeff

      --- In agile-usability@yahoogroups.com, Aviva Rosenstein <aviva@y...>
      wrote:
      >
      > Hi Jeff! It was great seeing you and great to meet all the other
      folks
      > from the list at CHI this month.
      >
      > Maybe the issue is that you're concentrating on different things
      > here.Your bottom up approach is aimed at catching pieces of the
      process
      > and bunding those up into user goals.
      ....

      > >
      > > XP 2005 (Sheffield, UK) Agile User Experience Tutorial:
      > > http://www.xp2005.org
      > >
      > > UPA Agile-UCD Tutorial:
      > >
      http://www.upassoc.org/conferences_and_events/upa_conference/2005/prog
      ram/activity.php?id=179
      > >
      > > UPA Agile-Usability Workshop:
      > >
      http://www.upassoc.org/conferences_and_events/upa_conference/2005/prog
      ram/activity.php?id=156
      > >
      > > Agile 2005 (Denver, CO) Agile User Experience Tutorial, Agile
      Code Metrics
      > > Tutorial: http://www.agile2005.org/
      > >
      > > "There is nothing that saps one's confidence as the knowing how
      to do a
      > > thing."
      > >
      > > --Mark Twain
      > >
      > >
      > > ------------------------------------------------------------------
      ------
      > > *Yahoo! Groups Links*
      > >
      > > * To visit your group on the web, go to:
      > > http://groups.yahoo.com/group/agile-usability/
      > >
      > > * To unsubscribe from this group, send an email to:
      > > agile-usability-unsubscribe@yahoogroups.com
      > > <mailto:agile-usability-unsubscribe@yahoogroups.com?
      subject=Unsubscribe>
      > >
      > > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
      > > Service <http://docs.yahoo.com/info/terms/>.
      > >
      > >
    • Glen B Alleman
      Alistair, Crystal has a variety of options. Others are narrower. Few are as broadly based as your approach. I m more focused on specific development method
      Message 36 of 36 , May 8, 2005
      • 0 Attachment
        Alistair,

        Crystal has a variety of options. Others are narrower. Few are as broadly
        based as your approach. I'm more focused on specific development method that
        move outside their "sweet spot" leaking into other areas - off the sweet
        spot. I see this not as an issue of the method but it's application. Mis
        applied CMMI, mis applied XP, mis applied TOC.

        Glen

        -----Original Message-----
        From: agile-usability@yahoogroups.com
        [mailto:agile-usability@yahoogroups.com] On Behalf Of aacockburn
        Sent: Sunday, May 08, 2005 10:46 AM
        To: agile-usability@yahoogroups.com
        Subject: [agile-usability] Re: elite methods

        I'm sure you mean "almost" everyone, Glen --- I've been researching
        and publishing on the topic of selecting methods for over a decade
        now, have a PhD, three books, a dozen articles and most of a website
        on the question of selecting a process. I'm not alone: that aspect of
        my PhD wasn't considered novel at all but rather as fully established
        in the research community; Capers Jones talks about it in his
        benchmarking book; RUP and the UP are all about that; Boehm has a
        book and articles about it, there are others.

        By this late date, the notion of a single methodology as a silver
        bullet is severely outmoded.

        Alistair

        --- In agile-usability@yahoogroups.com, "Glen B Alleman"
        <glen.alleman@n...> wrote:
        > Jon,
        >
        >
        >
        > The problem of deciding how to apply a processes to a problem
        domain is
        > nearly universal. Ranging from heavy to light. I've experienced
        poorly
        > applied CMMI to poorly applied XP and everything in between. No
        one seem to
        > want to approach the "improvement" process from an external point -
        as you
        > suggest - selecting the right process for the problem. I'm
        searching though
        > for the solution - none found so far. Everyone's got a silver
        bullet looking
        > for the werewolf to shoot ;>)
        >
        >
        >
        > Glen B. Alleman
        >
        > <http://www.niwotridge.com> www.niwotridge.com
        >
        > www.niwotridge.com/Blog
        >
        >
        >
        >
        >
        > _____
        >
        > From: agile-usability@yahoogroups.com
        > [mailto:agile-usability@yahoogroups.com] On Behalf Of Jon Kern
        > Sent: Friday, May 06, 2005 6:36 PM
        > To: agile-usability@yahoogroups.com
        > Subject: Re: [agile-usability] Re: elite methods
        >
        >
        >
        > i don't think there is any indication that anyone meant that all
        heavy
        > processes are to hide incompetence.
        >
        > however, i submit there are at least a few reasons for introducing
        process:
        > - because someone has a good set of steps worth repeating (good
        teams do
        > this automatically)
        > - because someone wants to ensure a set of steps are done and
        may not
        > trust the doer at knowing what to do (bureaucracies are good at
        doing this)
        >
        > i hope i left wiggle room in my original post for applying the
        right process
        > for the right reasons. my flippant remarks are intended to jolt
        people into
        > thinking if they are applying the right level of process. a
        heavyweight
        > process (such as might be applied in your NQA-1 example) applied to
        a
        > mediocre business app is probably not an effective use of resources.
        >
        > also, i have seen people conduct process steps "just because" --
        either
        > because they cannot think for themselves, or that they are dis-
        incented to
        > not follow process, or they are naive, or they do not care if they
        are
        > wasting resources (money and time).
        >
        > but, for a mission critical app, i hope the right process is
        followed... as
        > it is in almost every "hard" engineering discipline i ever worked
        within.
        >
        >
        >
        >
        > -- jon
        >
        >
        >
        >
        > Glen B Alleman said the following on 5/6/2005 8:54 AM:
        >
        > Jon,
        >
        >
        >
        > Mission critical can be applied outside man rated as NASA uses that
        term.
        > Mission critical can be applied to a brad variety of system from
        process
        > control, to supply chain management. Pacemakers are 21CFR,
        petrochem is OSHA
        > 1910.119, rod control for a reactor is NQA-1, the ground mission
        planning
        > and dispatch for air defense has another framework.
        >
        >
        >
        > The comment (now seen a flippant) that poor developers hide behind
        high
        > ceremony struck me a uninformed about those working in the high
        ceremony
        > development envirnemnt that also use agile methods. Thy are not
        mutually
        > exclusive
        >
        >
        >
        > Glen
        >
        >
        >
        > _____
        >
        > From: <mailto:agile-usability@yahoogroups.com>
        > agile-usability@yahoogroups.com [mailto:agile-
        usability@yahoogroups.com] On
        > Behalf Of Jon Kern
        > Sent: Friday, May 06, 2005 5:17 AM
        > To: agile-usability@yahoogroups.com
        > Subject: Re: [agile-usability] Re: elite methods
        >
        >
        >
        > please define mission-critical...
        > man-rated, mission critical systems are a different story.
        >
        > always attach the right level of rigor and process as needed...
        >
        > software for an embedded pacemaker is different than making an
        online
        > mortgage loan application system.
        >
        >
        >
        >
        > -- jon
        >
        >
        >
        >
        > Glen B Alleman said the following on 5/5/2005 11:40 AM:
        >
        > As one who leads CMMI IPPD development this is likely not true in
        > practice...but simply conjecture on the part of those not
        practicing heavy
        > processes in a mission critical environment.
        >
        > Glen B Alleman
        >
        > -----Original Message-----
        > From: agile-usability@yahoogroups.com
        > [mailto:agile-usability@yahoogroups.com] On Behalf Of aacockburn
        > Sent: Thursday, May 05, 2005 9:35 AM
        > To: agile-usability@yahoogroups.com
        > Subject: [agile-usability] Re: elite methods
        >
        > At least, they will defend them because it's easier to hid :-)
        >
        >
        > --- In agile-usability@yahoogroups.com, "Cummins, Darin"
        > <mailto:Darin_Cummins@a...> <Darin_Cummins@a...> wrote:
        > > If you twist this one more time, does that imply that incompetent
        > > developers choose heavy processes because it's easier to hide? ;-)
        > >
        >
        >
        >
        >
        >
        >
        >
        >
        >
        > _____
        >
        > Yahoo! Groups Links
        >
        > * To visit your group on the web, go to:
        > http://groups.yahoo.com/group/agile-usability/
        >
        > * To unsubscribe from this group, send an email to:
        > agile-usability-unsubscribe@yahoogroups.com
        > <mailto:agile-usability-unsubscribe@yahoogroups.com?
        subject=Unsubscribe>
        >
        > * Your use of Yahoo! Groups is subject to the Yahoo!
        > <http://docs.yahoo.com/info/terms/> Terms of Service.





        Yahoo! Groups Links
      Your message has been successfully submitted and would be delivered to recipients shortly.