Tasktop

Putting the L in ALM – Making the case for Lifecycle Integration

I think everyone agrees that software delivery is not an ancillary business process but is actually a key business process, and the ability to deliver software faster, cheaper, and of a higher quality is a competitive advantage. But delivering software is difficult, and if you believe the Standish Chaos report, anywhere from 24 to 68 percent of software projects end in some form of failure.

Even the criteria for success has been questioned by many, as ‘on time, on budget, delivering the functionality requested’ can still mean software that fulfills requirements but adds no business value. Billions of dollars a year are spent on software development tools and practices in the desire to increase project success and reduce time-to-market. Each year, development, testing, requirements, project management and deployment roll out new practices and tools. Many of these additions bring value, thereby increasing the capability of each individual discipline. But ultimately, the problem is not the individual discipline; the problem is how those disciplines work together in pursuit of common goals and how the lifecycle is integrated across those disciplines.

It has been a year since I joined Tasktop, and during numerous customer visits and partner discussions, two things are very clear: 1. the landscape of software delivery tools and practices is going through a major change, and 2. to be effective in software delivery you need to automate flow and analytics.

The ever-changing face of software tools and practices

Add Agile, Lean Startup and DevOps to a large amount of mobile, cloud and open web, and not only do you have the perfect book title, you have all the ingredients necessary for a major change in the practice of software delivery. Agile and Lean encourage rapid delivery, customer feedback and cross-functional teams focused on delivering customer value. Mobile and cloud are changing the landscape of delivery platforms, architectural models and even partner relationships. Never before have we needed to build flexible development processes that encourage both feedback and automation. Imagine spending three months writing a specification for your next mobile application when your competitors deploy new features on a daily basis. Imagine not connecting your new sales productivity application to LinkedIn, where your sales people have all their contacts. Our development approach needs to not only include partner organizations and services but also deliver software at a much higher cadence.

Automation of Flow and Analytics (reporting) is key.

I have noticed a strange relationship between increased speed, reporting and integration. When you increase the speed of delivery, traditional manual processes for reporting and analytics stop working or become an overhead. For example, one customer spent two days compiling the monthly status report spreadsheet across development, test and requirements. This two day effort required meetings with numerous people and emailing the spreadsheet around for comment and review. When the organization adopted two week delivery sprints, this work was an overhead that no one wanted to endure. Now the company had a choice: drop the status report, or look to an automated solution. Because more frequent releases meant the need to collaborate better, they opted for an automated solution that connected the test, development and requirements tools, providing a report that described the flow of artifacts among these three groups.

The automation not only resulted in creating the report but also improving the flow between these different disciplines. Suddenly there was clarity as to the state of a story or when a defect should move into test. This clarity was avoided in the manual approach, which left large amounts of ambiguity. The report drove the creation of automated flow, which resulted in a better process, which then fed the report with better data.

That means there is a sixth discipline in software delivery

Lifecycle Integration is emerging as a key discipline for ALM. It provides the glue that enables the disconnected disciplines of requirements, development, testing, deployment and project management to connect. It unifies the process and data models of the five software delivery disciplines to enable a unified approach to Application Lifecycle Management (ALM).

Without integration, many of the disconnects go unrecognized, and the flow between groups is never optimized. The larger your software delivery value chain, the more pronounced the impact of these disconnects. Factor in external organizations, either through outsourcing, application integration, service usage or open source, and these impacts can mean the difference between not just project, but business success and failure.

Perhaps we in the software industry are suffering a bit from the ‘cobbler’s children syndrome,’ with integration being a first-class citizen in the traditional processes we have integrated for our business clients for years. But the time is right to apply these lessons and build a discipline around lifecycle integration for the practice of software delivery.

(See also this article’s translation to Serbo-Croatian language by Vera Djuraskovic from Webhostinggeeks.com)

I joined Tasktop in part because I share the goal of increasing programmer productivity, especially by filtering out unimportant information.  I also liked how Tasktop is committed to being involved with and connected to the broader Eclipse community.

In this spirit, I suggested a feature to the EclEmma project: letting developers create and view incremental code coverage results.  This would let developers see a much smaller, but more relevant, set of classes and methods which they could then investigate.

It had bothered me how difficult it was to find where things happen in code, especially in large, unfamiliar code bases.  Yes, you can step through the code, but sometimes you have to step for a long time.  This is boring and tedious, and frequently you step one step too far and overshoot the place you wanted to see — losing the information about the values of the variables at the point you cared about.  If an asynchronous process gets spawned as the result of a Listener attached to a GUI element, it is nearly impossible to step through.

You can search for text on or around the GUI element to help you find where the actions related to that element are processed, but sometimes this isn’t practical.  Sometimes the GUI element has text that is so common that it is impractical to search for it, like “Finish” or “Next”.  Sometimes the GUI element doesn’t have text associated with it, like a button with a picture on it (and no tooltip).

In practice, I have observed that people usually guess at what words might be included in the class or method names, and then when they think they are close, simulate stepping through code by reading through it and making informed guesses about where the execution flow will go.  Unfortunately, frequently they guess wrong, usually in the choice of a starting point or the value of an if-condition.

Another particularly pernicious mistake is not realizing that you are tracing through a superclass of the class that is actually executed.  If you Command/control-click on a method name, Eclipse will preferentially take you to the implementation of that method in the same class; this means that if you ever trace into a superclass, Eclipse will tend to keep you in the superclass; realizing that you need to go back to the subclass is not always obvious.

I thus suggested to the EclEmma code coverage team that they add a feature to the code coverage tool to let users start and stop coverage so that they can see which code was executed for specific short periods of the execution.

With the 2.1 release of EclEmma, the EclEmma team has implemented incremental code coverage — a very useful feature!

How to use it

First, install EclEmma.

Next, go to Preferences > Java-Code Coverage, and check the “Reset execution data on dump”.

Open a Coverage view.  In the Coverage toolbar, there is a “Dump Execution Data” button.

Pressing the “Dump” button will now display coverage and reset the code coverage results.  Thus, if you press the dump button right *before* you do the action you are interested in (e.g. pressing a certain button), and then again right after you do the action, then the code coverage results will show only the exact classes and methods that were executed in response to that action.  Among other things, this means you won’t get misled to look in the superclass instead of the appropriate class.

If you need finer-grained information about which code executed, EclEmma colours your lines of code based on whether they were executed in that interval: green if they were fully executed, red if they were not executed at all, and yellow if they were partially executed (if, for example, the line uses a “?” ternary operator, as in the “drightSide” assignment below).

By default, EclEmma only shows coverage information for your code, not for all the libraries you bring in.  To change this, uncheck “Source folders only” in Preferences > Java > Code Coverage.

Note: while for code coverage, you probably want to see the coverage results for all classes and methods, when using incremental code coverage to locate places in code, you should select “Hide unused elements” from the Coverage toolbar’s drop-down menu.

Incremental code coverage is a very powerful technique: instead of wandering through thousands of classes and methods to find the handful of classes and methods that are interesting, you can spend a few minutes to get their names directly.

I do need to give a slight caveat: exceptions interfere with the code coverage instrumentation, interrupting the marking of that branch of code as executed.  That is a known limitation with the way that code coverage is done.  Thus if your code uses exceptions a lot, EclEmma might incorrectly say that a branch of code was not executed when it was in fact executed.   However, if EclEmma tells you that code was executed, it really was executed.

Using EclEmma in conjunction with Tasktop Dev or Mylyn is an exciting prospect.  Mylyn and Tasktop Dev tell you what you (or someone else, if you are looking at their context) had looked at; EclEmma gives you hints on what you should look at. We have only just started thinking about how those two could be combined, but are excited by the possibilities.

For further information, see EclEmma, Tasktop Dev, or Mylyn.

Note: the screenshots used from the open-source Java GIS tool GpsPrune, isolating the action of showing the scale legend.

Meet Tasktop at JavaOne at Booth #5004. Tasktop team members will be happy to show you the latest from Tasktop including Tasktop Sync, Tasktop Dev and Eclipse Mylyn.

Also, if you have some time, Tasktop and GitHub are co-hosting a Drinkup on Tuesday night starting at 8pm at Jasper’s Corner Tap. Jasper’s Corner Tap is located at 401 Taylor St. We hope to see you there.

Monday’s Panel: The Future of Java Build and Continuous Integration

• Ted Farrell, Chief Architect, Tools & Middleware
• Mik Kersten, CEO, Tasktop, @mik_kersten
• Mike Milinkovich, Executive Director, Eclipse Foundation, @mmilinkov
• Mike Maciag, CEO Electric Cloud
• Max Spring, Tech Lead, Cisco Systems

from Mik's JavaOne talk

We saw a great turn out at the panel, with attendees driving a discussion of how Hudson and Continuous Integration in general is becoming a central part of the modern ALM stack. Tomorrow (Tuesday October 4th), Mik will elaborate on the story in his talk titled “ALM Automation with Mylyn and Hudson”.

Tuesday’s Talk: ALM Automation with Mylyn and Hudson

Date: Tues., Oct. 4, 2011, noon – 1 p.m. Pacific
Location: Parc 55 – Divisidero

With the shift to PaaS and a new breed of open source ALM tools, the deployment loop of enterprise apps is going through its biggest transition since the creation of Java. Kersten will explore connecting the enterprise Java stack to cloud deployment via task-focused continuous integration based on Hudson. Distributed version control systems, code review and Agile planning, based on the Eclipse Mylyn interoperability platform, can be used to create a new level of connectivity and automation between the team and the running application. This talk outlines a roadmap for transforming productivity by connecting developers’ desktops to the release, and automating all the steps in between, from provisioning the IDE to monitoring the running application.

Hot on the heels of the Tasktop Sync 1.0 release, we are pleased to announce the availability of Tasktop Dev 2.1. As an indication of our focus on the Agile and ALM needs of the developer, the product line previously known as Tasktop is now called Tasktop Dev. This release builds on the Eclipse Indigo release of Mylyn 3.6, includes the latest connectors, productivity features and new Agile planning support, and is a significant step forward in terms of connecting developers to both the Agile and the traditional planning process, while ensuring that we get to use the best-of-breed ALM and open source technologies that make us productive.

James Governor (RedMonk founder and Principal Analyst) and I discussed the release and walked through some of the key features:

Here are a few highlights from the Tasktop 2.1 New & Noteworthy:

HP ALM & Quality Center 11 on Mac, Linux and 64-bit Windows
HP ALM Requirements, Defects and Tests can now be retrieved on Mac, Linux and 64-bit Windows machines using the REST connection provided by ALM 11 instead of the native connection. This feature is only supported when connecting to ALM 11 Patch 2 or higher.

HP ALM & Quality Center Tests
You can now bring HP ALM Tests into your Task List along side your HP ALM Defects and Requirements.

Tasktop for VS: Ability to View Task Associations
The Visual Studio task editor now displays task associations, making it easy to see the parent and child relationships and external dependencies inside Visual Studio. Double-clicking an associated task opens it in the task editor, allowing you to quickly access its content.

Planner Story Board and Kanban
The planning tools now support Kanban for compatible ALM tools, and includes a story board and WIP limits. The release planner now supports grouping stories and tasks by activity or assignee, allowing you to organize your planning around these high level concepts.

Focus plan on My Tasks
The task board and story board now include a “Focus on My Tasks” button which shows you only the tasks or stories that are assigned to you.

Download the free trial

Ever wondered what is going on inside the brain of people working at Tasktop?

Last week, I had to honor to speak at Skills Matter, Europe’s largest provider of open-source and agile trainings in the London area. It was a great time in London and Skills Matter was kind enough to provide a recorded version of the talk for people who could not attend.

As part of their branding, the talk was titled: “In The Brain of Benjamin Muskalla: Mylyn: Closing the Agile ALM loop with task-focused collaboration” so I thought: when you’re able to know what’s going on in my brain, I don’t even need to talk about anything. You’ll expierence some silence up to 5:20 as we forgot to turn on the microphone. As the whole talk is about 1:20h, it’s still worth watching it if you want to find out how to do task-focused collaboration with Mylyn and Tasktop. In addition, there is a quick outlook in the connectors coming up around code review with Gerrit and the Git integration for Mylyn.

You can watch the whole talk at the Skills Matter website.

Figure A: Friends enjoying each other’s company over beers in a community hall	Figure B: Developer held hostage during a code review meeting in the 1970s

Code review meetings are notoriously difficult to do well. In Jonathan Lange’s article “Your Code Sucks and I Hate You: The Social Dynamics of Code Review” he identifies several places where code review meetings commonly get off track. The author of the code can feel attacked (see Figure B), discussions escalate to arguments, and filibustering can occur. Adding to these woes the code review meeting introduces a communication bottleneck where several reviewers wait to provide feedback to a single author, which wastes reviewers’ time. Given all of the issues associated with code review meetings it’s a wonder they are ever successful.

Fortunately, there are options for conducting code reviews sans code review meetings. Developers have traditionally used a range of approaches. Some prefer lightweight approaches (i.e., commenting on patches) while others appreciate the more robust support offered by code review servers. Code review servers, such as CodeCollaborator, are recently enjoying an uptick in popularity as they handle all of the logistics of code reviews, from collecting relevant files, to moderating comments, to tracking discovered defects and ensuring they are corrected.

In an upcoming webinar with SmartBear I will be discussing how Tasktop and CodeCollaborator work together to eliminate many of the common pain points of code reviews, including the code review meeting itself. The bulk of this webinar will be a live demo of an author and a reviewer working asynchronously to complete a code review. While this demo will connect to the CodeCollaborator server, the we’ll show that to create, review, rework, and complete a code review developers never have to leave their IDE.

Sounds interesting? Join us on May 5th so that you too can eliminate code review meetings. If you just can’t wait, visit our product page to learn more about Tasktop’s CodeCollaborator integration.

With this final and belated prediction in the series, I have taken the liberty of looking beyond 2011 speculating on the coming decade. I’ll start with a trip down memory lane in order describe how we got into this mess of information overload and what we can do about it.

It all goes back to files. The concept of a file is one of the simplest and most widely used abstractions in user interface design. Files are how we share documents, source code, and online content. Part of the success of UNIX and C that started in 1969, and lives on today in Linux, came from the elegance that files provided to the programming model. Those of us who started our careers programming C may still be amazed at seeing UNIX-style file paths now engrained in pop culture in the form of URLs. In addition to being a useful construct for programmers and operating systems, the notion of files became the primary way to organize information in the IDE, on the desktop, and on the web.

The problem with files is that we have way too many of them. In 1981, the graphical user interface was created at Xerox PARC in order to help us manage large volumes of files more easily than we could on in the filing cabinet or command-line interface. That same desktop metaphor was imitated first by the Mac, then by Windows. With a few decades of Moore’s law driving graphics performance improvements the windowed desktop has become a lot prettier. But the window-based desktops have experienced only incremental improvements, and the amount of information that we now need to process has exploded. The document hierarchies that we access daily have grown to tens of thousands of files. For developers, tens of thousands of files turned into hundreds of thousands. Yet the file and folder metaphor for browsing them remained the same. We were spending more time hunting for and clicking for information than creating it. The desktop metaphor collapsed under the weight of all of those files.

