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

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

Expand Messages
  • Tom Poppendieck
    Nuno - Those same philosophical principles, under the banner of lean thinking have revolutionized manufacturing, logistics, and even government by eliminating
    Message 1 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 2 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 3 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 4 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 5 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 6 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 7 of 18 , Jun 26 10:48 PM
                • 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 8 of 18 , Jun 27 2:24 AM
                  • 0 Attachment
                    Hi,

                    Please could you remove my email from your mailing list?

                    Thanks,

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