In the current iteration we are working on NUnit and Selenium integration. In fact it is almost completed. The integration implemented as a plugin. It is possible to configure profile for each project and in general the plugin is ready for continuous integration support.

The idea is very simple. CC server puts NUnit result file in some location, TargetProcess grabs it, parses it, creates new test plan run and sets passed/failed results for all test cases in this test plan. Thus you will have complete test cases run history without any manual actions.

The one potential problem is how to map Tests from NUnit or Selenium to Test Cases in TargetProcess. There will be several possible ways:

1. Test cases may have the same names as tests. For example, TheOnePlusTwo in NUnit and The One Plus Two in TargetProcess.
2. Tests may have test case ID as a part of the name. For example, TheOnePlusTwo_1876 test relates to test case with id 1876
3. It is possible to use the regular expressions to define the test name pattern. For example, TheOnePlusTwoTest in NUnit and The One Plus Two in TargetProcess.

You may wonder why we integrated with NUnit. The main reason is that Selenium has a nice Remote Control test tool. You write tests on your favorite language, for example C#, and run the tests using NUnit. We were looking for Selenium integration and NUnit integration is just a nice side-effect :)

You have a project and several teams. You want to have a single project backlog and manage work separately for each development team. How can you do that in TargetProcess? The quick answer is “tags and bundles”, however some guidance will help to get the idea.

Tags and bundles is a way to categorize information. With creativity you may find very nice applications for this idea. Let’s try to see how it help to manage several teams’ work in scope of a single project.

First of all, we will create a bundle Teams and add tags Team A and Team B to the bundle. Team A is just a tag, people should know to what team they belong. Usually it is not a problem at all.

The next step is to assign user stories to teams. It can be done in several places. For example, you can go to User Stories list, mark several user stories and add “Team A” tag to these stories.

Alternative way is to use Tags Board. Navigate to General -> Tags Board screen and select Teams bundle. On the left you will see backlog of user stories that are not assigned to teams. On the right you will see two teams tags. All you need is to drag some user stories and drop them to required team.

As a result you will have backlog for each team. What about iteration planning? Navigate to Iteration Plan page and filter user stories by “Team A” tag if you want to see all user stories for Team A. Thus you may plan iteration for one specific team.

Potential problem is a team velocity. If you track overall velocity, it will work out of the box. To have a separate velocity for each team it is required to create parallel releases and iterations inside the project. Each team should have separate releases thread. For example, we create Release 1.A for Team A and Release 1.B for Team B. All releases will have the same Start/End dates (it is not a requirement, if you want you may have different dates).

Now you have iteration plan for both teams. All you need is progress tracking. First of all, user stories list itself give overview of the stories progress.

You may filter the list by Team A or Team B to see the progress specific for each team. Overall progress accessible in Release and Iteration Burn Down charts. However if you have parallel releases it is impossible to see combined burn down for all teams.

As you see, multiple teams support in TargetProcess is possible and quite painless.

TargetProcess v.2.10.4 has some problems reported. We are working on them and likely will release new build today. The list of known problems:

• Date custom field is not visible in lists.
• Exception in list if it is filtered by checkbox custom field.
• Sometimes javascript errors appear in lists (not reproduced yet, but several customers reported this issue).

UPD: bug with javascript reproduced and fixed, new build will be available today.

UPD2: v.2.10.7 released and contains all the fixes above.

Last week we had retrospective meeting. We have identified two major problems. We often unable to ship fully tested and complete build in the end of iteration. The main reason is that some user stories still in development even in the last iteration day, it means integration and acceptance tests will not be run. The other problem is knowledge transfer. Some developers are not willing to use pair programming all the time, the team decided to pair only for complex refactoring and development tasks.

We decided to try three new practices in the next iteration:

1. Daily Code Demos: Each developer must spend ~15-30 minutes every day demonstrating his code to other developer. It is a kind of code review on a daily basis, it does not take much time and should improve awareness inside the team.
2. Coding Deadline: Two days before Iteration end all user stories that are not completed excluded from the iteration delivery and moved to the next iteration. They must be hidden in UI and do not affect application in any way.
3. Define Iteration scope and specs before iteration start. When iteration starts, the following must be ready: iteration scope clearly defined, all use stories in the iteration scope have brief description, iteration planing meeting is done. It will help to start iteration development from the day one.

Let's see the results in two weeks :)

TargetProcess v.2.10 released yesterday. This release includes quite many features and was too long on my opinion. We will focus on shorter releases (about 6 weeks) starting from v.2.11.

The killer feature in v.2.10 is painless tags categorization. We've provided a framework that resolve many categorization problems, from Modules to several Teams in one project. It is possible to add tags to entities, filter and search by tags, see tags in lists and views. There is also exceptional Tags Board area where you can categorize entities easily.

The most important features in v.2.10 include:

• Tags and Bundles
• JIRA Integration
• Next/Prev navigation in views
• Convert entities from one type to another (for example, bug to user story)
• Import custom fields values
• Plugin: Auto-reply email when new request created
• Plugin: Bind emails/requests to a project based on a [key] in the subject
• Create custom field for several entities at once
• Feature is the assignable entity now (it has own workflow, assignments, appears in ToDo list, etc.)
• Help Desk Tickets

We do apologize for v.2.10 release delay. Many of you waiting for it. We have the last problem to fix - Automatic Installer on Vista. It is already fixed and passes the verification now. We hope the official release will be announced tomorrow. Also there was a question whether Tickets included into v.2.10. Yes, they included. What's new page will be updated soon.

One of the latest trends in client-side development is the unobtrusive JavaScript. This trend is very good, since it extends separation of concerns. Several years ago the same happened with CSS. Web designers used FONT tag, BGCOLOR attribute and other visual style representation HTML elements extensively. Pages were bloated with style elements and style change was a real pain.

CSS changed that completely. It separated document structure from presentation and modern web designers likely do not know what FONT tag was designed for. While CSS separates presentation from document structure, unobtrusive JavaScript separates behavior from the structure.

There are quite many frameworks and techniques that enable unobtrusive JavaScript, but jQuery on my opinion is one of the best. It supports Unobtrusive JavaScript nicely and very elegant by itself.

Inline JavaScript	Unobtrusive JavaScript
Have you rjavascript:void(0) Publish Postead our <a href="javascript:window.open( 'terms.html', 'popup', 'height=500,width=400,toolbar=no' );">terms and conditions</a>?	Have you read our <a href="terms.html" class="sidenote" >terms and conditions</a>? jQuery(function($) { $('a.sidenote').click(function() { var href = $(this).attr('href'); window.open(href, 'popup', 'height=500,width=400,toolbar=no'); return false; }); });

You may decide that the second way is more verbose, but it does not matter in general. You will have all handlers in a single place, they will be quite similar and document structure will not suffer from tons of inline javascript.