Believe me, I understand TDD. I grok it. It is in my soul.

I also happen to believe (and know from experience) that unit test frameworks are valuable far beyond their use in TDD. Some of the best uses are for integration tests at the API level.

It is this coolness that makes it so handy to run a unit test harness as a load test run using VSTS. I worked with one client who had a particular need for this in testing a HUGE network of independently addressable embedded Linux devices, each one exposing a TCP/IP-level API. More on how to running unit tests as load tests here.

But on to my latest use of a unit test. Remember back in the day when we wrote libraries without unit test frameworks? What did we do? We wrote a little command line EXE to exercise the thing while we wrote it and never checked that in to SCC. It worked, mostly.

I often have the same need when writing Windows Forms applications. I want to spool up and play with a window without all of the overhead of the entire application. So, here's my test.

               1:
              namespace ElegantCode.BeSure.Test.GivenTheConfirmationDialogIsDisplayed

               2: {

               3: [TestClass]

               4:
              public
              class WhenTheUserClicksNo

               5: {

               6: [TestMethod]

               7:
              public
              void ThenTheDialogResultShouldBeNo()

               8: {

               9: ConfirmationForm
confirmationDialog = new ConfirmationForm();

               10: DialogResult
result = confirmationDialog.ShowDialog();

               11:  

               12: Assert.AreEqual(result,
DialogResult.No);

               13: }

               14: }

               15: }

No, this is not a unit test. All this does for me is allow me to open the window in a run time environment, see it lay out on the screen, click around on it, etc.

If you notice the structure of the test naming, I am using a little BDD convention because I am wondering about the idea of building a manual regression suite this way. What if a tester sites down and runs through a manual test by launching the a unit test harness that drives the UI.

It's an interesting idea, anyway.

I am a simple man. All I ever wanted was drag and drop for source control. That folder chooser dialog was a bear. Now we will get it with Visual Studio 2008 SP1. Thank goodness. From the web site:

• Simplified the user experience through cleaner "Add to Source Control" dialogs, drag and drop support to the Source Control Explorer and a much easier to use "Workspace" dialog for working folder mappings.
• Version control now automatically supports non-solution controlled files.
• Various changes to the Source Control Explorer such as a new checkin date/time display column, local path hyperlink support and en editable source location field.

I am not a big fan of installing a beta SP on may dev laptop, but I gotta tell ya, I did it for that feature alone.

In many Agile development processes, there exists the idea of THE BACKLOG. This is particularly true in Scrum, the methodology that originated the idea. The recipe from Scrum is a Product Backlog which contains all the requirements or features desired in the software being created.

The backlog items are organized in priority order, determined by the Product Owner (PO). The PO can use any criteria to prioritize the backlog items. Priorities may be driven by risk, return on investment, or client demand. No matter what technique is used, this prioritization is crucial to the use and effectiveness of the backlog.

This all works quite well in a  situation of a single team creating a single product. It even works well when we scale up a bit and have one team working on several products. It just becomes necessary for the two product owners to strike a bargain on how to share team capacity.

It turns out that scaling to even bigger scenarios with an Enterprise Backlog and many teams working from it presents some new challenges. In this model you manage all work in the enterprise in a single backlog. This immediately draws into question what the "real" backlog is. Backlog managers may be interested in a view of the backlog that shows the prioritized list of items for a particular system, a team, a product, a release, or some other grouping.It becomes quickly apparent there are many ways to "see" the backlog.

Which Backlog View Wins?

Obviously, a PO is primarily interested in the view that shows the backlog for a particular product. For a release manager, coordinating the overall release of a product suite, the view of items to be included across many products in a big release is the perfect view. If you are a project manager, interested in a theme of work that will affect many products (think the Smart Art feature in Office 2007), you are looking for the theme view. We can think of this problem as dimensions in a multidimensional cube if it helps you BI types.

With all these views of the backlog going on, and each one of theme prioritized from 1-n, which one is the actual backlog?

• Theme View
• System View
• Release Cycle View
• Scrum Team View
• Product View

The easy answer is, "They are all important, depending on who you are and what you are interested in." It is true, though, that two of these view are closer to reality than all the others. While most of these views represent what we hope will get done, 2 of them are just a bit closer to what will get done, or has been done.

The Scrum Team View

This view aggregates the work items into a collection that actually represents what the team will be doing. This is the backlog the team will use in Sprint planning as they plan an iteration of work. If you are a theme owner and your work items aren't showing up in the Scrum Team View, you're in trouble.

The Release Cycle View

This view (and an associated burndown chart) helps us see the reality of features that are scheduled for release and those that have been completed. This view represents the absolute reality of what we can tell the clients will be in the next release.

Just Get Them

The real truth is that all of the views really are important. The real challenge is in deriving the views in the first place. If you are trying to work with an Enterprise Backlog and haven't got a good model for segmenting it, you may soon find it unwieldy. Find the right view to help you interact with the requirements and make sure your backlog items provide the data needed to see it. Just remember the 2 views that live closer to where the rubber meets the road.

I just had a meeting where we discussed setting up a TFS 2008 production server and I went through the system requirements with our system administrator. The focus was on groups needed in Active Directory, what software is needed on the server, things like that.

Here are some camera phone shots of the whiteboard during this discussion. Wow.

What's the takeaway from all this? PLAN YOUR IMPLEMENTAION DELIBERATELY. Stand up a research VM and play with it before you decide how you want to set up a production system.

Groups and Accounts to Create and Administer

Things to Install on the Server

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.

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.