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

Re: Product Management, Agile and UCD

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

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

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

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

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

          Bravo! Keep us all informed.

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

            David –

             

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

             

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

             

             

            - Tom Poppendieck

             

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

             

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

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



            .

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

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

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

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

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

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

              Nuno

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

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

              > David –
              >
              >  
              >
              > I am advocating the thesis that usage centered design is in fact the
              > foundation of a set of agile customer-side practices similar to the
              > developer-side practices that are the core of XP and the Project
              > Management Practices that are at the core of Scrum and the XP Joint
              > practices.  The fundamental issue is that while TDD permits
              > refactoring to let the architecture of code emerge, there is no
              > similar opportunity to refactor the users once they commit usage
              > patterns to muscle memory.
              >
              >  
              >
              > I am taking a stab at articulating this at SDWest 2003 in a tutorial. 
              > Larry Constantine is offering some sessions on Card Based design that
              > I expect will follow a similar direction.
              >
              >  
              >
              >  
              >
              > - Tom Poppendieck
              >
              >  
              >
              > -----Original Message-----
              > From: David J. Anderson [mailto:netherby_uk@...]
              > Sent: Wednesday, March 12, 2003 10:25 AM
              > To: usage-centered@yahoogroups.com
              > Subject: Re: [usage-centered] Product Management, Agile and UCD
              >
              >  
              >
              > <Snip>
              > Hence, I believe that Usage-Centered Design is a key
              > element to delivering a truly agile software
              > development organization. Agility is just about
              > programmers hugging each other while they write unit
              > tests.
              >
              > David
              > --
              > David J. Anderson
              > http://www.uidesign.net/
              > The Webzine for Interaction Designers
              >
              >
              >
              > .
              >
              >
              <image.tiff>
              >
              >
              > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
            • Tom Poppendieck
              Nuno - Those same philosophical principles, under the banner of lean thinking have revolutionized manufacturing, logistics, and even government by eliminating
              Message 6 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 7 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 8 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 9 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 10 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 11 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 12 of 18 , Jun 26, 2003
                          • 0 Attachment
                            Please unsubscribe me from this group.

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

                              Please could you remove my email from your mailing list?

                              Thanks,

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