I have seen that the longer and more detailed a software specification document, the bitter and contentious the discussions are. This is particularly so with teams that do not work in the same location.
So we decided to take a different approach. Instead of defining the 'spec' as a document we defined it as 'A common understanding among product managers, architects and user experience designers'. So instead of striving to write the spec, we strived to arrive at that common understanding.
This is where techniques such as use case creation as a team, trips to customers sites as a team and user interface creation as a team came handy.
When development team members had questions about the use cases and the spec document we posted on a wiki, they posted the questions as comments and product managers answered the questions as replies to comments. This process was followed slowly and steadily until the entire team arrived at a common understanding of the solution.
The final spec? Oh! That was written in a day and posted in the internal spec tool we had. No one bothered to discuss the 'spec' because everyone knew what was in the spec and everyone had a common understanding of what the spec meant.
Look for my earlier posts to read about the use case creation process.
No comments:
Post a Comment