Edmund Schweppe <schweppe@...> said:

>
> Dave Rooney wrote:
>
> > If I had a dollar for every time Ron wrote, "What would have
> > to be true to...", I could retire tomorrow! ;)
>
> Dang, the cost of living must be *much* lower in Canada than around my
> neck-o-the-woods. We still haven't even hit 100,000 messages (at least,
> according to http://groups.yahoo.com/group/extremeprogramming/).

Well, I'm cheap (but certainly not easy)! :)

> > I'm sorry if this group isn't what you're looking for, but we _are_
> > after all the Extreme Programming group.  Therefore, I would expect the
> > discussion to be pretty much about XP.  Once upon a time there was a
> > higher signal to noise ratio, and some people complained.
>
> Er, you did mean *lower* signal-to-noise ratio, did you not?

Uh, yes... that exactly what I wrote... can't you read!! :)

> > Since that time, the number of off-topic or questionable posts
> > has dropped considerably.
>
> Well, I guess I need to start making more cheap puns, then...

Limericks are good too... there once was a Software Architect from
Nantucket...

Dave Rooney
Mayford Technologies
http://www.mayford.ca

hi,
I'd be interested in the advantages (and maybe disadvantages) you see in
codinging the acceptance tests first. Coding unit tests first (TDD)  is very
good documented in the different XP-books but I can find nearly nothing about
test first and acceptance tests.
regards,
Christoph

--- In extremeprogramming@yahoogroups.com, "maps@g..." <maps@g...>
wrote:
>
> hi,
> I'd be interested in the advantages (and maybe disadvantages) you
see in codinging the acceptance tests first. Coding unit tests first
(TDD)  is very good documented in the different XP-books but I can
find nearly nothing about test first and acceptance tests.
> regards,
> Christoph

Writing tests first is a way of defining success in advance so that
attaining it is measurable.

Unit tests and acceptance tests have the same basic purpose at
different levels.

The customer tests are the specifications of your product. If a programmer
receives customer tests it is easier for her to derive and write the unit
tests and there is a lesser chance of her doing things she shouldn't have
done.

Moreover, in some cases the customer tests can replace the unit tests. It is
often the case you see a 1-1 mapping between CT and UT. In such cases we try
to do away with the UT... Remove duplication...

In

  Amir Kolsky
XP& Software


>-----Original Message-----
>From: maps@... [mailto:maps@...]
>Sent: Monday, November 01, 2004 9:41 AM
>To: extremeprogramming@yahoogroups.com
>Subject: [XP] write customer tests first
>
>
>
>hi,
>I'd be interested in the advantages (and maybe disadvantages)
>you see in codinging the acceptance tests first. Coding unit
>tests first (TDD)  is very good documented in the different
>XP-books but I can find nearly nothing about test first and
>acceptance tests.
>regards,
>Christoph
>
>
>
>
>
>
>To Post a message, send it to:   extremeprogramming@eGroups.com
>
>To Unsubscribe, send a blank message to:
>extremeprogramming-unsubscribe@eGroups.com
>
>ad-free courtesy of objectmentor.com
>Yahoo! Groups Links
>
>
>
>
>
>
>
>

On Monday, November 1, 2004, at 2:40:31 AM, maps@... wrote:

> I'd be interested in the advantages (and maybe disadvantages) you see in
codinging the acceptance tests
> first. Coding unit tests first (TDD)  is very good documented in the
> different XP-books but I can find nearly
> nothing about test first and acceptance tests.

This should make for an interesting discussion.

I feel strongly that I need the acceptance tests before I'm going to be
done programming: I want to run them to be sure that I've done what was
asked.

I get some real value from knowing before I start what a few of them will
be: it helps me shape my design and programming.

I do not generally get value from making one acceptance test work, then
another, then another, in the way that I do with unit tests. But this might
be a function of the particular tools I use, and of the fact that, working
mostly alone, I'd have to write the tests myself and it is usually easier
to write unit tests with the same "meaning". If the acceptance tests were
being fed to me, I might use them in the same kind of guiding way that I
use TDD unit tests now.

