launchpad development|
Size: 2381
Comment:
|
Size: 3419
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 10: | Line 10: |
== 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. |
|
| Line 38: | Line 65: |
| == Notes for next call == | == Starting a project checklist == |
| Line 40: | Line 67: |
| * Not buildbot with Juju. Jenkins? Net positive, but in future question directives? Have time associated with answering that question, when we propose? Kind of like agile. == Notes from weekly review call == === Resolutions === * Next "new to us" project (like charms) when we do not know enough to write tests initially, we want to try this process: * Prototype (no tests, as a rule) * Squad discussion: lessons learned, design decisions * Begin coding, TDD. * We will read all ~yellow reviews when in feature development. * We are interested in using Go for our next project, if appropriate. * Short term goal: charm is ready for review next Tuesday, Feb 14. We would like to provide feedback to the juju team about our experience, and we are willing to take time to do so. Gary is reaching out to hazmat and SpamapS to see how it would be best to do this. === Tabled === * How will we share smaller design decisions that we learn during the day? The daily call is good but not good enough. IRC? micro-blogging? |
* 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
