Version Control. I have made an executive decision that we will use Subversion (SVN) for source control, rather than Git. I decided to make this change before we started the project in the interest of increasing our likelihood of success. Centralized version control is simpler than decentralized version control. SVN is simpler than Git. Several of you know SVN already. The technical details of reading and writing to the repository are easier to manage with a locally-managed SVN server than with a free Github account.
If we had more time this semester, we might well stick with Git. Learning a little about decentralized version control and Git earlier this week will be of value to you in the future. But our goal in this course is to deliver working software, I think the best chance for this lies with SVN.
Schedule. Iteration 1 will run Friday, May 21, through Thursday, May 27. On Friday, May 28, we will conduct a retrospective of the iteration and plan for the next.
Iteration 2 will run Friday, May 28, through Thursday, June 3. On Friday, June 3, we will conduct a retrospective of the second iteration and of the project as a whole. That is the last day of class, so we will also take stock of what we have learned and wrap-up the course.
We prepared for the first iteration by playing the Planning Game. You estimated these stories, the cards for which are now on the story wall in our lab. Your estimates ranged from 1-3 units, where each unit is 1.5-hours of pair time. One story, on importing data in formats such as .xls and .qif, carried 4 units, so we split it into two 2-unit stories. The total units for the stories is 40.
(There are certainly more stories to tell and to write, but the customer is happy that this set of story cards specifies the core functionality of the desired system.)
The team estimated that the iteration permits 5 pairs * 2+ units/day * 5 days = approximately 60 units. Lacking any prior experience with the team's potential velocity or with estimating an iteration, we used a common practice from industry and halved the 60 to arrive at 30 expected units of work for the iteration. This may still be optimistic, something the team understands and is prepared to deal with.
The customer selected 30 units of work from the 40 points on the story board, in consultation with the team. The team indicated a desire to implement a particular feature or two dealing with data persistence. This is clearly an essential feature to have, and I was glad to ensure including these stories.
The team decided to use its remaining hour of the day working as a group to build the first tests and code of the system. The result was a handful of tests and the beginnings of two kinds of objects, a general journal and transactions.
You will recognize some similarities to XP in how software is built in iterations. We will borrow Scrum's idea of a morning stand-up meeting for our project.
Second, a couple of short articles on how design: