TP 2.0 will be officially released next month and pre-orders already available. If you are going to purchase TP 2.0 you have a chance to save some money.

In latest iteration we mostly did not work on exciting features, but focused on must have things like automatic installer, user guide, email notifications, etc. However, we still can show some nice things (as always, you may check online demo with any login and pasword)

The most important (and maybe smallest) feature is Inline Assignment. For example, you may go to user stories list, click Unassigned link for “my user story“, select user and assign user story. No page reloads, so assignments now are very fast and usable. We do like this feature very much.

We’ve finalized Bug Submission Tool (it is called TP.Tray now). It will be available for download soon. Really nice stuff.

Audit history tracks all changes in entities and provides nice log right in the entity View page. It tracks all field, attachments and comments, so you will always see complete entity evolution. Later we are going to implement Undo functionality.

Automatic installer is a must have thing for any serious application. We’ve used NSIS for installer and it works great. It is much more flexible than standard VS.NET installer. Now if you have IIS, .NET 2.0 and SQL Server installed, TargetProcess can be installed during 1 minute. Seriously.

Automatic email notifications are customizable now. You may choose user groups and events for them. For example, you may want to notify all developers in project team when new user story added into the system or notify user when she got new assignment.

Email about new assignment is quite informative as you see :)

It is possible to set company name and logo that will be displayed on top. Many customers asked us about this feature and now it is there.

Also we’ve added two reports. One is an old Bugs-by-Severity distribution chart and second is time report that shows total spent time for selected period.

Recently I’ve discovered Steve Eichert’s post about one-week iterations in theirs project. Honestly, as I read through, I felt something wrong about their process, at least it was my perception of provided information. I really wonder about QA. They fix bugs 0.5 day, I can imagine that it is possible, but how about testing and verification?

We are doing two-week iterations (10 working days) and typical iteration looks like this.

1 day. First day is Tuesday. In Tuesday development actually started. Iteration plan created on Monday, but this is not considered as a part of iteration in general (see 10 day for more details).

2-6 days (from Wednesday till Tuesday). Development of new user stories. In general we do not test unfinished features, since there is a big chance to get “Hmm, I don’t find that checkbox” bugs. So feature is not tested till completion, just some smoke testing may be done.

7 day (Wednesday). Pure testing. In this day whole team run acceptance tests (if one or two developers still need 1 day to complete user story, they may continue with development, but this is resolved on morning daily meeting). Usually full day of testing is enough to assert quality and collect about 20-30 bugs.

8-9 days (Thursday and Friday). Testing, bug fixing and verification, just QA activities.

10 day. Last day is Monday. During the first half of the day we are fixing and verifying bugs, releasing new version, making announcement and updating online demo. Second half of the day (usually 3 hours) dedicated to next iteration planning. We discuss priorities, select and re-estimate user stories, make initial assignments.

So we dedicate 3-3.5 days from each iteration to QA activities (about 30-35%) and 5% to iteration planning. If we’ll run 1 week iteration with the same proportions, activites distribution will be:

• Planning – 0.25d
• Development – 3d
• QA – 1.75d

So on average developer will have no more than 3 days to complete user story. In most cases it is OK, but you should be very careful with user stories and split them on smaller whenever possible. And I should say that such splitting is not ALWAYS a good thing. We have user stories that just can’t be smaller. One latest example is Bug Submission utility. It can capture screenshots and post bugs into TargetProcess without web-browser. It is fairly large user story (maybe even theme) estimated in 20 points. It was developed during 2 two-week iterations and actually was artificially splitted on 3 stories:

1. create screen capturing utility (8 points)
2. send bug functionality (8 points)
3. beautiful UI + installer (5 points)

But in general customers don’t need the tool without any of the smaller user stories above, so it will take four one-week iterations to implement it and it requires even higher granularity. I don’t think it is a good way to go in this case.

Maybe our agility is not as high as demanded by one-week iteration, but I don’t think they can work better than 2 weeks iterations in almost any web project with 4+ developers.

