Hi, everyone. I want to describe an issue I’ve recently faced when working on a TFS-based project and share the original solution found.

The Issue

The project utilized Team Foundation Server assemblies. The need to use both TFS 2008 and TFS 2010 assemblies aroused when TFS 2010 was released. In short, the names of the assemblies stayed the same, while their versions were different.

The Solution

As you can guess, this issue had a number of solutions and it’s not the purpose of this post to make you think that mine is the best one.

Our team elaborated on several ways to solve this problem:

1. Create two different branches for the project—each branch for each version of assemblies. However, we’ll have to support both branches in this case, which is not a great idea.
2. Use reflections. This method is really good, but requires a great deal of time on implementation and testing.
3. Compile the project for different versions of assemblies, depending on the chosen “Solution Configuration” option. Let’s have a deeper insight into this option, since it appears to be the best way to solve the issue.

Below is a step-by-step guide on implementing the solution.

To start with, open Configuration Manager.

Create a new configuration that will be used for build-building other TFS version. I’ve named the new configuration as “BuildRelease2010.”

As you may see, there’s no need to create a new configuration for each project in your solution. You may do this only in case your project utilizes different versions of assemblies—just like I had.

Open the properties of the projects that are supposed to be built with different versions of assemblies. Add “Conditional compilation symbols” to the new configuration.

Open the code itself and add the condition for working with different assemblies, if needed. In my case, the creation of the instance that implements the IserviceProvider interface required working with different versions of assemblies.

#if BUILD_RELEASE_2010
TfsTeamProjectCollection server = newTfsTeamProjectCollection(newUri(tfsUrl));
#else
TeamFoundationServer server = TeamFoundationServerFactory.GetServer(tfsUrl);
#endif

Open the .cproj file in Notepad or any other text editor, find the Reference to your assembly (in my case, it was Microsoft.TeamFoundation.dll), and add the following Condition tag: (Condition=”‘$(Configuration)’!=’BuildRelease2010′”).
..\Bin\TFS\Microsoft.TeamFoundation.dll

Now add the Reference to the new version assembly with the opposite Condition:
..\Bin\TFS2010\Microsoft.TeamFoundation.Client.dll

That’s it. Choose the configuration needed and start build-building, voila!

Pros

Implementation is fast and easy.

Cons

The look is not so preppy, as it could have been.

If you had the same issue, how did you solve it?

Team Foundation Server 2010 scheduled for release in mid-April will include several new TFS reporting options. The main improvements are a set of Excel-based SharePoint dashboards, improved SQL Reporting Services, and Excel Reports based on Work Item Queries. With more possibilities for bug, build, and test control, as well as more place for customization, software development projects, I believe, may become now more transparent.

Why I’m so fond of TFS customization and transparency?

Well, there are no two absolutely similar projects. The goals are different, as well as the requirements. Metrics that a customer needs to track are also different, depending on the goals a customer aims to achieve. TFS reporting allow for getting more metrics needed, which can make the project more transparent and improve the control over it.

What project transparency may lead to?

Improved TFS reporting allows for more comprehensive information on bugs, builds, and tests, which provides clearer picture of the project in progress and gives the possibility to find out the points where the project may stick.

By virtue of the improved TFS reporting, software development projects may get more transparency, with more places for improvement becoming evident. So, the decision on necessary changes may be taken earlier, which is an obvious benefit, since implementing changes and bug fixing on the early stages of the project prevents unwanted expenses.

Yesterday, I had a very interesting discussion with a friend of mine about project time tracking. Being a project manager in a small company, he’s been looking forward to find some project time tracking tool that could help him get more accurate data on time, as the way of time tracking they were used to often proved to be inaccurate and time consuming. So, my friend needed to find arguments to convince his executive in the efficiency of the efficiency of project time tracking software versus spreadsheets.
As a result of this talk, I decided to describe the difficulties a project manager faces when using the old-fashioned means of project time tracking, such as a kind of shared calendars to plan tasks and activities, and weekly Excel spreadsheets where actual time spent on those activities is marked.

