Re: Running tests from ant on a continuous integration server
Re: Running tests from ant on a continuous integration server
- Subject: Re: Running tests from ant on a continuous integration server
- From: Guido Neitzer <email@hidden>
- Date: Fri, 24 Oct 2008 09:38:57 -0600
On 24.10.2008, at 09:00, Brook, James wrote:
One of the few things that Scrum is prescriptive about is that there
are
only three roles on a team, the ScrumMaster, Product Owner and 'team'.
The team is self organising and collectively responsible and trusted
to
deliver features that are 'DONE' at the end of each iteration. So
our team
consists of two people who can write WO code, a CSS/Javascript person,
a ScrumMaster and a Product Owner. The trick is make sure that we all
share and agree to the same "definition of done" before we start.
After a
couple of painful iterations with lots of loose ends, the planning
soon gets good enough that everyone knows just how much is expected.
Currently the thinking seems to be that for Scrum, the ideal team
size is
7 or less, so I would argue that this is approach is quite well
suited to
small WO teams. The trick is in blurring the boundaries between the
skills
of the different people on the team and making everyone equally
responsible for quality. Note that there is no one called "tester"
involved.
Maybe I'm misreading that, but I see this as different to:
This means that developers don't get the points for a story until it
is 'DONE'.
what you wrote earlier.
The thing you describe in the first quoted paragraph is that all
people on the team share the same idea, have the big picture. Maybe I
just misread the second quote - for me that means, people are told
what they have to do for a small task without seeing the big picture.
I'm not a friend of overorganizing a team of developers - it might
work for some persons, it does not work for me. I'll end up totally
annoyed very fast if organizing work prevents me from getting things
done. And that is also why I don't work with the famous "getting
things done" - it is overengineering of simple things.
But okay, it works for you - that's great. It might work for me in the
way you use it, nobody can tell. But that's not the point. Every team
has to find a way of organizing itself in the most productive way, and
that depends immensely on the team members.
cug
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden