Project

Resources

BayTree Centre (Monday 2:30pm tutorial)

Hope Health Action (Monday 3:30pm tutorial)

  • HHA Tutorial meeting Zoom (for full semester)
  • Hope Health Action website
  • HHA Resources including:
    • customer's initial powerpoint
    • [NEW] Collected data spreadsheet (updated Sept 20)
    • HHA logo in SVG, recreated by a student; thanks!
    • HHA branding guidelines
  • Questions posted to Piazza by 8am (Vancouver time) on Tuesday and Thursday should have a response by ~5pm the same day.

Useful Links

General

The semester-long project is the central component of the course. Students are pseudo-randomly assigned to teams of about 8 students from their tutorial. Each team is given a project to work on where the instructor, or an external group, acts as the customer by providing feature requests and prioritizing the backlog. Some teams may be given similar projects, but each team works independently.

Teams will follow an Agile (Scrum) development process through three iterations. For each iteration, a new Scrum Master, Product Owner, and Repo Manager will be chosen. Most customer interactions and requirements gathering will happen during the tutorials, but product owners may also ask questions as described below. Projects (or its applicable parts) must be implemented in Java or TypeScript, using SFU's GitLab, unless agreed otherwise by the team and instructor. It's suggested that all code be released under an open source license to allow any customers of the project to continue using the application/code after the project completes.

Basics of scrum roles:

  • Scrum Master: In charge of making sure meetings are organized and happen. Make sure team works together, solves problems, and communicates.
  • Product Owner: In charge of asking the customer for project clarifications. Takes lead in ensuring all required features for the iteration are being developed. See this student made video explaining how they saw themselves as a PO.
  • Repo Manager: In charge of helping everyone work with Git/GitLab. Responsible for accepting merge requests when ready, and helping do code reviews (comments into GitLab).
  • Team Member: Like everyone else, shares responsibility for delivering required features. No additional duties.

Team Introduction

At the start of the project you must put special effort into building trust between teammates. You must know everyone's name and recognize them. Plus, your team must identify how it will work. Your team must:

  • Decide who will fulfill which Scrum roles for Iteration 1
  • Complete the team accountability exercise; Scrum master to email it to Dr. Brian (within about 1 week) as a reference for how your team plans to operate
  • Complete a couple (2+) icebreakers to learn about each other (accountability doc has some suggestions)
  • Set your name and profile picture in all systems your team uses
  • For online meetings, prefer video calls over just voice; everyone with video turned on (unless impossible)

Tutorials

Tutorials will be time to work on the project. Some days will be time with the customer (gathering requirements, or doing demos); others will be general team time with instructor and TA.

The course will feature some groups working in person, and some groups (which have chosen to) working online. Tutorials will often have students in team meetings and make productive use of the time. A TA or the instructor may join your meeting for a while. Please make use of their help and get their suggestions.

Questions to the Customer

Questions to the customer must be posted to Piazza by your group's Product Owner.

  • Post questions in the folder associated with your project.
  • Required title format
    <Group Name>: <Good title>
    Example:
    Neptune: Password complexity requirements
  • Always be professional when asking questions.
  • Questions will be visible to the entire class.
  • You are welcome to post followup questions under an existing question. Try to ensure the question is on-topic.
  • Product Owners should try to limit the number of questions per week (no fixed max, yet). Ensure you are asking the important questions first.

The customer will do their best to answer questions quickly. See above for specific times.

Team VMs

Each team has a virtual machine. I (Dr. Brian) am able to reboot your VMs if needed. If you need further help with technical issues (such as unable to SSH into the machine), please email helpdest@cs.sfu.ca and include "This message is likely best for Jason" in the body so it gets assigned correctly. Include mention of which VM you are accessing, what is wrong, and what you think might have caused the problem. Including a screen shot never hurts too!

You have root access to your VM. Your SFU password was copied to the VM when it was created. If you change your SFU password, the VM will not automatically update. You can change the password locally on the VM yourself.

Demos

[UPDATED Oct 24, 2021]
At the end of each iteration, each team will record a 10-15 minute video which showcases what they have accomplished this iteration and asks the customer questions. Hint: In your video, number the questions you are asking so the customer can easily reply on Piazza or in the video. The customer will then record a response video.

Retrospective

Project Requirements

  • Each task (greater than about an hour) must start with a GitLab issue, be on its own feature branch, and merge into master (closing the issue).
  • Merge requests should (must?) be code reviewed by at least one person on the team.
  • README.txt (or .md) file in root of the project repo. It must include: project intro paragraph, directory structure explanation, build directions (and dependencies), and run instructions. It is unlikely the instructor or TA will build/run the projects; however, this documentation is critical for anyone working with the code.

Expectations for all students

  • Attend all of your scheduled tutorials.
  • Attend all group meetings, or explain why that's not possible (Ex: conflicting commitments) and make a reasonable effort to catch-up with group afterwards.
  • Contribute to group discussions clearly, effectively, and respectfully.
  • Respond to all relevant group communications within 1 day at the most. Let team mates know quickly if work will be late or incomplete. Expectations for communication may be set by the teams, such as replying to Discord messages within 2 waking hours.
  • Agree to reasonable amounts of work, and reasonable deadlines. Make best effort to meet these commitments. Keep team informed about challenges and ask team members and TA/Dr. Brian for help as required.
  • Commit code changes to Git often (active at least 3 days per week, 1 or more commits on each of those days); make merge requests early and often (every couple days or less; at least each week; not big bang!). Commit only high quality code. Don't break the build. If in doubt about high-quality code, see Dr. Brian. Clean code conforms to a style guide such as the suggestion one for this course.
    • Do not squash git commits from multiple days into one; the commits show when developers have been active.
    • If you pair program for a commit, add the other student's SFU ID to the start of the commit message in square brackets, such as "[bfraser] Fix timing bug for DB access"
  • Actively seek to complete an equal share of the work and push the project ahead.

Suggestions for all groups

  • Find a good mode/place to meet: in person, or online chat. For in person, find somewhere that works for everyone (like a team room). For online team chat, I suggest using Discord or Slack.
  • For meetings, find a time that works for everyone: diverse schedules, 3 campuses, jobs, ... Be on time for these meetings!
  • Respect everyone's mode of communication. Some people don't like to speak up during meetings, but share more thoughts via online chat later. Try to work with each person's strengths. Scrum master to help ensure everyone has their say.
  • Respect team member's task preferences: give everyone a fair shot at working on the part they want to (UI, application logic, ...); but everyone needs to be willing to work on what needs to be done.

Marking Criteria

Students are marked mostly individually. The following are many of the things students will be marked on:

  • Significant positive contribution to code in the project, throughout the iteration, by following the required development process.
  • Picking tasks to work on; completing those tasks.
  • Participation in "standup" meetings; attend tutorial on time; active in team discussions during tutorial.
  • Performance of assigned team roles (scrum master, product owner, repo manager).
  • Follow expected workflow when using Git and GitLab.
  • Commit work early and often.
  • Active in code reviews (write comments in GitLab) of own code and team mates.
  • Code quality, conforms to team's style guide, neatly organized, does not break build.
  • Ability to function in team and have positive and productive interactions.
  • Iteration retrospective.
  • Overall success of the project.

Students will be evaluated for their participation in the software development process each tutorial as well as at the end of each iteration.

A student's iteration mark will be computed based on the following weighting. Instructor may adjust marking of an individual student to better reflect the student's overall contribution to the project.

End of Iteration Student Deliverables

At the end of each iteration (see schedule page for due dates) each student must submit the following:

  • Peer feedback evaluation of teammates
  • Personal iteration report to evaluate code and team roles

Peer Feedback (JSON)

20% of your grade is the mark your teammates assign to you during this feedback.

You will provide feedback to all your teammates, and they to you. This will be used for grading and for personal improvement.

  • Created using the on-line letter-mark peer-feedback tool, submitted to CourSys.
  • Please type SFU user IDs carefully: user IDs should be the short version of your email. For example, mine is bfraser, not brian_fraser. You should not need any underscores (_) or dashes (-).
  • Your written comments about a group mate will be shared with them anonymously; your numeric/letter scores will be averaged for them to see.

Iteration Summary

80% of your iteration's mark is for code contribution and team role. Marked largely based on code committed to master branch in GitLab by the code-merge-cutoff date for the iteration. This also considers work on GitLab Issues, GitLab comments on code (code reviews, ...), student's self evaluation, and performance of team roles (PO, SM, Repo). Graded based on the marking rubric.

You must submit a short (~1p) personal iteration report (.pdf) describing your contribution to the iteration. OK to exceed length by including evidence like DB design, etc. Include:

  • Successes: Discuss which of your individual contributions from this iteration that you are most proud of.
    • In your discussion, provide the URL to 2 SFU GitLab merge-requests (MR) which exemplify the code you are referencing.
    • If it is a non-code accomplishment, provide any reasonable proof which applies.
    • You may give a link to a commit if no merge requests fit. We may analyze any/all merge-requests/commits to the project.
    • For iterations 2 & 3, you must also mention the story points for the work you completed. How many points were each of the MRs you reference above? How many other story points did you complete this iteration? Note: this will factor in at most a little into the marking; I will still analyze the actual MRs.
  • Improve: How you want to improve your programming and/or group work. Discuss a big idea instead of some minor point like "I wish I had spelt 'hello' correctly in my comments."
  • Non-Git Work: Please explain your important contributions to the project/team which will not be demonstrated GitLab statistics (#lines of code, #merge-requests, commit/merge frequency....). For example:
    • Scrum role (PO/SM/RM): Explain what you did for the role. Justify this with examples. Tell us why you should get marks for this.
    • System design: Designing the architecture, REST API, etc. State what you did, explain how much time it took. Include evidence (UML diagram?...)
    • Database design: State how much you did; append database design document to your PDF
    • UI design: State how much you did; append UI design (or include an online link) to your PDF
    • Tutorials: State which tutorials you did, and what new technologies you needed to learn this iteration.
    • DevOps (VM): State any work you did on devops, such as CD/CD or VM installation work. Explain how much time it took.
    • Testing: Did you checkout/build/test each merge request? How much extra time did you spend testing?
    • Demo: Did you write/make/edit the demo video? Report what you did and how much time it took.
    • Extensive team help: Did you go well beyond the call of duty to help teammates? This is beyond the usual good teamwork help; this is teaching someone they should have been able to figure out, or spend much more time walking them through something than expected.
    • If you did pair programming on some merge requests or large commits, provide links and state with whom you did this in your document.

See marking rubric for guidelines on the value of each activity.

To evaluate your code contributions, we will (effectively) git pull your team's master branch after the code-merge-cutoff (see schedule page). Your iteration mark is based your individual project contributions. Commits not yet merged to master will not be marked. Scripts and tools will be used to evaluate your performance over the iteration.

Dispute Resolution

It is understood that with a large team there will be communication and interpersonal challenges. This is part of software development, and part of this course. Individuals should do their best to work well with their group and be a positive, valuable team member. If an issue arises where team members require help to resolve it, they should first ask their Scrum Master for assistance mediating a solution (if reasonable to do so). After that the TA and/or instructor can assist in resolving the issue. You are welcome to bring larger issues like discrimination, bullying, and abuse directly to the attention of the instructor as these will not be tolerated.

Any group member who is found to be a liability to the team will be first given directions by the instructor on what they must change in order remain on the team. They will be given a time-frame for when they must demonstrate that they have made these changes. If the student is unable to sufficiently improve, they will be removed from the team. Examples of how a student can be a liability include a disruptive personal interaction style, or incompetent technical contributions (such as horrific code quality, repeatedly breaking the build, ...).

If a student is removed from a team, that student begins working on a copy of the project alone and must fake the project experience. They must meet with the instructor once a week for 10 minutes and present their plan for the week. It is the student's responsibility to adapt the project to the work of a single student instead of a team. For example, they must analyze the backlog to select reasonable features, and design and implement the features. A large mark penalty may be applied to students who are removed from their groups.

Specific list of Intolerable Acts

  • Sexist, racist, or insulting conduct
  • Yelling at group members
  • Using profanity at group members (some tolerance for the heart-felt "That dang-gone compiler's error messages are incomprehensible!")
  • Disparaging remarks about team members (either in person or in chat)