Hi,

Am I correct in thinking that in the exploration phase of iteration planning,
not only does the
team write task cards for stories, but it also writes tasks to things that must
be done to support
the iteration? In KB's Extreme Programming Explained Kent mentions these types
of tasks.  I am
thinking that when the developers sit down to decompose the stories into tasks,
they will consider
what is required to support the development effort.  If a technical issue
arises, then it must be
factored into the planning, and thus a task card is created for it.

Is that the general gist?

Thanks,

Nick.

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Nicholas Robinson <nicholasrobinson@y...> wrote:
> Another subsequent question was how does XP cope with frameworks
> on a project that has none and needs one?

On an XP project, if a framework is needed, it will slowly appear over time.
If no framework appears, it wasn't needed.


Erik Hanson

--- In extremeprogramming@yahoogroups.com, Nicholas Robinson
<nicholasrobinson@y...> wrote:
>
> The framework question came from one of the workshop attendees.
  I believe he was alluding to the notion that for whatever
reason, a project may need a framework, but he couldnt see how
that would be estimated into story cards.  Maybe he meant that
some projects have a set of data access support, a logging
service, security, yada yada yar.
> The organization were we are working isnt an XP shop, so the
question could be from an understanding that will change as more
XP is introduced during our workshops.
> Nick.
>  "Kiel Hodges <kielhodges@m...>" <kielhodges@m...> wrote:--- In
extremeprogramming@yahoogroups.com, Nicholas Robinson
> wrote:
> > ...
> > Another subsequent question was how does XP cope with
frameworks
> on a project that has none and
> > needs one?
>
> Could you explain why a project would need a framework?

