Size: 3419
Comment:
|
Size: 3448
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 32: | Line 32: |
XXX |
|
Line 37: | Line 35: |
* Construct plans for the session |
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
- 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.
- Construct plans for the session
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