1. Inaccuracy in the reported time. – Shared calendars are great to plan some activities, as a manager may add changes to the tasks or appoint tasks for the next week or even month. The problem is that when it comes to entering the time spent on tasks in Excel spreadsheets manually, the probability of making a mistake is very high. Moreover, hardly everyone may remember (or mark in a calendar) the exact time it took them to fulfill this or that task. When company’s clients are billed for time-and-material, it’s more than just inconveniency.
2. Consolidating all spreadsheets takes too much time. – Even in a small company of about 30 employees getting all the Excel timesheets together is a pain. It takes a significant amount of time. But to worsen the things, someone may suddenly need changes in his/her spreadsheet, as misspelled the numbers, or “completely-forgot-about-that-little-five-minute-task…” I say, it’s a nightmare.
3. Time-consuming reporting. – Then a project manager needs to make reports for accountants, for customers, for executives, etc. out of the information received, which is also rather time-consuming.

Project timesheet software eliminates the double work of entering and re-entering the data from calendars to spreadsheets. Entering the time spent on tasks daily provides more accurate data, and there’s a far less chance for making a mistake.

There’s no need to wait for the spreadsheets to come, as the data gets into a single system, and a project manager has the access to the information just as soon as it is entered.

Moreover, there’s no need to spend loads of time on making reports, as project timesheet software, commonly, provides the possibility of creating different kinds of reports automatically. The reports for accounting, billing, etc. are done faster, and much more accurately, thus providing more accurate and actual calculations.

P.S. The problem is that my friend’s executive is a kind of far away from being a geek, using his PC once a week to check e-mails. He’s absolutely satisfied with the way project time tracking is performed currently. Hope, however, as my friend’s going to provide him with detailed calculations of the savings the customers and the company can achieve, thanks to accurate billing, his eyes and his heart will open to the progress.

Today, most companies have implemented or intend to implement and use software for project time tracking. But what exactly they should track?

Some mangers insist on tracking everything, every single step or activity aiming to be aware of how exactly an employee spends every minute of the working day. But this is, actually, time tracking for the sake of time tracking. And in such a situation I can understand guys who say they’re just wasting their time.

There should be a clear purpose for the use of project time tracking software. The key is to define the metrics and understand what data (received through project time tracking) will be useful for different business purposes. They may be accurate billing, productivity and efficiency tracking, project estimations, etc. So, when the purpose is known, it becomes easier to choose the project time tracking tool that can provide the necessary data

Project time tracking software is not just a tool for tracking time spent on different tasks and activities. It supposes that information will be analyzed and used to bring value into business.

Hi!

There’s no doubt that when a company outsources the development of their software products, they want a good possibility to better control everything about the outsourced project. Here project timesheet software is a great controlling tool that can provide a lot of information.

How much time developers spend on different tasks is not just a way to be sure the work is being done. Project timesheet software gives a clear image of developers’ productivity, and gives a great opportunity for improvement.

Most of project timesheets allow a variety of reports that can be used for accurate billing. Moreover, using the data in the reports helps find a space for improvement, control the project progress, and probably, make new project estimations on time and budget. This enhances greatly the quality of business, as project timesheet software eases management of the outsourced software development team to a great extent.

In one of my previous postings, I wrote about a rendez-vous with a friend of mine, the developer, whose way to entertain me was quite peculiar. To be exact, he was complaining about software for project time tracking, they started to use, and how much he was against it, etc.

My point was (as I got furious) that the problem, probably, was in his resistance to make an effort and adopt the new way of project time tracking. However, motivating people (in that case, employees) to adopt something, is a challenge. Here a lot depends on the software, rather than on people.

People are so often devoted to “old good way of doing something,” even if it takes a lot of time. As the idea of project time tracking software is to save time, it should be easy to use. When software has poor or bewildering user interface, for example, or a bunch of unnecessary features, it’s hardly to be adopted enthusiastically.

Then, form the technical point of view, software for project time tracking should be easily integrated with other company’s systems, so the data on time that employees spend on tasks could be accessed from different departments.

