Project Activities

How are we going to do this?

0. Forming Teams

You are expected to form project teams in the first week of the course¹. Teams should consist of four people, all enrolled in the same section of the course.

How do you find team members?

• Join friends who are taking the course! If you are in different sections, ask the instructor, and they may be able to move you all into the same section.
• Post in the course forums: we will have a forum thread where you can introduce yourself.
• If you’re in-class, introduce yourself to people sitting near you.

It’s important that you find team members that share your goals, and your approach to the course.

• Do you have the same work schedule? Are you available at the same times (e.g. mornings? evenings?)
• Are you all willing to make the same time and effort commitment to the course? If most of the team wants to put in extra time to get an A+, then you need to make sure that everyone is on-board to do that.
• Look for complementary skills! Not everyone needs to be a (fill-in-the-blank) programmer. There’s room for a lot of different skills to be applied to your project.

1. Project Proposal

In the first few weeks, you and your team will choose a project, define requirements, and discuss design issues.

Before starting to code, you will need to submit a project proposal that clearly identifies:

• Users: the group of users that would be interested in your project.
• Purpose: What purpose does your application serve? What problem does it solve for them?
• Functionality: What major functions exist?
• Design: What functionality is local vs remote? How do these components interact?

You are expected to document this in your GitLab project wiki. See GitLab Project for more details.

2. Sprints

Most of the term will be spent iterating on your project. Sprints start after the project proposal. You will be working in two-week iterations, called sprints. Over a two-week period, you will have a kickoff meeting, do some work, and finally demo that work to the TA.

Day 1: Kickoff

The first day is the official kickoff, where your team collectively decides what you want to include in the sprint. Your primary task in this meeting is to choose items from the Product Backlog and assign them.

Here’s some suggestions to help you determine what to do during the sprint.

• Address feedback from the previous sprint’s demo. You may have received feedback from the previous sprint. Treat suggestions from course staff as important - they represent your customers!
• Address high-risk items early. This gives you time to pivot if needed, and also helps prevents you from investing too much time in a path that ultimately won’t work.
• Look for blocking issues: items that are critical for other systems. Examples of this might be the class structure for business objects (e.g. data classes) that are used by other features.
• Do NOT assign more work than you think you can do.

Outcomes from this meeting:

• You should have all issues logged and assigned to the team, representing the work for this sprint.

Day 2/3: Standup

These are “working days” where your team gets together and does the actual work towards the sprint’s goals. You are expected to work in-class together; the instructor and TAs will be available to help you out.

Day 4: Demo

The last day of a sprint is demo to the course staff of what you’ve accomplished during the sprint. This is a checkpoint of sorts, where we can provide feedback and make suggestions.

This is what you should have completed before the demo:

• You should have recorded meeting minutes for every team meeting prior to the demo.
• The requirements for the sprint (from the kickoff) should be completed
  • Completed issues should be closed in GitLab with details on what was done.
  • Completed work needs to be committed and merged back to the main branch.
  • You should have unit tests that cover the features that you have completed.
• You should have readied a software release - see GitLab Project for details.
  • You should have release-notes for this release in your GitLab project, which documents the release.
  • You should have an installer for your application, so that it can be installed on the appropriate platform.

What does the demo look like?

• Your demo will be informal and last about 15 minutes.
• Using an INSTALLED version of the application, demo each completed feature, and answer any questions. (Your issues list in GitLab is a great way to drive this discussion).
• The person who developed the feature should demo it.
• All demos need to be run from the same machine.

Outcomes from this meeting:

• Open issues from this sprint should be moved to the product backlog (i.e. unassigned from the sprint). They can be reconsidered in the next sprint kickoff.
• After the demo, your team should discuss how things went, and what areas could be improved.
  • Reflect on ways to improve your development process so that you can be even more effective in the next sprint. Record your decisions in meeting minutes.
• The TA will assign a mark and your grade will be returned the week after the demo.
  • See the downloads/demo checklist for marking guidelines.

3. Final Submission

There is also a final submission due at the end-of-term. This will be an offline evaluation, where we consider all completed features, how well they work together, application design, source code structure and so on. Everyone on the team will receive the same grade for this component.

• We will grade this after the end of the term (and after the final sprint/demo).
• You do NOT have to actually submit anything! We will grade the last commit before the deadline from your repository.
• See downloads/final checklist for marking guidelines.