Skip to content

Latest commit

 

History

History
78 lines (51 loc) · 3.66 KB

Phase3Handout.md

File metadata and controls

78 lines (51 loc) · 3.66 KB
Raw

Phase 3 - Second Implementation Phase

The main goal of this phase is to finish most of the implementation of your project.

As always, it is up to you to choose what to implement, and how much work to put into this phase. We expect you to try to get as much work done as possible, while taking into account your schedule.

Important: To ensure that you're not planning to do too much or too little, you must get your release plan approved by your TA by Friday, Nov 7, at 8 pm.

Another goal of this phase is to get a better understanding of the Kanban model, and compare it with the Scrum-like process you used in phase 2.

Deliverables

Live Demo

  • To be presented During tutorial, on Nov 19.
  • Short - Max' 10 minutes (including time for Q&A).
  • Presented by 2 team members
    • One doing most of the talking ("the navigator"), and the other runs things on the computer ("the driver").
    • The TA will choose the 2 students on the spot, so you should all be ready to present.
    • The two students get to decide who will be the navigator and who will be the driver.
  • It is your responsibility to verify that you have everything that you need for your demo (e.g. adaptors, cables, etc.). If you have any questions/requests, please use the discussion board or contact your TA in advance.

Phase3/Process.md

A short report describing your Kanban process. The report should include the following items:

  • The names of columns your team chose to use for the Kanban board.
  • The WIP (work in progress) limit(s) you chose.
    If you decide to change the limit(s) during the phase, we want to know about it, and we want to know why/how you decided on the new limit(s).
  • Details on how you used GitHub issues - Labels, naming conventions, enforcing WIP limits, etc.
    Pro-Tip: Here is a cool way of using GitHub issues.
  • Your opinion about using Kanban versus the Scrum-like process (from phase 2) for your project.
    • Short paragraph (300 words max').
    • We want to hear your opinion, not a general comparison between the two models.
    • Focus on your team and project, when comparing the two processes.

Phase3/CodeReview.md

  • Important: Although the code reviews will be marked individually, we ask you to submit them all to the team repo in a single file, Phase3/CodeReview.md.
  • The format of Phase3/CodeReview.md should follow this template.
    This template contains a fake review that should give you a clearer idea of what we want to see in a code review.
  • It is the team's responsibility to ensure that every team member is assigned a reviewer.

Marking Scheme

  • Team 75%
    • Live Demo 20%
    • Phase3/Process.md 15%
    • Overall TA evaluation of the project, 40%
      • Progress was made consistently throughout the phase. 8%
      • Most members of the team contribute to the code, and find ways to work together effectively. 7%
      • Code quality and good software design practices. 12%
      • Product quality - Features, UX (i.e. user experience), making product decisions with the user(s) in mind, etc. 13%
  • Individual 25%
    • Code review 15%
    • Participation 10%
      • We will use the commit log and GitHub issues to determine individual participation.
      • If you have done significant work that is not reflected by commits or issues, make sure your TA is aware of it.