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

Re: [XP] Suitability, advantages and disadvantages of using an agile method such as XP in fast paced web development environments

Expand Messages
  • Phlip
    ... You have not listed your awareness of what the non- agile lifecycles look like. Suppose, for a moment, that they consisted of forcing individuals to sit
    Message 1 of 3 , Dec 31, 2002
    • 0 Attachment
      Michael Lane sez:

      > 1. Are agile methods such as XP the best approach is fast paced Web
      > development environment?

      You have not listed your awareness of what the non-"agile" lifecycles look
      like.

      Suppose, for a moment, that they consisted of forcing individuals to sit in
      separate offices, use tools they did not select or vote on, document what
      they do, enforce compliance with requirements documents the customer signed
      months ago, and test last.

      The HTML culture barely comprehends testing. So anything sent to the end of
      the lifecycle just might get skipped. The site looks okay, so publish it.

      HTML & its support systems are very easy to refactor, and terrible to
      refactor well. If the customer changes their mind, based on actually seeing
      the working site, changing it without up-front tests adds incredible risk.

      The Dot Com Boom fed HTML a huge gallery of support systems, all of dubious
      quality. Your customer does not >want< Jade, for example, they want a working
      site. But if your contract sold them Jade, by golly they'r gonna get Jade,
      even if it gives your project nothing and slows everyone down.

      Finally, people in offices far from each other collaborate poorly,
      leading to integration hell.

      > 2. What are advantages and limitations of XP in a fast paced Web
      > development environment?

      An XP team should be able to release any integration. The team should be
      producing deliverable code every 30 to 120 minutes. But a Web site should not
      change its appearance that often. XP makes the decision when, and what, to
      deploy entirely a business decision, at 2 week intervals for user stories.
      And because an XP project is "always in maintenance", it uniquely targets
      situations where end-users are using the release version at the same time as
      the team is adding features and removing issues.

      Happy Boreal Winter Solstice Festivals, everyone!

      --
      Phlip
      http://www.c2.com/cgi/wiki?PhlIp
      -- But all the other programmers were doing it! --
    • William Pietri
      ... They are the best I know of. If you turn up another one, please let us know! ... As compared to what, exactly? Speaking broadly, I think XP s advantages
      Message 2 of 3 , Jan 2, 2003
      • 0 Attachment
        On Tue, 2002-12-31 at 17:15, Michael Lane wrote:
        > 1. Are agile methods such as XP the best approach is fast paced Web
        > development environment?

        They are the best I know of. If you turn up another one, please let us
        know!

        > 2. What are advantages and limitations of XP in a fast paced Web
        > development environment?

        As compared to what, exactly?

        Speaking broadly, I think XP's advantages for fast-paced web projects
        are even stronger than for other types of project:

        * Having all the running copies of the program under your direct
        control makes frequent releases much easier.
        * Because your competitors are just one bookmark away, it's much
        harder to insulate yourself from competitive pressure. That
        makes the ability to adapt quickly much more important. It also
        gives you a bigger advantage if you can keep ahead of your
        competitors.
        * Because new releases are adopted immediately, feedback comes
        quickly. This makes steering the project easier.
        * Since bugs can be very, very public, XP's ability to drastically
        reduce bug counts and bug severity are a big win.
        * In fast-paced environments, priorities often change rapidly.
        Releasing frequently means that when a project suddenly gets
        shelved, relatively little work sits around unreleased.

        The main limitation I can think of is that XP's focus on testability
        does not match well with the web environment in two ways:

        * One of the major criteria for a web site is "looks right". This
        is hard to automate.
        * Client-side functionality (javascript, dhtml, assorted
        components) are very popular with some site designers. This is
        fiendishly difficult to test automatically, especially across a
        wide variety of platforms.

        My main techniques for dealing with this are a) validating the output
        HTML, b) ignoring the meaning of the HTML but making sure that the code
        outputs whatever the visual designers want, c) manual testing, and d)
        shaking my head sadly and pressing onward whenever the issue comes up.

        Still, this isn't really a problem with XP; XP just exposes the problem
        that other methods tend to ignore.


        Oh, wait, there's one other limitation, and this one is a real one: XP
        demands doing things right from the beginning. This pays off in the long
        run, but initial progress on an XP project feels slower than just
        jumping in and hacking stuff out. On fast-paced projects, this initial
        feeling of slowness makes XP adoption much harder than in environments
        where people are accustomed to taking a longer view of things.

        William

        --
        brains for sale: http://scissor.com/
      Your message has been successfully submitted and would be delivered to recipients shortly.