HOWEVER: when I do TDD, the test guides the code, and the code guides the
next test. Acceptance tests are kind of given from the outside. I could
/select/ the next test to do from the list, but I can't /create/ the next
test in the same way that I do with unit tests. That makes me suspect that
the inherent rhythm of customer-provided acceptance tests is always going
to be different from that of TDD with unit tests.

Let's see who else chimes in ...

Ron Jeffries
www.XProgramming.com
It is not the strongest of the species that survive, not the most intelligent,
but the one most responsive to change.  -- Charles Darwin

Hi,

We usually prepare a set of acceptance test cards for planning game. When
customer defines a user story we asked for a real example(s) of this story. We
write down these examples on Acceptance test cards. Later we can automate these
tests or simply add to manual check list for our testers, depending of the price
of the test automation.
I think idea is automating only affected acceptance tests, not all tests at
once. In any case we have them defined on paper.

Regards,
Alexander Fedorenko.
http://devplanner.com
DevPlanner - Improve Your estimating skills!

Monday, November 1, 2004, 2:01:34 PM, you wrote:


RJ> On Monday, November 1, 2004, at 2:40:31 AM, maps@... wrote:

>> I'd be interested in the advantages (and maybe disadvantages) you see in
codinging the acceptance tests
>> first. Coding unit tests first (TDD)  is very good documented in the
>> different XP-books but I can find nearly
>> nothing about test first and acceptance tests.

RJ> This should make for an interesting discussion.

RJ> I feel strongly that I need the acceptance tests before I'm going to be
RJ> done programming: I want to run them to be sure that I've done what was
RJ> asked.

RJ> I get some real value from knowing before I start what a few of them will
RJ> be: it helps me shape my design and programming.

RJ> I do not generally get value from making one acceptance test work, then
RJ> another, then another, in the way that I do with unit tests. But this might
RJ> be a function of the particular tools I use, and of the fact that, working
RJ> mostly alone, I'd have to write the tests myself and it is usually easier
RJ> to write unit tests with the same "meaning". If the acceptance tests were
RJ> being fed to me, I might use them in the same kind of guiding way that I
RJ> use TDD unit tests now.

RJ> HOWEVER: when I do TDD, the test guides the code, and the code guides the
RJ> next test. Acceptance tests are kind of given from the outside. I could
RJ> /select/ the next test to do from the list, but I can't /create/ the next
RJ> test in the same way that I do with unit tests. That makes me suspect that
RJ> the inherent rhythm of customer-provided acceptance tests is always going
RJ> to be different from that of TDD with unit tests.

RJ> Let's see who else chimes in ...

RJ> Ron Jeffries
RJ> www.XProgramming.com
RJ> It is not the strongest of the species that survive, not the most
intelligent,
RJ> but the one most responsive to change.  -- Charles Darwin




RJ> To Post a message, send it to:   extremeprogramming@eGroups.com

RJ> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com

RJ> ad-free courtesy of objectmentor.com
RJ> Yahoo! Groups Links

maps@... wrote:

> I'd be interested in the advantages (and maybe
> disadvantages) you see in codinging the acceptance
> tests first.

There are many people out there who went from
code-and-fix to "big analysis up front". Naturally
researching and thinking before doing is better than
code-and-fix...

But when we try to describe XP to them, they get stuck
on the parts that sound like "skip analysis and write
a test". We didn't say to skip analysis.

If you can't write a test, research why you can't.
Have we written any tests like this before? Can we
find a pair who knows how to do it? Maybe the customer
just turned a corner, and the team doesn't realize
this. Maybe we need to work, together, for a while, on
planning how to write infrastructure and fixtures for
this next kind of test.

That's analysis.

> Coding unit tests first (TDD)  is very
> good documented in the different XP-books but I can
> find nearly nothing about test first and acceptance
> tests.

IndustrialXP specifies that all userstories shall have
storytests. The more generic XP material just says
each userstory has a customer test, not necessarily
written first. IndustrialXP recommends writing it
first, because of the analytic effect, and because of
the rhythm it imparts to a team's progress.


