atul khot wrote:Hi Chris,
This is another I faced multiple times...
I love the behavior-driven development (BDD)
(http://en.wikipedia.org/wiki/Behavior-driven_development).
It always worked wonders for me...
Sounds great, but this...
The hard part is get the domain guy to write stories for you! ;-)
This is one of the toughest...
Verbal style of sharing requirements is far too common
(at least in the start up world here in India).
belies your understanding of what a "story" is.
A "story" actually
should be hashed out
verbally during
face-to-face conversations between stakeholders, developers, and testers. This goes back to the problem I mentioned in another reply. Most of the problems we have with software can be traced back to misunderstandings and failures to communicate properly.
I have tried demoing the Stock story on the wiki page above -
but someone who has not done any coding - it is tough to see...
Demoing spock and those almost English like executable descriptions help,
but not too much...
I have found the domain guy is not to blame - he just is not equipped to see it all...
a bio-statistician (surprisingly this guy knew GNU R - however, didn't get the
happy path/error path stuff at all...
And here lies another problem. All too often, developers want to pull non-technical people into their world and make them adapt to the developer's jargon and way of thinking. That needs to change. Again, we need to communicate better. At the very least, developers need to meet their customers halfway. Step out of your world and look at things from the customers' point of view. Use the language that
they use. These things have been said before, in particular, by Eric Evans in his famous book, "Domain Driven Development" (DDD).
As a result - no stories (and no tests exercising them) - and it becomes tough to get at
the rationale for someone writing all this code in the first place ;-).
I realize there cannot be any one answer to this - get what ever docs you have - and make the best of it...
User stories are simply reminders of a future conversation. If you claim to have no stories, then that probably means that you didn't have any meaningful and memorable conversations. How can you expect to write good software that way?
I like the way Jeff Patton puts it in his book "User Story Mapping", which BTW, is an EXCELLENT book that every developer should read, even if you aren't doing Agile development.
Jeff Patton wrote:Shared documents aren't shared understanding... Shared understanding is when we both understand what the other person is imagining and why... The real goal of using stories is shared understanding ... If you're using stories in development and you're not talking together using words and pictures, you're doing it wrong.