Some months ago, I wrote a review of Atul Gawande’s Checklist Manifesto and about using checklists in software development.
I’m pleased to say that it looks like I might get a chance to follow-up on that idea more in the coming year. I’ll keep you updated. In the meantime, here are few ideas on the subject from one of my notebooks. (I appear to be going through these “historical documents” in a rather random chronological order.)
When are the pause points where we might use checklists?
- Before starting to design
- Before starting to code
- Before code review
- Before submitting changed files
- Before QE-led testing
Who might be included in the check-off activities? The goal is to catch problems and communicate what’s happening.
- Coder/Developer
- Quality Engineer/Tester
- Buildmasters
- Doc Writer
- Project Leader (?)
What’s so mindless that it’s taken for granted? (e.g., “build and run tests on every platform.”) Are these second nature? Or are they sometimes forgotten/overlooked/not done?
What goes onto a “pre-flight” checklist? What goes onto special circumstance (“OMG the plane is crashing!”) checklists? The idea is to have lots of small checklists.
What level of specificity is required for a checklist?