This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Agile and Other Processes and the fly likes Big Design Upfront  and XP refactorings Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Big Design Upfront  and XP refactorings " Watch "Big Design Upfront  and XP refactorings " New topic
Author

Big Design Upfront and XP refactorings

HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
I have read that the XP methodology is only suitable for small systems.
Can UML modelling upfront (as in the SCEA) be used together with XP of smaller sub-systems. I am not really sure I understand the thought behind that it has to be either one or the other methodolgies but not both.
Is the problem just Project velocity ? Slower for upfront design and quicker for XP ?

regards
[ September 14, 2003: Message edited by: HS Thomas ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by HS Thomas:
I have read that the XP methodology is only suitable for small systems.

Where did you read this? It's wrong, XP is quite successfully used for big systems.
A different topic is big *teams*...

Can UML modelling upfront (as in the SCEA) be used together with XP of smaller sub-systems. I am not really sure I understand the thought behind that it has to be either one or the other methodolgies but not both.

How would BDUF help?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
How would BDUF help?

Here are a few thoughts:

  • Gathering information (requirements) to see whether a system is required
  • Cost-benefit analysis to see whether the system's development is realistic
  • Breaking the development into smaller subsystems to define the *small* teams sizes
  • Prepare user documentation, Integration testing (perhaps with legacy systems)



  • Note that the BDUF would never be used to cut code. That WOULD be silly!
    Also note that the design would be at a rather high abstract level and not at a lower-level.
    (They may take the risky bits to a lower implementation level.)
    regards
    [ September 14, 2003: Message edited by: HS Thomas ]
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by HS Thomas:
    Gathering information (requirements) to see whether a system is required

    That's done in vanilla XP, anyway. XP tries to capture as many User Stories as possible during the first Release Planning meeting.

    Cost-benefit analysis to see whether the system's development is realistic

    Cost analysis is done in the Release Planning, too. This may include the development of Architectural Spikes to reduce risk. See http://www.agilemodeling.com/essays/agileModelingXPLifecycle.htm#ExplorationPhase
    Benefit analysis is outside the scope of XP, but it's certainly implied that it's done somehow. (If it isn't done, the Customer couldn't decide about business value, which is required by XP.)

    Breaking the development into smaller subsystems to define the *small* teams sizes

    Could you please elaborate this point? Thanks.

    Prepare user documentation, Integration testing (perhaps with legacy systems)

    How would BDUF help here?
    [ September 14, 2003: Message edited by: Ilja Preuss ]
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Breaking the development into smaller subsystems to define the *small* teams sizes
    --------------------------------------------------------------------------------

    Could you please elaborate this point? Thanks.

    As a rule of thumb , I believe XP teams sizes are between 4-12.
    I suppose you'd start with 4 and build up from there. Won't a BDUFish model upfront help scope the work. Wouldn't want to be short of staff at a crucial time.

    Prepare user documentation, Integration testing (perhaps with legacy systems)
    --------------------------------------------------------------------------------

    How would BDUF help here?

    Preparing user documentation after the BDUFish models and keeping it up to date is good practise I feel.People usually have a sense of when things are settling.
    Preparing Integration tests alongside the user documentation is also good practise. All three are in sync! What more can you wish for ?
    A system. With XP you'd have that system in sync as well.
    regards
    [ September 14, 2003: Message edited by: HS Thomas ]
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by HS Thomas:
    As a rule of thumb , I believe XP teams sizes are between 4-12.

    That's the safe range most would advise to start with. There are bigger XP projects out there, though (up to around 25 without splitting up the team, iirc).
    I remember Robert Martin saying that he finds he is able to manage bigger and bigger teams with XP the more he learns about XP. So the real maximum possibly hasn't yet been discovered.

    I suppose you'd start with 4 and build up from there.

    Yes, starting small would be one strategy.
    Won't a BDUFish model upfront help scope the work. Wouldn't want to be short of staff at a crucial time.

    Please explain "scope the work" in this context. I think I don't yet fully understand you...

    Preparing user documentation after the BDUFish models and keeping it up to date is good practise I feel.People usually have a sense of when things are settling.

    Well, for a different view see http://www.xprogramming.com/xpmag/manualsInXp.htm and http://www.xprogramming.com/xpmag/Ferlazzo.htm
    Preparing Integration tests alongside the user documentation is also good practise. All three are in sync! What more can you wish for ?
    A system. With XP you'd have that system in sync as well.

    I don't yet understand how BDUF helps you to prepare integration tests - let alone keeping them in sync with the systems and its manual. Please explain.
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Please explain "scope the work" in this context. I think I don't yet fully understand you...

    Scope the work - discovering the scope of the system. Have three hundred or five hundred classes been discovered?

    I don't yet understand how BDUF helps you to prepare integration tests - let alone keeping them in sync with the systems and its manual. Please explain.

    BDUF should help in planning ahead , in getting the big picture upfront.
    Generate the user stories at the start as per XP , but take it further with a BDUF - this helps with estimating the user staff and skills required. At the same time also start with setting up Integration Testing and User Acceptance Testing Teams. A BDUFish model could help here, along with Use Cases perhaps, to make the Users feel the system is theirs.
    ( It was interesting that Robert Martin said he doesn't particularly utilise Use Cases, though.)
    Diagrams How do you stop other users/team members feeling that that they are left in the dark ?
    You need to create a Agile User environment also. A BDUF is something they can refer to. Obviously you also need a few UML specialists to help interpret and maintain the models. How's that for a job creation exercise ?
    When I mentioned user manuals I also meant the CD-based ones. We haven't seen the last of Paper manuals, especially when integrating with legacy systems, unfortunately.
    regards
    [ September 15, 2003: Message edited by: HS Thomas ]
    Lasse Koskela
    author
    Sheriff

    Joined: Jan 23, 2002
    Posts: 11962
        
        5
    BDUF should help in planning ahead , in getting the big picture upfront.
    Generate the user stories at the start as per XP , but take it further with a BDUF - this helps with estimating the user staff and skills required. At the same time also start with setting up Integration Testing and User Acceptance Testing Teams. A BDUFish model could help here, along with Use Cases perhaps, to make the Users feel the system is theirs.

    XP doesn't state that *all* user stories would be gathered/generated at the start so the approach you described would be simply waterfall/BDUF and nothing more.
    What would "setting up integration and acceptance testing teams" help when you don't know what the Big Design will look like until development starts (I feel like I didn't understand something)?
    Finally, having use cases written for a BDUF is not the best way to make users feel like the system is theirs. A lot more efficient way to achieve this would be to have the customers be involved in developing the system, writing tests and deciding which stories/features to build next.


    Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Originally posted by Lasse Koskela:
    XP doesn't state that *all* user stories would be gathered/generated at the start so the approach you described would be simply waterfall/BDUF and nothing more.

    Originally posted by Illja Preuss:
    XP tries to capture as many User Stories in the first Release Planning Meeting.

    What would the User get from this process. The User perspective,please.
    Is this sufficient process for the User to make sure that he knows what he wants? And I think you are telling me that the User will get some CDs(user manuals ) and an evolving system at continuous intervals. Does the User get a chance to change his mind about what he wants ?
    The users should have enough time amongst themselves to discuss options and proritize and then agree as a whole what's needed . A deliverable will be at least one BDUF model, produced by systems. The users may well work several Requirements specification ahead of systems.
    BTW , I really like the process from a System Development perspective , but I'd like the User to continue to employ me.
    regards
    [ September 15, 2003: Message edited by: HS Thomas ]
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by HS Thomas:
    What would the User get from this process. The User perspective,please.

    The User (or Customer, as XP names the role) gets a stack of User Story cards, containing all the important features he could think of, estimated and prioritized. Optionally he also gets a first release date, together with a projection of stories done to that date. And he (hopefully) also gets the feeling that the developers are understanding his priorities, as they discussed them together.
    After that, he gets a running, usable system every one to two weeks. He gets updated projections on development speed and the opportunity to change the plan based on new information.
    Is this sufficient process for the User to make sure that he knows what he wants?

    No - how the Customer knows what he wants is outside the scope of XP. XP just requires that he does. XP also accomodates for the fact that he can't *fully* know what he wants, so he gets massive feedback on what he requested and is allowed to change his mind.
    And I think you are telling me that the User will get some CDs(user manuals ) and an evolving system at continuous intervals.

    That's at least one way to do it - and a quite XPish way.
    The users should have enough time amongst themselves to discuss options and proritize and then agree as a whole what's needed.

    Yes. It doesn't need to be all upfront, though.
    A deliverable will be at least one BDUF model, produced by systems.

    A stack of user stories. Perhaps some sketches of the GUI. A sketch of a deployment diagram for very large systems. Whatever it needs. Doesn't need to be *B*DUF, so it seems to me.
    The users may well work several Requirements specification ahead of systems.

    To what goal?
    BTW , I really like the process from a System Development perspective , but I'd like the User to continue to employ me.

    That's why we try to suit him. I think it's easier to do by massive feedback than by massive upfront design.
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by Lasse Koskela:

    Finally, having use cases written for a BDUF is not the best way to make users feel like the system is theirs. A lot more efficient way to achieve this would be to have the customers be involved in developing the system, writing tests and deciding which stories/features to build next.

    Well said!
    Ilja Preuss
    author
    Sheriff

    Joined: Jul 11, 2001
    Posts: 14112
    Originally posted by HS Thomas:
    Scope the work - discovering the scope of the system. Have three hundred or five hundred classes been discovered?

    An XP team estimates all the stories it's got. While you may use some weeks to get a first cut on the whole design and count classes to revise your estimates, an XP team would rather use the time to implement the first, most important stories and revise its estimates based on that experience.
    I think the latter is a more accurate way.
    BDUF should help in planning ahead, in getting the big picture upfront.
    Generate the user stories at the start as per XP , but take it further with a BDUF - this helps with estimating the user staff and skills required.

    After having discussed all the user stories, the team should already have some idea about the big picture. It also has already worked on the System Methaphor and possibly build some Architectural Spikes.
    I think that actually starting to build the system again gives you better feedback about staff and skills required than musing about it.
    At the same time also start with setting up Integration Testing and User Acceptance Testing Teams. A BDUFish model could help here

    Once again, I think that actually starting to set up integration and acceptance testing helps more than musing about it. You need a test? Write it. You need help? Get it.
    How do you stop other users/team members feeling that that they are left in the dark?

    By much direct communication. By delivering something working early and often.
    You need to create a Agile User environment also. A BDUF is something they can refer to.

    I'd think that most users actually understand a working system much better than UML diagrams.
    When I mentioned user manuals I also meant the CD-based ones.

    OK. As the articles suggested, especially the second one, those can be done incrementally, too. No BDUF necessary.
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    By much direct communication. By delivering something working early and often.

    Who communicates with the User. The developer ?
    One developer , many , many users. Is this single/pair developer(s) able to get adequate feedback from the many, many users.
    Or the deliverables, the CD-manual created along with the system
    and a User-training database created to help the user to :
    1) understand the system
    2) log their disagreements/misunderstandings with a tool like Rational ClearQuest.
    If it's left to the developers to communicate, the developers in effect train the users. Not an ideal situation.

    regards
    [ September 15, 2003: Message edited by: HS Thomas ]
    HS Thomas
    Ranch Hand

    Joined: May 15, 2002
    Posts: 3404
    Or alternatively, the system communicates to the users.
    What you see is what you get! WYSIWIG.
    What qualities should this feedback have -
    Developers train the users ONLY in how to use the system.
    Users should understand the business context of the system;
    if not consult one of their own peers.
    .........
    .........

    Thanks Illja and Lasse.


    regards
    [ September 15, 2003: Message edited by: HS Thomas ]
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: Big Design Upfront and XP refactorings