Tags in Team Foundation Service work items

At the ALM summit it has been announced that a tag system is now supported on Team Foundation Service.
What does that mean? Well, that’s really easy J

I can now add simple tags to my tasks, PBI, etc:

Just inserting text into it:

As it’s a column in the Work Item Type, you can filter for them:

And here we are!

You have to remember it’s a first release, and as the Team Foundation Service delivery model is based on Continuous Delivery, we can expect further improvements and new features added soon.

MCSD:ALM – WTF?

Despite it can sound like a really complex acronym this is the new certification launched today at the ALM Summit, purposely baked for Application Lifecycle Management.

It’s made up of three exams: the 70-496 (Administering Microsoft Visual Studio Team Foundation Server 2012) is the first one you should approach, because it’s the most generic one on Team Foundation Server and it covers all the basis for an efficient administration of the platform.

The second one is the 70-497 (Software Testing with Visual Studio 2012), and it’s focused on the testing capabilities of the platform. So it is going to cover Test Manager, planning of test cases and correct management of them, analysis of results, etc.

The last one is the – guess what? – 70-498 (Delivering Continuous Value with Visual Studio 2012 Application Lifecycle Management), covering an effective definition of a end to end SDLC, and then expanding it to the whole ALM – for instance. Then Quality, and Operations.

As for all the new certifications, a recertification must be taken after two years from the completion.

400 characters path limit in Team Foundation Server 2012

This is a brief post to answer a simple question.

“I have been told Team Foundation Server 2012 supports paths longer than 260 chars. How is it possible? How can I manage it?”

Simple question, simple answer: if you have to work on a specific branch, which goes over the limit (eg.: $/Project/SubProject/Branch/…./WhatINeed, over 260 chars) you just have to map it to a shorter local path.

Rationale behind it? This is a needed change in cases we have a huge branching strategy in place, sometimes inherited from migrations of older projects. It impacts just the server, not the clients, so you are still subject to the Windows limit.

git-tf, linking the Distributed and the Centralized worlds

Recently Microsoft released a new open source project, aimed at all these developers who would rather avoid to use Team Foundation Server but they must do so – for several reasons – instead of using Git.

Then it came out git-tf: a bridge for using Git as a local repostitory, after which every commit can be merged as Team Foundation Server changesets.

After you set a local repository up (git init), I suggest you to copy the git-tf files over there. Then you have to bind the local repository to the Server and the Team Project:

Once you’ve done this, you can start adding/modifying the involved files. As a sample, I added a file into the local repo and I committed the file:

 

We’re only missing the check-in

and here we are!

This is the first step toward the Distributed Version Control System from Microsoft It still misses some features, but from version 2.0 (so the latest) on it is a feasible way of letting everybody use what they want inside the company

What’s the difference between the Backlog Board and the Kanban Board?

As you know, in one of the latest Team Foundation Service deployments (I recall it, the team works on a three-weeks-long sprint) and soon to be in the Quarterly Update 1 for Team Foundation Server, there has been a nice new feature: the Kanban Board.

Kanban is a process based on the boundaries imposed by the work-in-progress limits. Everything is in a queue, with defined states (eg. Development Ready, Test Ready, Release Ready, etc.), and the to-do jobs are governed by the capacity of the team. Ideally, this is the best way for ‘just in time’ production

It has a fairly interesting history, as it’s been created by a Japanese man watching american stocking habits in supermarkets. More on Wikipedia.

Kanban forces the team to rely on their self-control, continuously adjusting their queue based on the work they can do. Using it together with Scrum – for instance, inside the sprints – makes software development like a Swiss clock. That is my opinion, of course

How does that fit in Team Foundation Service? The Kanban Board is the main tool for adopting Kanban: it’s visual, and effective.

In our case, it doesn’t affect the existing Backlog Board, they are complementary! Here’s what I mean:

This is a sample Backlog Board: I can see on the left my PBIs, with the inner tasks composing it, and their status.

Here is the correspondent Kanban Board on the same project:

I can just see the User Stories, and not the linked Work Items. And as I am the only project member, I entered 1 as the maximum WIP load. So I can understand just looking at it that I am overcommitted.

So the Backlog Board can be used to understand a finer grain load, at a task level, for my team. The Kanban Board is a useful tool for a project level inspection. They are two different tool but they might be used together

Back to back, to back, to back!

Great news for this year: I have been awarded for the 4th time in a row (here’s the title ) as a Microsoft MVP for Visual Studio ALM.

So you can expect a new, great year of content around ALM, Team Foundation Server and Visual Studio.

And I am really happy to be still part of the family.