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

RE: [usage-centered] Product Management, Agile and UCD

Expand Messages
  • Larry Constantine
    --Larry Constantine [mailto:lconstantine@foruse.com] Director of Research and Development Constantine & Lockwood, Ltd. 58 Kathleen Circle | Rowley, MA 01969
    Message 1 of 18 , Mar 12, 2003
    • 0 Attachment
      --Larry Constantine [mailto:lconstantine@...]
      Director of Research and Development
      Constantine & Lockwood, Ltd.
      58 Kathleen Circle | Rowley, MA 01969
      tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com
      > I only recently discovered this group on the Yahoo! list. Is it still
      > alive? Did it die for a reason? Is anyone interested in resurrecting it?

      It's a matter of numbers and the fact that the forUSE newsletter has evolved
      into the primary forum.

      > I'd like to ask if anyone on the list has given any thought to the
      > best way to be an agile software developer is not to build stuff the
      > user doesn't need? To me, it's the notion that usage-centered design
      > can be applied early to help product managers focus their marketing
      > requirements.

      Jeff Patton (who has already chimed in) has done good work in this area.

      > I'm considering studying this area in greater depth and would like to
      > know if there is anyone out there who has looked at this issue already
      > and any work which I should go read before I start.

      Bravo! Keep us all informed.

      --Larry Constantine
    • Tom Poppendieck
      David - I am advocating the thesis that usage centered design is in fact the foundation of a set of agile customer-side practices similar to the developer-side
      Message 2 of 18 , Mar 12, 2003
      • 0 Attachment

        David –

         

        I am advocating the thesis that usage centered design is in fact the foundation of a set of agile customer-side practices similar to the developer-side practices that are the core of XP and the Project Management Practices that are at the core of Scrum and the XP Joint practices.  The fundamental issue is that while TDD permits refactoring to let the architecture of code emerge, there is no similar opportunity to refactor the users once they commit usage patterns to muscle memory.

         

        I am taking a stab at articulating this at SDWest 2003 in a tutorial.  Larry Constantine is offering some sessions on Card Based design that I expect will follow a similar direction.

         

         

        - Tom Poppendieck

         

        -----Original Message-----
        From: David J. Anderson [mailto:netherby_uk@...]
        Sent: Wednesday, March 12, 2003 10:25 AM
        To: usage-centered@yahoogroups.com
        Subject: Re: [usage-centered] Product Management, Agile and UCD

         

        <Snip>
        Hence, I believe that Usage-Centered Design is a key
        element to delivering a truly agile software
        development organization. Agility is just about
        programmers hugging each other while they write unit
        tests.

        David
        --
        David J. Anderson
        http://www.uidesign.net/
        The Webzine for Interaction Designers



        .

      • Nuno Nunes
        Hi there, This issue was already discussed previously here, by that time my only concern was how can you combine an upfront design method like UsageCD with the
        Message 3 of 18 , Mar 12, 2003
        • 0 Attachment
          Hi there,

          This issue was already discussed previously here, by that time my only
          concern was how can you combine an upfront design method like UsageCD
          with the principles of XP... One year latter this kind of combination
          (at the methodological level) still beats me...

          I don't want to be academic here, but there is an important difference
          between a method (like UsageCD - sorry but I don't consider XP a
          method) and a set of techniques: card games, participatory design,
          prototyping, etc.

          XP, and the Agile manifesto for that matter, are mainly a set of
          philosophical principles that promote rapid development, refactoring,
          pair-programming, etc. - which are techniques (most of them quite old)
          that can be used successfully with any other method. What XP doesn't
          describe are specific steps for systematic development... what are XP
          stories? how can you describe them? are they scenarios? are they
          (essential) use-cases? how are users modeled? with abstractions like
          actors? user profiles? or the "fascinating" personas (how on earth can
          you do UCD with stuff like personas!!!). What is an architectural
          spike? Is this a conceptual or physical model of the software
          architecture? But then it can be a model... modeling has nothing to do
          with XP...

          These are some answers I'm trying to find since I bumped into XP some
          years ago... before lightweight methods (or should I say any method)
          became the politically correct agile.

          Sorry for being the only guy on earth not excited with XP and the Agile
          Manifesto...

          Nuno

          PS: There are many important things about development agility and UCD
          or UID. For instance the importance of the structure of use of a
          software system to the underlying architecture... and the impact of UCD
          in the overall system size and complexity...

          On Quarta, Mar 12, 2003, at 19:52 Europe/Lisbon, Tom Poppendieck wrote:

          > David –
          >
          >  
          >
          > I am advocating the thesis that usage centered design is in fact the
          > foundation of a set of agile customer-side practices similar to the
          > developer-side practices that are the core of XP and the Project
          > Management Practices that are at the core of Scrum and the XP Joint
          > practices.  The fundamental issue is that while TDD permits
          > refactoring to let the architecture of code emerge, there is no
          > similar opportunity to refactor the users once they commit usage
          > patterns to muscle memory.
          >
          >  
          >
          > I am taking a stab at articulating this at SDWest 2003 in a tutorial. 
          > Larry Constantine is offering some sessions on Card Based design that
          > I expect will follow a similar direction.
          >
          >  
          >
          >  
          >
          > - Tom Poppendieck
          >
          >  
          >
          > -----Original Message-----
          > From: David J. Anderson [mailto:netherby_uk@...]
          > Sent: Wednesday, March 12, 2003 10:25 AM
          > To: usage-centered@yahoogroups.com
          > Subject: Re: [usage-centered] Product Management, Agile and UCD
          >
          >  
          >
          > <Snip>
          > Hence, I believe that Usage-Centered Design is a key
          > element to delivering a truly agile software
          > development organization. Agility is just about
          > programmers hugging each other while they write unit
          > tests.
          >
          > David
          > --
          > David J. Anderson
          > http://www.uidesign.net/
          > The Webzine for Interaction Designers
          >
          >
          >
          > .
          >
          >
          <image.tiff>
          >
          >
          > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
        • Tom Poppendieck
          Nuno - Those same philosophical principles, under the banner of lean thinking have revolutionized manufacturing, logistics, and even government by eliminating
          Message 4 of 18 , Mar 12, 2003
          • 0 Attachment
            Nuno -
            Those same philosophical principles, under the banner of lean
            thinking have revolutionized manufacturing, logistics, and even
            government by eliminating waste and enabling people to do the
            best work they are capable of. The resistance to lean practices
            in manufacturing took a decade to go away. Today, those
            organizations that did not adopt lean approaches are out of
            business. Information about how lean thinking applies to software
            development is available at www.leanprogramming.com.
            If you are still interested in learning about agile methods.
            answers to your questions are available at
            http://www.agilealliance.com/articles/index and many other
            places. A discussion group such as this is a poor medium to
            address such questions.
            - Tom Poppendieck
            Nuno wrote:
            <SNIP>
            XP, and the Agile manifesto for that matter, are mainly a set of
            philosophical principles that promote rapid development,
            refactoring, pair-programming, etc. - which are techniques (most
            of them quite old) that can be used successfully with any other
            method. What XP doesn't describe are specific steps for
            systematic development... what are XP stories? how can you
            describe them? are they scenarios? are they (essential)
            use-cases? how are users modeled? with abstractions like actors?
            user profiles? or the "fascinating" personas (how on earth can
            you do UCD with stuff like personas!!!). What is an architectural
            spike? Is this a conceptual or physical model of the software
            architecture? But then it can be a model... modeling has nothing
            to do with XP...
            These are some answers I'm trying to find since I bumped into XP
            some years ago... before lightweight methods (or should I say any
            method) became the politically correct agile.
            Sorry for being the only guy on earth not excited with XP and the
            Agile Manifesto...
            Nuno

            PS: There are many important things about development agility and
            UCD or UID. For instance the importance of the structure of use
            of a software system to the underlying architecture... and the
            impact of UCD in the overall system size and complexity...
          • Nuno Jardim Nunes
            I didn t say that those principles are not useful... They were before XP existed and they are now. My point is that all the excitement with X-this and
            Message 5 of 18 , Mar 13, 2003
            • 0 Attachment
              I didn't say that those principles are not useful... They were before
              XP existed and they are now.

              My point is that all the excitement with X-this and agile-that is
              leading to methodological misconceptions that ultimately lead
              practitioners to unfunded and misleading assumptions about the role of
              development principles, design techniques, process models and specific
              methods...

              For instance, some of the principles behind XP are not consistent with
              up-front modeling (or any kind of modeling). I'm not saying that you
              can't combine some XP principles and techniques with some UsageCD
              principles and techniques, just that the combination is not XP or
              UsageCD - it's something completely different that requires specific
              methodological concerns. The lack of such methodological concerns leads
              to chaotic styles of development (chaotic doesn't mean that they don't
              work on real projects, it just means that they are not consistently
              repeatable across projects and teams)... This is something I've been
              researching for a while... and I've seen people with rigid
              waterfall-like lifecycle models practicing pair-programming, or using
              iterative and incremental development with rigid up-front modeling
              approaches (meaning devoting literally months to analysis)...

              Nuno

              On Quinta, Mar 13, 2003, at 02:39 Europe/Lisbon, Tom Poppendieck wrote:

              > Nuno -
              > Those same philosophical principles, under the banner of lean
              > thinking have revolutionized manufacturing, logistics, and even
              > government by eliminating waste and enabling people to do the
              > best work they are capable of. The resistance to lean practices
              > in manufacturing took a decade to go away. Today, those
              > organizations that did not adopt lean approaches are out of
              > business. Information about how lean thinking applies to software
              > development is available at www.leanprogramming.com.
              > If you are still interested in learning about agile methods.
              > answers to your questions are available at
              > http://www.agilealliance.com/articles/index and many other
              > places. A discussion group such as this is a poor medium to
              > address such questions.
              > - Tom Poppendieck
              > Nuno wrote:
              > <SNIP>
              > XP, and the Agile manifesto for that matter, are mainly a set of
              > philosophical principles that promote rapid development,
              > refactoring, pair-programming, etc. - which are techniques (most
              > of them quite old) that can be used successfully with any other
              > method. What XP doesn't describe are specific steps for
              > systematic development... what are XP stories? how can you
              > describe them? are they scenarios? are they (essential)
              > use-cases? how are users modeled? with abstractions like actors?
              > user profiles? or the "fascinating" personas (how on earth can
              > you do UCD with stuff like personas!!!). What is an architectural
              > spike? Is this a conceptual or physical model of the software
              > architecture? But then it can be a model... modeling has nothing
              > to do with XP...
              > These are some answers I'm trying to find since I bumped into XP
              > some years ago... before lightweight methods (or should I say any
              > method) became the politically correct agile.
              > Sorry for being the only guy on earth not excited with XP and the
              > Agile Manifesto...
              > Nuno
              >
              > PS: There are many important things about development agility and
              > UCD or UID. For instance the importance of the structure of use
              > of a software system to the underlying architecture... and the
              > impact of UCD in the overall system size and complexity...
              >
              >
              >
              >
              > ------------------------ Yahoo! Groups Sponsor
              > ---------------------~-->
              > Get 128 Bit SSL Encryption!
              > http://us.click.yahoo.com/xaxhjB/hdqFAA/xGHJAA/NhFolB/TM
              > ---------------------------------------------------------------------
              > ~->
              >
              >
              >
              > Your use of Yahoo! Groups is subject to
              > http://docs.yahoo.com/info/terms/
              >
              >
              >
              --
              Nuno Jardim Nunes
              Assistant Professor, Universidade da Madeira
              http://math.uma.pt/njn
            • Larry Constantine
              Nuno and Tom, I think this is the right place to discuss and explore such issues--as they relate to presentation and interaction design broadly and
              Message 6 of 18 , Mar 13, 2003
              • 0 Attachment
                Nuno and Tom,

                I think this is the right place to discuss and explore such issues--as they
                relate to presentation and interaction design broadly and usage-centered
                specifically.

                As to the issue of rigor in practice, XP, for all it's informality in
                terminology and style, is far more an orthodoxy than usage-centered design,
                even with its quasi-formal models and logical process. In our view, you can
                do usage-centered design in pieces and mixed with almost any methodology
                within almost any life-cycle model. It can still be usage-centered. On the
                other hand, to claim to be doing XP, you have to buy a package and be
                following a whole series of practices.

                True, "agile" and "extreme" and "lightweight" are often mere jingoisms of
                the market-oriented zeitgeist, but that is just life. It was and is and
                always will be the name of the game. Once it was structured this and
                structured that, then object this and object that, then unified this and
                unified that. All these will pass and the agile agenda, too, someday. The
                good ideas from all will survive long after the brand names wither. Nobody
                does structured design anymore, but coupling and cohesion are alive and well
                as metrics and explanatory factors and the subject of continuing research.

                I do not worry either that many--even perhaps most--development groups
                misapply or mis-mix methods. It's Sturgeon's Law. The fact is that a group
                shoehorning pair programming into an otherwise baroque process may still be
                better off than if they didn't do it, and a team that builds a task case
                model and sketches a UI design along with orthodox XP will probably crank
                out better software than if they just went from stories to code.

                Tom may be right that fully lean approaches are absolutely superior, and
                Kent may be right that true XP is the true path, and Lucy and I may be right
                that model-driven usage-centered design based on a comprehensive task case
                model is the best way to go, and Nuno may have valid concerns about
                methodological muddling, but the fact is that the vast majority of
                developers will muddle and mix and practice only partially controlled chaos
                anyway.

                --Larry Constantine [mailto:lconstantine@...]
                Director of Research and Development
                Constantine & Lockwood, Ltd.
                58 Kathleen Circle | Rowley, MA 01969
                tel: +1 978 948 5012 | fax: +1 978 948 5036 | www.foruse.com
              • David J. Anderson
                Jeff, I read your material. Thanks for the pointer. What a pity, we didn t get a chance to meet at OOPSLA - I am based in Seattle and attended the conference
                Message 7 of 18 , Mar 13, 2003
                • 0 Attachment
                  Jeff,

                  I read your material. Thanks for the pointer. What a
                  pity, we didn't get a chance to meet at OOPSLA - I am
                  based in Seattle and attended the conference for a
                  single day.

                  Anyway, I felt I needed to give you some feedback
                  regarding FDD. You need to be careful when relating
                  Task Cases to FDD. FDD Features are not tasks. They
                  are not procedures but functions.

                  FDD uses architectural partitioning. There are four
                  types of Features in FDD: PD (problem domain or
                  business logic); UI (user interface); DM (data
                  management or persistence); SI (systems interface).

                  Most of the writing on FDD only talks about PD so
                  those less familiar with it can be forgiven for
                  mistakes in interpretation.

                  The Feature partitioning existed right from the start
                  in FDD. Of the regular contributors at
                  http://www.featuredrivendevelopment.com/ Steve Palmer,
                  Pauyl Szego and Jeff De Luca matured the PD Feature
                  methods. As these were most mature when the book "Java
                  Modeling in Color with UML" was written, these were
                  the things which were written down. Philip Bradley was
                  repsonsible for the SI and DM side of FDD and I was
                  repsonsible for the UI.

                  On the original project the UI was split into two
                  levels which were known as HLD and LLD (High level and
                  Low level design - respectively). The HLD tracked my
                  own work as the designer. The LLD tracked the
                  developers work programming the UI.

                  Later I wrote a paper "Extending FDD for UI" which
                  updated the LLD process using Ian Horrock's work of
                  Statechart Modeling for UI based on David Harel's
                  original Statechart notation.

                  Today, UI Features are grouped in Sets based on the
                  Container in the UI design. There are Features for
                  each View and Features for each event controller (or
                  action).

                  FDD Features are much more like object-oriented
                  Function Points than tasks or use cases. This is a
                  significant distinction from other methods.

                  Hence, Task Cases need to be elaborated into a Content
                  Model and Interaction Model before Features can be
                  defined.

                  Best Regards,

                  David
                  --
                  David J. Anderson
                  http://www.uidesign.net/
                  The Webzine for Interaction Designers


                  --- Jeff Patton <jeff621@...> wrote:


                  I haven't written too much, but you'll find an
                  experience report
                  here: http://oopsla.acm.org/fp/files/pra_extra.html
                  If I get my act
                  together, I'll be giving a presentation and/or
                  tutorial on exactly
                  this stuff at ForUse 2003.

                  cheers,

                  -Jeff



                  __________________________________________________
                  Do you Yahoo!?
                  Yahoo! Web Hosting - establish your business online
                  http://webhosting.yahoo.com
                • Jeff Patton
                  Thanks David for the feedback. I m sure it s obvious that my knowledge of FDD is a little sketchy. Based on the little reading I d done, I d very roughly
                  Message 8 of 18 , Mar 13, 2003
                  • 0 Attachment

                    Thanks David for the feedback.  I'm sure it's obvious that my knowledge of FDD is a little sketchy.  Based on the little reading I'd done, I'd very roughly equated FDD features to XP stories - and from what I'm hearing, if you look at them sideways, FDD PD type features could be mistaken for stories.  I'll dig in over the next little while and read more about FDD so I can understand it better.  But, I have to admit that the little bit of reading I've done has left me confused.  I had actually found your site and read your article there months ago.

                    >Hence, Task Cases need to be elaborated into a Content
                    Model and Interaction Model before Features can be
                    defined.<

                    In practice, these days, I've found this to be true also.  I am finding that I can't simply recast task cases into things to develop. 

                    My methods these days are more about establishing a language that works between development, customers and management.  I don't like the XP term "story" - since folks with millions of dollars to spend don't feel good about characterizing their needs as a "pack of stories."  I have been using the term "feature."  And by that I mean something that is understandable by customer and management, decomposable and buildable by development, testable by QA and easily demonstrable at acceptance time.  For those features I look for traceability back through the U-CD task and role models.  I need to know who uses the feature, in support of what goal, and as part of what task.

                    Looking at what I understand so far about FDD, the granularity of feature types might fail some of my tests for a valid feature - such as "understandable by customer and management."  Today, every once in a while, I let features slip into scope documents that fail my tests above.  After 30 minutes on a conference call explaining to a group of customers what I mean by BusinessObject, object-relational mapping and persistence, I've sworn to plan, manage and commicate about projects in terminology that works for most people involved.  Internally we'll break my course-grain features out into development tasks that might closely match up to FDD features types - but for us that sort of exercise is part of our teams implementation - not our public interface - if that makes sense.    

                    This very course-grain feature probably really is an XP story.  That's what I'm finding U-CD very effective at generating quickly and collaboratively. 

                    But, back to the original point of your message - I'd better get up to speed on FDD so I'm not mis-using its terminology.  And, more importantly, so I can make use of the work you and others have done.

                    BTW: I'd found and rooted around in your site sometime last year, but at that time it looked like you'd discontinued posting new content.  Looking at it now I see lots of new stuff to read.  I'll look forward to digging through it.

                    Thanks again for the feedback.  I look forward to meeting you sometime soon.  I'm sure we'll stumble across each other at one of these conferences.

                    If you're ever in or near my neck of the wood, Salt Lake City, please look me up. 

                    cheers,

                    -Jeff

                     "David J. Anderson" <netherby_uk@...> wrote:

                    Jeff,

                    I read your material. Thanks for the pointer. What a
                    pity, we didn't get a chance to meet at OOPSLA - I am
                    based in Seattle and attended the conference for a
                    single day.

                    Anyway, I felt I needed to give you some feedback
                    regarding FDD. You need to be careful when relating
                    Task Cases to FDD. FDD Features are not tasks. They
                    are not procedures but functions.

                    FDD uses architectural partitioning. There are four
                    types of Features in FDD: PD (problem domain or
                    business logic); UI (user interface); DM (data
                    management or persistence); SI (systems interface).

                    Most of the writing on FDD only talks about PD so
                    those less familiar with it can be forgiven for
                    mistakes in interpretation.

                    The Feature partitioning existed right from the start
                    in FDD. Of the regular contributors at
                    http://www.featuredrivendevelopment.com/ Steve Palmer,
                    Pauyl Szego and Jeff De Luca matured the PD Feature
                    methods. As these were most mature when the book "Java
                    Modeling in Color with UML" was written, these were
                    the things which were written down. Philip Bradley was
                    repsonsible for the SI and DM side of FDD and I was
                    repsonsible for the UI.

                    On the original project the UI was split into two
                    levels which were known as HLD and LLD (High level and
                    Low level design - respectively). The HLD tracked my
                    own work as the designer. The LLD tracked the
                    developers work programming the UI.

                    Later I wrote a paper "Extending FDD for UI" which
                    updated the LLD process using Ian Horrock's work of
                    Statechart Modeling for UI based on David Harel's
                    original Statechart notation.

                    Today, UI Features are grouped in Sets based on the
                    Container in the UI design. There are Features for
                    each View and Features for each event controller (or
                    action).

                    FDD Features are much more like object-oriented
                    Function Points than tasks or use cases. This is a
                    significant distinction from other methods.

                    Hence, Task Cases need to be elaborated into a Content
                    Model and Interaction Model before Features can be
                    defined.

                    Best Regards,

                    David
                    --
                    David J. Anderson
                    http://www.uidesign.net/
                    The Webzine for Interaction Designers


                    --- Jeff Patton <jeff621@...> wrote:


                    I haven't written too much, but you'll find an
                    experience report
                    here: http://oopsla.acm.org/fp/files/pra_extra.html
                    If I get my act
                    together, I'll be giving a presentation and/or
                    tutorial on exactly
                    this stuff at ForUse 2003.

                    cheers,

                    -Jeff



                    __________________________________________________
                    Do you Yahoo!?
                    Yahoo! Web Hosting - establish your business online
                    http://webhosting.yahoo.com


                    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



                    Do you Yahoo!?
                    Yahoo! Web Hosting - establish your business online

                  • David J. Anderson
                    Yes, the term Feature was never completed satisfactory. Se my post at the FDD community site on A Feature by any other name . Features in FDD come after
                    Message 9 of 18 , Mar 13, 2003
                    • 0 Attachment
                      Yes, the term Feature was never completed
                      satisfactory.

                      Se my post at the FDD community site on "A Feature by
                      any other name".

                      Features in FDD come after initial analysis. The PD
                      Features are definitely understandable by the
                      customer. The UI Features are too. Customers
                      comprehend a single View object and they understand
                      the notion that code must be written to process button
                      presses and their like. SI and DM are not understood
                      by the customer.

                      Hence, I tend to work with Marketing Features - which
                      would be your coarse-grained features - and either FDD
                      or Coad Features which are the Features as defined in
                      FDD for UI, PD, DM and SI.

                      The Feature template for PD and the architectural
                      partitioning are Peter Coad's contributions to FDD.

                      Sadly, there still isn't enough written down about FDD
                      in the other layers outside of PD.

                      I intend to re-launch uidesign.net in April with
                      irregular content. The recent material there will be
                      moving to my other site agilemanagement.net.

                      David

                      --- Jeff Patton <jeff621@...> wrote:
                      >
                      >
                      > BTW: I'd found and rooted around in your site
                      > sometime last year, but at that time it looked like
                      > you'd discontinued posting new content. Looking at
                      > it now I see lots of new stuff to read. I'll look
                      > forward to digging through it.
                      >


                      __________________________________________________
                      Do you Yahoo!?
                      Yahoo! Web Hosting - establish your business online
                      http://webhosting.yahoo.com
                    • Handan Nalbantoglu
                      Please unsubscribe me from this group. http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile.
                      Message 10 of 18 , Jun 26, 2003
                      • 0 Attachment
                        Please unsubscribe me from this group.

                        http://mobile.yahoo.com.au - Yahoo! Mobile
                        - Check & compose your email via SMS on your Telstra or Vodafone mobile.
                      • Ben Luff
                        Hi, Please could you remove my email from your mailing list? Thanks, Ben
                        Message 11 of 18 , Jun 27, 2003
                        • 0 Attachment
                          Hi,

                          Please could you remove my email from your mailing list?

                          Thanks,

                          Ben
                        • Richard J Watt
                          Message 12 of 18 , Jun 28, 2003
                          • 0 Attachment
                          • ben@system-concepts.com
                            Message 13 of 18 , Jul 9, 2003
                            • 0 Attachment
                            • tsjosten@abo.fi
                              Unsubscribe
                              Message 14 of 18 , Jul 16, 2003
                              • 0 Attachment
                                Unsubscribe
                              Your message has been successfully submitted and would be delivered to recipients shortly.