Project

General

This course focuses on the project. Your mark is mainly tied to your individual contributions to both the team and the project overall (code/tasks/testing/...)

The team will follow an Agile (Scrum) development process through four iterations. Note that all code developed for this project may be required to conform to the license of the current product. See the project proposal document which was emailed to you when applying for the course.

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. At the start of the semester, the team must:

• Decide who will fulfill which Scrum roles
  • Scrum Master: In charge of organizing meetings. 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.
  • Team Member: Like everyone else, shares responsibility for delivering required features. Everyone must fight to understand product requirements, participate in design process, and be an active member of the team.
• Get to know each other. For example, have a look the team accountability exercise that teams in other classes must complete. The team need not complete this; it's just for reference. I do, however, recommend you complete a couple icebreakers!
• Set your name and profile picture in all systems the team uses
• Prefer video calls over just voice; everyone with video turned on (unless impossible)

Instructor's Role

I (Dr. Brian) will be help facilitate the project and mark individual contributions. If you have any concerns with the course overall, or the marking, please see me during office hours or send an email.

Demo / Trial

At the end of each semester, it is desirable to have a field trial or in some way have the customer try out the product to give feedback on the work done and help set the direction for the next semester.

• Try to use demos to tell a story that relates to the customer, not just show features.
• Always use meaningful data during a demo. For example:
  • Enter a person's name as "Mohamed Kamara", not "name name"
  • Enter a person's symptoms as "Headaches and low energy" not "xyz"
• When possible, try to have the customer test it out each iteration.

Expectations for all students

• 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 for help as required.
• Commit code changes to Git often (active at least 2 days per week, 1 or more commits on each of those days); make merge requests frequently (avoid big bang!). Commit only high quality code. Don't break the build. If in doubt about high-quality code, ask the team or see Dr. Brian. Clean code conforms to a style guide.
  • Do not squash git commits from multiple days into one; the commits show when developers have been active.
  • If you are not familiar with the GitLab/GitHub workflow (issue --> feature branch --> pull request --> code review --> revisions.... --> merge) then please read this intro to GitLab Flow or watch this video.
  • Keep Git branches short; merge at least each iteration! Marking branches that exist for multiple iterations is tough.
  • Commit messages should mention if AI was used to help write the code.
• Actively seek to complete an equal share of the work and push the project ahead.
• Spend ~10h per week on the project, consistently.

Suggestions for all

• 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.
• Commit code each week. If your weekly schedule is too tight to do this, you'll likely find the course unsatisfying. You'll need to learn new skills each iteration and should plan to devote 10h/week to learning, coding, and the team.

Expectations for each Iteration

• Iteration 1
  • Get to know the team
  • Clone, build, and install/run the project
  • Read project README, on-boarding guides, etc.
  • Do tutorials (record topic and amount of time spent)
  • Start committing and merging code by week 3
    • If unable to commit code, Dr. Brian may shift up to 50% of the weight from iteration 1 to later iterations to maximize credit for contributions to the project.
• Iteration 2-4
  • Assign issues to self
  • Commit and merge code each week
  • Do code reviews each week

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. Expectation is spending ~10h/week, but marked on the productivity of this.
• Picking tasks to work on; completing those tasks.
• Commit work early and often.
• 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.
• Active in code reviews (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.
• Overall success of the project.

At the end of each iteration, each team member must submit the following to CourSys:

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

Peer Feedback (10%)

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

• Peer-feedback tool: Used to create the peer-feedback file for to submit to CourSys.
• Guide to writing peer feedback.
• Please type everyone's SFU user ID carefully! Otherwise I have to manually correct it.
• SFU User IDs should be the short version of your email. For example, mine is bfraser, not brian_fraser. You should not enter any underscores (_) or dashes (-).
• Your written comments about a teammate will be shared with them anonymously; they will also see an average of the letter-marks given to them by all teammates.

Code / Team Role (90%)

Marked largely based on code committed to master branch in GitLab by the code-merge-cutoff date for the iteration. Also considers changes to GitLab issues, GitLab comments on code (code reviews, ...), student's self evaluation, and performance of team roles (PO, SM, Repo). For a rough idea about the grading, see the marking rubricwhich is used for another class.

You must submit a short (~1p) personal iteration summary (.pdf) describing your contribution to the iteration. 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 GitHub merge-requests 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.
• Explain: Briefly (week-by-week) explain the time you spent on the project this iteration. Do this for each big task you did this iteration. Elaborate on tasks which are not visible in Git statistics (#lines of code, #merge-requests, commit/merge frequency....). For example:
  • For learning tasks, state the topic and time spent.
  • If you were the product owner, scrum master, or repo manager then explain the scope of your work in this role and comment on your success.
  • If you did 100% pair programming, state with whom you did this at the top of your document.
  • If you did pair programming on some merge requests or large commits, provide links and state with whom you did this in your document.
• Improve: How you want to improve your programming and/or group work. Discuss a big idea instead of more minor point.

To evaluate your code contributions, I will git pull the team's main (or master) branch after the code-merge-cutoff. 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.

Please do not use AI tools to generate any written content. This course is an opportunity for you to improve your writing! You may use AI tools to proof-read your writing, but not to generate it.

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 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 hostile behaviour will not be tolerated.