Building Better Software

Last week I attended ExpoQA International Conference on Software Testing & Software, in Madrid. There was a lot of very good presentations. Sorry that we can’t attend all of them.

The one that touched me more even wasn’t in the program. But due to a last hour cancelation it was replaced by a presentation by Paul Gerrard about Specification by Example and the Business Story method.

It is amazing when we understand how such a simple thing could resolve such a huge problem like requisite’s flaws.

Some time ago I wrote about these kind of flaws and how we could mitigate them. My theory was close to Business Story method.

The idea of writing Business Stories based on client’s requisites or specifications, describing and giving examples in a clear language, it is simple and powerful. When we send these stories to the client we got the client’s confirmation about the correct understanding about what the he wants.

Whenever I mention Development Team I mean a team of Analysts, Developers, Testers, Technical Writers and User Experience experts.

The truth is that a requisite’s flaw is, most of the times, a communication problem. It happens when the information flows across teams and loose a bit each time it is passed, or a team just didn’t have access to all information.

We all know that a requisite’s flaw is very expensive. This phase is the most expensive where it can happen.

Being a communication issue, why don’t we ever look for experts non IT to help us? An exper in Organizations, a Human Resources specialist, team managers and others, have skills to watch our Development team behavior, find the problems and propose changes.

Why aren’t these people evolved in the Software Development Process definition? Engineers are not the best people to do it, yet we can only fid them in these teams.

What I like most in Business Story method is the fact that it is neither an agile nor a conventional method. We can adapt it to any of them but it still is neither of them.

Another advantage is that the writing of Business Stories is a collaborative process, involving the entire development team.

With this method everyone is automatically informed. The fact that they receive a pack of requisites or specifications, discuss then e rewrite them, consolidates all data among team members. When the client confirms that is really what he wants everyone can start working. Business Analysts write more detailed documentation, programmers write code, testers write test cases while they wait for code to test. All of them have the same information and they are aligned with each other.

It is not necessary to follow a methodology to the letter, instead, we should adapt it to our company and our team, looking to improve our performance.