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
      --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
    • 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 2 of 18 , Mar 12, 2003
        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 3 of 18 , Mar 12, 2003
          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 4 of 18 , Mar 13, 2003
            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 5 of 18 , Mar 13, 2003
              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 6 of 18 , Mar 13, 2003
                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 7 of 18 , Mar 13, 2003

                  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 8 of 18 , Mar 13, 2003
                    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 9 of 18 , Jun 26, 2003
                      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 10 of 18 , Jun 27, 2003
                        Hi,

                        Please could you remove my email from your mailing list?

                        Thanks,

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