One of the primary reasons that organizations embrace agile development methodologies is on the assumption that faster application development will result in more applications being developed faster. The challenge is actually managing that process in a world where the number of languages and data sources being used is rapidly expanding.
Recognizing that new reality, Telerik this week announced version 3.0 of TeamPulse, project management software designed for agile development environments that now supports access to multiple data sources via a RESTful API.
According to Chris Eyhorn, executive vice president of application lifecycle management (ALM) at Telerik, IT organizations that were once exclusively committed to Microsoft.net have begun to embrace HTML5, especially for mobile applications. That has created a need to access repositories such as Git and GitHub alongside other repositories that can be accessed via a RESTful API.
Other new features of TeamPulse 3.0 include support for a Microsoft.net software development kit and the ability to assign personas to different members of an agile project development team.
Over time, customers should expect to see Telerik not only expand the number and types of languages it supports, but also one day find TeamPulse delivered as a cloud service, Eyhorn says.
While customers are not generally mixing and matching programming languages within the same application, Eyhorn says, they are managing more application projects based on different languages than ever. The Telerik approach emphasizes adaptability in terms of applying an ALM framework based on the roles of the individuals in the organization. That way, says Eyhorn, developers need only need focus on projects that concern them, while senior managers are presented with an overview that highlights the relationships and dependencies among different projects.
At the root of the ALM debate, of course, is the degree to which the management of the application development process needs to be intrusive. Developers want to write code. They know that some form of management is required. But when that management process takes time away from writing code, developers resent it to the point where many of them simply ignore the ALM tool altogether. That may not win them any friends with management. But until management can wrap ALM around the developers without getting in their way, trying to manage the application development process will continue to be a thankless endeavor.