The Next Generation: Build Management Essentials

You get the picture.

There are plenty of other navigation capabilities in most next generation dashboards.  If they are designed for a particular task or role, such as we have in the example above, it can make life a lot simpler.  No fumbling with commands or menus - just right to the point and zoom-in as necessary.  This same type of build comparison dashboard is invaluable to product managers who want to know what features and fixes have gone into the latest few builds.

Build and Change Query/Navigation
Builds and Updates are perhaps the most central records of a CM database.  They each have various links going back in time (cause) and forward in time (results).  The Update comes from assigned work items which resulted from requirements which came from customer (problem and feature) requests.  They produce new revisions of files which are incorporated into builds.  Similarly, Builds come from a series of Updates (with their traceability chain), usually defined in terms of a Previous Build, identifying Updates to a Baseline.  They spawn built artifacts, test sessions (a sequence of test case runs and their results), customer site deliveries, etc.  They are referenced by customer requests (especially for problems - which build was that found in?).  

Your second generation tool might be great at creating these relationships and storing data against them.  A next generation tool will populate most of these relationships based on the actions performed in managing updates and builds.  If data is not captured automatically when it can be, it will be lower quality data.  But even if the data is captured perfectly, if the navigation tools aren't there, or if they have slow response, or require too many clicks, the data won't be used nearly as often as it should be.  This in turn will result in lower quality and longer delays.  Your next generation build capabilities must provide rapid, easy navigation, eliminating the need for tool training, allowing you to focus on process training.

Meeting Support
Your query and navigation capabilities should be more than sufficient to drive your meetings.  Maybe you have test session reviews where you review which test cases failed, and which are still to be run.  Maybe you have quality reviews to ensure that Updates have been properly peer reviewed and coding standards have been followed.  Next generation CM/ALM tools must be used to drive such meetings and to capture in-meeting results so that there is no lag built into the process.  I might recommend that you have a dashboard/work-station specific to each meeting with all of the information and all of the actions needed to drive your meeting to completion.

For example, your Release Meetings might present a list of outstanding problems and features that were originally targeted for the release.  They might also show the failed test cases, with the ability to zoom in to details.  And perhaps things such as burn down charts, risk items, and a comparison between the previous release quality march (i.e. sequence of builds and their quality) and the current one.

Recurring Theme
If you've been following my columns, this will come to you as no surprise.  If you want to support a next generation process, your tools must be able to adapt to your requirements, readily and easily.  

Your Build process, like any other process, will evolve.  If your tools are static or provide limited support for the process, your process will quickly follow suit.  So much for continuous improvement.  But if your data, your process, your dashboards, your UI, and your guidance can evolve as you go, you'll become more