Re: Second practice: Whole Team

--- In xpbookdiscussiongroup-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx, "Dominic 
Williams"
<xpdoka@xxxx> wrote:
[...]
> > For example, if your project requires many changes to
> > a database, you will need a database administrator on
> > the team. When the need for database changes
> > diminishes that person no longer needs to be part of
> > the team, at least for that function.
> 
> I think this is very bad advice. Every time I have seen
> this happen, either (or both) of the following
> occurred:
> 
> - it was later necessary to call the DBA back for a
>   specific job: his availability became a bottleneck.
> 
> - the remaining team members did some things without
>   the DBA, ending up in a mess or starting over.
> 
> I believe the XP team should do everything itself. This
> can influence the choice of members of the team, and
> conversely influence the choice of tools according to
> the skills of the team.
> 
> > For larger projects, finding ways to fracture the
> > problem so it can be solved by a team of teams allows
> > XP to scale up.
> 
> Although this sounds interesting, it begs the
> questions:
> 
> - how should the problem be fractured?
> - how do the teams collaborate?
> 
> Do you develop those later in the book?
[...]

I agree with Dominic.

I feel that the idea behind the "dynamic of the team" is something
similar to a kind of "continuous team refactoring". Can we apply to
the team some patterns similar to the software itself?

Personally, I don't think this one can be. 

The code and the software can be agile, but human minds are probably
far more difficult to refactor and to improve :-)

Mentoring as described by Ron Jeffries seems more appealing to me, but
indeed, It is a long term process...






------------------------ Yahoo! Groups Sponsor --------------------~--> 
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->