Home > Archive > Extreme Programming > September 2007 > Moving towards Extreme Programming
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Moving towards Extreme Programming
|
|
| dcadenas 2007-07-29, 4:03 am |
| I'm part of a workflow solution .Net development team. We are
currently on version 3.0 of our product so we have good experience on
this kind of product and we think we have a good understanding of what
our clients want in this kind of system.
Lately I started to get an increased interest in agile methodologies
in general. I've been studying on my own but  ly, as far as I know,
the company has no plan on adopting an agile development process.
Maybe I can convince them but first I want to be sure I'm convinced
and have a good understanding of its benefits.
I'm quite seduced by the idea of applying an agile methodology, I'm
specially interested in TDD, but I have some doubts concerning how
good would it fit to our kind of packaged product. More specifically,
my doubts are about requirements. Our requirements don't change a lot
as we are our own clients, we base the requirements mainly in what
users wanted from our product in the previous versions. So we have a
fixed set of requirements upfront and we don't interact with real
clients from outside our company.
So here are my questions:
1- For our scenario, wouldn't some XP practices like TDD imply
unnecessary extra work from the perspective of its ability to protect
against requirements change?
2- Are the other benefits of TDD (as a design method, documentation,
etc.) still strong enough to justify it's use in an almost "fixed
requirements" situation like ours.
3- In case I find that XP fits well in our company, does anyone of you
have experience on convincing your bosses about migrating to an agile
process. Tips?
Thanks a lot!
| |
| Jim Kingdon 2007-07-29, 8:02 am |
| > Our requirements don't change a lot as we are our own clients, we base
> the requirements mainly in what users wanted from our product in the
> previous versions.
In XP jargon, the "customer" in this context is generally the product
manager (whoever figures out which user requests to listen to, and how
to prioritize them). The XP literature says this entity speaks with
one voice, but mostly doesn't elaborate about how to make that so.
> 1- For our scenario, wouldn't some XP practices like TDD imply
> unnecessary extra work from the perspective of its ability to protect
> against requirements change?
I've never really thought of test-driven development as being all that
closely tied to requirements changes. To the extent that tests are
about protecting against change, it is just as relevant to think about
restructuring of the code (for example, if I try to make this function
faster, does it still work? If I add feature A, do I break related
feature B? If I make this code simpler, does it still handle all the
relevant cases? etc).
> 2- Are the other benefits of TDD (as a design method, documentation,
> etc.) still strong enough to justify it's use in an almost "fixed
> requirements" situation like ours.
The rationale behind the coining of the phrase "test-driven
development", as I understand it, is that this kind of test-writing is
applicable beyond XP or agile.
> 3- In case I find that XP fits well in our company, does anyone of you
> have experience on convincing your bosses about migrating to an agile
> process. Tips?
This has been done different ways, but in a nutshell there is the big
"let's change our process and adopt all of XP" way (most likely to
succeed if past processes are seen as a failure, and the company is
bringing in new blood in terms of developers/consultants/managers), or
the incremental way (maybe a developer writes a few tests but doesn't
show them to anyone else at first, or you set up a build server so
that checkins will at least compile, or maybe you start rotating
people from component to component if code ownership is seen as too
strong, or whatever first step seems to make sense).
| |
| Roy Smith 2007-07-29, 7:02 pm |
| dcadenas <dcadenas@gmail.com> wrote:
> 1- For our scenario, wouldn't some XP practices like TDD imply
> unnecessary extra work from the perspective of its ability to protect
> against requirements change?
TDD is a tool that can be easily factored out of any Agile methodology and
used by itself. All TDD says is whenever you want to write some code, you
should:
1) Write a test that fails
2) Write some code that makes the test pass
3) Make sure all your tests pass all the time
Where's the "extra work"? You've got to write unit tests anyway (you DO
have unit tests, don't you?). And you've got the write the code. TDD just
has you doing them in a different order, and enforces some discipline about
having all the tests pass all the time.
> 2- Are the other benefits of TDD (as a design method, documentation,
> etc.) still strong enough to justify it's use in an almost "fixed
> requirements" situation like ours.
What I generally do is a slight variation on the above:
1) Document a feature
2) Write a test which proves the just-documented feature works
3) Write some code that makes the test pass
4) Makes sure all my tests pass all the time
If nothing else, this guarantees that the documentation gets written. If
you're in a highly-structured environment which likes to formal
requirements tracing, you can fill in your traceability matrix as you
complete each feature.
> 3- In case I find that XP fits well in our company, does anyone of you
> have experience on convincing your bosses about migrating to an agile
> process. Tips?
It's easier to ask forgiveness than permission.
| |
|
| Free xxx vdeo thumbnails video
More videos here: free xxx video sites, video clips of porn, xxx video games, porn video store, adult video host, hardcore webcam sex, online adult video games, sexy cams, adult video superstore, screech porn video from Paula, adult video arcades |
|
|
|
|