Previous Lecture | lect15 | Next Lecture |
lect15, Wed 11/17
UX Evaluation, 3rd Retro
Announcements
- As announced repeatedly, this week’s lab will be taken up by the group peer-evaluation lab08, so make sure to finish all points for lab06 (part2) before Section starts, and for lab07 before the end of the day, Friday. Today, please designate your leads for this evaluation (see below).
- Code Freeze for your projects will be two weeks later, Friday, Dec. 3rd, with Thanksgiving break in between, next week, Friday, 11/26!
- Project presentations will take place, as long announced and planned, during the final exam slot, Dec. 6th, 4-7pm.
- All documentation and the presentation video will be due at the end of Wednesday, December 8th.
Here, again, is the point percentage breakdown for grading that the teaching team plans to use for the “Final Product” 40% of the course grade:
- 15% Presentation
- 5% Idea, and Idea Refinement
- 25% Functionality, Quality (Reliability & Polish)
- judged by review of demonstration, user manual, peer review, teaching team testing
- 10% Technical Difficulty Implemented
- judged by review of code/scope taking into account team background/experience etc.
- 20% Implementation
- judged by review of Github code, PRs, etc.
- use the README.md to make clear the repository structure and guide through implementation effort!
- 15% Design Process
- judged by Design Document, Kanban Board, Meeting Logs, Github TEAM information, etc. Design Document should steer through the process.
- 10% Manual
End User Evaluation
You will likely not have time to conduct your own independent end user evaluation (prove us wrong if you do!), but this week’s peer group evaluation will be a step in that direction
Today: Designate a reviewer and reviewee contact for your team. Create a Review Placeholder.
Please list the names and Slack display names (separated by comma) of contact persons from your team in this table:
- reviewer contact: will coordinate the reviewing (working with the reviewee contact from the team you are peer-reviewing)
- reviewee contact: will be the contact person to work with the reviewer contact from the team that is peer-reviewing your team The rest of your team will be 100% focused on deploying and evaluating the software of the team you are evaluating, and the two designated contacts will help that effort whenever they don’t have anything to coordinate in their role.
As a team, create a Google Doc to capture the feedback from the team that is reviewing your product. The document should start as follows:
**Deployment and Product Feedback for Team <your team name>**
<link to your repo>
(Review in progress--leave this line here until review is final)
Please list the link to that document in your team folder as team/DEPLOY_FEEDBACK.md and, as the first action item of Friday’s lab section, communicate that link to the reviewing team.
Today (or at your schedule): Third and Last Retrospective
This is one of your last major opportunities to inspect and adapt on your path toward the goal line! This week’s lab there will be our peer evaluation where another team tests your deployment instructions and current state product, and then there is two more weeks of development until code freeze!
You already know the goal and procedure for Retrospectives from your previous retros. This Retrospective allows you to discuss things that are important to get to the best team productivity in this critical final final stretch to product deployment, documentation, and presentation.
-
In your team’s repo, under
team/retrospectives
directory, add a fileRETRO_03.md
capturing the following:# Retro #3 <date> * Led by: name-goes-here * Present: name1, name2, ... , nameN * Absent: name1, name2, ... ## Action item * a goal: identify something the team wants to get better at * a change: identify one thing that the team will change about how it works together * a measurement: identify at least one way to measure whether the change helped the team achieve the goal, or move closer to it. ## Optional * Record anything else you think the team might want to remember from this retro
-
After the Retro
Retro leader: add the following Section to
RETRO_03.md
:## Retro Assessment * A brief description of what retro outline or process you used. * A brief assessment of how it went. * A brief statement on how much any of the Retros changed the way you worked as a team (no correct answer here. Teams could be happy with the way they started operating from the get-go and Retrospectives would just be quick confirmations then, or teams could have tried a lot of different things based on their retro reviews. We just would like to know!)