My final talk at VSLive! San Francisco this week was on one of my favorite topics - parallel development. In other words, dealing with the real-world situations where multiple developers are coding away on the same project, and even the same file.

The first order of business was to have a few of the ex-Visual SourceSafers lay down on my couch so we could discuss their phobias and irrational urge to run to their "safe place" - a.k.a. locking.

In all seriousness, we discussed the two locking models of TFS and then explored the many wonderful benefits of not using locks by default, known as shared check out. Most in the audience agreed that the benefits of not blocking each other with their routine development (for example, not locking .csproj files when somebody adds a new file) greatly outweighs the detriment of having to deal with a conflict that requires manual intervention. Of course, arguments can be made either way.

I pointed out that there are four situations where conflicts can occur that may require auto/manual merging:

• CHECK-IN - the most obvious; somebody else may have just checked in competing changes just before you
• GET - you may already have pending changes on one or more of the files you are trying to download
• MERGE - by definition; when you merge changes from one branch to another, the chances are good that you will have to resolve conflicts
• UNSHELVE - not so obvious, but this is basically like a GET, just coming from another location in TFS; unfortunately, Team Explorer doesn't know how to handle the detection/resolving of these types of conflicts, so look to the TFPT UNSHELVE power tool for help

Finally, we looked at setting up a source control folder structure that will support your teams promotion model (a.k.a. staging environment). I proposed a simple structure, that looks somewhat like this:

Some explanations

• Code holds code artifacts - C#, VB, SQL, WiX, etc.
• Documents holds snapshots of the SharePoint site archived at the end of each iteration, release/version, build, etc. (whatever your term is)
• Active development occurs in "Current", which you could name "Dev" or "Main" (although I prefer "Main" for integration)
• Under the "Current" folder you'll have folders for each high-level application/component in the system, including common, database scripts, build definitions, and even setup projects
• "Branches" are just that - QA, UA, RC, Release, and private branches (Bridges), etc.

If you'd like to have a look at my slide deck, you can find it here.

That was the topic of our discussion today at VSLive! San Francisco. Unfortunately, in the short amount of time (75 minutes) we didn't get too deep into all of the tools and techniques, but I did get my point across: I feel that Team Foundation Server (TFS) can do it all, and you should strive to migrate your source/revision control system, requirements and defect tracking system, document managing system, automated build and deployment system, and even your custom process workflow over to TFS.

That said, there are certainly situations where existing systems must be used. I identified two categories of such legacy software:

• Politicalware - somebody important in the organization bought or built the system and you there are strong feelings about migrating away from it
• Guiltware - the organization spends oodles (that's a lot) of cash on said software, maintenance/support, training, etc. and they haven't seen their ROI (and they may never see it)

I don't know what to tell you about the above situations, except that running in parallel (not good) or integration (better) would be an option. That lead us to the discussion of building custom software to do one-way and two-way synchronization with said systems. We briefly walked through the TFS Migration and Synchronization Toolkit (found on CodePlex) and I demonstrated the TFS to TFS Migration Tool (also found on CodePlex) which uses the toolkit.

I see Team Foundation Server as yet another great "grassroots" platform. Just like .NET was for the developers, TFS is for the team. So, I say get it installed no matter what, even if just for source control, which is the no-brainer. Once it's in-house, then work on migrating the work items, automated builds, and other systems over sooner, rather than later, so you can enjoy the end-to-end traceability, product quality reports, and process quality reports.

If you'd like to have a look at my slide deck, you can find it here and my demo files here (you'll need to download the SDK and CodePlex toolkit and tool separately).

For those of you who joined me at VSLive! this week in San Francisco, I had fun sharing many worst (or un-preferred) practices I've run into over the years. My talk broke them down into several areas: TFS installation, TFS configuration, team projects, work items, and version control. Hopefully I didn't make anyone feel tool uncomfortable when I highlighted your practice on the big screen!

Actually, it was all in good fun. By highlighting Team System worst practices, we were able to define Team System best practices and preferred practices.

If you'd like to have a look at my slide deck, you can find it here and my demo files here.

Feel free to let me know about any other worst or worster practices you may know of.

I am currently in Jacksonville, North Carolina to teach a 3 day Team System class to the U. S. Marine Corp. To get here, I took 3 planes today with the last one loaded up with Marines on their way to Camp Laugune, just like me.

I was listening to podcasts, mostly "This American Life" and ".Net Rocks". In fact, if you are at all into Team System, you have go to listen to this episode of .Net Rocks: Joel Semeniuk on the State of Team System. Joel sheds some light on what to expect in Rosario, which is a mature v3 of Team System with a strong focus on test.

None of this is the point, though. The point is to let you know that nothing will make you feel like a bigger wuss than riding in an airplane of Marines with a ring neck pillow that won't fit in your carry on bag.

They were polite. No one actually called me out. "Hey, neck pillow, computer geek," they could have said. But, they didn't. One or two did sneer a little, though. It's ok, my neck was really comfy.

This is going to be an great week.

Because of the decentralized control model of Agile software development methodologies, there is a living debate on the role of a Product Owner, particularly in Scrum which defines the term.

Here are links to sufficiently ambiguous definitions from some trusted sources, all saying effectively the same thing.

http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms#1122

http://www.mountaingoatsoftware.com/product_owner

More informative is this course description from the Ken Schwaber for his Certified Product Owner Course.

http://www.controlchaos.com/certification/cspo.php

and this course description from Mike Cohn:

http://www.mountaingoatsoftware.com/product_owner_training

There is another question commonly asked in this discussion, though. “Who writes the requirements?”

The idea behind Agile product development is that requirements DO exist, typically in the form of a backlog. The next point is that they are expected to change. In this regard, the Product Owner has the responsibility to continuously and actively manage the requirements. It is easily seen that the only way for a Product Owner to effectively do this is through intimate familiarity with the requirements. While the Product Owner may not have been the person to initially place an item on the Product Backlog, they are accountable to the team for maturing that requirement into an executable state.

Therefore, who is responsible for requirements? Clearly, the Product Owner.

Lastly, if you are still having trouble identifying the Product Owner for a given system, product, project, or initiative, remember this one thing:

"The Product Owner is the one person in an organization responsible for P&L (Profit and Loss) of the work." -- Jeff Sutherland

Seriously. They can't.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=259259&SiteID=1

You may delete specific values, but not the list itself. This means you can effectively "zero out" a list by deleting all of it's items.

I don't quite understand why this would be a good feature, as it doesn't really stand up for a test of trace-ability. I just deleted a Team Project whose work items referenced a global list, so there are no references to the list in the system anymore.

Perhaps one way to mitigate this would be to use abstract list names? List A, List B, etc. Then you could re-purpose a list later by giving it new values. Nah.

So, what's the take away? Be very careful about the Global Lists you create in your Team Foundation Server. They will be with you a long time.

Mike Azocar, a fellow Team System MVP, reports:

We released LWS version 2.1 today.  This version includes a new process guidance and SharePoint template as well as many work item enhancements.   You can download it at
www.codeplex.com/vstsscrum

Mike also indicates that they will soon release a version that will work with the Project Server connector.

Having just inherited a TFS installation to manage, I received a request to add some values to a global list. I got a little nervous about this when I saw that the server had many (MANY) global lists in it already and I wanted to be very careful not to break anything during this change.

Of course the first thing I did was consult the master book on the subject of TFS, Rich's Working with Microsoft® Visual Studio® 2005 Team System. This was a great start to groking the whole Global List thing.

The steps needed to do this are pretty simple and documented well from Microsoft. The step to export your current global lists is to use the glexport command line tool. From the Visual Studio command line prompt (this works fine on a client), do this:

glexport /f AllGlobalLists.xml /t myTfsServerName

Credentials used are the local login credentials. This gives me one big file containing all the global lists in the server. Now the question I had was this, "Should I edit this master global lists file and import the whole thing, or should I just try to import changes to one list?" Obviously I wanted to work only on the one list I needed to change, but what effect would it have if I pulled out all the other lists from the file and uploaded just a single list in a smaller XML file?

I was scared to death of deleting all the other lists in the file. I saved a copy of the master, and then took out all the global lists except the one I was interested in, changed the values, and ended up with something like this:

<?xml version="1.0" encoding="utf-8"?>

<gl:GLOBALLISTS xmlns:gl="http://schemas.microsoft.com/VisualStudio/2005/workitemtracking/globallists">

  <GLOBALLIST name="Teams - Product Backlog">

    <LISTITEM value="Team A" />

    <LISTITEM value="Team B" />

    <LISTITEM value="User Experience" />

    <LISTITEM value="Team C" />

  </GLOBALLIST>

</gl:GLOBALLISTS>

So, on a wing and a prayer I ran this command:

glimport /f TeamList.xml /t myTfsServerName

And guess what happened: It worked great! All of my other lists were intact and my new team names showed up just fine. So I learned 2 things in this little exercise.

1. You can import a single global list XML file into your TFS server without affecting other lists.
2. glimport and glexport work just fine on a VS2008 client talking to a 2005 TFS server.

Martin Woodward has done his magic again! For those of you who don't know Martin, he is the primary developer of Teamprise, a fantastic suite of client applications that gives Java developers cross-platform access to Team Foundation Server from the command line, a stand-alone GUI or an Eclipse plug-in. In his blog, Martin announced the release of Teamprise 3.0, updated to take advantage of the new features in Team Foundation Server 2008.  This release contains some many impressive new features including check-in policy support, recursive folder compare, single sign on support on windows clients, and gui support for version control undelete and destroy commands. Perhaps the most impressive new feature is the full Team Build integration and the brand new Teamprise Extensions for Team Foundation Build, which allows developers to use Ant scripts with Team Build - amazing! Even better, Teamprise Extensions for Team Foundation Build, including source code, is available free of charge to everyone.

For more information, see Martin's announcement.

Last year I posted a note about how to integrate VSoft Technology FinalBuilder with Team Build. I really like FinalBuilder and think it's easy to use, compared with having to hand-jam the XML of MSBuild.

With the upcoming version 6.0 of FinalBuilder, this integration becomes a snap, even including a Visual Studio add-in for configuring Team Build.

Read this article for more information.

It's generally known that if you want to run any tests, code analysis, or database project build/deployment that you need to install one or more Team Edition of VSTS on your build server. What's not so well known are the licensing ramifications around these scenarios.

Fortunately Jeff Beehler, Team System Chief of Staff, has posted on this subject.

To summarize:

If the users creating the builds are licensed users of the edition in question (or Team Suite), that license extends to Team Foundation Build and you don't need to purchase an additional license. One way to think about it is: the people that are using the Team editions need to be properly licensed which in turn ensures the that the build machines are covered as well. Users who merely queue (execute) and review the automated builds are only required to have a Team Foundation Server CAL.

Have you ever had a production application in the data center act up, and you spend countless hours hunting down the source of the problem? If so, then then you might be interested in a new project on CodePlex called Design for Operations (DFO).

For years now engineers have been designing physical products with ease of manufacturing in mind. Called Design for Manufacturability (DFM), this technique takes fabrication and assembly into consideration early in the design process. DFM has a significant impact by improving the cost and quality of a product. Well, a variant of the technique has finally found its way to the world of software. Called Design for Operations, this technique allows software architects and developers to design their applications with built-in, real-time health monitoring, giving the operations staff much better operational information and improving the quality of service. According to William Loeffler, a Microsoft program manager:

It’s a recent effort from patterns & practices to provide tooling for architects and developers with a means to model their application in terms meaningful to operations. Once modeled the tool can be used to create a Health Model for the application and once the Health Model has been completed at the architect and development roles the tool can be used to generate platform instrumentation as defined in the model. All that’s necessary for the developer is to call the generated API within their solution for each instance of instrumentation. The tool will also generate a Management Pack for System Center OpsMgr 2008 from the model that matches the generated instrumentation.

For more information see:

http://www.codeplex.com/dfo

Hopefully DFO will become mainstream in the software development discipline, in the same way that unit testing has become popular.

Since first seeing the Code Metrics feature in the Development Edition of Visual Studio Team System 2008, I've been on a quest for bad (read: unmanageable) code. Rather than face the tool towards my code, I thought I would pick on Microsoft.

... and it looks like the EntLib has a maintainability index between 77 and 89.

Thanks to Ajoy krishnamoorthy for actually doing the hard work on this.