=====
Phlip
   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

Amir Kolsky schrieb:

>The customer tests are the specifications of your product. If a programmer
>receives customer tests it is easier for her to derive and write the unit
>tests and there is a lesser chance of her doing things she shouldn't have
>done.
>
>Moreover, in some cases the customer tests can replace the unit tests. It is
>often the case you see a 1-1 mapping between CT and UT. In such cases we try
>to do away with the UT... Remove duplication...
>
>

Why donīt you remove the customer tests in these cases? OK, the customer
might not be very happy if the tests he wrote were removed... But we run
the unit tests much more often then the customer tests. In particular
when we release new code, we run all the unit tests on the integration
machine but not always all the customer tests. So wouldnīt it be saver
to keep the unit tests and replace the customer tests?

Christoph

maps@... wrote:

> I'd be interested in the advantages (and maybe disadvantages) you see in
codinging the acceptance tests first. Coding unit tests first (TDD)  is very
good documented in the different XP-books but I can find nearly nothing about
test first and acceptance tests.
> regards,
> Christoph

Hi Christoph,

We began experimenting with this approach a few years back and now find
it to be indispensable.  There was an article in Better Software
magazine that was all about what we call Storytest-Driven Development
(SDD) -- I just looked and it seems like they're charging for access to
that article.  It may be worth the price, as it interviews some of our
clients who've now been doing SDD on diverse projects (like on a
mainframe or for a datawharehouse).  It also interviews some of us who
have been actively using this technique.

Here's a graphic about SDD here:  http://www.industrialxp.org/storyTdd.html

When time permits, we'll put our latest SDD content (from our OOPSLA
tutorial) on the industrialxp.org site.

I have generally found that SDD

* helps a project community get clear about the boundaries of a story,
which, in turn, helps avoid finger pointing or the creation of many
defect stories

* helps us produce executable documentation -- which, in turn, helps
with auditors and certification folks

* helps us evolve a simpler design, as it clarifies what we don't need
our software to do

* helps us understand what we want to defer till later -- i.e. a
discovered detail of some story that is too sophisticated for this
iteration can be deferred to a later iteration

best regards,
jk

--
I n d u s t r i a l   L o g i c ,  I n c .
Joshua Kerievsky
Founder, Industrial XP Coach
http://industriallogic.com
http://industrialxp.org
866-540-8336 (toll free)
510-540-8336 (phone)
Berkeley, California

Jeff Grigg wrote:
> If I recall my Internet history correctly, the first Internet (ARPA
> Net) program and protocol packets was...  PING.  And it took them
> some effort to get that working.

See my .sig...

--George Paci

    The main reason that the Internet works at all is the existence of
    "ping". So build a "ping" thing into your systems.
          -- John Carter (the one in New Zealand)

Dakshinamurthy Karra wrote:
> On Fri, 29 Oct 2004 15:46:51 -0400, J. B. Rainsberger
> <jbrains@...> wrote:
>
>>I found that quite clear.
>
> Looks like more of an expectation-gap. See my reply to Ron's mail.

It looks like you were expecting an answer other than "I see no problem
here." :) What if that's really the answer?

>>The most common technical hurdle is the ability to deliver a product
>>incrementally. If you cannot figure out how to deliver your product
>>incrementally without exorbitant cost -- either in materials or
>>resources -- then you will find XP difficult to do "by the book".
>
> What do we do in this case? Do we have examples of such cases? In each
> case can we have a compensatory-practice that can be used?

The only examples I have ever heard of pertain to working with hardware
construction (airplanes, for example), rather than software
construction. Software, being soft, admits to incremental delivery, as
long as we're able to start from scratch. Even if we can't, the
Strangler Application pattern is a way to deliver a greenfield
replacement of a legacy application in incremental fashion. One of the
things about software is that we can always deliver it incrementally.

The way I see it, the big question is whether the customer is willing to
take their software in increments. If not, then we lose much of the
value of incremental delivery, that being feedback from real users. I
have seen cases where the customer is unwilling to take their software
in increments, but not where we weren't able to deliver it incrementally
in a useful way. Of course, this issue is a social one, and not a
technical one.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Predictable, repeatable, quality delivery