What Can Be Improved?

In fact acceptance testing is a weak side of our process since we don’t have automated acceptance tests. Everything fine with unit tests (we already have about 500 fancy green tests :), but acceptance tests are harder to automate and support. We’ve tried web tests from MS VS Team Suite, but they don’t work with AJAX (really funny, Microsoft developed Atlas, but did not provide compatibility). Currently we are looking into Selenium and it seems very promising tool (test recorder, AJAX compatible, continuous integration support).

The second thing in our road-map is Continuous integration. We are working together in one room and so far broken builds are not a big problem, since problems discovered early and fix within minutes, but with automated acceptance tests continuous integration will provide even more value, so we are going to setup Cruise Control and have several daily builds with acceptance tests results.

Then we are going to integrate TargetProcess with both CC and Selenium and have real-time stats about project progress. This will be really cool.

So let’s us show some new features in latest TP 2.0 Public Preview (as always, it is available online with any login and pasword)

Advanced and Saved Filters

One of the most helpful usability feature in latest release is advanced filtering and saved filters. Advanced filtering includes possibility to filter data very flexibly, while saving filters allows you to filter data, save current filter into the database and reuse it later when required. Also it is possible to set saved filter as default and it will be applied each time you visit the list. For example, you may create filters “All Not Closed Bugs” or “All Open Unassigned Bugs” and use them in all projects.

Multiple Attachments

Another useful feature is multiple attachments on entity submission

They work without page reloads, so you may create a bug with five attachments if required with easy.

Drag and Drop Prioritization

The third feature is a drag and drop prioritization. In current preview this is just temporary demo, later we will combine prioritization with Plan Iterations tab to allow more actions from single place. It is very intuitive and works full on client without page reloads (very fast). This is the result of our long running “Drag and Drop Performance Optimization” activity.

Points Effort Units Support

And the next thing worth to mention is Point effort units support. In short, Points are relative abstract effort units that works great for experienced agile teams. Points are a relative measure of user story size. Usually they are used with discrete scale. For example: 1,2,3,5,8,13,20. This scale means that user story with 3 points is about two times simpler than user story with 5 points, no more. Estimation with points is easier, since you estimate-by-compare: "We'll give this story 2 points because it seems like it's twice as big as that 1-point story and about half as big as that 4-point story".

Many agile teams use Points (we are as well). The best examples and clarification of Points usage I’ve ever seen is in Mike Cohn’s book Agile Estimating and Planning. In general, it’s an exceptional book for every project manager and I highly recommend everyone to read it.

We are two iterations behind official release, so next iterations will be less feature-reach, since we should write documentation, create installer, fix some known problems and pass pre-release quality assurance activities. Keep reading us!

Latest iteration has been very productive. We’ve implemented many great features like custom fields, saved filters, drag and drop prioritization, bug submission tool (in alpha). Since some of them a quite large, in this post we’ll cover bug submission tool.

Bug Submission Tool is a Windows application that lives in systray and allows capture screenshots and post bugs directly into TargetProcess without web browser. This is a great productivity tool for QA people. Steps are quite simple:

1. Set login parameters so TargetProcess may authenticate you

2. Push Ctrl+B or Add Bug option in tray. Capture utility will appear. Select required area using cursor

3. In editor you may add text and lines to highlight problems. Then click Submit Bug button

4. Bug submission screen loads available projects in background as well as user stories. Fill required fields and click Submit button

5. Bug will be submitted together with screenshot. That is it.

User Interface is a work in progress and will be improved till final release, but functionality is quite good and tool will be very helpful.

At this time our team developing small desktop application which should improve productivity of QA by allowing them to post bugs with attached pictures in ‘one click’. The background idea of this app is that when QA Engineer found a bug he/she presses the special hotkey which starts our application, mark a bugplace, fill bug name/description and submit the bug. The application helps to avoid next typical actions of any QA engineer:

• Press Ctrl + Print Screen
• Open Paint
• Ctrl + V into Paint
• Mark a bug
• Crop a bug
• Save picture as (with selecting of folder of course…)
• Create bug and attach there picture (browsing folders again!)

