Project interations

Warning

This is final-stage draft! It will be finalized before we discuss it in class.

This section describes a project milestone. See the schedule for due dates.

You are working through product iterations, where you plan, design, and code in two-week cycles. You always start with planning, and end with a demo of what you accomplished.

First day: planning

The first day of an iteration should include be a planning meeting, where you:

  • Review the results from the previous demo.
  • Review work that was not completed and decide if you wish to continue working on it.
  • Plan out the remaining work, taking into account everyone’s availabilty, priority of issues and so on.

By the end of your meeting on the first day, everyone should have issues and work assigned to them.

Middle days: design, coding

Over the remaining two weeks, you should meet occasionally to coordinate your work.

You and your team should meet at least twice each week to review your progress.

  • Record meeting minutes and store in the wiki. Meeting minutes need to include: date, who attended, what you decided.
  • See gitlab/templates for a sample of a meeting minute format.

Issues must be maintained and updated as you work. Document your work indicating what was done. Use GitLab issues as the primary place to store information about what you’re working on.

  • The issue list in GitLab should always reflect the state of the project.
  • Issues always stay assigned to the person responsible for that work.

Gitlab issue

Last day: demo

On demo days, you will meet your TA in class and present your progress.

  • See the Team schedule for your assigned timeslot.
  • You have 15 minutes for the demo.

Before the demo:

  • You MUST product a software release. Please read and follow those instructions carefully.
    • Your application must be installed from the software release and runnable from a single machine. Do NOT demo from the IDE or an editor.
    • You should expect that your TA will review the code after your demo. You should NOT make code changes afterwards since we will grade what was tagged for the release.

During the demo:

  • You must run the demo from a single machine.
  • Each person on the team should demonstrate what they completed.
    • Do NOT demonstrate code, we want to see working functionality when possible.
    • You are allowed to show GitLab wiki documents, unit tests results, or other work that demonstrates what you accomplished (since these are things that cannot easily be demonstrated by a feature).

Caution

Your demo will be graded based on the features that are working during your demo. We strongly advise that you have everything working ahead of time.

Coding in the hall before the demo is a really, really bad idea.

How to submit

You do not need to submit anything. However, you can expect the TA to git clone your project and run your code following the demo to review what you showed them.