[Crossposted to XPlorations]

"Customer Value": Customers (product owners...) are told to select
stories according to what's most valuable. We can consider both
short- and long-term value.
http://xp123.com/xplor/xp0410/

Best Fit! - a framegame
Steve Metsker and I formulated this as a framegame - a game where
you can plug in the teaching content. We shared it as part of a
session on framegames at OOPSLA last month.
http://xp123.com/g4p/0410b/ - Best Fit!
http://xp123.com/conf/ - Other material from OOPSLA '04

I've also added a few book reviews:
- Agile Project Management with Scrum
- Marketing High Technology
- The Agile Manager's Guide to Coaching to Maximize Performance
http://xp123.com/books/

--
    Bill Wake  William.Wake@...  www.xp123.com
    NASAGA starts this week in Washington, DC - see nasaga.org

It depends!

Sometimes the acceptance tests can be defined before hand, sometimes the
acceptance tests have to be evolved as you work on a story.  As long as the
customer is involved during the process I don't think it makes much
difference.  As long as you do them before moving on (made that mistake
already...).  If your using FIT you can start your acceptance test by making
notes about what you want to achieve then filling it out with your tables as
your code evolves.

The problem I have with acceptance tests first is it assumes you know the
answer before doing any work.  Sometimes you do.  Sometimes acceptance is
defined in very fuzzy terms and you need to have a play with things before
you can nail down what is achievable and then what's your criteria for
acceptance.

Regards,

Keith

> -----Original Message-----
> From: Ron Jeffries [mailto:ronjeffries@...]
> Sent: Tuesday, 2 November 2004 1:02 a.m.
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] write customer tests first
>
>
> On Monday, November 1, 2004, at 2:40:31 AM, maps@... wrote:
>
> > I'd be interested in the advantages (and maybe
> disadvantages) you see
> > in codinging the acceptance tests first. Coding unit tests
> first (TDD)
> > is very good documented in the different XP-books but I can find
> > nearly nothing about test first and acceptance tests.
>
> This should make for an interesting discussion.
>
> I feel strongly that I need the acceptance tests before I'm
> going to be done programming: I want to run them to be sure
> that I've done what was asked.
>
> I get some real value from knowing before I start what a few
> of them will
> be: it helps me shape my design and programming.
>
> I do not generally get value from making one acceptance test
> work, then another, then another, in the way that I do with
> unit tests. But this might be a function of the particular
> tools I use, and of the fact that, working mostly alone, I'd
> have to write the tests myself and it is usually easier to
> write unit tests with the same "meaning". If the acceptance
> tests were being fed to me, I might use them in the same kind
> of guiding way that I use TDD unit tests now.
>
> HOWEVER: when I do TDD, the test guides the code, and the
> code guides the next test. Acceptance tests are kind of given
> from the outside. I could /select/ the next test to do from
> the list, but I can't /create/ the next test in the same way
> that I do with unit tests. That makes me suspect that the
> inherent rhythm of customer-provided acceptance tests is
> always going to be different from that of TDD with unit tests.
>
> Let's see who else chimes in ...
>
> Ron Jeffries
> www.XProgramming.com
> It is not the strongest of the species that survive, not the
> most intelligent, but the one most responsive to change.  --
> Charles Darwin
>
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>

>
> Accountability is a form of trustworthiness. If I am willing to be
> accountable for my use of family money, then my spouse can trust me
> to use it wisely. She needn't spend time worrying about what I'm
> doing with our money. If I constantly come back with, "I took out
> $200 on Wednesday and it's just gone. I don't know what I spent it
> on." then she shouldn't trust me to spend our money wisely.
>
That is interesting you should bring this example up.  In my
household the "rule" is if you spend more than $100 you have to ask.
Anything less than $100 you are free to spend on your own.  There is
also an expectation that if your are going to spend over $75, you
should inform the other person before the purchase.

I wonder how that might fit into this discussion?

Carlton

Ron Jeffries schrieb:

>I get some real value from knowing before I start what a few of them will
>be: it helps me shape my design and programming.
>
>
>
To me the unit tests are a kind of design tool when written first. I īm
not sure if the acceptance tests also shape my design as the unit tests
do. They rather seem to give me a rough direction. This might be due to
the tools I use: Acceptance tests mostly are GUI tests in my case.

>HOWEVER: when I do TDD, the test guides the code, and the code guides the
>next test. Acceptance tests are kind of given from the outside. I could
>/select/ the next test to do from the list, but I can't /create/ the next
>test in the same way that I do with unit tests. That makes me suspect that
>the inherent rhythm of customer-provided acceptance tests is always going
>to be different from that of TDD with unit tests.
>
>
This is a very interesting point. I could imagine that only the cycles
of the rhythm are longer: When the customer gets his program after an
iteration this will inspire him to write new acceptance tests (user
stories).

Christoph

Hi Josh,

> There was an article in Better Software magazine that was all
> about what we call Storytest-Driven Development (SDD) -- I
> just looked and it seems like they're charging for access to
> that article.  It may be worth the price, as it interviews
> some of our clients who've now been doing SDD on diverse
> projects (like on a mainframe or for a datawharehouse).  It
> also interviews some of us who have been actively using this
> technique.

Could you post a copy on your site?  Did you give Better Software
exclusive rights to the article, or only first publication rights?

Dale

--
Dale Emery, Consultant
Collaborative Leadership for Software People
Web:    http://www.dhemery.com
Weblog: http://www.dhemery.com/cwd

A true gentleman is a man who knows how to play the bagpipes--but
doesn't. --Anonymous

Madson Menezes wrote:

> Hy everyone!
> A friend of mine are working with the problem of introduce usability
> process in a agile methodology (XP in first place) . These two things
> have a lot of principles which have the same concept.
> Had any of you work with that??

There was a nice workshop at IBM CASCon in Toronto in October entitled
"Agile and UCD". You might wish to contact Dr. Frank Maurer at the
University of Calgary for more information about the workshop and his
interests. Frank might even be looking in on this group from time to
time, although I haven't seen him here recently.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Predictable, repeatable, quality delivery

--- In extremeprogramming@yahoogroups.com, "maps@g..." <maps@g...> wrote:
>
> hi,
> I'd be interested in the advantages (and maybe disadvantages) you
see in codinging the acceptance tests first. Coding unit tests first
(TDD)  is very good documented in the different XP-books but I can
find nearly nothing about test first and acceptance tests.
> regards,
> Christoph

The White Book doesn't make a clear distinction
between programmer tests and customer tests;
they're both covered under testing, and they're
both described as test first.

The sharp distinction came later, I believe
that Ron Jeffries started making it. That
distinction let us codify the development
loop as Test Driven Development (TDD) by
removing customer tests.

It also brought test tools like FIT and
FitNesse for customer tests.

As most of the leading lights say, the Customer
Tests ***ARE*** the requirements document.
Writing them after the code is the same as
documenting your requirements after writing
the program. It doesn't work nearly as well
as documenting them beforehand.

Treating them as the formal requirements
document also gives you some interesting
insights.

John Roth

maps@... wrote:
>
> I'd be interested in the advantages (and maybe disadvantages) you see in
codinging the acceptance tests first. Coding unit tests first (TDD)  is very
good documented in the different XP-books but I can find nearly nothing about
test first and acceptance tests.
> regards,

On my perfect project, some Customer Tests are available before we start
building the feature in question. Presumably someone with programming
skill who works closely with the Customer helps her build those tests.
(Customer defines, programmer builds.) These are enough tests for us to
get the basics of the feature done.

In the meantime, on that same perfect project, Testers look at the
Customer Tests and identify holes where business value can leak out.
They work with the Customer to decide how best to plug those leaks,
resulting in additional tests, either Customer Tests or Programmer
Tests, depending on their nature.

