Introducting the legacy code project (10 minutes mini-lecture/discussion)

We’ll go over this material:

Please pay attention during this discussion; it’s short, and it has important information about 25% of your course grade.

Fill out CATME PeerEval3 now (in class, but after announcements)

If you didn’t already fill out your CATME PeerEval3 survey, please do it now. You may spread out at the unused tables for privacy; when finished return to your original table and start preparing for the retro.

Everyone should finish the CATME survey before starting today’s retro.

Please don’t work on that during Conrad’s announcements though. The announcements are short and have important information about how the legacy code project will work.

Retro3 (approx 2:15-2:45)

Click the triangle for instructions

Details of how to do Retro 3

Before deciding on a new experiment, have a discussion of the experiment from your last retro.

  • Read the experiment from your Retro2 document.
  • In your Retro3 document, make a section “Retro2 Experiment”
  • Copy/paste the description of the experiment.
  • Then, invite each member of the team to write something on the slack channel indicating whether they thought the experiment had a successful outcome, a failed outcome, an indeterminate outcome (can’t tell) or a mix, and why. But don’t press enter until there’s a signal that everyone is finished.
  • Then you call all press enter and see what each other wrote.
  • Discuss. If possible come to a consensus summary. If a consensus doesn’t emerge after a few minutes of discussion, then you can “agree to disagree”.
  • Write down either a summary of your consensus, or a summary of your differing opinions.

Then, come up with a new experiment for this Retro. It can be a variation on the old one (i.e. a different approach to the same problem), or could be entirely different (some other aspect of the team’s performance.)

Sprint Planning (approx 2:45-3:15pm)

Goal: Each team member should have an issue in the “in progress” column on Kanban board before you leave today.

What to do:

  • Look over the issues list for your repo (see issues link in table below)
  • Find an issue to work on, and claim it; discuss this with your team
    • If it’s a large issue, consider working in pairs.

    • Go into the issue, find the place that says Assignees / No one—assign yourself and click to assign yourself (and your pair).

      image

    • But note that you may need to create smaller issues from it
    • While some issues are small and can be moved onto the Kanban board directly, some issues are “epics” that need to be decomposed into smaller issues first!
  • If your issue needs to be broken down, create at least one smaller issue (the first one you plan to work on), and add it to your issues list.
  • Assign that smaller issue to yourself, and add it to the Kanban board.

For more information on sprint plannings, see: https://ucsb-cs156.github.io/m23/lab/project.html

Team
(Links to Slack)		 Repo Issues Kanban PRs Merged Project
m23-9am-1 Repo Issues Kanban PRs Merged gauchoride
m23-9am-2 Repo Issues Kanban PRs Merged gauchoride
m23-9am-3 Repo Issues Kanban PRs Merged gauchoride
m23-10am-1 Repo Issues Kanban PRs Merged happycows
m23-10am-2 Repo Issues Kanban PRs Merged happycows
m23-10am-3 Repo Issues Kanban PRs Merged happycows
m23-10am-4 Repo Issues Kanban PRs Merged happycows

Optional:

  • If your team finds it helpful, you can create an extra columns on the Kanban board called “Epics in Progress” and “Epics Done”.
  • In this column you can add the issues for any Epics the team is working on, and move them to Done when complete.
  • Some teams also add a column for the “Icebox”, which is a place that stories go when the team has decided not to work on them in the near future, but might come back to them later if/when other work is finished.