- Complete Iteration 4.
- Reflect on our experiences.
- Wrap up the course.
Tuesday, December 11: Iteration 4 Demos; Project
Review in The Art of Agile Development:
- Retrospectives (pp. 94-100)
- Iteration demo (pp. 138-143)
- "Done Done" (pp. 156-159)
- Customer tests (p. 282)
- Any other practices you wish to discuss during the project
Bring your copies of The Art of
Agile Development to class so that you can refer to it regarding
these or other practices.
Your team should be prepared with a <10 minute demo of the stories
from Iteration 4 that are "done done".
See also the results of our debrief from the third round of demos. In particular, please remember to demo full stories from beginning to end.
- You should have a demo release that customers can try. Deploy
your master branch to Heroku (or another server) before the demo.
the demos are short, the demo should be conducted by no more than three
team members. Your team can decide whether the product manager will
always lead the demo or whether this duty will rotate around.
- You will give the demo on the instructors' workstation. At least
one team member should arrive early to class to cue up the project's
home page in the Web browser.
- Out of respect to customers who may be visiting the class, we
will start demos promptly at
2:15. Any announcements or general discussion will wait until after the
demos. Arrive on time or early
The project retrospective
will follow the same general pattern as the iteration retrospective:
- Step 1: The Prime Directive. As usual.
- Step 2: Brainstorming. Instead of focusing on just the most
recent iteration, you will reflect over the entire project. Respond to
the following questions:
- What were the most profesionally satisfying parts of the project?
- What were the most frustrating
parts of the project?
- Which methods or processes worked
- Which methods or processes were
difficult to use?
- Which methods or processes evolved
over the course of the project?
- If you could wave a magic
wand and change one thing
about the the project, what would it be?
- What would you keep the same?
- Step 3: Mute Mapping. As usual.
- Step 4: Summing Up. Instead of choosing one retrospective
objective, summarize all significant themes from your retrospective.
What lessons have you learned?
Thursday, December 13: Wrap-up; Is Rails good or
At the beginning of the semester, Hartl and I sold Rails to you as a
good framework for
writing structured Web applications through an agile software
development process. But there are also arguments against
Rails: both arguments against Rails in general, and arguments that
Rails is inappropriate for some applications.
your answers to the following questions by 10
a.m. Put "CSC325-DEC-13" in the email subject line.
- Did you find any of these arguments particularly persuasive? Why or why not?
- In your view, was Rails a good choice for this class? Why or why
- What else would you like to discuss in relation to today's
In addition to discussing the final readings, you will have the opportunity to evaluate this course.
Friday, December 14, 5:30 p.m.: Team and peer evaluations due
Team and peer evaluations are due by 5:30 p.m. today. I encourage
you to use this week's regular project worktime to get this done. Your
team should have received links to:
- An Evidence of Practices spreadsheet, for your team to fill out as a group.
- A Self- and Peer-Evaluation form, for each team member to fill out individually.
- A Customer Feedback form, to send to your customers to fill out (as appropriate).
Creatted December 7, 2012
Last revised December 10, 2012