Project

Project Description

In your assigned group of ~4 students, complete three iterations of development on an assigned project. The details about this project, each iteration, and your group will go up here later in the course, after we complete the assignment component over the first six weeks. Your group will have to create a GitLab repository to be used for all three iterations, so be sure to add the TAs and instructor as members on the GitLab page to allow us access for marking.

Your grade for the project will largely be based on the quality of your app and code, marked as a group. However, portions of your mark will come from your individual contribution as rated by your group members and possibly evaluated by the instructor/TA. At the end of each iteration, you will provide constructive feedback to your group members on their strengths and areas for improvement. Students with poor participation with their team will earn a poor grade or be removed from the group. In cases where students contribute very little, their individual contribution may significantly affect their grade.

Kickoff

• Project kickoff slides
• Project structure document with details on Scrum Master, task list, and application constraints. Plus info on required documents in your repo.
• Initial project description, team meeting, and software architecture discussion in class.
• Know which team you are in! You should be able to check on CourSys, and from there be able to send emails to the group and discuss setting up a GitLab project.
• Suggested steps once you talk to your group:
  • Assign the following roles to team members for Iteration 1. Will rotate in later iterations.
    • 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 (TA/Instructor) for project clarifications. Takes lead in ensuring all required features for the iteration are being developed.
    • 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. No additional duties.
  • Setup how/when you'll (virtually) meet as a team. See suggestions at bottom of page.
  • Your group can be found in CourSys, use that same name/number when creating your GitLab project. For example, if you are "Project Group 01", be sure your GitLab project name includes Group 01, even if you go for something like "Group 01 Team Cool Folks". Be sure to add the Instructor (jackt) and TAs (tirthp and kpathani) as team members on your group project for marking and technical assistance purposes!
  • Complete the Expectations and Accountability Exercise with your team first-thing to get the ball rolling.

Iteration 1

• User stories for Iteration 1 for required features and marks per feature.
• Data
  • Initial data set and list of all violations in dataset.
• Tutorials and Resources
  • Image Resources
    • Sample images
  • Workflow Tutorials
    • GitLab workflow with Merge Request: issue, feature branch, switching branches, commit/push, merge request.
    • GitLab workflow with Conflicting Changes: Resolving conflicting changes before submitting a merge request in Android Studio with GitLab.
• Due November 4th @ 11:59pm on CourSys. 10% per day late; max 2 days.
  • You may add a docs/readme2.txt file with any points you'd like to mention to the marker.
  • Create a document listing the Scrum roles for this iteration.
• Details on the Group Retrospective and Peer Review to come.
• [UPDATED] Retrospective done as a group, to be completed by November 6th @ 11:59pm on CourSys (will not be received late).
  • Retrospective form Must be completed as a team, one per team, and submitted on CourSys.
• Individual Peer-review: A private review to be completed separatly by each team member, evaluating the performance of your teammates. Complete this document and put your contribution scores in an Excel or Calc spreadsheet formatted like this example .csv file. To be submitted by November 6th @ 11:59pm on CourSys

Iteration 2

• User stories for Iteration 2 for required features and marks per feature.
• Data Downloading
  • Where to get data - directions on using the City of Surrey data set.
• Maps tutorials
  • Google Maps API Video: getting an API key and app showing map.
  • Google Maps API Project On loan from Dr. Brian Fraser, and uses his API key (hence password protected); your group must generate your own key and replace it in the google_maps_api.xml file under app/src/release/res/values/.
  • Google Maps API tutorial videos (produced by someone else; recommend by a student).
• Downloading
  • Using Postman to test a REST API.
• Due Wednesday, Nobember 18th @ 11:59pm on CourSys. 10% per day late; max 2 days.
  • You may add a docs/readme2.txt file with any points you'd like to mention to the marker.
  • Update your document listing the Scrum roles for this iteration.
• [UPDATED] Retrospective done as a group. To be submitted on CourSys by November 23rd @ 11:59pm (will not be received late).
  • Retrospective form Must be completed as a team, one per team, and submitted on CourSys.
• Individual Peer-review: A private review to be completed separatly by each team member, evaluating the performance of your teammates. Complete this document and put your contribution scores in an Excel or Calc spreadsheet formatted like this example .csv file. To be submitted by November 23rd @ 11:59pm on CourSys.

