P | Problem or present position | What are we trying to solve? |
---|---|---|
O | Objective or desired outcome | What does good look like? How will we know when we have achieved it? |
S | Strategy or solution | What do we need to do or change to reach our outcome? |
T | Tasks (time-based, measurable and assigned) | Who does what by when? |
E | Execution | Now go and actually do it. |
R | Regular reviews and reflection | Are we making progress? How can we remove obstacles? Is our strategy still the right one? Did it work out? |
Specific, Measurable, Achievable, Realistic and Timely.
I believe that objectives need to be simply:
Put simply; 'do this by then' with an understanding of what 'done' looks like.
Let's use what we already have before adopting new technology. Here's a great article that describes this better than I can.
For me, testing proves out two things:
I know that not everyone is a fan of BDD or TDD, but my default position is that these are good practices, until I see hard and well articulated evidence that we shouldn't do them.
At the very least, we need a common understanding of what quality means to us, which drives out behaviours and expectations.
I don't care about code coverage, other than a high level of code coverage generally indicates a high degree of attention on quality and testing.