IT Experts Community
HP software technical network
Contemporary software development projects typically involve a broad range of development tools and technologies. Even within a single project, multiple programing languages often will be used (Java, C# and other .NET languages), source code is stored in various repositories (SVN, GIT, Perforce, or Microsoft Team Foundation Server), and different testing frameworks are used (JUnit, TestNG, NUnit).
Tracking project status and progress across these various development environments is a constant challenge—getting accurate and timely metrics is almost impossible. A wide assortment of tools and cumbersome manual processes are often required to pull together scraps of information that tends to be either too imprecise to be useful, or too overwhelming in detailed data.
How long does it take in your organization to find out which user stories and defects were delivered or fixed in last 2 sprints? What is their code coverage and unit test results? Quickly finding the exact answer to important questions like these requires advanced analytics capabilities.
HP Agile Manager provides application teams with rich Agile activity management and deep insights about the status of source code, builds, unit tests, coverage and more, all in an instant-on Software-as-a-Service model. A critical part of its analytics capabilities is how it aggregates source code and build management information from heterogeneous development environments and surfaces the meaningful data to provide team members and leaders with greater insight.
This guide will show you how these analytic capabilities can further empower your Agile team
1.0 Application Lifecycle Intelligence (ALI)
At the core of Agile Manager is Application Lifecycle Intelligence, a technology that was originally developed as part of the HP Application Lifecycle Management (ALM) software suite. ALI aggregates information from multiple development tools to establish complete traceability in the development process and surface actionable information for the team and stakeholders alike.
ALI achieves this by taking information from development environments such as build servers and source code repositories and links this with project information like release plans, user stories, defects and tests.
Agile Manager presents, in real-time, an intuitive view of all this data in a single Web interface, so that everyone has easy visibility into the same information and insight into potential issues.
2.0 Release Overview
The Release Overview summary screen is the primary starting point, offering a quick status snapshot of all current development. On this one screen desk managers assess:
- Quality—Metrics on the number of open defects and a breakdown of their severity
- Code changes—Reports on the quantity of changes that are underway and provides an indication of whether development efforts are more focused on implementing new features or fixing defects
- Build status by configurations—Color-coded tiered bar charts reveal whether some builds are failing too often, which could slow down the team
- Active committers—List of developers who have submitted most of the changes, which can help identify who should be contacted if there is a problem, because they are more likely to know extensive details
- Development alignment—A side-by-side review of the amount of changes made to top users stories and their priority/rank so teams can check that they are aligned
3.0 Build Summary
What new features or user stories have been implemented in the last three sprints? Have all the defects been fixed prior to a release?
Finding answers to important questions like these often prove to be dizzyingly complex for development teams.
Agile Manager aggregates the information on its Build Summary screen.
In Agile, perhaps even more so than other development methodologies, it is important to spot trends early so that problems can be addressed quickly.
By using the analytics on the Build Summary page, development teams can assess whether builds are improving or worsening over time, and in particular track trends about defects and their severity.
Source Code activity metrics offer crucial information about what kinds of code changes are occurring, and whether teams are investing more in developing new features or just “keeping the lights on” by fixing issues.
One key metric to watch is the ratio of defect fixes versus implementation of new features or user stories.
These three trends are invaluable toward the end of each sprint. At this stage, development teams should focus resolving open issues instead of implementing new features. ALI technology allows development teams to visualize this trend. Of course, what is most critical in the run-up to a new release is that defects—and especially the severity of them—are tracking with a downward trend.
Identifying trends can be a powerful tool, but being able to rapidly access greater detail about the potential problems they highlight can prove even more powerful by allowing you to quickly resolve emerging issues before they derail projects.
4.0 Build details
The analytics engine of Agile Manager generates a summary page for each build, providing development teams with a detailed account of its progress. This is particularly helpful if you have suspicions about what the high-level metrics are indicating, or you need to investigate contradictory metrics.
There are several steps you can take on a Build Detail page:
1. Review commits
Gather comprehensive information about all of the commits, changed files, and developers who have committed to the build.
2. Review user stories
What was really implemented or modified in the build? For every user story, check the Coverage and Unit Tests to be able to easily spot if a newly delivered functionality has not received enough testing (i.e. it has had low coverage) or tests are failing. This can help detect whether a story was reported as “done” when in fact it did not have adequate quality or proper testing.
The amount of change and number of committers per user story can also be red flags, because as more changes occur and more developers work on the same item, there is increased risk that something will not work as expected.
3. Review related defects
In a similar approach to user stories, you can confirm what was fixed in the build and see the associated metrics. If, for instance, a defect fix has low test coverage, this may require a deeper investigation into the details.
In addition, you can track newly detected defects and closed defects related to the build, so you can identify if a final build of a sprint introduced a lot of new defects. Also, in instances when something does not work, you can learn about which defects were resolved in the build.
5.0 Source Code Changes
In addition to analytics related to specific builds, ALI allows teams to track source code changes, and set policies to ensure developers follow prescribed guidelines and best practices related to source code commits.
5.1 Reviewing the change log
Developers and others on the team can review a stream of commits interwoven with information about builds. This allows team members to very quickly see the last five commits, for instance—or any commits during a defined period such as the previous sprint—and get to file content and any differences that have emerged over time between commits. If a build experiences problems, developers can see the commits (and the committers) that preceded the problem and probably identify the cause.
In situations where a member of the team finds a suspicious commit, he or she can quickly find related builds as well as related defects or user stories and create a picture of how the pieces fit together.
5.2 Enforcing SCM Policies
Dev team leaders can do more than simply watch what is occurring in development. Scrum masters or team leaders can take active control by setting Source Code Management (SCM) policies in a unified manner. With ALI, it is possible to define SCM policies that control committed changes. The enforcement of the SCM policies helps to ensure that developers follow prescribed guidelines and best practices.
Team leaders can be confident that developers implement the right features and add required metadata to the committed change sets. Policy enforcement also provides invaluable help during stabilization periods as it is easy to ensure that developers fix only severe defects or to lock the code base of a release completely.
6.0 SaaS implementation and security
As a SaaS-based service, Agile Manager does operate with a different model than traditional software. However, it does not force development teams to make tradeoffs in the systems and tools they use.
Agile Manager supports Hudson, Jenkins, SVN, GIT, Perforce, CVS, Cobertura, Ncover, Junit, Nunit and more. Teams can simultaneously use different systems and be coding in both Java and .NET and all of the same analytic information will still be available in a single place.
In order to bridge local dev environments with Agile Manager running in SaaS, development teams need to download the pre-configured ALI Dev bridge, but no changes to network configurations are required, including firewalls, open ports or network tunnels.
Of course, any time an organization chooses to work with a SaaS provider, it is necessary to inquire about security practices. In the case of Agile Manager, it only ever transmits meta information about builds, development metrics and commits, while information is exposed in the same manner, and only to your tenant. Code and binaries never leave your local dev environment, so intellectual property remains in your hands.
Find out more
To get further details on how Agile Manager can help improve project management of your application development, visit the product page.
Want to take it for a test spin? Register for the Agile Manager Public Beta trial between October 17 and December 1, 2012—and then weigh in with what you think of it at our practitioner-focused discussion forum. If you have any ideas for further enhancements, we would love to hear of them. Please post those requests to this discussion forum.