One strong downside to this approach is a tendency for some people to
confuse the goals of Customer Tests with Programmer Tests. Programmer
Tests are meant mostly to test individual objects against collaborating
interfaces. Boundary conditions, exceptional conditions, these should
all be covered with Programmer Tests. Customer Tests are meant to be
examples of how the features will be used and should behave, and so
perhaps are not the best vehicle for doing all kinds of testing
(boundary conditions, exceptional conditions, load, performance,
security). If one writes the Customer Tests first and stops there, one
runs the risk of essentially writing highly-detailed end-to-end tests,
which suffer from the combinatoric explosion problem that Programmer
Testing techniques like interface richness and test isolation are
designed to avoid.

Aside from that, I haven't seen serious problems with writing Customer
Tests first.
--
J. B. (Joe) Rainsberger
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Predictable, repeatable, quality delivery

J. B. Rainsberger wrote:

>One strong downside to this approach is a tendency for some people to
>confuse the goals of Customer Tests with Programmer Tests. Programmer
>Tests are meant mostly to test individual objects against collaborating
>interfaces.
>
Is that a downside?  Or is it like saying that one strong downside of
unit tests (a.k.a. Programmer tests) is that people tend to use them
like storytests (a.k.a. Customer tests) when they just don't know
better?

>Boundary conditions, exceptional conditions, these should
>all be covered with Programmer Tests. Customer Tests are meant to be
>examples of how the features will be used and should behave, and so
>perhaps are not the best vehicle for doing all kinds of testing
>(boundary conditions, exceptional conditions, load, performance,
>security).
>
Isn't that too strict? In practice, I see more of a mix.  For example,
some boundary conditions help define essential boundaries of a story and
clarify those boundaries for  people within a project community.  Other
boundary conditions aren't useful to expose in storytests, so unit tests
provide a better place to express them.

>If one writes the Customer Tests first and stops there, one
>runs the risk of essentially writing highly-detailed end-to-end tests,
>which suffer from the combinatoric explosion problem that Programmer
>Testing techniques like interface richness and test isolation are
>designed to avoid.
>
>
Can you give an example?

>Aside from that, I haven't seen serious problems with writing Customer
>Tests first.
>
>
What problems have you run into when you haven't written them first?

best
jk

On Sat, 30 Oct 2004 07:08:14 -0400, Ron Jeffries
<ronjeffries@...> wrote:
> But perhaps you are asking something like "What technical obstacles get in
> the way of the practices," rather than "What stops you entirely from doing
> XP." Is that the case? Are you asking what kinds of things interfere rather
> than what are reasons that ultimately cause you not to do XP? Here's an
> example one might write about obstacles:
I dont think I can put it any better than this. Thanks.

> You might think that you can't practice TDD if you are using languages like
> ASP or HTML that aren't like ordinary executable languages. However, you
> can use executable languages to test these languages, or even mechanically
> inspect the output text in the case of HTML.
>
Do we need any cost-benifit analysis in this case. Specifically for
output that is renedered on screen, is it better to ignore TDD and
rely more and heavily on test automation, even when TDD is possible,
We have two major projects one using JFCUnit to write UTs for GUI and
another doesn't test at the UI level. When I look at the bug reports
from these projects, what strikes me is that at the GUI level there
are not many bugs reported on both the projects. We automate the
customer tests using Marathon (it is a Java/Swing app on the client
side) and It is my belief that most of the bugs are being captured at
that level and fed back to the development teams. What are other's
experiences with these cases? What do others suggest?

> Is that the sort of thing you had in mind?
Yes. Thanks again.

This is what I have in mind - as far as I get opinions on these issues
I dont want to say "any XP practice is technically in-feasible" ;-)

Can you throw some light on similar veins on other practices also?

