Software development teams hate building status reports, Right? Here's an answer to that.
timhahn 100000F0AC Visits (4387)
Software development teams that want to work well, spend more time coding new function and less time answering those age old questions "So, are you on time? In budget? On schedule?" are always looking for ways to make reporting something that they don't have to spend time on. Building reports whenever someone asks for status just wastes the development team's time. Well, maybe not wastes time, but it does take away from their ability to focus on the tasks that they're being asked to do, namely, design new solutions, write code, and deliver functions and fixes and enhancements.
I have always been interested in how application development tools can actually help development teams rather than get in their way. One of the areas of interest for me is in this area of reporting. How well can a version control and bug tracking system support a team's need for reports, or their management's hunger for status reports from the team? Is it easy to create these reports? How do the reports look? How can consumers of the reports get them without impacting the development team who is usually asked to create them?
In my experience, most bug tracking systems and version control systems have various mechanisms for getting information out of them and then leave it to some set of smart people to figure out how to make the results look pretty for their organization. This usually means that an enterprising individual in the organization has to take it upon themselves to figure it all out, write some reports, and then maintain those reports over time. This is somewhat to be expected since every organization tends to want their reports to look and act a certain way, whether this is because of past history and tools that they have used, or because they just like to have some customization.
Bottom line, the development tool needs to serve multiple needs. There need to be some good built-in or pre-canned reports to get people started, and then there needs to be a good way of extending/adding reports to the environment so that the right information is available to the right folks ... whenever those folks need to access that information.
After working with lots of different tools over the years, I keep being impressed by what Rational Team Concert (RTC) provides in both built-in function/features as well as extensibility. This area of reporting is no exception. I found a great article on setting up Rational Team Concert reports this morning, written by Ken Kumagai. It is titled: "Creating customized reports through multiple project areas in Rational Team Concert". At first, the information provided seems complex and daunting. BIRT reporting is used, you have to understand that RTC provides a "Jazz data source" that is usable in BIRT reports, and so on. However, once you get past this, you see that there is real power here.
First, RTC provides a bunch of built-in reports that can be used in dashboards. Second, after looking at some of the references, including some from Tim McMackin back in 2010 (see: "Creating custom reports with BIRT and Rational Team Concert - 3 part series"), you see that RTC also offers a great way to build customized reports and then enable integration of those reports into dashboards as well.
So here you have it, a set of tools to allow both easy reporting and customized reporting across both work items and version control information. This wouldn't be possible without an integrated tool that allows access to this type of information. If you haven't already, you should have a look at these capabilities if your software development teams are plagued with the typical issues of needing to provide status all the time while still finding time to write the applications and features that they're expected to deliver.