aspose file tools*
The moose likes Agile and Other Processes and the fly likes Agile Breakdown Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Agile Breakdown" Watch "Agile Breakdown" New topic
Author

Agile Breakdown

JD Delany
Greenhorn

Joined: Oct 31, 2007
Posts: 2
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 ]
James Shore
author
Ranch Hand

Joined: Sep 21, 2007
Posts: 46
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.


    James Shore, coauthor of <a href="http://www.amazon.com/Art-Agile-Development-James-Shore/dp/0596527675" target="_blank" rel="nofollow">The Art of Agile Development</a>. Website and blog at <a href="http://www.jamesshore.com" target="_blank" rel="nofollow">http://www.jamesshore.com</A> .
    Christophe Verré
    Sheriff

    Joined: Nov 24, 2005
    Posts: 14687
        
      16

    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.


    [My Blog]
    All roads lead to JavaRanch
    James Shore
    author
    Ranch Hand

    Joined: Sep 21, 2007
    Posts: 46
    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

    Joined: Nov 24, 2005
    Posts: 14687
        
      16

    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 ]
    Lasse Koskela
    author
    Sheriff

    Joined: Jan 23, 2002
    Posts: 11962
        
        5
    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).


    Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
    Christophe Verré
    Sheriff

    Joined: Nov 24, 2005
    Posts: 14687
        
      16

    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

    Joined: Oct 31, 2007
    Posts: 2
    Thank you for your replies. Helpful info.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Agile Breakdown