|
|
 | | From: | JoJo | | Subject: | Agile development | | Date: | Thu, 20 Jan 2005 15:50:23 GMT |
|
|
 | Hi, just been reading up on XP and the Agile methods. Can someone clarify a
few points for me?
The Agile way of working seems to stress that BUFRG and BUFD is bad bad
news, at that each stage of the project should be broken into subsets of
deliverables that can be tested agains reqs.
Is that right?
I'm a little confused as to how one decides how to split the whole project
into subsets if one hasn't done much upfront analysis - I mean how do you
know what youre doing so how can you split it up?
Also, if each subset is designed as and when it's coded, can this lead to a
mish mash of non-integrating modules, being as the big picture isn't being
considered? (or is it?)
Thanks for any input!
|
|
| | From: | Alexei A. Polkhanov | | Subject: | Re: Agile development | | Date: | Thu, 20 Jan 2005 12:56:10 -0800 |
|
|
| JoJo wrote:
>
> I'm a little confused as to how one decides how to split the whole project
> into subsets if one hasn't done much upfront analysis - I mean how do you
> know what youre doing so how can you split it up?
What do you mean by "split the whole project into subsets", if this is
Requirements Allocation then it should be performed during Architectural
Design phase. I don't think any "agile" method will allow you to skip
this step without losing integrity of the entire project.
You must have requirements prioritized and most important features
(those users won't accept product without) to be agreed upon. If you
cannot complete this step and user does not want to agree in principle
then prototype should be built or more research made.
Alexei.
>
> Also, if each subset is designed as and when it's coded, can this lead to a
> mish mash of non-integrating modules, being as the big picture isn't being
> considered? (or is it?)
>
> Thanks for any input!
|
|
| | From: | Ron Jeffries | | Subject: | Re: Agile development | | Date: | Sat, 22 Jan 2005 17:50:29 -0500 |
|
|
| On Thu, 20 Jan 2005 15:50:23 GMT, JoJo wrote:
>Hi, just been reading up on XP and the Agile methods. Can someone clarify a
>few points for me?
>
>The Agile way of working seems to stress that BUFRG and BUFD is bad bad
>news, at that each stage of the project should be broken into subsets of
>deliverables that can be tested agains reqs.
The focus is on doing requirements in business value order, which
means that as soon as you know what the most important ones, you can
start.
And the focus is on design as you go, not just design up front, which
means that we move to programming early, let the code participate in
our growing understanding of the design, and improve the design as we
learn.
>
>Is that right?
>
>I'm a little confused as to how one decides how to split the whole project
>into subsets if one hasn't done much upfront analysis - I mean how do you
>know what youre doing so how can you split it up?
One tends to split breadth-first rather than into silos. So if the
project is a blog, we get the ability to have articles up, all in a
row. Then more formatting; then the calendar, and so on.
If the project is a payroll, we pay simple checks first, then more
complicated ones, but always paying all the way from input to output.
In my experience, for most projects, someone who's interested in doing
a project knows "what it's about" very early on -- otherwise they
wouldn't be thinking of doing a project, they'd be wandering around
wondering what to do.
It's quite possible, using Agile approaches, to get a good enough view
of the requirements in a very short time. Not hours, but depending on
the project perhaps in days.
All this quite surprised me. I used to always be complaining about
customers who couldn't make up their minds, and wanting the
requirements nailed down before we started. Then I wanted time to
design.
Then I learned how to work one feature at a time, and how to grow a
design in concert with the code. Now I find that a better way to go
for a wide variety of reasons.
>
>Also, if each subset is designed as and when it's coded, can this lead to a
>mish mash of non-integrating modules, being as the big picture isn't being
>considered? (or is it?)
It is, because one is going breadth first in requirements, and because
one is ALWAYS looking at keeping the design in good shape.
It is, of course, possible to screw up either one of these. You could
have a really dumb set of ideas for what you want and that's not as
good as having really good ideas. Or you could pay too little
attention to the design, and let it get out of hand.
In practice, these things happen to a degree. But when you're shipping
real software every couple of weeks, the customer usually learns early
on that she has asked for the wrong stuff. And if you're not good
enough at design to realize when your design is going bad while you're
programming with it, my guess is that you're not good enough to think
up a design in your head either.
Let me turn that one around: if you're good enough to design on paper,
you're certainly good enough to design as you go.
It's also important to remember that these techniques work differently
depending on the size of the team, how closely sited they are, and a
host of other variables. The principles apply broadly, but like most
principles, the art is in the specific application, not just the broad
understanding.
Ask more questions ...
--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.
|
|
| | From: | Phlip | | Subject: | Re: Agile development | | Date: | Thu, 20 Jan 2005 20:39:11 GMT |
|
|
| JoJo wrote:
> Hi, just been reading up on XP and the Agile methods. Can someone clarify
a
> few points for me?
>
> The Agile way of working seems to stress that BUFRG and BUFD is bad bad
> news, at that each stage of the project should be broken into subsets of
> deliverables that can be tested agains reqs.
>
> Is that right?
Up-front design, meaning design without feedback from coding, is harmless.
Treating that design as official, and slavishly implementing it, causes
trouble.
To prevent trouble, write the highest priority features first, and deliver
these to users.
> I'm a little confused as to how one decides how to split the whole project
> into subsets if one hasn't done much upfront analysis - I mean how do you
> know what youre doing so how can you split it up?
By proceding in order of business priority. Everyone probably has a good
idea what this feature is and what its requirements are. If you attempt to
find requirements for feature X, and nobody knows how to describe it, then X
might be lower priority.
So "upfront" analysis continues until the case for new code is compelling.
Then you write the new code. After you see it working, you'l learn what the
next set of features should be.
> Also, if each subset is designed as and when it's coded, can this lead to
a
> mish mash of non-integrating modules, being as the big picture isn't being
> considered? (or is it?)
There are two cycles at work. The outer cycle is specifying and delivering
features. The inner cycle is writing those features.
You test the outer cycle by delivering to users (or their proxies).
Test the inner cycle by writing tests and running them after every 1~10
edits.
Write new tests before writing the code abilities that they test. Then
refactor to improve the design, but only change the code in tiny, testable
increments.
When individual lines of code are robust and easy to change, the system's
high level design becomes easy to rework. Instead of making drastic changes
to build healthy modules (and instead of avoiding such changes), small
incremental changes to the classes and methods will add up to well-balanced
modules.
Frequent refactoring reduces the odds of a major refactor. This permits
teams to add features at a very steady pace - and with a vanishingly small
defect rate - while continuously morphing the architecture to make room for
all the features.
--
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
|
|
|
