SitePoint Sponsor

User Tag List

Results 1 to 7 of 7
  1. #1
    Founder of Primal Skill Ltd. feketegy's Avatar
    Join Date
    Aug 2006
    Posts
    482
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Question Agile Web Development Pros and Cons?

    A detailed reference can be found on Wikipedia

    I heard lot's of comments and criticism on agile web development some of them good some of them bad.

    Agile development is considered harmful, stressful and unproductive, because the concept itself promotes making software projects by means of continuously iterating over the work in progress with the client.

    So what is your opinion?

  2. #2
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, the first problem is the definition of "agile". Some people use it as a synonym for test driver design. Some think that the essence of it is in using SCRUM. Some insist on having the whole package, before it can be called agile. Others just use it as a marketing term.

    So which aspect of agile, are we looking at?

  3. #3
    Founder of Primal Skill Ltd. feketegy's Avatar
    Join Date
    Aug 2006
    Posts
    482
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I refer to what is defined on the Wikipedia page.

  4. #4
    SitePoint Author silver trophybronze trophy
    wwb_99's Avatar
    Join Date
    May 2003
    Location
    Washington, DC
    Posts
    10,635
    Mentioned
    4 Post(s)
    Tagged
    0 Thread(s)
    The wikipedia page is a bit nebulous. Anyhow, IMHO, the big challenge with using agile methods really is selling management on it. From their lofty perch, it looks very chaotic and unpredictable. And management hates chaos and unpredictibility. Now, the thing they fail to realize is that, in most cases, is that software development actually is chaoitic and that the older processes they had in place were just effective ways to hide said chaos from their pervue, oftentimes at the cost of delivering inferior products.

    Insofar as the web + agile goes, I think it fits better than many things because the web is so much more fluid and so much of what people want to do is a moving target. Whereas if one is building an inventory tracking system, you have many more fixed pieces and processes to deal with, so morphing requirements as the project rolls does not work out so well.

  5. #5
    Founder of Primal Skill Ltd. feketegy's Avatar
    Join Date
    Aug 2006
    Posts
    482
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Can you elaborate a little bit on this?
    How do you complete for ex. an iteration in the project? What are the steps you take?

    I'm really interested in this.

  6. #6
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by feketegy View Post
    ..., because the concept itself promotes making software projects by means of continuously iterating over the work in progress with the client.
    This is nothing like as hard as it sounds, as long as you gear your development system to it. You still have to do design, you still have to capture requirements, you still have to usability test. You actually add a load of additional process that allows you to delay those decisions for longer. What these processes are depends on your environment and the skill of of your developers.

    For example, you can capture a big dollop of requirements in great detail, design, recapture the requirements you now realise you forget, usability test a prototype, recapture the requirements that are now obviously wrong, redesign, etc, etc...and then start coding just as the project gets cancelled.

    A more agile approach is to prioritise rough requirements, decide on what can be released quickly (a couple of weeks), and do it. With code actually out there, you work out the next part, and start to build a design based on the experience you have already.

    At first sight this is clearly inefficient. Agile is primarily a risk management strategy. It tries to minimise business risk by giving rapid feedback to the people that matter - the users and stakeholders. Contrast this with the design centric RUP say (Rational Unified Process), which is about reducing technical risk. As web companies tend to face high business risk (competitive time to market, innovative user interfaces, novel busniess models) it makes a lot of sense for web companies to be interested in agile development. Telecoms companies have larger projects that face big technical challenges, hence the RUP popularity in that sector.

    Various practices make agile less inefficient than it would otherwise sound. Unit tests reduce the damage caused by frequent code changes. Refactoring is a skill for changing the design of existing code while keeping it running. Continuous integration allows for frequent releases. The idea is that this is less inefficient than the much greater damage caused by changes in spec. when using a more upfront design system.

    Note that agile is not hacking. It's actually a very controlled process, even stifling at times. It puts the business first.

    The downside of agile is the amount of religeon surrounding it. You'd think software had never been shipped before the arrival of agile methods, listening to some of the proponents . Most criticisms are from those who've never tried it.

    My own view? It's hard work applying agile, and you'll need skilled developers.

    What are you using now?

    yours, Marcus

    p.s. I think "hacking" is a perfectly legitimate software process, and underused at times. I wouldn't use it by default though.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  7. #7
    SitePoint Enthusiast
    Join Date
    Jan 2008
    Posts
    30
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Agile is quite simple. Take the old waterfall method and just do a lot of them on the same project, delivering smaller bits of the BIG project at a time.

    Let's say you're building a customer relationship management system. In the waterfall method, the old way, it'd be like this:
    Client says: We want a system to manage customers, complaints, product orders, shipments, deliveries, returns, ad campaigns, marketing documents, and leads. You have 2 years to complete the entire thing. Here's $3 Million. At which point the client says, "Oh man... i hope these guys can actually deliver something that works and is usable."

    In the Agile world, that same project would be like this:
    We want a CRM, first thing we need is a customer manager, get that to us in 2 weeks. Here's $50,000. If we like it, we'll tell you what we want next. So the development team goes and builds that. The client likes it and they say, "Okay, now add onto that customer manager a lead manager and marketing materials management" 3 weeks later, the client is satisfied and they add more features to their CRM. Oh and they also say, "We'd prefer it if the customer module did this and this, instead of this and that."

    The second approach the Agile method is better for many reasons:
    The Client sees more quickly whether or not they will like the work product
    They can change the requirements more easily
    They get to use the product in 2 weeks in bits and pieces instead of having to wait for 2 years for anything at all
    They pay less more frequently, so the investment is smaller

    One thing I especially like about Agile is that programmers are smart. A lot of times they have great ideas that can really make a product a lot better, but if they aren't brought into the project at an early enough stage, then they are forced to simply implement what the customer predicts they are going to want.

    With Agile, the programmer is brought in quicker and can help collaborate with the end user on some of the requirements. They can say, "I've noticed the customer module acts this way, have you considered something like this? What about if we let the customer log in and check their accounts from the web?" And the customer says, "Whoa! Customers can log in and check their accounts from the web??"

    The cons with the Agile method is as that bureaucrats are afraid of it. They believe it is less predictable. It's new. It'll take time, but really there is no better way -- yet.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •