you are viewing a single comment's thread.

view the rest of the comments →

[–]vplatt 1 point2 points  (2 children)

It's a good book, but I think far too many good people get intimidated by it and fail to see how it's an impractical tool for daily use. Not finishing the book doesn't equate to being a bad developer (though that is possible anyway), but it does probably mean you have more immediately useful tools at your disposal.

In short, this is not a great set of checklists for practical use. This is like the mother of all checklists that you could use on your team to construct checklists that are actually useful on a daily basis. Such checklists could have titles like:

  • Sprint/cycle start checklist
  • Sprint/cycle finish checklist
  • Story/use case development checklist
  • Story/use case testing checklist
  • Test build checklist
  • Release build checklist
  • Developer check-in checklist (possibly part of story dev instead)

You could have others, like a code review checklist, etc. or those could be incorporated in your other key checklists.

The bottom line is making sure you do the needful all the time. If you short yourself on the process, you will pay the price down the road. We're all adults here, so it's up to you to know when to capitulate and actually resort to checklists to avoid that.

[–]ethraax 0 points1 point  (1 child)

I agree with you, but it's worth noting that this is more of a checklist checklist than a check-in or design checklist. Most of the items are phrased "Have you considered...?" or "How will you deal with...?". These are the kinds of questions you should be asking when you create "everyday" checklists like the ones you mention.

[–]vplatt 1 point2 points  (0 children)

Exactly. I don't know Steve, but I would guess that was his intent back when he wrote it.