Skip to content

Latest commit

 

History

History
92 lines (74 loc) · 5.48 KB

Phase1Handout.md

File metadata and controls

92 lines (74 loc) · 5.48 KB
Raw

Project, Phase 1 - Planning

For the first phase of the project, you will be using the various planning techniques we've learned in order to get ready for building your product. There are two main goals to this phase:

  • Understanding what product you want to build, and planning your first few steps.
  • Developing an efficient way of working together as a team (i.e. developing a process).

First Step

Get together with your team (you can use your team repo to exchange contact information), and choose one of the 2 project options or suggest one. Once you decide on a project, read this handout together, and make sure everybody is clear on what they need to do.

Note: You will not be allowed to switch projects after this phase, so please make sure you are happy with your choice.

Team Deliverables

All of your team’s deliverables should be submitted in a folder called Phase1, in the root of your team repo. (Your team repo will be created)

  • It is up to you to decide how to organize the files in the Phase1 directory, and which format(s) to use (e.g. PDF, text, etc...). Markdown (md) is prefered but not a requirement (Just try to make it easy for us to read it).
  • Make sure it is easy for the marker to read your submission.
  • Suggestion: You can create a README.md file in the root of your team repo, and link to your submition from there.

What information should be included in the submission?

Your submission should include the following information

  • Introducing the team (5 points)
    • One picture with all group members.
    • Short bio for each member (up to 150 words).
  • Choosing the project (5 points)
    • A short paragraph (up to 200 words).
    • Which option did you choose?
    • Why did you choose it?
    • How did you reach the decision as a group?
  • At least two Personas (5 point)
    • At least as detailed as the examples that appear in the lecture notes.
  • User Stories (20 points)
    • High-level stories to help you define the MVP.
    • More detailed stories to help you define your first release (i.e. The features you realistically plan to implement in Phase 2 of the project).
    • Detailed stories to help you plan your first iteration (iteration = 1 week of work).
    • We also want to see the lower-priority stories that you decide not to implement for the first release.
    • Stories should include priority and size/difficulty.
      If you specify the priority and/or size using numbers, please let us know what the numbers mean. For example, you might choose to specify the priority of a feature/story as
      • 1 - We must have this feature, without it our product has no value to our users.
      • 2 - Valuable feature, but we can still release a product without it.
      • 3 - Might be valuable, but we should look at it later.
  • MVP (15 points)
    • A short description (up to 300 words).
    • This description is meant to be read by a non-technical client.
    • The initial project descriptions are open for interpretation, and we expect different teams to end up with fairly different products. We want to know what makes your team’s product special. Think of it as if you are trying to convince a client to choose your team’s proposal over other proposals.
    • Here are examples of things you may want to mention:
      • Cool features that make your product unique.
      • Technical challenges you are planning to overcome, and, by doing so, have an advantage over potential competition.
      • Unique user experience, based on an insight about your users.
  • Release & Iteration Planning (10 points)
    • Which user stories are you planning to implement for your first release?
      That is, the features you will implement in Phase 2 (almost 3 weeks long) of the project.
    • Mention 3 user-stories/features/components that you decided to exclude from your first release, and explain why you decided to postpone implementing them.
    • Which user stories are you planning to implement in the first iteration? (Iteration = 1 week of work)
  • CRC cards (15 point)
    • CRC Cards that show a high-level design of your software architecture.
    • Choose 3 user stories you are planning to implement early on, and “play out” their scenario using your CRC cards.

Individual Deliverables

Your individual deliverable should be submitted in a file called phase1-peer-eval.md, in the root of your personal repo.

  • Evaluate yourself and each one of your teammates, and explain your evaluation in 1-3 sentences.

  • Use the following evaluation scheme:

    • 0 - Absent, non-communicating and/or destructive.
    • 1 - Significantly below average contribution.
    • 2 - Contributing but below average.
    • 3 - Average contribution.
    • 4 - Above average contribution.
    • 5 - Excellent contribution.

  • First entry is evaluating yourself. Mention briefly (what do you think are) your strengths and weaknesses.

  • For other entries, please make them sorted on the GithubUsername to make it easier for the TAs to consolidate this data.

  • We expect that most of the students are between 2 and 4.

  • 0, 1 and 5 are extremes, then you need to give a strong justification for such evaluation.

  • TAs might need to ask you to elaborate more on your peer evaluation (esp. if it is an extreme)

  • Please follow this format:

    * GitHubUsername1, NumericEvaluation - Self Evaluation Explanation
* GitHubUsername2, NumericEvaluation - Peer Evaluation Explanation
* GitHubUsername3, NumericEvaluation - Peer Evaluation Explanation
…