Size: 24
Comment:
|
Size: 3419
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
Yellow Squad Wiki Home | = Yellow Squad Wiki Home = https://launchpad.net/~yellow/+mugshots Slogan for public consumption: '''''Go go Golden Horde!''''' Slogan when we feel tired: '''''Go go [[http://en.wikipedia.org/wiki/File:Banana_slug_closeup.jpg|Yellow Banana Slugs]]!''''' Current project is [[LEP/ParallelTesting]] . == Daily call checklist == * Review cards in Deployment, QA, Active (slack, multi-branch, and quick), and Miscellaneous WIP/Done lanes. * Have any non-Done cards been in the same lane for more than 24 hours? If so, discuss pairing and problem solving. * Are the developers stuck? Consider "convening a panel" after this call (see checklist below) to become unstuck. * Have they been in the same lane for more than 48 hours? If so, consider adding or rotating programmers. * Is no-one available for regular pair programming? If so, strongly consider blocking an active card in order to get that developer(s) available for focusing on the non-moving card. If more than one card is not moving, consider focusing on one at a time. * Is a card Done that had been a problem (non-moving)? If so, record it on a kanban miscellaneous card [any other ideas?] as a topic for the Friday review call. * Do any non-done cards on the board have deadlines? If so, review as necessary. * For each person, mention any items that the squad should know: remind people of reduced availability, request help such as reviews or pair requests, etc. == Unsticking panel checklist == * Take note of when the panel starts. * Describe problem avoiding mentioning your own (stuck) solutions and ask for solutions and approaches. * If that fails, describe your own solution and ask for solutions and ideas. * If the panel has taken longer than 20 minutes, stop. Arrange for a pair programming or consultation as necessary. * If no-one has said anything other than filler for three minutes, stop. Arrange for a pair programming or consultation as necessary. Consider rotation. == Pair programming observer checklist == XXX * be actively skeptical. * watch the other person's back. * When something doesn't make sense, this is a trigger for both parties to check assumptions and step back. == Weekly review call checklist == * Briefly review where we are in project plan. * Any new tricks learned? * Collaboration tricks? * Debugging tricks? * Communication tricks? * Checklists? Processes? * Any nice successes? * Can you attribute your success to anything beyond the innate brilliance of yourself and your coworkers? * Any pain experienced? * Questions to ask: * Are there any cards that are/were taking too long to move? * Are they blocked? * Are we spinning our wheels? * How long is too long? * Are we not delivering value incrementally? * Are we not collaborating? * Did we duplicate any work? * Did we have to redo any work? * Did we misunderstand the technical requirements, the goal, or a process? * Was the ordering of tasks that we chose broken? * Can we learn from it? * Checklist? * Experiment? * Another process change? == Starting a project checklist == * Prototype (no tests). Consider competing prototypes. * Have a squad discussion about lessons learned and design decisions. * Begin coding with TDD |
Yellow Squad Wiki Home
https://launchpad.net/~yellow/+mugshots
Slogan for public consumption: Go go Golden Horde!
Slogan when we feel tired: Go go Yellow Banana Slugs!
Current project is LEP/ParallelTesting .
Daily call checklist
- Review cards in Deployment, QA, Active (slack, multi-branch, and quick), and Miscellaneous WIP/Done lanes.
- Have any non-Done cards been in the same lane for more than 24 hours? If so, discuss pairing and problem solving.
- Are the developers stuck? Consider "convening a panel" after this call (see checklist below) to become unstuck.
- Have they been in the same lane for more than 48 hours? If so, consider adding or rotating programmers.
- Is no-one available for regular pair programming? If so, strongly consider blocking an active card in order to get that developer(s) available for focusing on the non-moving card. If more than one card is not moving, consider focusing on one at a time.
- Is a card Done that had been a problem (non-moving)? If so, record it on a kanban miscellaneous card [any other ideas?] as a topic for the Friday review call.
- Do any non-done cards on the board have deadlines? If so, review as necessary.
- Have any non-Done cards been in the same lane for more than 24 hours? If so, discuss pairing and problem solving.
- For each person, mention any items that the squad should know: remind people of reduced availability, request help such as reviews or pair requests, etc.
Unsticking panel checklist
- Take note of when the panel starts.
- Describe problem avoiding mentioning your own (stuck) solutions and ask for solutions and approaches.
- If that fails, describe your own solution and ask for solutions and ideas.
- If the panel has taken longer than 20 minutes, stop. Arrange for a pair programming or consultation as necessary.
- If no-one has said anything other than filler for three minutes, stop. Arrange for a pair programming or consultation as necessary. Consider rotation.
Pair programming observer checklist
XXX
- be actively skeptical.
- watch the other person's back.
- When something doesn't make sense, this is a trigger for both parties to check assumptions and step back.
Weekly review call checklist
- Briefly review where we are in project plan.
- Any new tricks learned?
- Collaboration tricks?
- Debugging tricks?
- Communication tricks?
- Checklists? Processes?
- Any nice successes?
- Can you attribute your success to anything beyond the innate brilliance of yourself and your coworkers?
- Any pain experienced?
- Questions to ask:
- Are there any cards that are/were taking too long to move?
- Are they blocked?
- Are we spinning our wheels?
- How long is too long?
- Are we not delivering value incrementally?
- Are we not collaborating?
- Did we duplicate any work?
- Did we have to redo any work?
- Did we misunderstand the technical requirements, the goal, or a process?
- Was the ordering of tasks that we chose broken?
- Are there any cards that are/were taking too long to move?
- Can we learn from it?
- Checklist?
- Experiment?
- Another process change?
- Questions to ask:
Starting a project checklist
- Prototype (no tests). Consider competing prototypes.
- Have a squad discussion about lessons learned and design decisions.
- Begin coding with TDD