KD
--
Dakshinamurthy Karra
CTO, Subex Systems Ltd.(http://www.subexsystems.com)

Keith Nicholas wrote:

>The problem I have with acceptance tests first is it assumes you know the
>answer before doing any work.  Sometimes you do.  Sometimes acceptance is
>defined in very fuzzy terms and you need to have a play with things before
>you can nail down what is achievable and then what's your criteria for
>acceptance.
>
>
Is the "playing" you're talking about different from doing a spike?
Spikes often help us learn more about fuzzy criteria that we can use
during story acceptance.  --jk

On Sat, 30 Oct 2004 13:58:22 -0700, William Pietri <william@...> wrote:
> I agree that you can do it in situations where the code is small and
> short-lived, but my gut feel is that below some threshhold, it's not
> worth doing XP in a full-on fashion. I tried this experiment recently
> writing the engine for this site:
>
>     http://www.us-election.org/
>
> I'll write the results of my experiment up soon, but I found I happily
> got away with trimming a fair bit of what I'd do in a full XP context.
>
I disagree with this. IMHO any code delivered to a customer is worth
going through the rigors of XP processes. YMMV.
>
> Interesting. You were doing full-on standard XP with 4 teams on the same
> code with no additional planning or development practices? I'd be
> interested to hear more about this, especially regarding how work was
> allocated, how cross-team integration was managed, how responsibility
> for particular code was determined, and how long the project ran.
>
Unfortunately, I dont have the gift of gab that some others on this
list have. Hopefully, at some time I can give full details. The
contributing factors to achieve this are plenty (and some of them are
nothing to do with XP). I will list out what IMO are important points:
1. The teams themselves are small in size. Two teams have 9 developers
and other two have 5 developers each.
2. All the teams have developers who worked on the code base.
3. The "collective ownership" trascended the team boundaries in this
particular case as due to reorganization of the teams, most members
belonged to another team earlier.
4. All customer tests are automated and run atleast daily by testers
belonging to each of the teams. Any broken test is immediately known.
5. Some teams are working on customizations to existing features and
some teams are working on adding new features. They *do* step on each
others toes.
6. The most important factor is the concept of "sync point". Each team
considered the last half day of their iteration (they are 2 week
iterations) as sync point. At the end of that day it was mandated that
all the customer tests for completed stories should be run 100
percent. In quite a few cases, other teams held back their changes for
a while (not very long) to ensure that the team that is completing an
iteration can achieve their sync point.

As an aside, the project was running like this for the last six months
and currently has only two teams (of 9 developers each) working on the
code base. This is not considered as a standard practice, only that
the need at that point in time forced us into this. The only change to
the standard practices was the idea of "sync point" and it worked for
us.

Thanks and Regards
KD

--
Dakshinamurthy Karra
CTO, Subex Systems Ltd.(http://www.subexsystems.com)

>Why donīt you remove the customer tests in these cases? OK,
>the customer might not be very happy if the tests he wrote
>were removed... But we run the unit tests much more often then
>the customer tests. In particular when we release new code, we
>run all the unit tests on the integration machine but not
>always all the customer tests. So wouldnīt it be saver to keep
>the unit tests and replace the customer tests?
>

>Christoph

First of all, a phrase like "the cutomer might not be happy" isn't part of
our vernacular. You cannot have members of your community unahppy in XP, at
least not for long.

So, why is the customer unhappy?

The customer is unhappy because you did away with his specifications. You
did away with his way of ensuring that the product he needs is what he gets.

Remember - A story is complete when the story test passes. This is the proof
of acceptance by the customer. If the test passes the customer can't
complain that what you did was wrong. He may change his mind, or expand on
the original story, but this will be accompanied by revised or new story
tests.

So how do you use these customer tests to guide the design, like you do with
unit tests? Well, to begin with there's the issue of the test fixtures that
exercise your code in the story tests. These can be tied to the unit testing
framework so that when the unit tests run, they actually execute the story
tests. Secondly, if there are things that you know that you need to assert
in the unit tests and are not customer issues and hence have no place in the
story tests (For example, ensuring that files are closed), you can build
your story test fixture to allow you to make these assertions.

What we usually see is that we start developing with story tests to guide
our unit tests. In some cases we see that the unit tests are exactly like
the story tests in these cases we fold the unit testing functionality into
the story test fixture.

The reason why to split the two is that you, as the developer, have insight
into your code. A complicated customer test, given the current design of
your system may be a simple unit test for you, so the two are not the same.

Anyway, you should never have your customer unahppy. You're the developer,
if you want to do away with something, do away with the unit tests, not the
story tests.

Amir
Xpand Software...

On Thursday, Nov. 18th we're pleased to host Colin Sampaleanu from
Interface21 (http://www.interface21.com) in Toronto.  He's one of the
authors of the open source Spring framework
(http://www.springframework.com), and will be presenting an overview of
Spring.

The meeting will take place at the Sybase Canada offices in Kanata at
6:30 PM.  I'll provide the specific location details shortly.

Hope to see you all there!

Dave Rooney
Mayford Technologies
http://www.mayford.ca

Kay,

On Sat, 30 Oct 2004 16:20:30 -0400, Kay Pentecost
<tranzpupy@...> wrote:
> The question itself manipulates the answer, and the direction of attention.
Thanks for the clarification. I hope my coding is better than my english ;-)

KD
--
Dakshinamurthy Karra
CTO, Subex Systems Ltd.(http://www.subexsystems.com)

On Mon, 01 Nov 2004 14:19:43 -0500, J. B. Rainsberger
<jbrains@...> wrote:
> It looks like you were expecting an answer other than "I see no problem
> here." :) What if that's really the answer?
>
I am old enough ;-)

-- KD

--
Dakshinamurthy Karra
CTO, Subex Systems Ltd.(http://www.subexsystems.com)

On Monday, November 1, 2004, at 2:52:11 AM, Kent Beck wrote:

> Yes, you trust your team. But, you don't trust blindly. You work based
> on faith until you acquire experience. You build trust based on
> experience. Accountability is one of the most effective means to this
> end.

It is. And I'd like to have the team know what they spent their time on.
And I'm in no sense opposed to estimating how much working time is involved
in some story -- I think it's the most effective way to estimate.

It has the advantage that it can't drift against past estimates. I used to
be able to estimate what I could do in a day, now I still can. What I can
do is different, but the units are the same. A "one" a year ago, and a
"one" now? Don't know.

However ...

> Accountability is a form of trustworthiness. If I am willing to be
> accountable for my use of family money, then my spouse can trust me to
> use it wisely. She needn't spend time worrying about what I'm doing with
> our money. If I constantly come back with, "I took out $200 on Wednesday
> and it's just gone. I don't know what I spent it on." then she shouldn't
> trust me to spend our money wisely.

I think it's good to know where the money is going. I don't think it's good
to have the spouse demand reporting, or even need or want it. That's not
trust, it's something else.

> You can't control whether someone trusts you, but you can control
> whether you are trustworthy. Accountability is one way to demonstrate
> trustworthiness.

Yes. And sometimes we do need to demonstrate trustworthiness. Maybe we
should consider that need to be a process smell, a relationship smell. It's
good to know where the time went. I'm not comfortable with the general need
to be producing that accounting for others.

Ron Jeffries
www.XProgramming.com
Accroche toi a ton reve.  --ELO

On Mon, 01 Nov 2004 21:03:31 -0000, Bill Wake <william.wake@...> wrote:
>
>
> [Crossposted to XPlorations]
>
> "Customer Value": Customers (product owners...) are told to select
> stories according to what's most valuable. We can consider both
> short- and long-term value.
> http://xp123.com/xplor/xp0410/
>
> Best Fit! - a framegame
> Steve Metsker and I formulated this as a framegame - a game where
> you can plug in the teaching content. We shared it as part of a
> session on framegames at OOPSLA last month.
> http://xp123.com/g4p/0410b/ - Best Fit!
> http://xp123.com/conf/ - Other material from OOPSLA '04
>
> I've also added a few book reviews:
> - Agile Project Management with Scrum
> - Marketing High Technology
> - The Agile Manager's Guide to Coaching to Maximize Performance
> http://xp123.com/books/
>
> --
>    Bill Wake  William.Wake@...  www.xp123.com
>    NASAGA starts this week in Washington, DC - see nasaga.org
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>
>

The message contains Unicode characters and has been sent as a binary
attachment.



[Non-text portions of this message have been removed]