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
|