In late 1990s search-based navigation started getting embedded into both our desktop and online information retrieval experience. We were no longer bound to constant browsing for files through deep hierarchies or Yahoo-style categorizations of tagged content. Computers, network infrastructure, indexing and ranking technologies had become fast enough to place at our fingertips the thousands of files on our desktop, millions of classes accessible in our IDEs, and billions of pages on the Internet. When you consider the sheer speed of access that we have via Google’s Instant Search or Eclipse’s Open Type, this is nothing short of remarkable. But then we started seeing a familiar pattern emerging again: we were spending more time searching for information than we were spending on the collaborative and creative endeavours that are productive and rewarding. The repeated, wasteful clicking and keystrokes used to constantly browse and re-browse through information had now turned into repeated, wasteful finding and re-finding for the same information. We increased the volume of information that we could work with effectively by an order of magnitude or two, but the level of information relevant to our day-to-day work grew at an even higher rate.

The information overload problem that we are facing goes back to this notion of files that we have been relying on so heavily. Files encapsulate content. We tag them, bookmark them, index them and search them. Some of us are filers and obsess with having our content neatly organized and desktops de-cluttered. Most of us are pilers, with our computers’ desktops as cluttered as our physical ones. Either way, we are all playing a losing battle. The fundamental problem is that no matter how we organize and structure our documents and source code, our daily tasks crosscut that structure. We need a new approach to managing knowledge work in order to survive the ongoing deluge of information and increased demands for collaboration. The graphical user interface and search-based navigation will continue to be a key part of user interface design, but improvements on that front will only provide diminishing returns.

