Skip to content

Latest commit

 

History

History
171 lines (115 loc) · 8.17 KB

Phase2Handout.md

File metadata and controls

171 lines (115 loc) · 8.17 KB
Raw

Phase 2 - Implementation

IMPORTANT UPDATE

The marking scheme has been updated.

The main goal of this phase is to implement and present the first working version of your product.

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 being realistic about your busy 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 Saturday, Oct 25, at 9 pm.

Another goal of this phase is to get a better understanding of the Scrum model/framework. You will follow a scrum-like process, and will be asked to document and evaluate the process.

Team Deliverables

Live Demo

  • To be presented During tutorial, on either Nov 5 or Nov 12.
    You will need to coordinate with your TA which teams get to present on which date.
  • 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.

Phase2/Product.md

  • A report describing your product (i.e. The what, not the how).
  • Please keep it short (2 min' read, seriously).
  • Be informative, but concise.
  • You can use your submissions from phase-1 as a starting point.
  • Focus on the features that you built during this phase, not on future plans.

Phase2/Process.md

A report describing your scrum-like process. The report should include the following items:

  • A summary of your planning and review meetings for both sprints (i.e. 4 meetings in total).
    • Includes date and location.
    • Please keep it short, and give us the highlights.
    • Include important decisions you've made, and arguments for/against them.
    • Tip: You can use GitHub to label all the user stories you plan to complete during a sprint, and include a link to an issue search result (example) in your planning meeting summary.
    • For the review/retrospective meeting, we would like to see some numbers and/or interesting statistics.
      For example: Percentage of planned work that was actually completed, distribution of completed work among team members, percentage of planned work completed categorized by priority, etc.
      The point is to evaluate the estimations that you've made during the planning meeting.
  • A summary of your "daily" scrum meetings.
    • Please include date and location.
    • If you use a chat, you can simply copy-paste the highlight of the chat.
    • Otherwise, please give us a very quick summary.
      A good format would be a list, specifying the highlights of each member's update (each highlights should be 1-3 sentences long).
  • Description of how you used GitHub issue management system (e.g. naming conventions, labels, team's conventions, etc.)
  • Description of any other major decisions/conventions you may have made/used during the process, and why.
    • For example: Did you have a "scrum master"? Why? Do you think it was the right decision?

Individual Deliverables

The following files shoulds be submitted to the root of your personal repo.

proj-phase2-individual-contrib.md

  • Describe your most significant individual contribution. 10%
    • Must be a technical contribution (i.e. “I was in charge of documentation” doesn’t fly). For example: A nasty bug that you resolved, a component that you've implemented elegantly, a complicated problem that you had to solve, etc.
    • A good description should include links to specific commit(s) and/or issue(s) on GitHub.

proj-phase2-code-review.md

You do not need to submit this deliverable for this phase.
You will do code reviews during phase 3.

proj-phase2-short-answers.md

  • Answer the following questions (2-3 sentences for each answer)
    • What did you like the most about your Scrum-like process, and why?
    • What did you dislike the most about your Scrum-like process, and why?

Marking Scheme

  • Team 75%

    • Live Demo 20%
    • Phase2/Process.md 15%
    • Phase2/Product.md 15%
    • TA's evaluation of your project 25%
      • Delivered everything that was promised in the approved release plan. 10%
      • Overall product quality (e.g. interesting features, creative solutions to problems, attention to details, stable product, etc.) 9%
      • Code quality. 6%

  • Individual 25%

    • proj-phase2-individual-contrib.md 20%
    • UPDATE proj-phase2-code-review.md 10%
    • proj-phase2-short-answers.md 5%

Our Scrum-like Process

Scrum is used by teams where most/all members work full-time, usually in the same physical space, and the project is ongoing. Our situation is different, so we will adapt scrum to fit our realistic constraints.

Here is a description of the scrum-like process we would like you to follow.

The players

  • Development team - All members of the team.
  • Scrum Master
    • In a real agile team, the scrum master is not a member of the development team.
    • In our case, the “scrum master” will be a team member who volunteers to facilitate the process (e.g. Scheduling, organize note taking, recording the meetings, and/or anything else you might find useful).
    • It is up to you to decide whether or not to have a "scrum master". If nobody volunteers, or the team decides that it is unnecessary, that's totally fine.
  • There is no product owner.
    • The closest thing to a product owner is your TA, who has to approve your release plan.

The artifacts

  • Use GitHub issue management system to keep track of all user-stories/tasks.
  • It is up to you to decide on how to use the system (i.e. Which labels to use, naming conventions, how to assign/pick-up issues, how to prioritize stories, etc.)

The events

  • Sprints
    • Two sprints, each sprint between 7 to 10 days.
    • Different teams might have different scheduling constraints, so we’ll leave it up to you to decide on the exact dates.
    • The two sprints should be roughly of even length.
    • If your schedule permits, we suggest that you review sprint-1 and plan sprint-2 on separate days (to give you some time to reflect, and reach conclusions).
  • Sprint planning meeting
    • At the beginning of each sprint.
    • Try your best to get everybody to meet in person. In extreme cases, when scheduling is too problematic, consider using a video chat.
    • At the end of this meeting you should know which user-stories you plan/commit to implement during this sprint.
  • Daily Scrum meeting
    • We ask you to hold 2-3 of these short meetings during each sprint.
    • Try to get as many team members as possible.
    • You can run these meetings in person or via video/voice/text chat.
    • Remember, these are supposed to be short meetings (15 min’ max). The goals are to keep everybody in sync, and to exchange relevant information.
  • Sprint Review/Retrospective meeting
    • At the end of each sprint.
    • At the end of this meeting you should know how much of the planned work was actually done, and what are the next main challenges.
    • Tip: You’ll need to document this meeting, so please make sure you have enough time between reviewing sprint-2 and the due date.