As agile development methods become more accepted in the
development world, I have wondered the best way to incorporate agile methods on
the reporting side of projects. Face it, reporting is often the forgotten
step-child of most projects.
Agile has many practices, including Stories, Planning Poker,
daily standups, team rooms, continuous integration and more. How and can we
incorporate reports in these practices?
Some of these questions have easy answers. For instance, we
can turn a request for a report into a story. And most teams worth their salt
can score those stories in their Planning Poker sessions. We can discuss the
reports in our daily standups, and ask for help on these reports in our team
rooms.
The practice that is vital to most of the projects I have
worked on is Automated Customer Acceptance tests. Automated Customer Acceptance
Tests constitute our customer requirements document. The customers create or
are highly engaged in creating these tests. They also get to see the tests turn
green or red when the backend code is executed against the tests. If the tests
are not green, the customers and developers know something is wrong. Combine
this with live demos every week of the software using these methods, and the
customers develop faith and trust in the development process.
These acceptance tests represent executable requirements. Executable
requirements make for a highly maintainable software project. Your continuous
integration constantly runs all of your automated tests when team members check
in source and this verifies that the new changes have not broken the software. In
this series of articles, we will investigate how to include your automated
acceptance tests against Crystal Reports.