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

Product Management, Agile and UCD

Expand Messages
  • David Anderson
    Hi, 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? I d like to
    Message 1 of 18 , Mar 11, 2003
      Hi,

      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?

      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.

      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.

      Best regards,

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

      PS The thread on Interaction Design from a year or two back made me smile.
    • David J. Anderson
      Agile Manifesto Principle #10 reads Simplicity--the art of maximizing the amount of work not done--is essential. To me this means that it is important to
      Message 2 of 18 , Mar 12, 2003
        Agile Manifesto Principle #10 reads

        "Simplicity--the art of maximizing the amount
        of work not done--is essential."

        To me this means that it is important to know what is
        appropriate and will be valued by the user - producing
        a minimal design for it and insuring that maximum
        value is delivered for the programming buck. That is
        right in the agile space but it needs UCD to achieve
        it.

        I believe that this principle can be delivered through
        correct persona definition, and thorough task analysis
        leading to the right set of task cases.

        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



        --- David Anderson <netherby_uk@...> wrote:

        ---------------------------------
        Hi,

        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?

        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.

        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.

        Best regards,

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

        PS The thread on Interaction Design from a year or two
        back made me smile.


        Yahoo! Groups Sponsor ADVERTISEMENT

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


        __________________________________________________
        Do you Yahoo!?
        Yahoo! Web Hosting - establish your business online
        http://webhosting.yahoo.com
      • Jeff Patton
        The group may be a little stagnant, but the concepts aren t. I ve been doing exactly what you describe. U-CD, as Larry and Lucy teach it is very agile. I use
        Message 3 of 18 , Mar 12, 2003
          The group may be a little stagnant, but the concepts aren't.

          I've been doing exactly what you describe. U-CD, as Larry and Lucy
          teach it is very agile. I use a collaborative U-CD session involving
          development and customers to establish the initial scope. During
          this quick collaborative session (1-2 days depending on the size of
          the problem) we create a role model, task model and interaction
          contexts. From this we can extract features, stories or whatever
          your agile methodology wants to call them. Since developers are in
          the room we can roughly and quickly estimate development time. We
          write up the result of this meeting in a scope document that the
          customers and developers walk away with. During development, at the
          head of each iteration we flesh out tasks and create wireframe UI -
          just-in-time. The role and task models live as posters on the wall
          in the development room to contuously help us be aware of the users
          and tasks, their relationships and priorities.

          The whole thing works very well.

          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

          --- In usage-centered@yahoogroups.com, "David Anderson"
          <netherby_uk@y...> wrote:
          > Hi,
          >
          > 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?
          >
          > 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.
          >
          > 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.
          >
          > Best regards,
          >
          > David
          > --
          > David J. Anderson
          > http://www.uidesign.net/
          > The Webzine for Interaction Designers
          >
          > PS The thread on Interaction Design from a year or two back made me
          smile.
        • David J. Anderson
          Interesting! I look forward to seeing you at forUse 2003. Glad to see at least one more person sees the agile advantage from UI design effort up-front. Have
          Message 4 of 18 , Mar 12, 2003
            Interesting! I look forward to seeing you at forUse
            2003. Glad to see at least one more person sees the
            agile advantage from UI design effort up-front.

            Have you seen the paper I wrote in 1999 on
            collaborative UI design sessions?
            http://www.uidesign.net/1999/papers/UI_Modelling1.html

            This was the process used on the original FDD project
            in Singapore. This stuff was never documented as part
            of the official book on FDD as the UI processes were
            not considered sufficiently mature at the time. Since
            then I've significantly improved them. I must get
            around to writing it all down sometime.

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

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

            ---------------------------------
            The group may be a little stagnant, but the concepts
            aren't.

            I've been doing exactly what you describe. U-CD, as
            Larry and Lucy
            teach it is very agile. I use a collaborative U-CD
            session involving
            development and customers to establish the initial
            scope. During
            this quick collaborative session (1-2 days depending
            on the size of
            the problem) we create a role model, task model and
            interaction
            contexts. From this we can extract features, stories
            or whatever
            your agile methodology wants to call them. Since
            developers are in
            the room we can roughly and quickly estimate
            development time. We
            write up the result of this meeting in a scope
            document that the
            customers and developers walk away with. During
            development, at the
            head of each iteration we flesh out tasks and create
            wireframe UI -
            just-in-time. The role and task models live as
            posters on the wall
            in the development room to contuously help us be aware
            of the users
            and tasks, their relationships and priorities.

            The whole thing works very well.

            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

            --- In usage-centered@yahoogroups.com, "David
            Anderson"
            <netherby_uk@y...> wrote:
            > Hi,
            >
            > 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?
            >
            > 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.
            >
            > 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.
            >
            > Best regards,
            >
            > David
            > --
            > David J. Anderson
            > http://www.uidesign.net/
            > The Webzine for Interaction Designers
            >
            > PS The thread on Interaction Design from a year or
            two back made me
            smile.


            Yahoo! Groups Sponsor ADVERTISEMENT

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


            __________________________________________________
            Do you Yahoo!?
            Yahoo! Web Hosting - establish your business online
            http://webhosting.yahoo.com
          • Larry Constantine
            --Larry Constantine [mailto:lconstantine@foruse.com] Director of Research and Development Constantine & Lockwood, Ltd. 58 Kathleen Circle | Rowley, MA 01969
            Message 5 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
            • 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 6 of 18 , Mar 12, 2003

                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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 of 18 , Jun 27, 2003
                                  Hi,

                                  Please could you remove my email from your mailing list?

                                  Thanks,

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