The problem is that C# does not have solution to bind hotkey through its API. Quick search in Internet allowed creating basic solution. Fist it is need to import two Win API functions to register/unregister Hotkeys in System.

[DllImport("user32.dll", SetLastError = true)]
private static extern bool RegisterHotKey(IntPtr hWnd, int id, KeyModifiers fsModifiers, Keys vk);
[DllImport("user32.dll", SetLastError = true)]
private static extern bool UnregisterHotKey(IntPtr hWnd, int id);

Since these functions requiring HWND we need add support of Windows Handle in our code.

  private IntPtr handle;
  public IntPtr Handle
  {
   get { return handle; }
   set { handle = value; }
  }

Now Hotkeys can be registered by calling

  RegisterHotKey(handle, id, modifier, key);

where id is unique identifier for hotkey for this thread.

We also need to handle windows message when hot will be pressed in our application. To do this we inheriting our class from IMessageFilter and creating handler of messages:

  public bool PreFilterMessage(ref Message m)
  {
   switch (m.Msg)
   {
    case WM_HOTKEY:
     // rise event from here
     return true;
   }
   return false;
  }

where WM_HOTKEY is 0x0312.

Finally our class will look like bellow. The class is created exclusively for one Hotkey assignment for whole application, however it may be easily expanded for any keys count.

 class HotKey : IMessageFilter
 {
  

  [DllImport("user32.dll", SetLastError = true)]
  private static extern bool RegisterHotKey(IntPtr hWnd, int id, KeyModifiers fsModifiers, Keys vk);
  [DllImport("user32.dll", SetLastError = true)]
  private static extern bool UnregisterHotKey(IntPtr hWnd, int id);


  public enum KeyModifiers
  {
   None = 0,
   Alt = 1,
   Control = 2,
   Shift = 4,
   Windows = 8
  }
  
  private const int WM_HOTKEY = 0x0312;
  private const int id = 100;


  private IntPtr handle;
  public IntPtr Handle
  {
   get { return handle; }
   set { handle = value; }
  }

  private event EventHandler HotKeyPressed;
 
  public HotKey(Keys key, KeyModifiers modifier, EventHandler hotKeyPressed)
  {
   HotKeyPressed = hotKeyPressed;
   RegisterHotKey(key, modifier);
   Application.AddMessageFilter(this);
  }

  ~HotKey()
  {
   Application.RemoveMessageFilter(this);
   UnregisterHotKey(handle, id);
  }


  private void RegisterHotKey(Keys key, KeyModifiers modifier)
  {
   if (key == Keys.None)
    return;

   bool isKeyRegisterd = RegisterHotKey(handle, id, modifier, key);
   if (!isKeyRegisterd)
    throw new ApplicationException("Hotkey allready in use");
  }

  

  public bool PreFilterMessage(ref Message m)
  {
   switch (m.Msg)
   {
    case WM_HOTKEY:
     HotKeyPressed(this, new EventArgs());
     return true;
   }
   return false;
  }
  
 }

From now we are going to push new releases every other week (yep, we are doing 2 weeks iterations). Yesterday we have released second public preview of TP 2.0 (agile project management software). You may check it at http://20.targetprocess.com/demo/register.aspx (use any login and password)
Your feedback is greatly appreciated!

This release includes the following features:

Simple Search

Programs Area

Latest Activities Control

Release Planning With User Stories

Planning and TimeTracking Tuning

Some features planned for latest iteration have not been implemented. User Stories Drag And Drop Prioritization and Drag&Drop Performance Tuning

The main idea behind D&D performance improvement is re-write D&D, get rid of update panels and move all actions on UI. With current implementation D&D works not very good in IE with more than 100 entities (there is no such problem in FireFox though). New implementation will be really fast, prototype proved that.

In general, we expect that first General Availability release will be made in the middle of November. We still need three iterations to complete important functionality and make first release comparable with TP 1.7.