The primary unit of knowledge work is the task. Tasks have a structure that is defined by the process that we use in our knowledge production activities. For software, this could be an Agile process, with tasks being recorded in a project tracking tool and taking the form of user stories and defects. For the sales part of the organization, tasks are captured as opportunities in Salesforce. The game changer created by the task-focused interface [http://en.wikipedia.org/wiki/Task-focused_interface] is to leverage these entrenched tracking tools to make tasks the primary anchor for the conversation and context around knowledge work. This concept means that the primary way that we access the information in the IDE and desktop user interface becomes the task, not the file. All conversation is available through a single point of access, no matter how many different repositories, email, or social communication channels it appears on. Even more importantly, all knowledge accessed and created as part of the task is tracked automatically, meaning that we offload our brains and let the computer do the work of ranking the information that’s relevant to what we are doing. Multi-tasking becomes a one-click operation, meaning that we don’t have to pay the price of context switching in the presence of constant interruptions. The near-term benefits of this approach are the reduction of information overload and multitasking overhead. The long-term benefits are a new level of knowledge capture and sharing that will eventually transform the productivity of the knowledge worker by an order of magnitude.

In 2011, tasks will be well on their way to becoming an entrenched unit of abstraction in the software development of leading IT-centric organizations. Every change made to a system will be automatically linked back to the task that it originated from as task activation becomes an integral part of developer workflow. This task-level traceability will be connected to continuous integration systems, which will position tasks as the primary unit of production in the continuous integration loop. This will dramatically improve development transparency across heterogenous ALM stacks, and plug Agile project tracking into the development loop, while empowering developers with the tools that they need to manage changes in very complex systems.

In 2012, this automatic capture of context will be leveraged by other stakeholders in the software delivery loop, including support staff, DevOps and QA. Stakeholder-specific context tracking will tie together the activities of developers, operations and quality assurance engineers; this will help to unify all of the participants in the deployment, diagnosis, and development of an application. Materializing a release-specific workspace to investigate a defect in a deployed application, along with all of the context from the application operators and help desk staff, will become as easy as clicking the “activate” button on a task.

2013 will bring tasks-focused collaboration higher up the management stack. Requirements tracking, project, and portfolio management tools will become directly linked to development activities happening at the production level. The production level of software development activity will finally have a high-fidelity link to the planning level, allowing for a new level of predictability and productivity in the software lifecycle. In their support of this movement, ALM tools will learn to speak the language of development tasks and then get out of the developer’s way.

What follows in 2014 is an infection to other parts of the enterprise. With project and portfolio management activities planned via tasks, email will finally start being displaced by task-focused collaboration as the mechanism for tracking work. One-click multitasking™, task-focused collaboration and automatic knowledge capture will start to be tailored to the other departments in the organization.

In 2015, the single integrated Task List and task-focused interface will layer so seamlessly over desktop and mobile operating systems that consumers will start seeing the same level of productivity and collaboration benefits. By 2020, it will be effortless to assign your grandmother a task to bake you cookies, no matter where she is located, and have the recipe automatically captured as part of the context in order to later delegate the same task to your robot assistant before flying to work in your car.

As William Gibson stated, “the future is already here – it’s just not very evenly distributed”. In writing this blog series, every bit of content that I produced and accessed has been automatically captured as part of my task context, and each of the many revisions and bits of feedback were tracked on the task. When I re-activated this task after a series of interruptions, my desktop-based Word and web-based WordPress editors were instantly restored. In the same way, every change that any committer has made in the Eclipse Mylyn codebase is automatically linked to the Bugzilla bug describing the social conversation around the change, then linked to the corresponding build and release. Tasks and contexts externalize our memory and make it much easier for both our forgetful selves and for newcomers to help us evolve our software.

To my surprise and concern, Tasktop is telling me that I have spent over 88 hours researching, collaborating on, and writing this prediction series on Agile, ALM and developer tools. All of this information was automatically captured and will be accessible to me in 2015 when I attempt to explain away any inaccuracies in my predictions.

“The best way to predict the future is to invent it” said Alan Kay at Xerox PARC in 1971, inspiring Smalltalk and paving the road for the graphical user interface. Our vision at Tasktop, as embodied in the “less is more” logo , is to transform knowledge work around the focus and flow required to get creative work done in the presence of ever-growing volumes of infromation. As with other innovations, like the file hierarchy and desktop metaphor, this move to task-focused collaboration will originate from developers and move upwards and outwards in the organization. We look forward to working with you in making this vision a reality, starting with the transformation of the Agile ALM stack and developer tools. <=>

Software developers leverage many supporting technologies to get their own work done and to coordinate their activities with others. Developers use issue-tracking systems to organize tasks, SCM systems to store source code, and an IDE to write code. As developers use these disparate technologies it’s easy for them to develop ALM ADD. They switch to the issue tracking web UI to determine what task to do next, open the IDE to work on that task, and use a command-line client to check-in the newly created code. They code for a few minutes and then reopen the web UI to retrieve a code snippet. The constant switching, inability to focus, and distraction that is a hallmark of this workflow kills developers’ productivity. It causes otherwise productive programmers to forget relevant details and struggle to stay on task. Fortunately, through tool support this development disorder can be avoided.

In our upcoming joint webinar with Perforce we’ll be showing how to use Perforce and Mylyn to stay inside of Eclipse as you work. Instead of switching from IDE to browser to command-line, we map out a IDE-centric approach. Of course, bringing the ALM tools into the IDE avoids switching, but it also enables some deeper integration across the ALM stack such as automatically creating change-sets for tasks. Sound interesting? Join us by registering for the webinar that Perforce’s Randy DeFauw and I will be holding on Wednesday, April 27, 2011, 11 AM PDT / 2 PM EDT.

If you are involved in large-scale software development, you may be alarmed to hear leading analysts discussing the growing number of Agile rollouts that are failing. Several factors are contributing to this. Legacy and in-house ALM tools have proven to be sticky and hard to migrate from. Their content, customizations and workflows encapsulate product history. Agile tools have moved in, but have not been adequately connected to developer workflow or to enterprise ALM tools and processes. Lightweight open source ALM tools are becoming favoured by developers and being adopted in a bottom-up fashion, but these are disconnected from both enterprise and Agile ALM tools. The resulting difficulty of modernizing and integrating the increasingly heterogeneous ALM stack is a key cause of the failing Agile deployments and ALM stack modernization efforts.

For the past three years, the Tasktop 1.x train for releases was focused on providing developers with the integrations that they need to work with Agile and ALM tools within their home environment, the IDE. Our goal is to bring the productivity benefits of the task-focused collaboration paradigm to as many developers as possible. On the Mylyn side, this has meant collaborating with Agile and ALM vendors and contributors in order to grow the frameworks that have become the most widely extended APIs for ALM integration. With last year’s restructuring of Mylyn to become a top level Eclipse project, these frameworks grew to encompass SCM tools, Build and Continuous Integration tools and code reviews. The Tasktop 2.0 release extends this ecosystem with new Mylyn connectors and new features that support the range of our integrations, including Task Federation™ and cross-repository Agile planning.

New Mylyn Connectors

For the 1.x release, our obsession with improving the developer’s workday meant providing integration with the huge breadth of ALM tools in use today. This meant getting involved with each of the corresponding open source projects and partnering with the best-of-breed Agile and enterprise ALM vendors in order to enhance their web service APIs and establish the long-term support needed for this level of interoperability. The figure below highlights the new integrations made available as part of Tasktop 2.0 in green, with the most notable being:

		HP Agile Accelerator (Tasktop Enterprise): This builds on our existing support for HP Quality Center and ALM in order to provide both the task management and IDE-based Agile planning facilities. Learn more.
		Accept360 (Tasktop Enterprise): Brings requirements and other product management artifacts to the developer’s desktop in order to better connect development to planning activities. Learn more.
		SmartBear CodeCollaborator (Tasktop Enterprise): This is the first full-featured Mylyn connector for a code review tool, SmartBear’s popular CodeCollaborator. Learn more.
		Polarion ALM (Tasktop Pro): Polarion is the vendor behind the Eclipse Subversive SVN client project and we now have full support for the Track & Wiki and ALM solutions. Learn more.
		Hudson/Jenkins (Eclipse Mylyn): For the Mylyn 3.5 release we created a Hudson integration that layers on top of Mylyn’s new Builds framework. On top of this Tasktop provides traceability with tasks that exist in ALM tools such as HP Quality Center. Learn more.

Tasktop for Visual Studio

Many of our customers have been asking for support for their teams and colleagues who are based in Visual Studio. Organizations are building both Java and .NET based applications that need common lifecycle management tools. The Tasktop 2.0 release includes the GA of Tasktop for Visual Studio, which brings the ecosystem of our task connectors into the Visual Studio IDE. Whereas previously only basic integration existed for task management within Visual Studio beyond Microsoft’s TFS product, you now get Mylyn’s functionality including instant opening of tasks, offline access, the Task List and a full-featured and WPF-based task editor.

Supported Connectors (Tasktop Certified): Accept360, Atlassian JIRA, CollabNet TeamForge & ScrumWorks, Edgewall Trac, Google Gmail, HP Quality Center & ALM, IBM Rational ClearQuest, Microsoft Outlook, Microsoft TFS, Mozilla Bugzilla, ThoughtWorks Mingle, Polarion ALM, VersionOne. Adding support for the remaining Tasktop Certified connectors is underway.

Learn more about Tasktop for Visual Studio.

Task Federation, for Developers

The big news in Tasktop 2.0 is not the new connectors, but what we have created on top of this ecosystem in order to solve the problem of ALM stack heterogeneity. Tasktop 2.0 includes a Task Federation framework that provides a layer of insulation between the various stakeholders in the software lifecycle and the implementation details of the organization’s ALM stack. Task Federation manifests differently for each set of stakeholders.

Developers are often stuck working with multiple ALM tools. You may be working on two different projects, each of which has a different ALM tool. Or you may be adopting Agile, but still needing to use the company standard defect tracker. Those of us depending on open source frameworks and SDKs will have dependencies between our internal task and those managed in an external repository such as Eclipse.org or Apache. Tasktop 2.0 provides full support for linking dependencies between the various task repositories that define your software’s evolution, and new features such as cross-repository Agile planning and task synchronization build on this support.

Task Federation, for Agile Planning

The biggest single new feature in Tasktop 2.0 is the release of the Agile Planner that we launched as beta at the Agile 2010 conference. Just as we do not replace your existing ALM servers, we are not replacing your existing Agile planning tool. Instead, we augment it with our unique interoperability features. The Tasktop Planner provides:

		Task Federation: The most important feature of the planner is its ability to show plans that span repositories. Planning your user stories in an Agile tool but using HP Quality Center for defects or an open source issue tracker is no longer a problem. Depending on another team or an open source project? These dependencies now show right in your release plans since Tasktop can display and reconcile state across repositories. All of the cross-repository state is stored in your existing ALM tools as hyperlinks and metadata.
		IDE Integration: This is the first full-featured cross-repository Agile Planning tool within the IDE. You get a fully native and offline-capable Scrum style task board and a release planner. Relevant content from your web-based planning tool, such as burn down charts, is available when connected via our embedding of web UI gadgets. For product owners and project leads, the planner is also available in the Tasktop desktop edition.
		Developer Focus: Whereas most tools focus on project-level views, the Tasktop Planner supports developer centric workflows such as highlighting everything assigned to you for the current Sprint or populating your Task List with user stories assigned to you for an iteration. Everything you need for your daily Scrum or release planning is always at your fingertips.
		Automatic Time Tracking: The Tasktop Planner uses time values from Tasktop’s automatic time tracking facility to make Agile estimation dramatically more realistic
		Supported Tools: Agile plans can be displayed from HP’s Agile Accelerator and Rally. More tools will be supported in subsequent releases. All Tasktop Certified connectors are supported as targets for cross-repository plans.

Task Federation, for the ALM Tools Manager

In addition to providing developers and plan stakeholders with a unified view of the various tools and servers that define their planning activities, Task Federation can also be deployed to further unify an ALM stack. Say that you are deploying IBM Rational Team Concert (RTC) for Agile planning, but have realized that HP Quality Center (QC) is completely entrenched in your defect and quality management process. You can deploy a Task Federation setup that bi-directionally synchronizes all the key tasks and fields between RTC and QC so that RTC has the state needed for planning, while QC happily remains your system of record for quality management. Since each Tasktop client includes the full federation functionality and uses Mylyn’s hardened bi-directional task synchronization and conflict resolution interface, it is possible to deploy this solution in a scalable and secure fashion without requiring any new servers.

Learn more about Task Federation

Task-Focused Continuous Integration

As always, our commercial efforts in Tasktop have been driving framework and open source tool improvements in Eclipse Mylyn. The most notable of these is the new Hudson tooling, which also supports Jenkins. You can now work with Hudson day-to-day entirely from within the Eclipse IDE, monitor and run builds, and inspect results. Accessing build information is instant and available offline. One of the most useful automation features is the ability to run tests that failed on the server within your workspace, with just one click. But the most profound feature here is the first phase of our new support for ALM traceability. If your developers are using Tasktop, thanks to the magic of task activation and automatic change set tracking, you now have perfect traceability between your Hudson builds and the tasks that changed for a given build, providing an unprecedented level of traceability between your tasks, source and builds.

Learn more about Mylyn 3.5

Summary

With this release of Tasktop 2.0, we are taking a big step forward in bringing a new level of interoperability and sanity to your Agile deployment and ALM stack, helping developers focus on coding while giving teams a much more complete and real-time view of plans and progress.

		Read the Tasktop 2.0 New & Noteworthy
		Sign up for my webinar on Tasktop 2.0

The recent Mylyn 3.2 and Tasktop 1.5 release for Eclipse Galileo (3.5) includes a new Connector Discovery wizard that makes it much easier to find and install Mylyn and Tasktop connectors. This has proven to be a popular feature and we’ve teamed up with Atlassian to produce a short screencast that shows it in action.

This screencast shows an example of how to install the Atlassian Connector for Eclipse, which provides Eclipse integration for JIRA, Bamboo, Crucible and FishEye. All other Tasktop Certified connectors can also be installed using the Connector Discovery wizard.