Iteration 3 Readiness & Pair-Programming CoP
本页目录· 7 条
Readiness is a decision supported by evidence
Pre-deployment readiness should answer: can the current build be safely demonstrated/submitted, and what risks remain? It is not the same as “all tasks moved to done”.
Product evidence
- Agreed user stories satisfy acceptance criteria.
- Critical paths and data flows work end to end.
- Known limitations are visible and appropriately prioritised.
- Usability, accessibility, security and data integrity checks are recorded.
- Build/version and deployment environment are unambiguous.
- Demo and recovery paths have been rehearsed.
Delivery evidence
- Definition of Done is met or exceptions are formally recorded.
- High-severity defects have disposition and ownership.
- Dependencies, credentials and external services are available.
- Repository and PGP links open for intended reviewers.
- CI/CD or manual release steps are repeatable.
- Rollback/restore path is known.
Pair-programming CoP workshop
Use the workshop to improve both code and shared practice:
- choose a risky or knowledge-concentrated story;
- state the user outcome and acceptance criteria;
- select a pairing mode and switch interval;
- narrate decisions and test assumptions;
- run the relevant checks;
- document what the second perspective changed;
- update the code, story, test or standard so the lesson persists.
Evidence from the session
- Pair / roles / time:
- Story or risk addressed:
- Assumption exposed:
- Defect or design change:
- Test/check added:
- Knowledge transferred:
- Follow-up owner:
- Governance/ePortfolio link:
Review questions
- Did pairing reduce a blocker or late defect?
- Is the knowledge now distributed beyond one member?
- Which practice should become a team standard?
- What is still unsafe, unknown or dependent before the Thursday readiness deadline?