Teams WIT Tools : VSTSR

Team Foundation Server 2010 - Relational Warehouse and Cube Schema Changes

sunder — Sun, 17 May 2009 02:15:47 GMT

Team Foundation Server 2010 is a BIG release for us by all counts. We have made conceptual changes; Brian introduced some of the key concepts in TFS 2010 that includes the concept of Team Project Collections (TPCs). These changes required a lot of infrastructure support that we built from the ground up and changes to all the subsystems including the warehouse adapters, relational warehouse schema and the Analysis Services cube schema.

As our Beta 1 release approaches, I wanted to outline the changes to the relational warehouse and cube schema. These are, unfortunately, breaking changes. While we will provide an updated set of out-of-the-box reports (details below), these schema changes will affect your custom reports. By custom reports, I mean SQL Server Reporting Services (SSRS) or Excel pivot table/chart reports you may have authored against the warehouse or cube.

Read the rest of the post: http://blogs.msdn.com/sunder/archive/2009/05/16/team-foundation-server-2010-relational-warehouse-and-cube-schema-changes.aspx

Sunder Raman

Program Manager, Team Foundation Server

Value Propositions, Experiences and Features revisited

sbhatia — Fri, 08 Feb 2008 08:06:59 GMT

A long time ago, I wrote a post on the internal project management processes we are using in Developer Division. It was all about Value Propositions, Experiences and Features. A year later, I'd like to revisit that and dive into the process we are using in Visual Studio Team System.

Not surprisingly, our process has changed (evolved?) since then. One big difference is that we are using a build of "Rosario" to manage our work vs. a build of TFS 2008. (In fact, the build we're using is similar to the "Rosario November CTP" -- so you can play with all the features that we're using.)

Planning List

We introduced the concept of a planning list where we can store a list of all the features we've been asked for and all features we've thought of. It's the list of everything we could build.

Here's an example of a Feature -- meant as a light-weight way to capture a request:

Then we group these features into "feature groups" and prioritize the features:

Then we stack all the "feature groups" against each other and proceed to execute in stack order.

The "feature groups" map up to Value Propositions which represent the rolled up value of a set of feature groups expressed in terms of our customers. For example: "Schedule and track Agile and CMMI project easily" is a value proposition in the system.

Execution List

The execution list represents everything we have built or are building. We introduced the concept of a Deliverable which represents a unit of functionality that a feature crew (a group of developers, testers and a program manager) produces. A deliverable is what goes through our quality gates (e.g. code coverage, pseudo-localization etc.) and it is what we track work on (remaining hours & completed hours).

Here is an example of a Deliverable -- heavier than a Feature in order to capture all the quality gate & progress data:

The quality gates that a Deliverable goes through:

And how we track the progress of a Deliverable:

We can break-down the Deliverable into the set of Tasks needed to complete it:

It is up to the feature crew to choose which tool to use to manage the Deliverables and Task breakdown. They could use MS Project or MS Excel or the Team Foundation Client or their own custom tool. All they need to make sure is that the remaining work and completed work on the Deliverable is filled out weekly.

And we use that information to review progress across deliverables on a weekly basis:

Though this report, we can see how much progress was made overall, how much progress was made last week and what is left to do.

Tying it all together

So, what is the relationship between features (the planning list) and the deliverables (the execution list)?

In our process, Deliverables produces one or more Features and we express that in the system by using a Produces/Produced By relationship.

In this way, as deliverables complete on the execution list one or more features are completed on the planning list and we can see how we are making progress against delivering customer value (value propositions):

Thanks,

-Siddharth

What improvements to subscriptions and notifications would you like to see?

sbhatia — Wed, 30 Jan 2008 08:38:00 GMT

I'm posting this on behalf of Matthew Moloney -- a PM intern who has joined us from Australia!

He's got a query on what sort of improvements you'd like to see in the subscriptions & notifications space in a future release.

------

G'day everyone,

I'm looking for feedback on a design for a subscription and notification interface that will allow users to specify which events they would like to be notified on. I would also like to get a few ideas on what would be the most common types of notifications that a users such as you would like to subscribe to.