I had envisioned this lovely Socratic dialogue that would
elegantly lead to a beautiful explanation of the XP way! Oh,
well. :-(

A project never really needs a framework per se. Instead, the
software needs to accomplish certain things and the code should
be well factored with no duplication and with relevant concepts
nicely represented. Perhaps that /implies/ a framework (or
perhaps not) but the need is explicitly for a framework.

Say we have an implied need for a "framework", perhaps one for
object persistence. Now XP doesn't preclude us from thinking
about what the general shape of the software might be. We might
decide that we would have some sort of data access layer with a
Persistence facade, which behind the scenes uses XML
configuration files to determine which DataAccessObjects should
handle specific requests, blah, blah, blah.

Ok, we did some thinking. Now let's do some real work and try not
to let that thinking get in our way. If it's real work, then it's
work directly contributing to the completion of a current story.
Hmmm, we don't have any stories requiring object persistence this
iteration. Thinking about persistence at all will get in our way,
so let's not think about it.

Skip ahead to the next iteration. Hey, we have a story where we
have to persist a WhizBang object! Let's think just a little bit.
We figured we would have this facade and it would have a store
method. Does that still sound good? Great! We have a task to
create a Persistence facade with a store method that can store a
WhizBang.

Now we do that task, doing just enough to make it work and leave
the code in good shape. We don't worry about that XML file,
because we don't need it for this story. We don't worry about
DataAccessObjects. After all, we're only persisting a single kind
of object.

Ship ahead again. Now we're persisting a FooBar object. First, we
do the simplest thing we can think of to get it to work. That
leads us to an if statement that checks the class of the object
we're persisting to decide which path to take. It's ugly, but we
just want to get the tests to pass at first.

When the tests pass, we turn to refactoring. We now are focused
on the code /being/ the simplest code that passes the tests.
Being rabid OO people, if statements make our heads hurt and just
don't seem simple. This looks like a job for polymorphism! Making
small steps, we end up with the facade delegating to a
DataAccessObject. We have two implementations: WhizBangDao and
FooBarDao. How do we determine which to use? Well, we have a
method that returns a DataAccessObject for a given object. It
uses an if statement, but it's so simple that our heads don't
hurt.

Skip ahead some more. We're implementing persistence for yet
another kind of object. The method that produces the DAO to use
for a given object doesn't seem so simple anymore. Maybe we
should do that XML thing we talked about some time ago. Otoh, XML
parsing is such a pain and all we really need is to map a class
name to DAO class name. Let's just use a Properties file!


Step by step, we're evolving what some people might call a
framework. We thought about what it might look like up front, but
we actually built it by responding to the needs of current
stories and by refactoring. Some of the things we thought we
would do, we actually did; others we never did or did in a
different way. The framework does what we actually need, not what
we thought it would need.

This approach has another very important advantage: we delivered
business functionality throughout the project. We didn't make the
customer wait six weeks while we developed frameworks we were
going to need. We delivered stuff they could actually use.


Well, this certainly wasn't elegant, but hopefully you will find
it useful.

Kiel Hodges
SelfSo Software

>
> When the initial planning takes place with the business/customer,
and it is in this same meeting
> that some of the user stories are fleshed out, how is it feasible
to give estimates?  This was
> asked of me in my last workshop.  We were walking through the
stories and needed some estimates.
> Nobody felt confident until the following had been produced:
>
> 1. Domain models
> 2. Some high-level sequence diagrams
> 3. An appreciation of the architecture required
>
> Another subsequent question was how does XP cope with frameworks on
a project that has none and
> needs one?
>
I know this is COMPLETELY a stupid question, but I will ask.  Can you
please define what you mean by "domain models" and "high-level
seqeunce diagrams"?  I have an idea what you mean, but those exact
phrases are just not in my vocabulary.

How do you know the project NEEDS a framework?  Or are you imagining
based on your experience with similar projects, there will be a
framework?  On this current project I am working on, it certainly
could have been argued that a framework was needed and I had an idea
what that framework would look like.  However, I let the customer
drive the development and added framework architecture as the
development needed it.

One framework item I thought I needed, but the customer did not, was
the ability to create a dynamic lefthand navigation for the
customer's website.  I was imagining a dynamic ordering of a dynamice
number of items with view permissions for each item based on access
levels.  In addition, the customer could either use a text link or a
upload an image for the link.  As it turns out, the customer was
completely happy for 8 months with a static navigation of simple link
buttons.  Now, as the project has grown in complexity, the ability to
turn on and off lefthand navigation is needed.  We still do not need
dynamic number of items, dynamic ordering, or view permissions based
on access levels.

Thats what I thought.  So if no framework exists yet the team need a
consistent mechanism for the data access layer, how would this be factored
in?  Not sure if that makes sense.  i am currently working on a project that
means I have to use the framework that gets built.  The framework has been
built as a separate project, but I dont think thats how it would happen with
XP.  When I say separate project, I mean we have the main project, project
X, and there is a band of programmers working on the framework for project
X.

Nick.

-----Original Message-----
From: Erik Hanson [mailto:yahoogroups@...]
Sent: 28 February 2003 15:13
To: extremeprogramming@yahoogroups.com
Subject: Re: [XP] Re: Initial Planning and Metaphor


Nicholas Robinson <nicholasrobinson@y...> wrote:
> Another subsequent question was how does XP cope with frameworks
> on a project that has none and needs one?

On an XP project, if a framework is needed, it will slowly appear over time.
If no framework appears, it wasn't needed.


Erik Hanson



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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Kiel, thats very useful.  I am sure when we discussed this, we kinda thought
that that is how it must happen in XP, given all the principles.
Now, when i think more about the original question I need to dig deep for
asking why would one want a framework.  One reason is that there are
different ways for doing DB persistence, and the team lead may wish to have
it done one way and everybody else uses the pattern.  That way, if there are
weak people in the team (in relation to DB persistence say), then its
covered.  Its consistent.  If you have strong minds with different ideas for
implementation (lets say one wishes to ignore the DB and use a pure domain
model while another wishes to use recordsets for example), then creating a
defacto framework is one way of saying, "This is how you do DB persistence".

Thanks for your reply - its a good answer.  One question.  If two
programmers start work on stories but both need to persist their objects,
how do you deal with that in XP? So I want to build the story that requires
wizzbang and you are doing foobar.  Both of us need the facade code you
mentioned.  This is no different to normal world of development, but I am
curious on how XP would deal with this.  Maybe there is something it
advises.

Thanks Kiel,

Nick.
-----Original Message-----
From: Kiel Hodges <kielhodges@...>
[mailto:kielhodges@...]
Sent: 28 February 2003 15:39
To: extremeprogramming@yahoogroups.com
Subject: [XP] Re: Initial Planning and Metaphor


--- In extremeprogramming@yahoogroups.com, Nicholas Robinson
<nicholasrobinson@y...> wrote:
>
> The framework question came from one of the workshop attendees.
  I believe he was alluding to the notion that for whatever
reason, a project may need a framework, but he couldnt see how
that would be estimated into story cards.  Maybe he meant that
some projects have a set of data access support, a logging
service, security, yada yada yar.
> The organization were we are working isnt an XP shop, so the
question could be from an understanding that will change as more
XP is introduced during our workshops.
> Nick.
>  "Kiel Hodges <kielhodges@m...>" <kielhodges@m...> wrote:--- In
extremeprogramming@yahoogroups.com, Nicholas Robinson
> wrote:
> > ...
> > Another subsequent question was how does XP cope with
frameworks
> on a project that has none and
> > needs one?
>
> Could you explain why a project would need a framework?

I had envisioned this lovely Socratic dialogue that would
elegantly lead to a beautiful explanation of the XP way! Oh,
well. :-(

A project never really needs a framework per se. Instead, the
software needs to accomplish certain things and the code should
be well factored with no duplication and with relevant concepts
nicely represented. Perhaps that /implies/ a framework (or
perhaps not) but the need is explicitly for a framework.

Say we have an implied need for a "framework", perhaps one for
object persistence. Now XP doesn't preclude us from thinking
about what the general shape of the software might be. We might
decide that we would have some sort of data access layer with a
Persistence facade, which behind the scenes uses XML
configuration files to determine which DataAccessObjects should
handle specific requests, blah, blah, blah.

Ok, we did some thinking. Now let's do some real work and try not
to let that thinking get in our way. If it's real work, then it's
work directly contributing to the completion of a current story.
Hmmm, we don't have any stories requiring object persistence this
iteration. Thinking about persistence at all will get in our way,
so let's not think about it.

Skip ahead to the next iteration. Hey, we have a story where we
have to persist a WhizBang object! Let's think just a little bit.
We figured we would have this facade and it would have a store
method. Does that still sound good? Great! We have a task to
create a Persistence facade with a store method that can store a
WhizBang.

Now we do that task, doing just enough to make it work and leave
the code in good shape. We don't worry about that XML file,
because we don't need it for this story. We don't worry about
DataAccessObjects. After all, we're only persisting a single kind
of object.

Ship ahead again. Now we're persisting a FooBar object. First, we
do the simplest thing we can think of to get it to work. That
leads us to an if statement that checks the class of the object
we're persisting to decide which path to take. It's ugly, but we
just want to get the tests to pass at first.

When the tests pass, we turn to refactoring. We now are focused
on the code /being/ the simplest code that passes the tests.
Being rabid OO people, if statements make our heads hurt and just
don't seem simple. This looks like a job for polymorphism! Making
small steps, we end up with the facade delegating to a
DataAccessObject. We have two implementations: WhizBangDao and
FooBarDao. How do we determine which to use? Well, we have a
method that returns a DataAccessObject for a given object. It
uses an if statement, but it's so simple that our heads don't
hurt.

Skip ahead some more. We're implementing persistence for yet
another kind of object. The method that produces the DAO to use
for a given object doesn't seem so simple anymore. Maybe we
should do that XML thing we talked about some time ago. Otoh, XML
parsing is such a pain and all we really need is to map a class
name to DAO class name. Let's just use a Properties file!


Step by step, we're evolving what some people might call a
framework. We thought about what it might look like up front, but
we actually built it by responding to the needs of current
stories and by refactoring. Some of the things we thought we
would do, we actually did; others we never did or did in a
different way. The framework does what we actually need, not what
we thought it would need.

This approach has another very important advantage: we delivered
business functionality throughout the project. We didn't make the
customer wait six weeks while we developed frameworks we were
going to need. We delivered stuff they could actually use.


Well, this certainly wasn't elegant, but hopefully you will find
it useful.

Kiel Hodges
SelfSo Software


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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

> -----Original Message-----
> From: banshee858 <cnett858@...> [mailto:cnett858@...]
> Sent: 28 February 2003 16:09
> To: extremeprogramming@yahoogroups.com
> Subject: [XP] Re: Initial Planning and Metaphor
>
>
> >
> > When the initial planning takes place with the business/customer,
> and it is in this same meeting
> > that some of the user stories are fleshed out, how is it feasible
> to give estimates?  This was
> > asked of me in my last workshop.  We were walking through the
> stories and needed some estimates.
> > Nobody felt confident until the following had been produced:
> >
> > 1. Domain models
> > 2. Some high-level sequence diagrams
> > 3. An appreciation of the architecture required
> >
> > Another subsequent question was how does XP cope with frameworks on
> a project that has none and
> > needs one?
> >
> I know this is COMPLETELY a stupid question, but I will ask.  Can you
> please define what you mean by "domain models" and "high-level
> seqeunce diagrams"?  I have an idea what you mean, but those exact
> phrases are just not in my vocabulary.
>

Domain Model - model of the domain concepts.  Then end result of producing a
domain model is that you have a conceptual, class graph of the concepts in
the problem domain.  High level sequence diagram is something that allows
the analyst to get his thoguhts together when considering the system at an
informal, conceptual level.  Maybe an example would be a sequence diagram
that shows a user indicating a request, the system receives the request and
sends another request to an external system.  Three messages.  High level.
Value? To some I am sure.

> How do you know the project NEEDS a framework?  Or are you imagining
> based on your experience with similar projects, there will be a
> framework?  On this current project I am working on, it certainly
> could have been argued that a framework was needed and I had an idea
> what that framework would look like.  However, I let the customer
> drive the development and added framework architecture as the
> development needed it.
>

I think, if one considers an non-xp project, some technical questions will
be raised.  How will we log exceptions? How will we raise notifications? How
will we persist consistently.  How will we navigate in a web application?
yada yada yar.  In such projects, someone would start to work on one aspect,
some on another.  The forces are different.  I am begining to see the
differences now, and in XP if a frameowrk is needed, it will be built.  If
it isnt needed, it will not get built.  If it doesnt get built, nobody
epxended anything that didnt add value.

I am trying to recall the conversation with the guy who mentioned frameworks
in XP at the workshop.  I believe he made a good point.  Hes a bright chap,
and knows his stuff.  Hes working wihtin a large project, and early on
realised he had a number of pices of development he needed to do that could
benefit from a framework.  If he spent some time building the framework,
then he would be able to add in all the pieces of development with ease and
elegance.  Knowing that further in time some more development pieces will
definitely come along, he built this framework to ease that burden and
provide an extendible solution.  It works and it works well.

> One framework item I thought I needed, but the customer did not, was
> the ability to create a dynamic lefthand navigation for the
> customer's website.  I was imagining a dynamic ordering of a dynamice
> number of items with view permissions for each item based on access
> levels.  In addition, the customer could either use a text link or a
> upload an image for the link.  As it turns out, the customer was
> completely happy for 8 months with a static navigation of simple link
> buttons.  Now, as the project has grown in complexity, the ability to
> turn on and off lefthand navigation is needed.  We still do not need
> dynamic number of items, dynamic ordering, or view permissions based
> on access levels.
>
>
>
>
>
> 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
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Not to speak for Ron, but...

> -----Original Message-----
> From: Steve Berczuk [mailto:berczuk@...]
> Sent: Friday, February 28, 2003 8:37 AM
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] Re: For product development with XP, CVS
> branching and merging seems difficult.
>
>
> Ron Jeffries wrote:
> > Yes. This requirement does not, however, argue for
> branching the code.
> > It argues, instead for partitioning the code into (in this
> case) three
> > partitions: common, v1, and v2. If the code with the bug in
> it occurs
> > in both version 1 and version 2 (the case in point), then
> it wants to
> > be in "common". There are two build procedures, no branching.
> >
> >   (Now some may argue that this is indeed branching. Not in
> the spirit of
> >   the thing I'm after, the appearance of separate copies of
> the same code
> >   in two versions of some program.)
>
> This is sort of what I meant earlier when I referred to their being
> "architectural solutions" to this, but what do you do to support a
> deployed customer with v1?

Fix the problems in the code and make another build of v1?

> and how do you deal with changes in common
> over time? (at some point you may have a common that works
> with v1, but
> not v64).

Why?

I guess you could end up with multiple levels of "commonness" that are
shared between potentially disjoint sets of versions.  But that's
probably an inherent complexity that comes from trying to support 64
versions of the product.

> A proper partitioning is ideal in many (but not all?) ways, but it
> requires a LOT of foresight to do thye partition before you
> deploy a system.

Why does it have to be before you deploy the system?  If v1.1 is
refactored significantly from v1, but still operates the same way
(passes all the v1 tests) is that a problem?

>
>   Then again, Maybe I just don't understand what you mean by
> : "the appearance of separate copies of the same code in two
> versions of
> some program."  do you mean 'identical code' in two versions?

Slightly different but with lots of duplication.

So we're assuming that v1 and v2 share a lot of code, right? Otherwise
you wouldn't even want to be branching and merging...you'd have two
totally separate products.

So they share a lot of code, but have some differences.  One way to
handle that would be to have two copies of the code that are identical
to the extent that they must be the same, and have little embedded
differences that need to be occasionally merged back and forth between
the duplicated code.  This is the branch and merge solution.  Figuring
out which code is supposed to be shared (merged when modified) and which
is supposed to be version-specific becomes a huge maintenance nightmare.

Another approach is to factor out the code that is shared from the code
that is not.  Keep a single code base, and write build scripts to
generate either version 1 or version 2 on demand.  This is what Ron and
I are suggesting, and it follows from the OAOO principle.

--
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863

>
> -steve
>
> --
> Steve Berczuk  | steve@... | http://www.berczuk.com
>   SCM Patterns: Effective Teamwork, Practical Integration
>       www.scmpatterns.com

On Friday, February 28, 2003, at 10:33 AM, Nick Robinson wrote:
> Thanks for your reply - its a good answer.  One question.  If two
> programmers start work on stories but both need to persist their
> objects,
> how do you deal with that in XP? So I want to build the story that
> requires
> wizzbang and you are doing foobar.  Both of us need the facade code you
> mentioned.  This is no different to normal world of development, but I
> am
> curious on how XP would deal with this.  Maybe there is something it
> advises.

It seems like this is the sort of thing that would come up in iteration
planning, or worst case in a daily standup meeting.

You: I'm going to implement persistence for wizzbang today.
Me: I implemented persistance for foobar yesterday, and it's almost the
same problem - let's pair today so we can make something reusable.

-Alex

"Nick Robinson" <nicholasrobinson@...> wrote:
> > Nicholas Robinson <nicholasrobinson@y...> wrote:
> > > Another subsequent question was how does XP cope with frameworks
> > > on a project that has none and needs one?
> >
> > On an XP project, if a framework is needed, it will slowly appear over
time.
> > If no framework appears, it wasn't needed.
>

> Thats what I thought.  So if no framework exists yet the team need a
> consistent mechanism for the data access layer, how would this be factored
> in?

The data access layer wouldn't be factored in, it would be refactored out.
You could start by not having a data access layer.

When it comes time to make sure the data persists, you could perhaps save
everything to a flat file.

If another piece of code needs to persist some data, the pair working on
that story extracts the persistence code into its own class. They have just
extracted a framework.

As people use the persistence mechanism, they'll add features they need and
the framework will evolve. (XP's collective code ownership principle says
that everyone is free to modify the framework.) Perhaps it would evolve to
store the data in a SQL database, or perhaps the flat file will suffice.


Erik Hanson

--- In extremeprogramming@yahoogroups.com, "Nick Robinson"
<nicholasrobinson@y...> wrote:
>
>
> > -----Original Message-----
> > From: banshee858 <cnett858@s...> [mailto:cnett858@s...]
> > Sent: 28 February 2003 16:09
> > To: extremeprogramming@yahoogroups.com
> > Subject: [XP] Re: Initial Planning and Metaphor
> >
> >
> > >
> > > When the initial planning takes place with the business/customer,
> > and it is in this same meeting
> > > that some of the user stories are fleshed out, how is it feasible
> > to give estimates?  This was
> > > asked of me in my last workshop.  We were walking through the
> > stories and needed some estimates.
> > > Nobody felt confident until the following had been produced:
> > >
> > > 1. Domain models
> > > 2. Some high-level sequence diagrams
> > > 3. An appreciation of the architecture required
> > >
> > > Another subsequent question was how does XP cope with frameworks on
> > a project that has none and
> > > needs one?
> > >
> > I know this is COMPLETELY a stupid question, but I will ask.  Can you
> > please define what you mean by "domain models" and "high-level
> > seqeunce diagrams"?  I have an idea what you mean, but those exact
> > phrases are just not in my vocabulary.
> >
>
> Domain Model - model of the domain concepts.  Then end result of producing a
> domain model is that you have a conceptual, class graph of the concepts in
> the problem domain.  High level sequence diagram is something that allows
> the analyst to get his thoguhts together when considering the system at an
> informal, conceptual level.  Maybe an example would be a sequence diagram
> that shows a user indicating a request, the system receives the request and
> sends another request to an external system.  Three messages.  High level.
> Value? To some I am sure.

You don't have a domain model already? From some of the
conversation I had assumed you were working in a corporate
environment, where most of the turf is already well trodden.

One of the attributes of a properly done domain model is
that in such an environment, it will fit with other
domain models in a fairly natural way, because they are,
after all, describing aspects of one company.

To answer (or at least irritate) the original question
about estimates, you can't give a detailed estimate at that
point in the project. The best you can do is size it and
give a rough estimate based on similar work you've done in
the past. You can't get detailed estimates until you've got
most of the stories on the table, and sometimes not even then
if there's significant risk that still has to be investigated.

John Roth

On Friday, February 28, 2003, at 8:36:47 AM, Steve Berczuk wrote:

> Ron Jeffries wrote:
>> Yes. This requirement does not, however, argue for branching the code. It
>> argues, instead for partitioning the code into (in this case) three
>> partitions: common, v1, and v2. If the code with the bug in it occurs in
>> both version 1 and version 2 (the case in point), then it wants to be in
>> "common". There are two build procedures, no branching.
>>
>>   (Now some may argue that this is indeed branching. Not in the spirit of
>>   the thing I'm after, the appearance of separate copies of the same code
>>   in two versions of some program.)

> This is sort of what I meant earlier when I referred to their being
> "architectural solutions" to this, but what do you do to support a
> deployed customer with v1? and how do you deal with changes in common
> over time? (at some point you may have a common that works with v1, but
> not v64).

Separate build procedures. Stuff common to v1 and other versions + stuff
unique to v1.

> A proper partitioning is ideal in many (but not all?) ways, but it
> requires a LOT of foresight to do thye partition before you deploy a system.

I would suggest that (a) it requires exactly as much foresight as does
branching, since branching also requires separate build procedures, and (b)
it requires no foresight at all, just post-hoc analysis.

>   Then again, Maybe I just don't understand what you mean by :
> "the appearance of separate copies of the same code in two versions of
> some program."  do you mean 'identical code' in two versions?

Yes. My primary concern with branching is the necessity to make multiple
identical edits to separate copies of identical code.

Ron Jeffries
www.XProgramming.com
Analysis kills spontaneity.
The grain once ground into flour germinates no more. --  Henri Amiel

On Friday, February 28, 2003, at 9:13:02 AM, Nicholas Robinson wrote:

> Am I correct in thinking that in the exploration phase of iteration planning,
not only does the
> team write task cards for stories, but it also writes tasks to things that
must be done to support
> the iteration? In KB's Extreme Programming Explained Kent mentions these types
of tasks.  I am
> thinking that when the developers sit down to decompose the stories into
tasks, they will consider
> what is required to support the development effort.  If a technical issue
arises, then it must be
> factored into the planning, and thus a task card is created for it.

> Is that the general gist?

Well, if you create task cards, yes. I don't usually recommend them any
more: I recommend that the team brainstorm tasks onto the whiteboard during
iteration planning and leave them there.

Ron Jeffries
www.XProgramming.com
Speculation or experimentation - which is more likely to give the correct
answer?

Hi Alex, that definitely makes some sense.  I am begining to see that the
fundamental principle here is that one doesnt worry too much during
planning? Maybe there is something that hasnt clicked just yet, but it seems
that in one context we just worry about the structure once we get going with
the code - we might not need anything we try to BDUF.  The other is that we
need to produce estimates during the planning game....

Nick.

> -----Original Message-----
> From: Alex Pukinskis [mailto:alex@...]
> Sent: 28 February 2003 17:51
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] Re: Initial Planning and Metaphor
>
>
> On Friday, February 28, 2003, at 10:33 AM, Nick Robinson wrote:
> > Thanks for your reply - its a good answer.  One question.  If two
> > programmers start work on stories but both need to persist their
> > objects,
> > how do you deal with that in XP? So I want to build the story that
> > requires
> > wizzbang and you are doing foobar.  Both of us need the facade code you
> > mentioned.  This is no different to normal world of development, but I
> > am
> > curious on how XP would deal with this.  Maybe there is something it
> > advises.
>
> It seems like this is the sort of thing that would come up in iteration
> planning, or worst case in a daily standup meeting.
>
> You: I'm going to implement persistence for wizzbang today.
> Me: I implemented persistance for foobar yesterday, and it's almost the
> same problem - let's pair today so we can make something reusable.
>
> -Alex
>
>
> 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
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Hi Erik,

Doesnt the factored out depend on how you are going to implement it.  If I
was building a domain model, I personally would add persistence when needed.
However, the team that have decided on "how we will structure things"
arrived at a data access pattern that involves our domain descending from
data access layer objects....I dont quite like convenience inheritance, but
I'm not technical lead here.  In this case, I dont quite get how the super
class layers could not be factored in.

Nick.

> -----Original Message-----
> From: Erik Hanson [mailto:yahoogroups@...]
> Sent: 28 February 2003 17:53
> To: extremeprogramming@yahoogroups.com
> Subject: Re: [XP] Re: Initial Planning and Metaphor
>
>
> "Nick Robinson" <nicholasrobinson@...> wrote:
> > > Nicholas Robinson <nicholasrobinson@y...> wrote:
> > > > Another subsequent question was how does XP cope with frameworks
> > > > on a project that has none and needs one?
> > >
> > > On an XP project, if a framework is needed, it will slowly appear over
> time.
> > > If no framework appears, it wasn't needed.
> >
>
> > Thats what I thought.  So if no framework exists yet the team need a
> > consistent mechanism for the data access layer, how would this
> be factored
> > in?
>
> The data access layer wouldn't be factored in, it would be refactored out.
> You could start by not having a data access layer.
>
> When it comes time to make sure the data persists, you could perhaps save
> everything to a flat file.
>
> If another piece of code needs to persist some data, the pair working on
> that story extracts the persistence code into its own class. They
> have just
> extracted a framework.
>
> As people use the persistence mechanism, they'll add features
> they need and
> the framework will evolve. (XP's collective code ownership principle says
> that everyone is free to modify the framework.) Perhaps it would evolve to
> store the data in a SQL database, or perhaps the flat file will suffice.
>
>
> Erik Hanson
>
>
>
> 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
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

> -----Original Message-----
> From: jhrothjr <yahoogroups@...>
> [mailto:yahoogroups@...]
> Sent: 28 February 2003 18:13
> To: extremeprogramming@yahoogroups.com
> Subject: [XP] Re: Initial Planning and Metaphor
>
>
> --- In extremeprogramming@yahoogroups.com, "Nick Robinson"
> <nicholasrobinson@y...> wrote:
> >
> >
> > > -----Original Message-----
> > > From: banshee858 <cnett858@s...> [mailto:cnett858@s...]
> > > Sent: 28 February 2003 16:09
> > > To: extremeprogramming@yahoogroups.com
> > > Subject: [XP] Re: Initial Planning and Metaphor
> > >
> > >
> > > >
> > > > When the initial planning takes place with the business/customer,
> > > and it is in this same meeting
> > > > that some of the user stories are fleshed out, how is it feasible
> > > to give estimates?  This was
> > > > asked of me in my last workshop.  We were walking through the
> > > stories and needed some estimates.
> > > > Nobody felt confident until the following had been produced:
> > > >
> > > > 1. Domain models
> > > > 2. Some high-level sequence diagrams
> > > > 3. An appreciation of the architecture required
> > > >
> > > > Another subsequent question was how does XP cope with frameworks on
> > > a project that has none and
> > > > needs one?
> > > >
> > > I know this is COMPLETELY a stupid question, but I will ask.  Can you
> > > please define what you mean by "domain models" and "high-level
> > > seqeunce diagrams"?  I have an idea what you mean, but those exact
> > > phrases are just not in my vocabulary.
> > >
> >
> > Domain Model - model of the domain concepts.  Then end result
> of producing a
> > domain model is that you have a conceptual, class graph of the
> concepts in
> > the problem domain.  High level sequence diagram is something
> that allows
> > the analyst to get his thoguhts together when considering the
> system at an
> > informal, conceptual level.  Maybe an example would be a
> sequence diagram
> > that shows a user indicating a request, the system receives the
> request and
> > sends another request to an external system.  Three messages.
> High level.
> > Value? To some I am sure.
>
> You don't have a domain model already? From some of the
> conversation I had assumed you were working in a corporate
> environment, where most of the turf is already well trodden.

In an ideal world.  However dont forget, these questions came out of a "out
of hours" XP workshop.  The domain model is for the system we will be
building during the workshop.

>
> One of the attributes of a properly done domain model is
> that in such an environment, it will fit with other
> domain models in a fairly natural way, because they are,
> after all, describing aspects of one company.
>

Absolutely.

> To answer (or at least irritate) the original question
> about estimates, you can't give a detailed estimate at that
> point in the project. The best you can do is size it and
> give a rough estimate based on similar work you've done in
> the past. You can't get detailed estimates until you've got
> most of the stories on the table, and sometimes not even then
> if there's significant risk that still has to be investigated.
>

Ok that does make sense.  So maybe I can open up this question.  As
developers we have a meeting with the client, and he has written all of his
stories (whupeee).  The idea of the meeting is to produce a guestimate of
the first iteration.  There are a few issues about how the system is going
to be built etc.  What happens next? Do we make rough estimates and then the
meeting ends after the stories are selected? When would we revise the
estimates - there was a lot we werent sure about in the planning meeting?

Thanks John,

Nick.

> John Roth
>
>
>
> 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
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

On Friday, February 28, 2003, at 12:33:32 PM, Nick Robinson wrote:

> Kiel, thats very useful.  I am sure when we discussed this, we kinda thought
> that that is how it must happen in XP, given all the principles.
> Now, when i think more about the original question I need to dig deep for
> asking why would one want a framework.  One reason is that there are
> different ways for doing DB persistence, and the team lead may wish to have
> it done one way and everybody else uses the pattern.  That way, if there are
> weak people in the team (in relation to DB persistence say), then its
> covered.  Its consistent.  If you have strong minds with different ideas for
> implementation (lets say one wishes to ignore the DB and use a pure domain
> model while another wishes to use recordsets for example), then creating a
> defacto framework is one way of saying, "This is how you do DB persistence".

How might pair programming, team code ownership, and refactoring address
the same problem?

> Thanks for your reply - its a good answer.  One question.  If two
> programmers start work on stories but both need to persist their objects,
> how do you deal with that in XP? So I want to build the story that requires
> wizzbang and you are doing foobar.  Both of us need the facade code you
> mentioned.  This is no different to normal world of development, but I am
> curious on how XP would deal with this.  Maybe there is something it
> advises.

Observe during planning, where we brainstorm the tasks: "Hey, these two
stories are going to need persistence."

Decide whether:

1. Programmers signing up on these two stories will pair on one, then the
other.
2. One programmer will work on something else until the other story is
done, then reuse what's there, possibly pairing with one of the first
story's implementors.
3. ... what other ways?

Ron Jeffries
www.XProgramming.com
Do I contradict myself? Very well then I contradict myself.
(I am large, I contain multitudes.) --Walt Whitman

On Friday, February 28, 2003, at 12:49:57 PM, Tim Moore wrote:

>> and how do you deal with changes in common
>> over time? (at some point you may have a common that works
>> with v1, but
>> not v64).

> Why?

> I guess you could end up with multiple levels of "commonness" that are
> shared between potentially disjoint sets of versions.  But that's
> probably an inherent complexity that comes from trying to support 64
> versions of the product.

Just so. The same problem occurs in the branched format.

Think Venn Diagram.

Ron Jeffries
www.XProgramming.com
It's easy to have a complicated idea. It's very very hard to have a simple idea.
   -- Carver Mead

--- In extremeprogramming@yahoogroups.com, "Nick Robinson"
<nicholasrobinson@y...> wrote:
> Kiel, thats very useful.  I am sure when we discussed this, we
kinda thought
> that that is how it must happen in XP, given all the principles.
> Now, when i think more about the original question I need to
dig deep for
> asking why would one want a framework.  One reason is that
there are
> different ways for doing DB persistence, and the team lead may
wish to have
> it done one way and everybody else uses the pattern.  That way,
if there are
> weak people in the team (in relation to DB persistence say),
then its
> covered.  Its consistent.  If you have strong minds with
different ideas for
> implementation (lets say one wishes to ignore the DB and use a
pure domain
> model while another wishes to use recordsets for example), then
creating a
> defacto framework is one way of saying, "This is how you do DB
persistence".

Doing it in two completely different ways is not good design,
period.

The team should be communicating through pairing and stand-up
meetings and just talking. It should be apparent if things are
not being done in the "ordained" way, however that is decided.

> Thanks for your reply - its a good answer.  One question.  If
two
> programmers start work on stories but both need to persist
their objects,
> how do you deal with that in XP? So I want to build the story
that requires
> wizzbang and you are doing foobar.  Both of us need the facade
code you
> mentioned.  This is no different to normal world of
development, but I am
> curious on how XP would deal with this.  Maybe there is
something it
> advises.

Again, through good communication it should be apparent that two
people need the same thing. The way most teams work, this would
come up during iteration planning.

A straightforward approach would be for those two people to pair
up to do the first one. They could do the second one, too, but it
might be better for one of them to then pair up with another team
member to spread the knowledge around and add even more
perspective.

Alternatively, it could just be decided than one task will be
done before the other. (Presumably, these stories have been
broken down into tasks.)

A third approach is for the two developers to get together
briefly and sync up on what the interface would look like. Then
they proceed making adjustments as appropriate and talking more
when needed. The second one to commit changes to the version
control system is responsible for making sure it all adds up. Of
course, he enlists the help of the first if necessary.

The key is proceeding in small increments. That way, whichever
approach is taken, things will go pretty smoothly and with
minimal delay.

Kiel Hodges
SelfSo Software

>
> Domain Model - model of the domain concepts.  Then end result of
producing a
> domain model is that you have a conceptual, class graph of the
concepts in
> the problem domain.

Why would you create a class graph?  Is the class graph just a
representation of the customer's experience and knowledge in the
domain?  Why would the programmers want this on paper?  Why would the
customer pay for it?  Why not just ask the customer how their domain
works?  How does having a class graph give you information about an
estimate?

> High level sequence diagram is something that allows
> the analyst to get his thoguhts together when considering the
system at an
> informal, conceptual level.  Maybe an example would be a sequence
diagram
> that shows a user indicating a request, the system receives the
request and
> sends another request to an external system.  Three messages.  High
level.

Why do you need to produce this thing before you can provide an
estimate?  Why not talk about it with the customer and from their
description, provide an estimate?  In the example above, I am sure
that 5 or 6 bright people could figure out that three messages are
sent.

>
> I think, if one considers an non-xp project, some technical
questions will
> be raised.  How will we log exceptions? How will we raise
notifications? How
> will we persist consistently.  How will we navigate in a web
application?
> yada yada yar.  In such projects, someone would start to work on
one aspect,
> some on another.  The forces are different.  I am begining to see
the
> differences now, and in XP if a frameowrk is needed, it will be
built.  If
> it isnt needed, it will not get built.  If it doesnt get built,
nobody
> epxended anything that didnt add value.
>
> I am trying to recall the conversation with the guy who mentioned
frameworks
> in XP at the workshop.  I believe he made a good point.  Hes a
bright chap,
> and knows his stuff.  Hes working wihtin a large project, and early
on
> realised he had a number of pices of development he needed to do
that could
> benefit from a framework.  If he spent some time building the
framework,
> then he would be able to add in all the pieces of development with
ease and
> elegance.  Knowing that further in time some more development
pieces will
> definitely come along, he built this framework to ease that burden
and
> provide an extendible solution.  It works and it works well.
>

Yes, very good.  Use the knowledge and experience of all your people
to help flush out the problem and identify where the program might
grow.  Remember with simple design and unit tests, adding a framework
can be done at a later time in the project.

As how to estimate the framework or adding the framework into each
story, I would suggest do not.  First, estimate how long it takes to
make each component standing independent from a framework.  Then male
an estimate on how long it will take to integrate all of them into
framework on a card.  Defer the card until later.

If you delay the creation of the framework to a later time, then when
it is time to create this framework, you will know what it needs
since you will have identified where the independent components do
not fit well together.  After some components are built, then you
reestimate integrating the components into a framework.  At this
point, IMO, you can build a framework.

"Nick Robinson" <nicholasrobinson@...> wrote:
> Doesnt the factored out depend on how you are going to implement it.  If I
> was building a domain model, I personally would add persistence when
needed.
> However, the team that have decided on "how we will structure things"
> arrived at a data access pattern that involves our domain descending from
> data access layer objects....I dont quite like convenience inheritance,
but
> I'm not technical lead here.  In this case, I dont quite get how the super
> class layers could not be factored in.

I'm not saying that I agree with the proposed design, but perhaps you could
do it this way:

You have class Foo. If it needs to persist, you write a method in Foo called
Foo.store() (or whatever) that does a bunch of persisting stuff.

You have class Bar. You eventually decide that it needs to persist too. So
you create a superclass for Foo called Persistent and move store() up to it,
and then make Bar subclass from Persistent too.

Now Bar has store(). You'll probably need to modify store() and maybe add
some other methods in Persistent to deal with the fact that you are
persisting different types of things now.

If Bar already has a superclass, then I guess you'd need to make that one
extend from Persistent, or if you are using a language that allows multiple
inheritance, Bar could also extend from Persistent.



Erik Hanson

>
> Another approach is to factor out the code that is shared from the
code
> that is not.  Keep a single code base, and write build scripts to
> generate either version 1 or version 2 on demand.  This is what Ron
and
> I are suggesting, and it follows from the OAOO principle.
>
Oh, I get this now.  Thanks for explaining this.  I will keep this in
mind the next time I deal with versioning issues.

Carlton

> > Another approach is to factor out the code that is shared from the
> code
> > that is not.  Keep a single code base, and write build scripts to
> > generate either version 1 or version 2 on demand.  This is what Ron
> and
> > I are suggesting, and it follows from the OAOO principle.
> >
> Oh, I get this now.  Thanks for explaining this.  I will keep this in
> mind the next time I deal with versioning issues.

