Guy kolbis

As some of you may heard, I had the pleasure of attending both the champion’s league semi finals that took place in London: Arsenal VS Manchester United. Chelsea VS Barcelona.

Here are some pics:

View Full Album

Let me know what you think…;-D

When you say that you are done with a task, what do you mean?

Does it mean you completed the code?

Does it mean you created tests for that code and all the tests passed?

Does it mean you integrated the code back to the repository and execute a new build?

Does it mean you had your R&D manager review your code?

The point I am trying to explain is that there are so many definition to the term “done”. So I will ask you again: what do you mean when you say done?”.

In my opinion there is “right” answer, nor there is no “single” answer. The term “done” should have it own meaning within your development team. Here is what I usually do: I gather a definition and make sure that everyone agrees with that (according to the company and the situation in hand). Once I have this definition, I make sure everyone in the team knows it, so when I ask: “Is this task done?”, we will all know what is the meaning behind it.

Although there is no single answer or right answer, I strive to make sure that a coding task is (at least):

1. Well coded.
2. Tested.
3. Reviewed.
4. Integrated.

So, you can create a checklist to enforce the term (as above) or you can create a simple rule: “It is done when the tester say so”.

However, there are exceptions, for instance consider the two:

1. Create a new report.
2. Create a manual for the report.

It is clear that you would give different translation to each. My way to solve that is to add another field to a work task, that allows you to define the “done” term.

That’s it, now I am done ;-)

We all know by now the idea behind work item tracking. You all have heard before the word wit (either Task, Requirement, Bug, Issue, Risk, Story and etc.). Basically you can create those items and store them in a repository. This repository, the team foundation server work item tracking engine, is the backlog.

Definition

This is not “T-H-E definition”, however this is my definition for a backlog. A backlog is the location where we store all the “things” that we need to do during the ALM (Application Lifecycle Management) process. The “things” are translated into a work units, which can be Requirement, Task, Bug and etc. All the wits we create are stored, traced and evaluated within the given development process (SCRUM, XP, CMMI, Waterfall and etc.).

Why?

When you develop software or even hardware, there is one important rule in regarding to Backlog: “You should have one!!!”. There are many reasons why you should keep one, for example: Create a work plan from those wits or create an iteration sprint.

The backlog should always be maintained and updated according to the company needs. If you are practicing “Agile” process development, you should be able to add, remove and update items from the backlog. It is a challenging work, but it is worth it.

How to interact with it?

Basically, I like to think (and this is my preference) that everybody can suggest new work units. only the product manager can accept them and decide whether to add them to the sprint / iteration or to ignore them because they have no ROI or any other value to the company. The developers (dev team) can give estimations and derive new work tasks (activities) out of them and so on and so forth.

Summary

Team Foundation Server supply a very good infrastructure for creating and maintaining backlog. You can easily query those work units, update them, give estimations and derive new activities.

What is DOORS?

Telelogic DOORS allows to manage requirements and to increase the requirements communication and collaboration. DOORS ensures conformance to requirements and compliance with regulations and standards. It provides:

• A collaborative requirements management environment

• The ability to manage changing requirements

• Traceability

• Test Tracking Toolkit for small-scale test environments

• Integration with HP QualityCenter for large-scale test environments

• Requirements-driven development

• Business process optimization
• Informal requirements discussions

• DOORS integration with Microsoft® Team Foundation Server

DOORS & TFS Integration

The integration between Telelogic DOORS and Microsoft Team Foundation Server (TFS) enables development teams that use Microsoft Visual Studio to create and maintain traceability between requirements in DOORS and TFS Work Items in Visual Studio.

The DOORS - TFS integration supports drag-and-drop linking between requirements and work items and provides a synchronization function to keep link information up-to-date.

DOORS also supports external links, which enables requirements to be directly associated with information outside of the DOORS environment. As traceability needs to be traversed in both directions, DOORS provides support for URLs that take you directly to DOORS elements including Objects, Baselines, Modules, Folders, Projects, or even the database as a whole. This combination of external links and URLs promotes full traceability between information held in DOORS and in other repositories.

For more information click here.