Some ideas have been:

· "I would like to receive an email when any of my Bugs have been updated"

· "I would like to know when I have been assigned a new work item"

· "I would like to be notified when a work item that was previously assigned to me has been assigned to someone else"

By collating such request into a set of common requests we can try to optimize a user interface.

The idea is analogous to the Outlook rules and alerts wizard. The intent is to have two different approaches. A wizard that will be able to facilitate the event subscriptions for 80% the most common cases, and a Query Builder driven approach that will handle the remaining 20%.

The most important input I am looking for is your answer to the following question; if an ideal subscription and notification infrastructure existed what events would you subscribe to and how would you like to receive those events? In order to quantify each of the answers please give an indication on the subscriptions importance (integral, very important, nice to have) and on the frequency of occurrence (all the time, regularly, occasionally).

Some things to consider:

If you could only subscribe to changes in queries as opposed to individual work items could that be enough?

For subscribing to a change in a query how would we define 'a change in the query'?

· When work items within the query has changed in a certain way; or

· A new work item enters the query results or an old item leaves the query results

And, what kinds of notification endpoints are desired?

· Email

· Instant Messaging

· RSS

· Newspaper (A webpage collating events)

Thanks for your time,

Matthew Moloney

New permissions on work item types?

sbhatia — Wed, 30 Jan 2008 07:17:00 GMT

Folks,

I recently sent out a request to the VSTS Customer Council and the MVPs asking them if they had thoughts on important new permissions to add to work item types in a future release.

Note that we’ve already enabled the following scenarios:
• Hide work items under a particular area node from a group of users (in TFS 2005)
• Set work items as read only under a particular area node for a group of users (in TFS 2005)
• Allow TFS Server admins & project admins to destroy work items as well as destroy work item types (in TFS 2008 + Power Tool)
• Allow TFS Server admins & project admins to rename work item types (slated for “Rosario”)

The high-level results on the priorities of potential new permissions on work item types were:

As a result of the feedback, we are unlikely to make an investment in new permissions for work item types and a model around that. However, we are looking at a creative workaround/solution for the top ranked request ("Allow/Deny a user to 'Contribute' on work items of a particular type) involving work item rules.

My questions for you:

Do you agree with this prioritization? Are there scenarios that are more important/less important to you?
Have you encountered any really painful scenarios in and around this area that we should really look at?

Thanks,

-Siddharth

Rosario: What is the “Name” attribute for on Links Control XML

Gregg Boer — Tue, 21 Aug 2007 00:34:00 GMT

Last post, I talked about how to filter on link types. Here’s an example:

</LinksControlOptions>

</Control>

Some of you may have wondered want the “Name” attribute is for?

Well, it does have a purpose. :-)

The TFS Client uses this name to store the column widths for the links control. If you, the user, would adjust a column width on a links control, the TFS Client will remember that width by storing it in the client machine’s registry. It uses the Name value to retrieve that information. This allows a form designer to move the links controls to a different location on the form, and as long as the Name value is still the same, the TFS Client retains the user-defined column widths.

Therefore, changing the value of the Name attribute will result in all of the users who have set the column widths just the way they like them to lose them. Not the end of the world, but something to be aware of.

Other than the fact that the name must be unique for a work item type, it is arbitrary and set by you. So you decide what you want it named.

Rosario: Filtering link types on a work item form

Gregg Boer — Mon, 20 Aug 2007 23:57:00 GMT

In Whidbey, and Orcas, the work item links control that displayed the links always showed all the links. For Rosario, we made a design decision based on the fact that whoever is designing a work item form, may want to display certain link types separately from other link types.

For example, let's say you have a tab on the work item form which manages your dependent features. It would make sense that the links control on that tab only display links to dependent features.

This is where the new filtering functionality with the links control comes in.

In the work item type XML in Whidbey/Orcas, this is what you did when you wanted to display a links control:

With Rosario, we’ve add the LinksControlOptions section to allow you to filter what link types to include.

The simple example would render a links control that includes all work item links (Related, Parent/Child), and exclude any non-work item links (ChangeSets, Hyperlinks, Test Results):

</LinksControlOptions>

</Control>

The following example would render a links control that displays only Requirement and Hierarchy links.

</WorkItemLinkFilters>

</LinksControlOptions>

</Control>

The following example would render a links control that displays all work item links except Requirement and Hierarchy links.

</WorkItemLinkFilters>

</LinksControlOptions>

</Control>

The following example would render a links control that displays only Change Set links.

</ExternalLinkFilters>

</LinksControlOptions>

</Control>

That should give you a pretty good idea of what can be done. Any questions? Feedback?

Rosario - Customing Link Types Primer

Gregg Boer — Fri, 17 Aug 2007 19:17:00 GMT

With Rosario, you can define multiple link types. This allows for you to customize link types to match your processes. This blog post is a primer in how to do that.

Quick-start guide on creating a new link type:

Here's how to create a new link type:

From the command shell, go to “Program Files\Microsoft Visual Studio 9.0\Common7\IDE”
Run "witadmin.exe exportlinktype /s ServerName /n System.LinkTypes.Dependency /f mylinktype.xml”
View the mylinktype.xml file that was created. It should look like this:

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

<LinkTypes>

<LinkType ReferenceName="System.LinkTypes.Dependency" ForwardName="Successor" ReverseName="Predecessor" Topology="Dependency" />

</LinkTypes>

Edit the mylinktype.xml file to look like this.

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyLink" ForwardName="My Successor" ReverseName="My Predecessor" Topology="Dependency" />

</LinkTypes>

NOTE: It is important to change the namespace from “System.” To “MyLinks.” (or some other name), because “System.” Is a protected namespace.

Run “witadmin.exe importlinktype /s ServerName /f mylinktype.xml
Go to your Team Explorer and select “Refresh Cache”, or close and reopen your Visual Studio.

The new link item type should now be available to use from your forms.

What is that "topology" field for?

Now, what is that “topology” field in the definition XML. Topology assigns a set of rules that are enforced for that link type. There are four topologies to select from:

Network

Link types of this topology have essentially no rules and no directionality. You can have circular relationships, and the link looks the same from both sides.

Example XML:

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyRelated" ForwardName="My Related" ReverseName="My Related" Topology="Network" />

</LinkTypes>

Directed Network

Link types of this topology are like Network links, except there is directionality. You can specify a name that appears at each end of the link. In other words, the link looks differently depending from which side you view it.

Example XML:

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyDependent" ForwardName="My Dependent" ReverseName="My Provider" Topology="DirectedNetwork" />

</LinkTypes>

Dependency

Link types of this topology are like Directed Network links in that they have directionality, but an additional constraint to prevent circular relationships.

Example XML:

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyPred" ForwardName="My Successor" ReverseName="My Predecessor" Topology="Dependency" />

</LinkTypes>

Tree

Link types of this topology are essentially trees, it enforces a one-to-many relationship and doesn’t allow circularity.

Example XML:

<LinkTypes>

<LinkType ReferenceName="MyLinks.LinkTypes.MyTree" ForwardName="My Child" ReverseName="My Parent" Topology="Tree" />

</LinkTypes>

There you have it. Creating link types in a 343 words. Let us know how it goes.

Rosario: Managing hierarchies in Microsoft Excel

Yogita Manghnani — Fri, 10 Aug 2007 22:04:00 GMT

As a follow up to Gregg's post on querying on links and creating tree queries, I'd like to introduce you to managing work item hierarchies in Microsoft Excel.

Creating work item hierarchy

There are a few ways you can get started with creating hierarchies in Excel:

Create a tree query in Team explorer and export it to Excel by right clicking on the query and choosing "Open in Microsoft Excel".
Alternately, create a query bound list in Excel and bind it to a tree query. The dropdown that lists the queries now has icons to easily distinguish between tree queries and non-tree queries.
Export one or more items from Team explorer query results view to Excel and then click on either "Add tree level" or "Add child" button in the toolbar. This will automatically bring in all the child work items for items in the list.
Alternately, create an empty ID bound list in Excel and then click on either the "Add tree level" or "Add child" button in the toolbar. Then import one or more work items into the list using the Get work items dialog.This will automatically bring in the selected work items and all their child work items into the list.