Then run each script, and all sets of version-specific and version-neutral
tests, every time you integrate.

--
   Phlip

On Fri, 2003-02-28 at 09:41, Nick Robinson wrote:

> [...]How will we log exceptions? How will we raise notifications? How
> will we persist consistently.  [...] I am begining to see the
> differences now, and in XP if a frameowrk is needed, it will be built.  If
> it isnt needed, it will not get built.  If it doesnt get built, nobody
> epxended anything that didnt add value.
>
> I am trying to recall the conversation with the guy who mentioned
> frameworks in XP at the workshop.  I believe he made a good point.
> [...] If he spent some time building the framework, then he would be
> able to add in all the pieces of development with ease and elegance.


His point is an excellent one, and his behavior is great in a non-XP
context. It is a dangerous behavior in XP. My tips for dealing with this
urge:

Explain to him that in XP frameworks emerge through the relentless
removal of duplication. E.g., as soon as you have two exceptions being
logged, common functionality should be extracted out: there should be no
duplication between the cases. Since he has a keen eye for the benefits
of this, make it his responsibility to notice, comment upon, and fix any
duplication he finds.

As he refactors, he will have a hard time not adding functionality that
he "knows" will be needed "soon". Ask him, as part of the experiment, to
not do that. But if that's too hard for him, then make a deal with him
about what "soon" means. E.g., that at first he's allowed to write stuff
that he's sure he needs this iteration. Then ramp that down to a day and
then an hour. And make sure to check him on it, too, and remove stuff
that doesn't get used within the limit.

For me, much of the fear was I'd lose a good idea. If that's a problem
for him, ask him to make a quick write-up or sketch rather than writing
code. He will probably discover as I did: although making the sketch is
useful mental exercise, I almost never look at the sketches again.

Another thing that irked me was a lack of symmetry or completeness.
E.g., if I needed a collection of User objects, I'd write both addUser()
and removeUser() even though removeUser was never called. These days I
generally just leave it out and trust that whomever needs the method
will add it. But a good middle ground is to put in a comment with the
method signatures that will come later:

     // todo: public void removeUser(User user)


I find that about half of those comments end up getting replaced with
real methods. That makes me happy, as I feel like I'm on the right
track. And about half of them get deleted, which also makes me happy
that I avoided doing unnecessary work.


Do you think that will help him?

William

--
brains for sale: http://scissor.com/

On Fri, 2003-02-28 at 00:23, Nicholas Robinson wrote:
> Nobody felt confident until the following had been produced:
>
> 1. Domain models
> 2. Some high-level sequence diagrams


Regarding 1 and 2, if they need 'em to estimate, then let them produce
them on the whiteboard, right then. Forbid them to copy them down.

If they need to think about the broader system for them to estimate,
then drawing diagrams is one good way to structure the thinking. But the
point of XP is to always be thinking; if they have copies of the
documents around, they will be tempted to let paper substitute for
future thought.

> 3. An appreciation of the architecture required

Try breaking it down slowly for them. Remind them that in XP, you can
change what you want at any time, so they aren't allowed to do anything
that isn't needed at the moment. Then give them your very first story
card and say, "What architecture do you need for this?"

Likely, they will give you a whole lot of unnecessary architecture,
stuff that relates to future stories. Challenge them on it. Make them
pare it down to the bare essentials. Then give them your second card and
say, "Ok, let's add this one." Go through the same process. Then tell
them, "Well, suppose instead I had added this other card." You should
get a third architecture.


Also, help them understand that unlike in the non-XP world, they will
get the chance to change these estimates. Their first estimates are
almost certain to be wrong, and that's ok. If after four iterations they
are still wildly off, you have a problem, but for now, they shouldn't
sweat it much.


William

--
brains for sale: http://scissor.com/

--- In extremeprogramming@yahoogroups.com, "Nick Robinson"
<nicholasrobinson@y...> wrote:
>
>
>
> > To answer (or at least irritate) the original question
> > about estimates, you can't give a detailed estimate at that
> > point in the project. The best you can do is size it and
> > give a rough estimate based on similar work you've done in
> > the past. You can't get detailed estimates until you've got
> > most of the stories on the table, and sometimes not even then
> > if there's significant risk that still has to be investigated.
> >
>
> Ok that does make sense.  So maybe I can open up this question.  As
> developers we have a meeting with the client, and he has written all of his
> stories (whupeee).  The idea of the meeting is to produce a guestimate of
> the first iteration.  There are a few issues about how the system is going
> to be built etc.  What happens next? Do we make rough estimates and then the
> meeting ends after the stories are selected? When would we revise the
> estimates - there was a lot we werent sure about in the planning meeting?

Your first iteration is kind of special. You're going to be
shaking down the development environment. Besides this, you
need to put out something that goes end to end. For example,
if it's a web application, at the end of the iteration, you
need to be able to fire up a browser, get to the server, and
request some kind of a page. With all of the appropriate tests.
Any real user functionality that gets in there is a bonus.
Granted, a real nice bonus, but still a bonus.

John Roth

>
> Thanks John,
>
> Nick.
>
> > John Roth
> >
> >
> >
> > To Post a message, send it to:   extremeprogramming@e...
> >
> > To Unsubscribe, send a blank message to:
> > extremeprogramming-unsubscribe@e...
> >
> > ad-free courtesy of objectmentor.com
> >
> > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/

On Fri, Feb 28, 2003 at 07:13:21AM -0800, Erik Hanson wrote:
> Nicholas Robinson <nicholasrobinson@y...> wrote:
> > Another subsequent question was how does XP cope with frameworks
> > on a project that has none and needs one?
>
> On an XP project, if a framework is needed, it will slowly appear over time.
> If no framework appears, it wasn't needed.

I'm wondering if the above doesn't assume there is only one project whose needs
must be considered. Mike Beedle has done some XBreed stuff using a combo of
scrum and XP. And it involves some stuff that crosses multiple projects.

So if I have a set of resources (people) that make up a half dozen different
projects and project teams, and if I get multiple requests for that same set of
resources to deliver recurringly similar requests in a particular "area" of
functionality, I don't necessarily want multiple projects trying to solve the
same problem their own separate way, particularly when the end-result from each
of them get coordinated and combined together in various "service packages".

It might not be a request for a framework, and the resulting task/story might
not be trying for a framework, but the desire to eliminate redundancy could
easily drive me to want just one of those teams (or a subteam that coordinates
with the projects) to get together and come up with a way to write the code once
that meets both needs (assuming they aren't too diverse, which would be an
important judgment to make) and passes each projects tests.

