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

Re: [XP] Customer Surrogate

Expand Messages
  • Ron Jeffries
    ... That would be the standard thing to do in a product organization. ... How does that work compared to finding out in minutes what they like? Ron Jeffries
    Message 1 of 24 , Mar 30, 2000
      At 09:32 PM 3/30/2000 -0500, you wrote:
      >So how do we accurately meet the requirements of our customer(s).
      >I tend to think that we're going to need a surrogate for the customers.
      >We call them "product analysts" in my organization. That product
      >analyst can do a full requirements phase with a reasonable number of
      >customers, document it, and then get on the team as a surrogate
      >customer and work through the iterations with us.

      That would be the standard thing to do in a product organization.

      >We currently do some iterative development like this. Eventually we
      >get Beta's out to customers, although the communication with them is
      >typically just phone and E-mail. We don't do much on-site with them and
      >they rarely come on our site to work with us.

      How does that work compared to finding out in minutes what they like?



      Ron Jeffries
      www.XProgramming.com
    • Daniel T.
      A recent post on comp.object got me thinking about this subject so I started doing some re-reading over the weekend. I would like to start up a discussion
      Message 2 of 24 , Mar 30, 2000
        A recent post on comp.object got me thinking about this subject so I
        started doing some re-reading over the weekend. I would like to start
        up a discussion about some of the AntiPatterns listed in the book by
        Brown et al., how they affect XP and how problems might be fixed...

        For those not in the know. An antipattern is formed when a solution
        to a perceived problem causes a completely different problem that is
        even worse.

        Quickly perusing the book, I find that XPs practices seem to do a
        good job of protecting the project from all of the antipatterns in
        chapter five (which deals with development level issues,) however
        there are several antipatterns in chapter 6 that need to be watched
        for, namely... (Chapter 6 deals with Architecture issues.)

        Architecture by Implication (a system developed without a documented
        architecture.) As I understand both XP and the antipattern (and I'm
        not claiming to understand either all that well.) XP has several
        methods to help insure this antipattern doesn't come about. Namely
        the system metaphor, planing game, stand--up meetings and
        pair-programming (BTW I'm beginning to see pair-programming in a
        different light, maybe more on that later.) However only the system
        metaphor addresses this antipattern explicitly.

        Design by Committee (Committee designs are overly complex and lack a
        common architectural vision.) Again, XP relies on communication to
        avoid this. That and the fact that a committee isn't needed to change
        the design, just one pair with a lot of time on their hands. :-)

        Reinvent the Wheel (Legacy systems with overlapping functionality
        don't interoperate. Every system is built in isolation.) I have
        strong reservations about this one, especially after Mr. Beck's
        comments on a "money" class. Although framework reuse seems to be
        lauded by XPers (especially the "unit" framework.)

        Stovepipe Enterprise (Uncoordinated software architectures lead to
        lack of adaptability, reuse, and interoperability.) XP doesn't seem
        to have any processes to address this antipattern. I feel that XP
        should take definite measures to address this issue or it could
        easily be a problem.

        Grand Old Duke of York (Four out of five developers cannot define
        good abstractions; this leads to excess complexity.) XP could clearly
        suffer on this front (and I'm not just saying that because I'm one of
        those "abstractionists" that the book talks about. Some people are
        better at coming up with great frameworks and some are better at
        coming up with great algorithms. It makes sense to have a formal
        system in XP to recognize this fact and allow "framework gurus" some
        explicit say in the design of the program... These people would be
        better off in the cat-bird seat instead of on the keyboard for
        instance...

        Jumble (Interface designs are an unfactored mixture of horizontal and
        vertical elements, which necessitates frequent interface changes and
        an inability to reuse.) Not only does XP not address this
        antipattern, XP seems to claim that it doesn't exists! Or at least
        that the "frequent interface changes" that this antipattern involves
        are cheap enough not to be a real problem...

        The chapter seven antipatterns are all "people issues". As such, in
        most cases I don't feel that *any* "design method" should or could
        protect against them. XP however seems as though it would be
        especially vulnerable to:

        The Feud (Managers who engage in protracted conflicts with peers have
        serious negative impacts on their staffs.) In XP's case, sorting the
        "managers" from the "staff" might be a little difficult. I guess the
        coaches job primarily is head off these kinds of problems.

        Irrational Management (Habitual indecisiveness and other habits
        result in de facto decisions and development emergencies.) XP seems
        to revel in "de facto decisions" calling it "let the code tell you
        what needs to be done". Again, it seems the only one to ensure
        against this problem is the coach...

        =====================================================================

        In case someone missed it above, I must again say... There are many
        antipatterns discussed in the book, XP has clear and effective (IMO)
        methods to stave off many, if not most of them (especially the
        "development antipatterns".) I've only covered the ones that I
        personally perceive as potential problems in a typical XP project
        (assuming that the XP book describes "typical" XP projects. :-)

        I would like to here what people using XP think. What XP practices do
        you think address the potential problems above? How? Why?
      Your message has been successfully submitted and would be delivered to recipients shortly.