Chapter 25 — Team project studio

Chapter 25 — Team project studio

Lesson map

Lesson 25 published. Map, example, EX073.

flowchart TD
  N0["Learning outcomes"]
  N1["25.1 Planning as a team"]
  N2["25.2 Dividing responsibilities"]
  N3["25.3 Reviewing each other's work"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX073"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["25.1 Planning as a team"]
  N2["25.2 Dividing responsibilities"]
  N3["25.3 Reviewing each other's work"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]

[Learning outcomes]
    |
    v
[25.1 Planning as a team]
    |
    v
[25.2 Dividing responsibilities]
    |
    v
[25.3 Reviewing each other's work]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX073]

Learning outcomes

You will (1) plan work as a team; (2) divide responsibilities; (3) review each other's work.

25.1 Planning as a team

In the studio module Lucas joins three classmates to build an improved monitoring dashboard for the makerspace. They plan in two-week cycles, agreeing goals, tasks and a short demonstration at the end of each cycle. They keep a shared board of tasks and a decision log. The makerspace manager attends demonstrations and gives feedback. Planning in short cycles lets the team adjust early when something does not work, rather than discovering problems at the end. Ms Adebayo assesses both the product and how the team worked together throughout.

25.2 Dividing responsibilities

The team divides work by strength and interest: one member builds the data collection, one the dashboard pages, one the alert rules and Lucas the testing and documentation. Each piece has an owner and a reviewer. They agree interfaces between pieces early, such as the format of data passed from collection to the dashboard. Clear division prevents duplicate work and gaps. They also agree that only read-only access to nodes and the database will be used, so their project cannot affect live credits or bookings at the makerspace.

25.3 Reviewing each other's work

Every change is reviewed by another team member before merging. Reviews check correctness, clarity and safety: does the code only read data, are errors handled, are credentials kept out of the code? Lucas's review catches a credential accidentally written into a configuration file in the repository; it is removed, rotated and the file added to the ignore list. Peer review spreads knowledge and catches mistakes that authors overlook. The team finishes the dashboard on time, and the manager adopts it for daily use the following month.

Worked example

The team builds a read-only dashboard in two-week cycles, and Lucas's review catches a committed credential that is removed and rotated.

Synthetic case. The team, project and review are synthetic.

Errors and limits

Skipping review lets mistakes like committed credentials reach shared repositories.

Exercises

• EX073 — Cycle length. How long is each planning cycle? Rubric: 3 = two weeks;; 2 = 2 weeks;; 1 = six months;; 0 = none.
• EX074 — Lucas's responsibility. What does Lucas own in the team? Rubric: 3 = testing and documentation;; 2 = testing;; 1 = dashboard pages;; 0 = none.
• EX075 — Review catch. What did Lucas's review catch? Rubric: 3 = a credential written into a configuration file;; 2 = committed credential;; 1 = a typo;; 0 = none.

Synthesis

Short cycles, clear ownership and peer review produce safe team results.

Continue studying — chapter 25 of 30

← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →