Previous Lecture | Lecture 16 | Next Lecture |
Lecture 16, Tue 11/01
Tue Lecture: First Retrospecive (Retro)
Reminder: Speed Advising Tomorrow
See announcement from last Thursday’s lecture
Speed Advising: Wed Nov 2, 2pm-6pm, HFH 1132, Refreshments Served.
Today (outline)
- Pause all work/submission for team02, and do the retro first
Then:
- if (done with team02), handle the submission of team02 (see instructions on Canvas)
- One submission per team is enough
- Make sure links are clickable
- Make sure you’ve made
phtcon@ucsb.edu
and your mentor admins in the app itself (on prod and qa) - Make sure you’ve shared the Heroku deployments (prod and qa) with whole team
- Check other Kanban board related things listed on Canvas
- Be sure current main branch is deployed on prod (qa may have any branch).
- else
/* not done with team02 */
: do a standup and more work on team02.
You may merge PRs and submit even if you don’t (yet) have 100% code coverage or mutation coverage, but there may be deductions for that, so continue working on that if you can make the time to do so. (If it’s fixed before we get around to grading it, there is no penalty, though that would be an extra PR.)
Retrospective: the heart of Agile
The core principle of Agile is “inspect and adapt”.
- It was “inspecting and adapting” that led the original authors of the Agile Manifesto to their ideas.
- It has been by “inspecting and adapting” that the Agile philosophy continues to grow and develop.
Inspect and Adapt is, in many ways, linked to the Scientific Method;
- we observe
- we form a hypothesis
- we do an experiment
All in the service of doing a better job of software development.
In a retro, the team stops, pauses, reflects, and most importantly comes up with an actionable change for their practice.
Today’s Retro
- Start by having everyone take 5 minutes to read through this article: https://ucsb-cs156.github.io/topics/agile/agile_retros.html
- Really read it! It has the instructions for the most important activity in today’s class
- Next, choose a leader for your retro. It should be someone that has read the instructions and is comfortable leading the group.
- Then, locate the Google Drive folder for your team. It should be linked in your Slack channel with a
gdrive
link this:
Check that each member of the team is able to access the folder.
In that folder, create a folder called Retros
and in that folder, create a document Retro1
Then follow the instructions in the https://ucsb-cs156.github.io/topics/agile/agile_retros.html article for Stop/Start/Continue retro.
In the document, write down who your retro leader is.
At the end of the process, you should have in your document:
- Name of person leading the retro at the top, and a list of who participated
- A document with three parts, “stop/start/continue”, and items from each member under the three categories
- Dot voting (three votes per team member participating) on the items in the document.
- A summary at the bottom on an “experiment” in the form “If we change X we hope to see Y result”
- This should be related to one of the top three items by votes that your group agreed on.
- A brief explanation of how you will know whether your experiment was or was not a success.
After the retro is done, you can:
- Ask a staff member to look over your GDrive document; they’ll check it to make sure it has the required elements:
- items from each member under start/stop/continue
- dot voting
- an experiment, including the criteria by which you can know whether the experiment was a success
- If done with team02, handle the submission of team02.
- else /* not done with team02 */: do a standup and more work on team02.