Get hands-on training for JIRA Software, Confluence, and more at Atlassian Summit Europe. Register now ›

michaelhuettermann.jpgThis is a guest blog post by Michael Hüttermann, a software developer and coach on Java/JEE, SCM/ALM, SDLC-Tooling and agile software development. He has recently authored a new book, Agile ALM, that provides an overview of task-based development, continuous integration, and using Scrum as an agile approach, and which uses the Atlassian toolset as an example of agile in action.

Task-based development is an essential part of an Agile application lifecycle management (ALM). Working in a task-based way means that all activities are based on specific requirements or tasks. Task-based also means tracing each task and the changes it creates, and this becomes even more appealing if you span the tracing over all roles, phases, and organizational units, including production.

The Task-Based Approach

Traditionally, work items (or tasks) are spread across artifact types and tools. Tasks are an abstraction level for coping with the general information overload and the challenges of parsing information from many different sources. A task is a fine-grained, measurable unit of work, extracted from a broader scope, like a use case or a feature. Many projects feel comfortable with defining use cases to describe requirements and features in a coarse-grained way. Those use cases are split into tasks that express a more technical view on the tasks to complete in order to ship the use case. With a task-based approach, the task is the unit of interaction and the base of work. Task-based development is the technique of linking work items (issues, defects, tasks, and so on) to the specific set of changes (such as an atomic changeset) made to complete the work described in the work item.

Working in a task-based way means that, first, all activities are based on specific requirements or tasks, often called work items. Task-based also means tracing each task and the changes it creates, and this becomes even more appealing if you span the tracing over all roles, phases, and organizational units, including production. When are you close to the maximum of improving your process? When the production crew (and any other stakeholders) not only host final deployment units, but also know exactly which units are based on which sources. Additionally, you will know which sources were touched because of which changes were requested. This doesn’t depend on languages, systems, and organizational barriers. You can link requirements and defects to coding items, and vice versa. This referencing makes it much easier to validate that the work is done to plan and that the plan is getting done. This end-to-end referencing provides much more scale than using the plain story cards that are used by some Agile approaches, although this may be sufficient in many circumstances too. A common method to enable task-based development is to add a ticket number to the check-in command so tools can cross-reference requirements with coding artifacts.

Tools for a Task-Based Approach

Using a highly integrated toolchain for task-based development adds much more value compared with the approach of just using single tools in an isolated way, without integrating them with each other. Integrating different tools minimizes the barriers between different project roles (meaning the users of respective tools) and makes the status of the project visible at any time. One example toolchain that implements task-based development includes the Atlassian tools JIRA/GreenHopper, Bamboo and FishEye, and integrates Artifactory and Eclipse/Mylyn. All tools are lightweight, with an open architecture and can be configured as needed. Let’s now briefly discuss the different nodes of the toolchain and their intention while integrating with other tools.

Readers of the Atlassian blog are, naturally, aware that tasks can be managed through JIRA. You create and manage tasks in JIRA and assign tasks to target milestones. JIRA’s default setting is to have tickets that can be split into sub-tasks, but that’s just a matter of wording and default configuration: you can freely customize the types of JIRA tickets and their relationships to each other. In JIRA, tasks have unique identifiers. GreenHopper further enriches JIRA with additional features for Agile software development such as burn-down charts or visualized story cards.
The IDE is the place where developers implement the tasks. We can use Eclipse with Mylyn as part of our example toolchain. For example, if you’re working on a task that’s listed as task #4711 in JIRA, task-based development requires that you link the exact set of code changes to defect 4711 in JIRA. This is done by referencing the ticket in your version control system (VCS) commit message. The ticket number is then passed through the whole system, see figure 1 above, thus all other tools have access to the progress of the developers. Using Eclipse/Mylyn, together with its JIRA connector, enables you to work on JIRA tickets directly without leaving the IDE. Advanced usage scenarios are possible like working in offline mode or attaching contexts from your IDE to the task in JIRA to share them with coworkers.

Committing changes to VCS is the basic step that is needed to share your work with others. Advanced tracking of source changes can be done with FishEye. FishEye is an advanced source code repository browser that makes changes visible in a convenient way by scanning your repository continuously and visualizing the information via an appealing web application. FishEye can work with different VCS types, including Subversion and Git. With FishEye, you can browse your repository, monitor changes on files and follow activities of developers. Integrating JIRA with FishEye, you can quickly navigate from your task in JIRA to the code changes in your VCS that were done to implement the task.

The continuous integration server Bamboo pulls sources from the VCS, for example Subversion or Git, to build the software. You can create your own build plans to create your software on a scheduled basis (with Ant or Maven, for example), or a developer’s check-in can trigger it. Key features of Bamboo include monitoring build progress, using deploying steps, and reviewing the results of static code analysis. Bamboo helps to bridge the development with delivery and testing activities. By integrating Bamboo with JIRA, you can navigate from a task in JIRA to the builds that contain activities to fulfill that task, and vice versa: you are able to navigate from a Bamboo build back to the JIRA task that motivated changes in the sources and triggered the build.

Bamboo produces binary artifacts that are deployed to the component repository Artifactory. It is a good decision to differentiate between managing sources (in your VCS) and binaries, and Artifactory can help to do exactly that. Besides basic features in the context of proxying artifacts, artifacts search and access control, Artifactory provides traceability by visualizing dependencies between binary artifacts and linking back artifacts to the Bamboo builds that produced these artifacts. As a result, having the binaries, you have knowledge about which Bamboo builds produced these artifacts and, going one step further along the toolchain and navigating to JIRA, you’ll see which tasks were implemented in these binaries. Binaries are shipped to the customer, and deriving release notes from a Bamboo release build is a no-brainer. You can further work on built artifacts, for example triggering atomic operations on the complete group of artifacts that were produced by one build.


To sum up, with task-based development, the development process can be streamlined and become more efficient, improving the collaboration between stakeholders (such as developers, testers, DevOps), making the project progress visible and helps to minimize barriers between different project phases and project roles. The lightweight tools that I’ve covered in this blog post can be orchestrated to build up a tool chain that implements task-based development.

Michael Hüttermann is a developer and coach on Java/JEE, SCM/ALM, SDLC-Tooling and agile software development. A Java Champion, he is certified as SCJA, SCJP, SCJD and SCWCD, a member of the JCP and Agile Alliance, JUGs Community Leader and founder of the Cologne Java User Group. Michael led the Tools for Agility track at Agile 2009.

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now