[xmlWiki-developers] Encouragement

[Arnaldo C. <ar...@mi...>]

All,
    Based on my understanding of comments Andrew has made, the vast =
majority of 327 projects find themselves far behind the schedule they =
originally anticipated meeting.  Using this as a standard of reference, =
this puts us right on track.  :)
    I don't know exactly how much of our intended first iteration will =
be ready by our internal deadline of tomorrow night's meeting, but keep =
in mind that part of XP is expecting your planning estimates to be =
wrong.  We'll reestablish our project velocity tomorrow night and plan =
accordingly.
    What are we being graded on here?  Well, a big part of what we're =
being graded on is a)how closely we followed the process, and, by what =
I've gathered from Andrew, b)how we dealt with problems as we encoutered =
them.  Note that the last item there wasn't *if* we encountered =
problems.  In corporate America (in my case, in the military), often the =
best strategy is to deal with problems without reporting them.  =
Fortunately for us, that's neither what the course staff wants nor =
expects.  On the contrary, we need to be sure and intelligently describe =
what snags we hit, and why we reacted as we did.
    Having said this, I think it would be easy for our group to get so =
focused on the code at this point that we forget to produce the other =
part of what we're being graded on.  I think that it would be very =
helpful to draft a document for the course staff that tackles, roughly, =
the following aspects of our project this semester:
-chronology
    --point-by-point progress
    --specific problems encountered
    --how we dealt with them
    --how (specifically) we stuck to or had to depart from XP
    --defense of the decisions we've made.
-obstacles/advantages that have been with us*throughout* the semester
    --how they've affected us, how we've dealt with them
-general observations about XP in geographically distributed groups
    -what XP practices become impossible?
    -what XP practices become difficult?
    -what XP practices are not affected?
    -any other "intangibles" that have affected our project?
-other musings about what we've learned this semester.
-a UML diagram of our interfaces

I'd like to volunteer to write the document described above.  (Since =
I've been summarizing our meetings, I'm probably the most logical =
candidate.)  I'd get it to the group a week and a half before we intend =
to turn it in.  That way, group members can check over it and suggest =
additions and changes.  (I'm sure there'll be many - as Johnson says, =
"Criticism is easier than Creation.")  If people can suggest all their =
changes by two or three days before the due dates for artifacts, I'll be =
able to incorporate them and have it ready to turn in.
    So, much of our success is process-oriented, rather than =
product-oriented.  Is the product unimportant?  Absolutely not - but, =
we're not expected to have a final working product by this semester's =
end; that comes in May.  Personally, I think by this semester's end we =
need a base of code that can be hacked on and refactored, and we need to =
be done with the intial planning phases, poised to continue growing our =
product.
    We can discuss some of this tomorrow night.  I look forward to our =
meeting then.
--Arnaldo