Iteration 3

• Due December 2nd @ 11:59pm on CourSys. 10% per day late; max 2 days.
• User stories required for this iteration.
• Suggested Resources
  • Demo code for database operations and internationalization
  • SQLite database: simple example
  • DB to ListView: Populate a complex ListView with text & image IDs from the SQLite database
  • Internationalization: Translating to multiple languages
• [UPDATED] Retrospective done as a group. To be submitted on CourSys by December 14th @ 11:59pm (will not be received late).
  • Retrospective form Must be completed as a team, one per team, and submitted on CourSys.
• Personal Project Retrospective: A project-wide retrospective done individually. To be submitted on CourSys by December 7th @ 11:59pm (will not be received late). Submit as part of the "Iteration 3 Peer Review" activity on CourSys.
  • Personal retrospective form Must be completed individually and submitted on CourSys.
• Individual Peer-review: A private review to be completed separatly by each team member, evaluating the performance of your teammates. Complete this document and put your contribution scores in an Excel or Calc spreadsheet formatted like this example .csv file. To be submitted by December 14th @ 11:59pm on CourSys.

Team & Project Support

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 text 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. Thomas 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. Thomas. Clean code conforms to a style guide such as the suggestion one for this course.
• Actively seek to complete an equal share of the work and push the project ahead.

Suggestions for all groups

• Find a good method for team meetings. Since meetings will likely have to be online, I suggest using Slack.
• When scheduling 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.

Extra group-related support is available for any student or team to draw on. Example support includes:

• Help discussing challenges with your team to work out a solution.
• Discuss the situation with me (Jack) to develop a strategy to solve the problem.
• TA or I can sit in on a group meeting to help the group settle into working together.
• If some members are not contributing equally, TA or I can highlight to them the need for more high-quality contributions, and the consequences of not participating.
• TA and I can watch GitLab repositories to ensure a reasonable amount of activity by all group members. I may email teams if I see a lack of commits from some team members.
• If pair-programming, please put other programmer's SFU ID at the start of the commit message. For example, if Able, Betty (id bty1@sfu.ca), and Cassandra (id csndr@sfu.ca) work together on code that is checked in on Able's computer, then the first line of the commit message should be like: "[bty1, csndr] Connect UI to game model"

Handling Group Problems

If you feel a group member is not pulling their weight and should be considered for probation (see below), include the text "DROPPED THE BALL" in your iteration evaluation (confidential section OK). If a student is found to not be contributing well to his/her team then Dr. Thomas will do the following:

• Email the whole team highlighting the situation. All team members are invited to reply and clarify the situation (such as if the person was working on something not visible in Git).
• Meet with team as a whole or with individual members. The group problem will be explained, and the required changes in the student's performance will be outlined. Team members can contribute to this discussions by highlighting their needs and views.
• An under-performing student may get a reduced grade on that iteration (~50%); other team members may have their grades scaled up if their mark suffered as a result of other's poor performance.
• An under-performing student may be placed on probation; see below.

Probation

A student who is not meeting expectations for contributions to the project may be told they are on probation within their group (often at the end of an iteration where they did insufficient work). The student will be told how long probation is to last (often one iteration), during which time the student must demonstrate that they have changed their behaviour and become a contributing team member. Discussion likely focuses on the details of what went wrong, and what must change (notes will be taken to ensure required changes are document).

At the end of probation, the student's contribution will be evaluated against what they were asked to do. If they have been a productive member of the team, their probation ends with no extra consequences (may still have reduced grade for earlier work). Otherwise, the student on probation will be removed from the group.

If a student is removed from a group then the remaining members of the team will either complete less of the requirements, or their product polish can be less. The remaining team members must analyze the iteration's use case features and tell the instructor their plan for what the team will implement.

Students removed from groups will either get 0 on remaining work, or be required to complete some/all of the work individually. The student must analyze the iteration's use case features and tell the instructor their plan for what they will implement that iteration. It is likely that a 25% penalty will be applied for the failure to function in the team.

Dr. Thomas may make adjustments to these guidelines to better address individual situations.