• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Agile Breakdown

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. Can you breakdown the agile methodology by activity? I've heard for some s/w methodologies the Requirements Phase is 30%, Coding 10%, testing/QA 50%, etc.

2. Can you scale down Agile without fundamental changes?

3. If you find your customer is not the collaborative type, do you scrap using Agile or modify it? Obviously communication, a lot of it, is key to Agile? Customers of different cultures/country may play a factor.

[ October 31, 2007: Message edited by: JD Delany ]
[ November 01, 2007: Message edited by: JD Delany ]
 
author
Posts: 46
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi JD,

1- XP uses simultaneous phases, so the proper answer would be "100% requirements, , 100% design, 100% coding, and 100% testing."

In the book, we recommend that you have two people focused on requirements ("on-site customers") for every three programmers. We also recommend one tester for every 4-6 programmers. That leads to the following ratios:
  • 36% of the team is dedicated to requirements full-time.
  • 54% of the team is dedicated to designing, coding, and programmer testing full-time.
  • 10% of the team is dedicated to testing full-time.

  • The ratios are just rules of thumb and must be modified for your specific situation.

    2- The book is written for teams as small as five people (four programmers and a product owner). You can go smaller, but some practices would need to be changed.

    3- You can always modify your approach to agile development. However, you're correct that communication is the key to success (in any project!) Agile methods prefer face-to-face communication over document-based communication. It's one of the reason's they're successful. If your customer isn't the collaborative type, you'd need to figure out some way to improve communication.
     
    Sheriff
    Posts: 14691
    16
    Eclipse IDE VI Editor Ubuntu
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    10% of the team is dedicated to testing full-time.


    Doesn't that mean that 10% of the team might have nothing to do ?

    And what about the following scenario : a project has been released. From now one, every 6 months, there are new requirements. Some small, some big. How is the team going to be composed ? Will the testers from the first release remain testers, or will they shift to programming ? I can't imagine people dedicated to testing all time.
     
    James Shore
    author
    Posts: 46
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Christophe,

    From your response, it sounds like you're assuming that analysis, design, coding, and testing have to happen in sequential order. On XP projects, that isn't true; they actually all happen at once, all the time. So testers always have something to do. However, it doesn't always look like traditional testing; much of what testers do on an XP team is help the team prevent bugs. This involves them much more deeply in the overall production of software. Compared to regular testers, very little of their time is actually spent executing tests.

    I talked more about the role of testers in my post on where QA fits in.
     
    Christophe Verré
    Sheriff
    Posts: 14691
    16
    Eclipse IDE VI Editor Ubuntu
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    So testers always have something to do


    But they won't as long as the coding team does not finish, will they ?

    I talked more about the role of testers in my post on where QA fits in.


    Another great post ! Thank you.
    [ November 01, 2007: Message edited by: Christophe Verre ]
     
    author
    Posts: 11962
    5
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Christophe Verre:
    > So testers always have something to do

    But they won't as long as the coding team does not finish, will they?


    On an XP project, a team of 5 developers might be working on anything between 1-5 user stories in parallel. Each of those stories might take anywhere between a couple of hours to a couple of days to complete. This means that it's not uncommon for new functionality to start popping up already on the very first day.

    Furthermore, as Jim said above, being a tester on an XP team is generally more of a development role than the traditional testers-test-software-once-its-written kind of verification role. In practice, the tester would, for example, help the customer and developers devise acceptance tests, automate those acceptance tests in parallel to or before the programmers writing the implementation, and perform exploratory testing (pdf).
     
    Christophe Verré
    Sheriff
    Posts: 14691
    16
    Eclipse IDE VI Editor Ubuntu
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    In practice, the tester would, for example, help the customer and developers devise acceptance tests, automate those acceptance tests in parallel to or before the programmers writing the implementation, and perform exploratory testing


    I see. I had a wrong picture of what a tester was doing in an Agile team. Thank you.
     
    JD Delany
    Greenhorn
    Posts: 2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thank you for your replies. Helpful info.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic