Chapter 25 — Team project studio
Lesson map
Lesson 25 published. Map, example, EX073.
flowchart TD
N0["Learning outcomes"]
N1["25.1 The project"]
N2["25.2 Planning"]
N3["25.3 Dividing work"]
N4["25.4 Reviewing"]
N5["25.5 Increments"]
N6["25.6 Retrospective"]
N7["Working agreements"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX073"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["25.1 The project"]
N2["25.2 Planning"]
N3["25.3 Dividing work"]
N4["25.4 Reviewing"]
N5["25.5 Increments"]
N6["25.6 Retrospective"]
N7["Working agreements"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX073"]
[Learning outcomes]
|
v
[25.1 The project]
|
v
[25.2 Planning]
|
v
[25.3 Dividing work]
|
v
[25.4 Reviewing]
|
v
[25.5 Increments]
|
v
[25.6 Retrospective]
|
v
[Working agreements]
|
v
[Worked example] --> [Exercise EX073]
Learning outcomes
You will (1) plan a team project; (2) divide work; (3) review each other's changes; (4) deliver in increments.
25.1 The project
Diego's team of three builds a shared "client security status" page showing inventory, open advisories and drift for each client. The page answers the questions clients and owners most often ask Brightwave: what each project uses, which advisories are open and whether the site runs the approved release. It reuses data the nightly job already produces, so the team builds a view rather than a new collection process. Clinic contacts can check their own status without emailing the agency. The page also gives Diego's team a real product with real risks to manage.
25.2 Planning
They write a short plan: users, data, risks and a first version in two weeks. Listing the page's risks early shapes its design from the very first version. The plan names the page's users, staff and client contacts, notes that inventory and advisory data could help an attacker choose targets, and therefore marks access control as the first risk. The two-week first version is small enough to finish and review properly. The plan also states that tests use synthetic client data only. Each item in the plan has a named owner and a target date.
25.3 Dividing work
One builds the data import, one the page, Diego the access checks and tests. Diego takes the access checks because the page shows sensitive information about clients' weaknesses. Splitting the work this way lets each person own one part while reviewing the others. The data import person also handles the case where the nightly job has not yet produced a report, so the page shows that gap instead of stale data. The split also matches each person's strengths, which the team discussed openly at the start.
25.4 Reviewing
Every change gets a review; reviewers check authorisation and data shown. Reviews within one working day keep work flowing, and nobody merges their own change. Each reviewer checks two things beyond the code itself: who can see each page, and whether the data shown is limited to what that viewer needs. The authorisation line added to the checklist came from a review that caught all clients being visible to any staff member. Reviewers leave written comments so the reasoning remains visible later.
25.5 Increments
The first version shows inventory only; advisories and drift come in later increments. Starting with inventory alone gives clients something useful early while the riskier advisory view is still being designed. When the second increment runs late, the team moves drift to the third increment instead of skipping reviews. Each increment goes through the same review and test steps, so the page grows without losing the controls built into the first version. Each increment ends with a short demonstration to Aiko before the next one starts.
25.6 Retrospective
After each increment, the team notes what went well and what to change. Retrospectives are kept short, about fifteen minutes, and the notes are written down. After the second increment, the team notes that reviewing within a day kept work moving, while one estimate was too optimistic because of the authorisation work. They adjust the plan for the third increment accordingly and keep the review agreement for later projects. The notes also help the next placement student understand why the page works as it does.
Working agreements
The team agrees how to work before starting: daily ten-minute check-ins, reviews within one working day, and no merging of one's own changes. They also agree that tests use only synthetic client data. Having these written down helps when the second increment runs late: instead of skipping reviews, they move the drift feature to the third increment. The page's first version is shown to Aiko after two weeks as planned, and clinic contacts begin using it in the following month. Their feedback, mostly about wording, shapes the second increment. The retrospectives also show that reviews within a day kept work flowing, so the agreement is kept for later projects.
Handover of the page
At the end of the project, the team writes a short note on how the page works, who owns it and how to add a client, so the page keeps working after the placement ends.
Worked example
In review, a teammate notices the status page would show all clients to any staff member. Access is limited so client contacts see only their own projects, and the review checklist gains an explicit authorisation line.
Synthetic case. The project is synthetic.
Errors and limits
Small increments make reviews easier and problems smaller.
Exercises
- EX073 — Project. What did the team build? Rubric: 3 = client security status page; 2 = partial; 1 = vague; 0 = none.
- EX074 — Diego's part. What did Diego build? Rubric: 3 = access checks and tests; 2 = partial; 1 = vague; 0 = none.
- EX075 — Review catch. What did review catch? Rubric: 3 = all clients visible to anyone; 2 = partial; 1 = vague; 0 = none.
Synthesis
Plan, divide, review and deliver in steps.
Continue studying — chapter 25 of 30
← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →