I recently ran into a problem with our new Windows SharePoint Services (WSS) 3.0 instance running on Windows Server 2008. I'm running Windows Vista x64 on my laptop, which has been working very well. But, when I tried to download a file from this new SharePoint site, the download started OK but then stopped almost immediately, as if the connection was lost. I did some searching around the web and came across this post. As it turns out Windows Vista can negotiate the TCP packet size with Windows Server 2008 to optimize download speed. Apparently my router (A NetGear FVS318) is throwing a wrench in the works by blocking the SYN packets used to negotiate packet size. Result: no download! Fortunately the fix is very easy once the problem has been identified. Just run a Command Prompt as Administrator, and paste this onto the command line: netsh interface tcp set global autotuning=disabled That did the trick for me! However, you may want to re-enable auto-tuning when connected to a router that handles SYN packets properly. To re-enable TCP auto-tuning, use this command: netsh interface tcp set global autotuning=normal To see the current TCP settings on your Windows Vista client, use this command: netsh interface tcp show global
I expect some people to see this and say, "Hey, that's clever." I know that others will read this and think, "What a hack." Whichever side you fall on, there is little debate that navigating Work Items in Team System via customizable queries can be a little frustrating at times. The rub is in the data matching and ensuring you have fields defined for all the data you want. Often, I want to work with a set of work items that seem to have little to do with each other and aren't tied together with a genuine data model. For example, when my backlog of Product Backlog Items (PBLIs) has 300 work items in it, I want to take 5 of them into an estimation meeting. Or maybe I want to flag 10 of them as a group because they are related via a project that I cannot get to with Area or Iteration data. The logical next question is, "Wouldn't it be great if I could tag a work item in TFS?" Here's how I did it. - Add a custom field to every single Work Item type in my Team Project.
This field is just a string and is not marked as reportable. I only need it available for queries. I added no custom rules for the field, it is just there if you want it, not required or managed as part of workflow. - Add a control (a long one) for the field on all the work item types. I put it right near the top to make it easy.
 - Tag away. As a best practice, I am advising users to treat space as a delimiter to make tag searching easier.
- Create a custom team query that looks like this:
This lets users get to a search fairly quickly inside VS, but the best thing is to create your own private tag searches and keep them around like this:
 - It is much easier to get use out of this using Team System Web Access because the search feature will simply hit against tags.
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 
Now that Team Foundation Server 2008 is out, the Visual Studio Team System product team is totally focused on the next version, known as Rosario. If the current release rhythm continues, Rosario is likely to be released in 2010 (Visual Studio 2005 was released in November 2005, and Visual Studio 2008 was released in November 2007). The latest version of Rosario is now available for public download on the Microsoft download site. This version is called the April Community Technology Preview (CTP). It's called a CTP because the product is still under development. The CTP gives the development community an opportunity to see what's been produced so far and provide feedback. It's not called a Beta because the bits have not been as thoroughly tested. For this reason, Microsoft recommends that this CTP release not be used for any sort of production development. The product team has made impressive progress so far. Rich Hundhausen and I got a sneak preview of this CTP a few weeks ago, and what I saw blew my socks off! Whereas the new features in Team Foundation Server 2008 focused mainly on improvements to build and version control, the main areas of focus for Rosario are project management, design and test (Although I'm interested in all things Team System, I'm somewhat partial to project management). This April CTP is the third CTP release for Rosario. To see the features included in each release, as well as a slick way to download the beast, check out these posts from Jeff Beehler:
When creating a new Team Project in your Team Foundation Server, everything is nice and smooth right up until you get to the permissions of groups and individuals. This can be a real PITA because permissions must be set up in 3 separate places. - Team Project level permissions within TFS itself
- The Share Point Portal site for the Team Project
- The SQL Reporting Services site created to serve reports on the Team Project
If you have done a little forward thinking, you have Active Directory groups for the major role mappings you want to make in all three of these areas. This will make the task a little better, but by the time you've gotten through with your Reporting Services permissions, you start to wonder if you remembered all the right group permissions way back on the Team Project itself. You know that feeling, and by the time you've assured yourself all is well, 10 minutes have elapsed. Enter the CodePlex project "Team Foundation Server Administration Tool". This handy little utility lets you see permissions for each group across all 3 areas all at once. There may be the occasional uncaught exception or UI oddity, but this beats the heck out of doing the job manually. These early releases of Team Foundation Server do still have a few ugly little knots on their heads, and the open source community has really stepped in to smooth those knots out. This utility is one great example. For a more complete list of open source tools for Team System, check out http://widgets.accentient.com/. Thanks to Richard Hundhausen's for his excellent slide deck on Team System implementation anti-patterns which turned me on to this utility.
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
|