I believe Mike had some elements of XBreed that explicitly addressed this
problem. Tho I'm not sure that's how XBreed did it.

But I definitely think I see how it would arise when I'm taking a higher-level
business perspective across multiple projects and teams in the same
organization. The hard part would be knowing when to let them stay separate and
knowing when to combine them together (maybe you don't combine at the start, but
wait until refactoring time to coordinate the projects and remove cross-project
redundancy to reduce overall maintenance). I don't see an easy answer - but I
think it's a legitimate scenario. (Tho I'd be happy to be in a department that
had to face the dilemma whilst having all its project teams doing XP :-)
--
Brad Appleton <brad@...> www.bradapp.net
   Software CM Patterns (www.scmpatterns.com)
    Effective Teamwork, Practical Integration
"And miles to go before I sleep." -- Robert Frost

--- In extremeprogramming@yahoogroups.com, "jhrothjr
<yahoogroups@j...>" <yahoogroups@j...> wrote:
> Your first iteration is kind of special. You're going to be
> shaking down the development environment. Besides this, you
> need to put out something that goes end to end. For example,
> if it's a web application, at the end of the iteration, you
> need to be able to fire up a browser, get to the server, and
> request some kind of a page. With all of the appropriate tests.
> Any real user functionality that gets in there is a bonus.
> Granted, a real nice bonus, but still a bonus.

John, I've heard this before, but I've never been comfortable with
it. It seems to me that an iteration that doesn't implement any
/User/ Stories should be the exception.

As you recall, you and I struggled with setting up our environment
during Tuesday's Code Fest. Still, we delivered a story. And that
was a two hour iteration!

Kiel Hodges
SelfSo Software

On Wednesday, February 26, 2003, at 3:12:23 PM, Nick Robinson wrote:

> That was last week.  This week we decided to start the planning game.  I
> suggested we develop the Lemonade Game.  Its fun, relatively simple, and its
> accessible enough for us to see the key parts of XP in practise.  The idea
> behind this week was to discuss the system and then build the user stories.
> I appreciate the user stories should have been written by the customer (who
> was me in this workshop).  I decided to play my trump card and said that I
> am a customer from an old skool process, and I dont have time to write the
> stories, nor would I want to when I dont know what goes on them.

What caused you to do this? I would think that if I were going to
experiment with the planning game, I'd start with a situation that matches
the entry criteria, rather than try to do the planning game with a
disengaged customer. But we'll see how it went ...

> This is
> how it went - I would love to hear some comments on this.

> 1. The lemonade game was explained by me to the team.
> 2. Team asked questions and together we developed a better understanding of
> the requirements.

Sounds good so far ...

> 3. Next we knew we had to create our stories.  I basically iterated what
> people had said here, in that they are essentially use cases (ignoring
> acceptance tests for this part of the XP workshops.

I would say that user stories are not enough like use cases to make that a
useful analogy. And I would not ignore acceptance tests, as they are, to
me, a critical part of the planning process.

> 4. The team then had a stab at the use cases (stories): Purchase Stock,
> Define Recipe, Start the Day, Setup Game, Set Price (a rough sketch).
> 5. How to move forward from this was then discussed.  I explained
> tentatively that the idea is that the stories could be fleshed out a little
> now so that they could produce their estimates (I explained the notion of
> craft units etc).

> At this stage I feel it kinda broke down a little.  I was under the
> impression that within this first planning scenario, the programmers would
> estimate on all of the story cards, I would choose which I wanted to have
> built first, and they would do they "ooo...ahhh" with the technical issues
> and together we would review what goes in the first release iteration.  It
> didnt work out quite like that.  The workshop has concluded with the
> following as a result:

> 1. Two people are going to consider the requirements (going over the stories
> so far) and will produce a domain model.

In similar exercises that I do, I make them estimate the stories. If a
story is for some reason too big, I get them to break it down. If they
think it might be easy or might be hard, I get them to see if there is part
of it to break out. I get them to ignore small difference. Often I start
with one story that looks easy to the team, then get them to estimate the
others as a function of it.

I've had success getting estimates on around 40 or 50 stories in a couple
of hours.

> 2. I will write up the stories and also create a Yahoo Group for the team to
> use to document the workshopa and have a forum for us all to discuss wihtin
> (we are all consultants and are therefore remote for some of the working
> week).  I also felt this was a good idea, because people here could maybe
> see how we are doing and offer some guidance...that might not happen.

I've not done this. XP is about together. If we try to do it

> 3. Two people will get the development environment setup.  This involves
> installing VSS on a server and getting Draco running (Continual Integration)

OK. I like to start people thinking about XP after the environment is
somewhat set up.

> 4. Oh yes, three others will do some domain modelling and the other pair who
> are modelling will get together with them before the next workshop to
> normalize their ideas.

I don't recall this being a recommended XP step. And I'd be thinking
"together".

> I think it will be the next workshop were the development team writes down
> their estimates.  Their argument (which seems reasonable), is that they need
> to spend this time between now and the next workshop to try to understand
> what the system has to do (high-level) and were the risky areas are.  They
> want to conisder architecture, which I corrected as metaphor.  The workshop
> ended.

Is there a writeup of the lemonade game somewhere? I'd like to do it. Paul
Friedman: you want to pair on a lemonade game chapter?

> We were all buzzing at the end which is cool, but I think some detail in
> some of the areas that was lacking resulted in a good 20 mintues scattered
> throughout the session with people just thinking and wondering about what
> things mean.

> Anyway, thats the workshop for this week.

Sounds cool. And -- meaning absolutely no disrespect whatsoever, because
you did well -- it also underlines how helpful it can be to have someone
involved who gets XP.

Ron Jeffries
www.XProgramming.com
Computers are useless. They can only give you answers.  -- Picasso

I'm contemplating writing a story on XP that would follow the experience of an
actual team on an actual project. The methodology has been written about a lot
already, of course, but I'd like to try an approach for Wired that I haven't
seen done yet: an up-close narrative that follows the psychological and
sociological shifts the group undergoes. What sorts of resistance do XP
proponents come up against? How are resistors ultimately won over? What's it
like to do pair-programming for the first time?

To sell my editor on the idea, I need to find a team that might be willing to
let me get to know them and learn about their process. Ideally, this would be a
group inside -- or working for -- a company Wired readers have heard of.
Ideally, the group would include some first-time XPers. Definitely, it would
have to be a group working in the US.

If you're at all interested, or know a company or a team that might be, reply to
me directly. I'm open to all suggestions.

Here's my last piece for Wired:
http://www.wired.com/wired/archive/11.02/code.html?pg=1&topic=&topic_set=