First Week

My first week here at Agile I've been working on a few different things. First, I've been digging into the Huddle code base. I brushed up on the basics of WPF and even wrote a simple application in XAML before starting last Monday. Now I get to dive in head first to, basically, every feature WPF offers. Along with that I will need to learn WCF. C# is close enough to Java that the transition is looking to be straight-forward. Separately from getting to know the Huddle system, I have been investigating issue tracking systems.

TRAC looks to be a decent system for tracking issues, but I know there are better systems out there. At UNL I used a system named Jira, by Atlassian. Compared to TRAC or Bugzilla, it is a joy to use. Managing issues, tracking change history, and generating reports is super-easy. Jira also has a nice dashboard portal value-add that is useful for viewing the overall progress of a project. It gives a nice '50,000 ft' view from above look at a project (or projects). One thing that we never got into a UNL is workflows.

Pretty much every issue tracking system has some notion of a workflow. This allows the development group to lay out, in the system, their process for doing work. In practice, a workflow may look like the following:

1. A tester discovers a bug, and creates an issue. The tester isn't sure exactly who the issue should be assigned to, but the workflow would auto-assign it based on the component. In addition to auto-assigning the task, the workflow auto-assigns a tester who is in charge of that component.
2. The issue is automatically assigned, and the assignee developer receives an e-mail notification.
3. The developer finishes his other tasks, and is finally ready to begin work. He marks the issue as 'in progress' and begins work.
4. When the developer feels the issue is completely resolved, he marks the issue as 'resolved,' which then sends an e-mail notification to the tester and assigns the tester as the new 'owner' of the task.
5. The tester runs through and discovers that the bug isn't totally finished, so she marks the issue as 'reopened'. Again, the developer gets an e-mail and is auto-assigned.
6. Steps 3-4 are repeated, and this time the tester feels that the issue has been completed. She marks the issue 'closed' and the process is complete.

That is a pretty average case scenario for how work might be done, but the workflow automation allows each person to focus on his/her work without having to coordinate with the component developers to know who is best able to resolve the issue. This also prevents an overall manager from having to intervene and delegate issue assignments. As teams grow, minimizing the need for constant communication is going to become more and more important.

I've been evaluating several different systems for managing issues. The most important attributes I have been looking for include:

• Web Access - a lot of the systems have a Windows client, but web access is convenient
• Requirements Tracking
• Test Plan Management
• Customer Access features - this comes in a wide variety of flavors
• SVN integration - I think this is pretty important
• ActiveDirectory Authentication - most of them support LDAP authentication, so we should be good there
• VisualStudio .NET integration - this would add a lot of convenience
• Ability to import existing TRAC tickets - I think some level of import would really ease a transition from TRAC to the new system

I have been spending more time on this investigation than I originally intended. I think that, if we are going to move to a new system, we should do it while the team is still very small. The need for a more formal process is going to grow with each new hire.