In fact, project time tracking, is not the general part of work on the project. It helps to control (self control, as well) and analyze employees’ productivity, as well as search the place for improvement. Employees need solutions that make their jobs easier and become a part of their daily routine. Software for project time tracking that possesses these qualities (apart from functionality, etc.) will be easily adopted.

P.S. And surely, it will not become the subject to be discussed on a date!

Project time tracker is a very effective and essential part of any successful business; however, to get the most out of it, a company should make the right choice from a variety of offerings. The right choice means that the project time tracker suits company’s goals and possibilities the best. There are a number of factors to pay special attention to, in order to avoid an inappropriate purchase.

• Usability. Good usability leads to faster adoption of a project time tracker, while poor usability may result in strong resistance and the need to look for another solution (which means additional expenses and wasted time).
• Functionality. Here the major features and functionality a project time tracker provides should be analyzed and compared to company’s requirements. Often, large companies have more requirements and demand for wider set of features than SMBs.

Possibilities for support and maintenance, including various updates, add ons, etc.
Compatibility. There should be a possibility to integrate a project time tracker with other company’s systems, as the data, provided by the tool, may be used by different departments (HR, accounting, etc.)

Hi!

Project timesheet software, apart from giving clear idea on how and on what tasks employees spend their time, affects greatly billing. This fact speaks in favor of using automated timesheet software against Excel spreadsheets (not speaking about paper-based time tracking).

Usually, invoices are sent to clients, when account managers get the information of all the hours spent on the project by each member of the team. And a team supposes a number of people – developers, project managers, etc. Collecting this information is quite an effort, as people may not submit their hours or send spreadsheets on time, they may get sick, or by any other reason… This becomes more challenging if the development team is comparatively big (which is a common situation with complex projects). Moreover, employees’ rates are different.

So, without project timesheet software gathering the information and making all the calculations necessary to prepare invoices may be really time-consuming and error-prone. Project timesheet software makes this process faster, as the changes and corrections employees make in their timesheets (when timesheet software is used) are made in real time. So account managers get this information faster, with no, or at least, less mistakes, and are able to prepare invoices withing a shorter period of time.

I’ve recently found out an interesting thing about TFS and VSTS. There are several misconception regarding TFS and VSTS, which may result in difficulties with TFS adoption. I’m convinced, that companies that plan to adopt VSTS/TFS to manage their software development lifecycle, should have a kind of TFS training, explaining these misconceptions.

One of them is about Team Foundation Server (TFS) to be just an expensive source control repository. The other, regarding both VSTS and TFS, is saying that they are hard to adopt.

Well, as for the first misconception, it is more about what you are using TFS for. Being an Integrated Process Environment, TFS provides the space for storing and managing everything regarding development initiatives, such as project planning, task status tracking, defect tracking, time tracking, source control, etc. So, in fact, using it just for source control may be expensive. But that’s only because TFS is, a kind of, misused.

Second one, is a misunderstanding that VSTS/TFS is hard to adopt, though the difficulty is mostly about improving software development process. TFS training, in this case, might help to discover how to use this framework to improve the processes, using best practices, such as test driven development, automated builds, continuous build environment, trend information about your project plan tasks,etc.

Hi!

I’d like to have a word about Visual Studio add ins. I’m convinced that VSTS/TFS guys when provided the possibility to create different kinds of add ins, thought about such people, as, for example, I am.

Look, any company that uses VSTS in their software product development and management processes, has not only developers among their staff, but also a number of non-technical specialists of all kinds who do not code, and do not use Visual Studio in their everyday working activities. But as well as developers, they have to utilize some of the VSTS/TFS functionality, in terms of receiving and tracking their tasks, for example.

I suppose, entering TFS each time to check for new tasks, to track their time spent on those tasks, etc. might bring some difficulties, as the environment is completely unfamiliar. So Visual Studio add ins may become a great way out. Let’s take, for example, add ins that allow people work with TFS through the Microsoft Outlook interface that is familiar to most employees. This can improve productivity, as they do not have to spend their time on investigating an unknown interface, and at the same time, work together with the rest of the team.