Ten Application Lifecycle Management (ALM) "Best" Practices

in the underlying technology.  I don't want the GUI to expose everything in the tool to me - just what I need.   That's where role-based GUIs come in.  These are important.  Don't make a tech writer understand configuration management.  Don't make a tester understand ... OK, testers need to understand a lot... but not so much project management or makefiles.

If your shop doesn't have interfaces that are tailored to each role, you're going to waste a lot of money training people what not to do, and searching for how to do what they want to do.  What are the things a developer does?  Those should appear in the developer interface.  What about a CM Manager?  How about a Product Manager? A Project Manager? A Tester?  They all have different roles.  Yes the same tool can help them all if it's well designed.  Each should have their own set of Inboxes/To-Do Lists specific to their roles.  Each should have the abilitiy to add and modify the data for their role, and to navigate it easily.

In recent years, the concept of a dashboard has arisen.  Dashboards are nice - they summarize what you need to know, and you can even zoom-in to details with most of them.  But as your responsibility increases, your dashboards can get cluttered.  The solution is role-based dashboards.  Let me look at the info from the perspective of this role, then that, then another.  In fact, as dashboards have evolved, a few things are obvious to me:

• I need to customize my dashboards (and I don't want to spend a lot of time doing it).
• Dashboards can be used to reduce clicks and to reduce the time I spend looking for the right menu buttons.
• Dashboards are designed to show information, but I often want to use them as Work Stations.

What's a Work Station? It's basically a dashboard of information from which I can actually do work.  For example, I might have a Change dashboard that let's me zoom into changes to see the details of each change.  But maybe I'd like to use the same dashboard to do peer reviews, or as a developer, to do my checkouts and checkins from, and more.

The ultimate Work Station for me is a Meeting Work Station.  It's a work station dashboard that I can use to run a meeting.  For example, a Problem Review Board can use a Meeting Work Station to present the Problems being reviewed, to zoom-in in a priority-based fashion, to add decisions, approvals, comments, etc.  Even to assign and re-prioritize the problems.  Similarly for a CRB (Change Request Board), a quality review board, a project management team, etc.  Design the work station to make the meetings run smoothly while at the same time ensuring that all information is immediately captured.

When looking at how you're using your current tool, or for planning your next tool, consider role-based user interfaces, with role-based dashboards, and work stations, that are easy to customize (and easy to build in the first place).  Resist the temptation that a tool vendor already knows what you need and has hard-coded the dashboards for you.  "What you need" will change over time, more rapidly than you know.

7.  Interactive Build Comparisons

One dashboard, and associated query capability, that is crucial to any CM environment is that of build comparisons.  Build comparisons are a frequent and important capability that can answer questions such as:

• What problems are going to be fixed for a customer if they upgrade to a new build?
• What changes went into the build that might have caused