12KB

原始文件 Blame 文件历史

Sprint Retrospective

Sprint: 4 Date: 2026-09-29 Facilitated by: scrum-master, per process/05_sprint_retrospective.md Inputs used: backlog/sprints/sprint-4.md (Daily Scrum Log + Execution Order), backlog/backlog.md (Sprint 4 Review outcome), backlog/epics/02_template_designer_gui_foundation.md and backlog/epics/03_csv_integration_and_field_mapping.md (Sprint Review verification notes), logs/technical_debt_log.md, logs/impediment_log.md (both untouched this sprint — confirmed via diff, not assumed), logs/process_improvement_log.md (Sprint 3's “Watching” entry), backlog/sprints/sprint-3-retrospective.md (for follow-through check). No live human team to poll in real time; subjective signals are synthesized from dev-team's own daily-scrum notes and product-owner's independent review notes.

Signals

Objective:

3/3 committed stories Done (18/18 points), sprint goal assessed “met in full” at Sprint Review (backlog/backlog.md, Sprint 4 Review outcome).
Test suite grew from 223 (Sprint 3 close) to 288/288 — 65 new tests across desktop and CLI projects.
Zero new impediments and zero new technical debt logged this sprint (confirmed by diff, not just absence of mention) — notable given the sprint's work (rotation geometry, bounding-box math, vendor sign-convention discovery) was inherently more error-prone than an average sprint's.
Two epics closed outright this sprint: CSV Integration and Field Mapping (4 of 4 stories) and Template Designer GUI Foundation (6 of 6, having been reopened specifically for the rotation work).
The Sprint 3 retrospective's one “Watching” process item — product-owner's Sprint 3 review leaning on dev-team's pre-written verification notes for 3 of 4 stories — did not recur. This sprint, dev-team was explicitly instructed not to touch epic “Status:"/verification content, and all three stories’ Sprint Review verification notes were authored fresh by product-owner at review time, independently assessing evidence rather than inheriting dev-team's framing (see “Follow-up” below).

Subjective (from dev-team's daily-scrum notes and product-owner's independent review):

Empirical-verification-before-coding discipline showed up a third distinct time this project: before writing any rotation render code, dev-team probed the real Debenu DLL to confirm the rotation-direction sign convention (positive angle is counterclockwise in PDF space) rather than assuming it — the same discipline as Sprint 3's throughput-hypothesis probe and CSV-token-format spec check, now demonstrated on a third, unrelated kind of question.
Sizing accuracy showed a concrete positive signal: Batch 3's sizing note (written during backlog refinement, before implementation) predicted it would reuse Batch 2's panel/canvas sync plumbing with no new wiring needed — and the actual implementation confirmed exactly that. This is evidence the “code-inspection-backed sizing” practice introduced in Sprint 3 is predictively accurate, not just a retrospectively-justified estimate.
Honest self-reporting continued with good judgment, not just volume: a testing-tooling focus glitch (SetForegroundWindow failing once during Batch 3's live GUI verification, briefly misdirecting some keystrokes) was caught from screenshot evidence, worked around, and reported plainly — but correctly not logged as technical debt, since it's a verification-tooling artifact, not a product defect. Distinguishing “worth reporting” from “worth logging as debt” is a sharper judgment call than Sprint 2-3's debt entries required.
“Leave it better than you found it” continued inline: a TemplateDesignerForm.MinimumSize GUI bug (too small for the two new rotation panel rows, clipping them) was caught live during verification and fixed same-batch, not deferred.
Dependency-ordered batch swarming held for a fourth consecutive sprint without deviation (Batch 1 and 2 independent and pulled by priority, Batch 3 correctly gated on Batch 2).

What went well

Full follow-through on all four Sprint 3 retrospective action items, including a clean, structural resolution of the one process watch item (see “Follow-up” below) — the fourth clean full-follow-through sprint in a row counting the watch item's resolution as a follow-through, not just a repeat of prior actions.
Two full epics (Template Designer GUI Foundation, CSV Integration and Field Mapping) are now genuinely Done outright, each verified against every one of their stories’ acceptance criteria, not just “the last story landed.”
The empirical-verification habit named as a strength in Sprint 3 wasn't a one-off — it showed up again on a materially different kind of question (a rendering geometry/sign-convention question, not a performance or format question), suggesting it's becoming a durable team habit rather than a lesson tied to one specific investigation.
Zero new technical debt on a sprint with real geometric/rendering complexity is a meaningfully stronger signal than zero debt on a low-risk sprint would be — and the one rough edge that did surface (the tooling focus glitch) was triaged correctly rather than either buried or over-logged.

What didn't go well

Nothing rises to a real finding this sprint. The closest candidate — the SetForegroundWindow testing-tooling glitch — was self-caught, self-corrected within the same verification pass, and correctly kept out of the technical debt log since it never reflected product behavior. Naming it here for completeness rather than manufacturing a larger problem where the evidence doesn't support one.

Patterns / Insights (prioritized)

(Process-level) The Sprint 3-named PO-review-independence watch item is resolved, not just “not recurred by luck” — this sprint structurally separated dev-team's implementation evidence from product-owner's own acceptance-criteria authorship (dev-team was told not to write epic verification notes; product-owner wrote all three independently). Close the watch item in logs/process_improvement_log.md rather than carrying it forward as an open monitor.
(Team-level) Empirical-verification-before-coding is now demonstrated across three distinct, unrelated kinds of questions (throughput root cause, template token format, rotation sign convention) — stable enough to treat as a default team habit, not something that needs re-earning each sprint.
(Team-level, new evidence) Code-inspection-backed sizing (introduced Sprint 3) produced a sizing note whose specific technical claim (plumbing reuse) was later confirmed exactly by the real implementation — a concrete data point that this practice is working as intended, worth keeping as the default sizing approach for render/canvas-touching stories going forward.
(Product-level, not a process/kit matter) With epics 02 and 03 both fully Done, this is a natural moment for release-planner-level thinking about what a first releasable milestone looks like — routed as an observation for whenever the user wants that conversation, not a retro action here.

Kit-level decision

No new kit edit proposed. The one open item from logs/process_improvement_log.md (PO-review independence, logged 2026-09-22) is marked Resolved below — it never needed a formal process-file change; it resolved through how work was delegated this sprint (product-owner writing review notes independently, dev-team leaving epic status untouched), which is exactly the “watch and see whether the natural behavior holds” outcome that entry's own resolution note anticipated. See logs/process_improvement_log.md for the updated entry.

Action Items (added to Sprint 5's plan)

Continue empirical vendor/spec verification before implementing render- or format-affecting code — no process change, a standing expectation now demonstrated three times — owner: dev-team — due: ongoing.
Continue live actual-built-artifact verification for every GUI-facing story — owner: dev-team — due: ongoing.
When backlog/epics/08_composite_address_controls.md is next refined and sized, apply the same code-inspection-backed sizing rigor used for the throughput and rotation stories, especially to “Mix static text and CSV fields within a single text element” — flagged in that epic itself as the biggest render/format-compatibility risk in the whole epic — owner: dev-team (sizing), product-owner (facilitating) — due: whenever epic 08 is next refined.
No further monitoring needed on PO-review independence — watch item resolved this sprint, closed out, not carried forward as an open action — owner: scrum-master — due: n/a (closed).

Deferred / lower-priority ideas (kept, not discarded)

Whether the GUI verification tooling's focus-stealing reliability (SetForegroundWindow) is worth hardening — revisit only if it recurs and risks masking a real defect behind a tooling artifact, not preemptively off a single self-caught instance.
AddressLineCollapser's current “lines sharing the same X position” grouping heuristic may need to key off “belongs to the same Address Control” once epic 08 lands — already flagged directly in that epic's own conversation notes; not duplicating as a separate action here, just cross-referencing so it isn't lost.

Follow-up on previous retro's actions

All four of Sprint 3's retrospective action items were carried into Sprint 4's plan and applied, confirmed via backlog/sprints/sprint-4.md's Notes section and Daily Scrum Log, plus this sprint's own review process:

Resolve the open 1,000,000-record file-size technical debt item before any story commits to rendering near that ceiling — Correctly not touched: no Sprint 4 story rendered anywhere near that scale, so this item remains open and untouched, exactly as expected, not a drop.
Continue live actual-built-artifact verification for every GUI-facing story — Applied: all three stories (blank-line collapse, rotation angle, drag handle) verified against the real built .exe, two of them with real Win32 input injection.
Continue verifying real spec/code before implementing rather than trusting stale story notes — Applied: the Debenu rotation-direction sign convention was empirically confirmed against the real DLL before any render code was written, exactly matching the story's own conversation-note requirement.
Watch whether product-owner's Sprint 4 review notes are written independently at review time versus carried over from dev-team's own pre-written verification text — Resolved, not just watched: this sprint structurally enforced the independence by instructing dev-team not to touch epic “Status:"/verification content at all, and product-owner wrote all three stories’ Sprint Review verification notes fresh, citing and independently assessing dev-team's evidence rather than inheriting its framing (see e.g. the rotation-angle story's note explicitly judging the sizing note's flagged risk as “genuinely resolved rather than papered over” — an independent judgment call, not a restatement).

No drops. This is the third clean full-follow-through sprint in a row (counting Sprint 3's own clean follow-through on Sprint 2's actions).

Anti-patterns checked

No follow-through on prior retro actions: Ruled out — all four Sprint 3 actions were applied or structurally resolved, not just referenced (see above).
Blame-focused discussion: Ruled out. The one imperfection found (the tooling focus glitch) is described as a tooling artifact, never attributed to an individual or treated as a mistake worth dwelling on.
Hidden mini-waterfall within the sprint: Ruled out. Each batch was designed, built, tested, and live-verified together in one pass, consistent with Sprints 1-3.
Avoiding an obvious known problem: Ruled out — there wasn't one to avoid this sprint, and the one candidate (the tooling glitch) was surfaced and addressed immediately rather than left for someone else to find.
Status-theater (named in Sprint 1, improved in Sprint 2, still absent in Sprint 3): Ruled out again. Evidence this sprint is unusually concrete even by this project's standard — a pixel-ink-centroid regression test proving the rotation pivot is correct (not just “it looked right”), and an exact full-floating-point XML value match proving drag-to-rotate persistence (not just “the number looked right in the UI”).
Review rubber-stamping (the Sprint 3-named watch item, checked explicitly here rather than assumed away): Ruled out with direct evidence — see “Follow-up” item 4 above.

12KB 原始文件 Blame 文件历史