You will notice multiple Title columns in the list, one for each level in the hierarchy of work items.

Extending the hierarchy

"Add tree level" extends the tree by adding a new Title column. For ex. you have a tree of features and tasks, and want to break down the tasks further into sub-tasks.
"Add child" inserts a new row in the list. For ex. you want to add a new task to a feature in the list. You can also choose to manually insert additional rows into the list. The benefit of using the Add child button is that it will also add a new Title column if necessary.

Updating hierarchy links

To add, remove or update hierarchy links, you do not have to use the Links and Attachments dialog for each work item. This can be easily accomplished by moving the title values from one Title column to another. More over, it allows you to create and edit links in bulk.

To make a work item a child of its sibling (demote), cut and paste its title into the Title column to the right.
To make a child work item a sibling of its parent (promote), cut and paste its title into the Title column to the left.
To delete a link between 2 work items, either cut and paste the child work item's title to the very first Title column or delete the entire row from the list and publish.

Let us know what you think about this functionality and how you plan to use it.

Rosario: Querying on Links

Gregg Boer — Fri, 03 Aug 2007 20:31:00 GMT

The enhanced query builder in Rosario offers the ability to query on links. This gives you the ability to ask the system questions like:

· Give me all the Scenarios and any Bugs that might be linked to them.

· Give me only the Scenarios that have Bugs linked to them

· Give me only the Scenarios that don’t have any Bugs linked to them

And finally,

· Give me a Scenario, and recursively give me the tree of child Tasks below them.

The query builder allows all of these. To query on links, you first select the “Query on links” checkbox from the query builder view.

You will now see three panes

· The top one (the one you’ve always worked with) allows you to specify the main list work items. In the examples above, it relates to “Give me the Scenarios…”

· The middle one refers to what type of links you want to query on. Since work items can be linked together via different link types (Parent/Child, Related, Predecessor/Successor), you can filter on what type of link relationship to include. Default is “[Any]”, or All link types.

· The bottom pane refers to the filter on the linked items. In the above examples, it would relate to the “Bugs” or “Tasks” part of the scenario.

The query type defines how you want the query to return the information. You have the following choices:

· “All” – Return all items matching the main query (top query pane), and all linked items matching the bottom pane.
Example: Give me all the Scenarios and any Bugs that might be linked to them.

· “Must have” – Return only the items matching the main query that have links to items matching the bottom query.
Example: Give me only the Scenarios that have Bugs linked to them

· “Must not have” – Return only items matching the main query that DO NOT have links to items matching the bottom query
Example: Give me only the Scenarios that don’t have any Bugs linked to them

· “Tree” – Recursively return all children of the items in the main query.
Example: Give me a Scenario, and recursively give me the tree of child Tasks below them

Hope this helps to make sense of this. Let us know what you think!

What’s new in work item tracking in Microsoft Visual Studio Team System code name “Rosario”

Gregg Boer — Fri, 03 Aug 2007 20:02:00 GMT

What’s new in work item tracking in Microsoft^®Visual Studio^®Team System code name “Rosario”

Traceability is a big push with Rosario. To that end, we have improved the linking functionality is work item tracking, in Rosario.

Before Rosario, there was only one type of link between work items: “Related”. With Rosario, you can define as many different link types as you want. Each link type can be named, and can be defined to have certain rules that are enforced for you by TFS.

OK, what does this really mean?

Well, it opens the door to implement a real traceability solution in TFS. You can now create trace relationships between work items such as

· Parent / Child

· Predecessor / Successor – (Any ideas on how this might be useful with MS Project integration J)

· Fulfills / Fullfilled By – For relating Requirements to Features. Requirements are fulfilled by Features. Features fulfill requirements.

· Depends On / Required By – For relating Features to each on to define feature dependencies. Feature A depends on Feature B. Feature B is required by Feature A.

Since you can define new link types, you can customize your system to implement the process that you use.

What link types do you think you would create?