Export capacity from TFS iteration to Excel? - tfs

When working on an iteration on TFS one of the avaiable features is to set capacity for individual team members.
Is there a way to export this info to Excel (through a query, for exemple), to generate reports on team avaiability?
Article on MSDN about Capacity Planning on TFS: https://www.visualstudio.com/en-us/docs/work/scale/capacity-planning

Unfortunately not (short of copy and paste). The best way would be to use the api and export it yourself, maybe a little PowerShell script
REST API - Capacity

Related

TFS Web Interface

We are currently trying to find a new bug tracking and integration software and we were looking at FogBugz, Jira and TFS. My question is about TFS.
I have done some research and found that TFS has "Power Tools" in which Non IT users can log on and get some information, but all the examples and tools I have found didnt really give them the kind of UI that other bug tracking software provides such as estimates, full fledged reporting on hours, P&L, Bugs Released, When A feature will be complete. For example Fogbugz has a feature that will predict when a feature will go live off past estimates, is there any way to get that kind of functionality from TFS? Or Any of the functionality listed above in a web interface?
Team Web Access is built into TFS 2010 (grab a trial and try)
Urban Turtle is the best Web UI for dealing with Work Items in TFS.
Reporting and Bug reports are available, though everyone, everywhere wants something different.
P&L reports are not available out of the box.
There are minimal prediction reports, but it's all BS anyways :). Burndown reports give you information about your likelihood to delivery.
As you mention, there is a tool called Team System Web Access Power Tool with following features:
* Direct links to work items, query results, diffs, change sets and more
* Display custom controls on work item forms
* View queued builds new, queue new builds
* Add new work items or edit existing ones
* Work with any type of work item, including custom ones
* Add new work item queries or edit existing ones
* View, download, upload, check-in and check-out documents on SharePoint team portal
* View reports, export as PDF or Excel
* Browse source control repositories, download files, view changesets, diffs, histories, and annotated views
* View build results, start or stop builds
* Search for keywords in work items
If you need more than that you'll have to integrate the TFS with SharePoint server which will give you all you asked for in your question and much more...

Excel report which rolls-up task work item attributes original estimate, completed, and remaining work hours to a parent requirement work item

In TFS when I setup a new iteration, I start out by creating "Requirement" work items, which are then associated with multiple child "Task" work items. On the task work items I put the estimate for the task and then as the task is worked on the completed and remaining hours are updated.
What I want is an excel report that will show a breakdown of iteration, requirements, and task, with the hours totaled at the requirement and iteration level.
I envision this to be some kind of pivot table but I can't figure out how to pull in the data so I can relate it.
There is no rollup available out of the box in TFS 2010. You could write a macro in Excel to calculate the rollup hours and pivot on that.
You could also use the SSRS report User Story Overview to see the value, but that value is delayed (which is probably not what you want).
You could also take a look at the Project Server Integration CTP, which has the rollup feature.
If instead of Excel, you use an Agile planning web application for TFS such as Urban Turtle, you will obtain rollup feature at the requirement and iteration level.
According to Microsoft, the premier Agile tooling for TFS is Urban Turtle. Discloser: I work with the Urban Turtle team. So do not take my words. Instead, read what Brian Harry, who is the Product Unit Manager for Team Foundation Server, said about Urban Turtle: "...awesome Scrum experience for TFS." You can read Brian Harry's blog here

is it possible to get checkin differences using WIQL?

This is in Team Explorer 2010
Question:
Using WIQL, is it possible to get the list of file differences due to checkins
for a given date range
for a given folder
WIQL is about work items alone - so it isn't possible to retrieve this kind of information through this path.
Using the TFS data warehouse should provide with a viable alternative. A very nice introductory presentation can be found here.
You should probably make a focus on the filters "Version Control Changeset" in combination with "Date" filter for your (1) & "Version Control File" for your (2).

TFS 2008 Disk Usage

From within TFS 2008, is there a way to view the disk space taken up on the server by a project (or by all projects)? Or is this something that can only be done by looking directly at the underlying database?
I cannot think of a good way to easily do this on a per project basis (including Version Control, Work Item Tracking, Build and Project Portal data). The data is all stored in the various SQL Server databases but there is no separation at the project level showing you how much that data ends up costing you in disk space - you'd need to sum up the totals of the various databases on disk to give you that number.
The following blog post from Brian Harry might help you get close to the data you need for TFS 2008
TFS Statistics
The way that stuff is stored in TFS 2010 is very different, see Grant Holliday's blog post for a set of queries that work against the TFS 2010 database.

Managing Team Development with SSAS, TFS, & BIDS

I am currently a single BI developer over a corporate datawarehouse and cube. I use SQL Server 2008, SSAS, and SSIS as my basic toolkit. I use Visual Studio +BIDS and TFS for my IDE and source control. I am about to take on multiple projects with an offshore vendor and I am worried about managing change. My major concern is manging merges and changes between me and the offshore team. Merging and managing changes to SQL & XML for just one person is bad enough but with multiple developers it seems like a nightmare. Any thoughts on how best to structure development knowing that sometimes there is no way to avoid multiple individuals making changes to the same file?
SSIS, SSAS and SSRS files are not merge-friendly. They are stored in an xml file that is changed drastically - even with minor changes (such as changing a property) - so it becomes really impossible to merge.
So stop thinking about parallel development on one file. You need to think how you can achieve that people are not need to do parallel development on one file. So start with disabling the multiple checkout of a file. You might even want to consider to enable the option to get the latest version on a checkout.
Then start thinking how you can achieve that people can work independent. This is more in the way you structure the work and files:
Give people their own area they can work on. One SSIS package is only developed by person X at any given moment in time.
Make smaller files so the change that two people need to work in the same file is small.
I have given feedback to the product team of the imcompatability of BIDS to merge. It is a known issue, but will be hard to tackle. They don't know when it will be possible to really do parallel development on these files. Until then keep away from parallel development.
As Ewald Hofman mentioned, SSAS and SSIS is not merge-friendly.
In one environment I worked solved the problem as follows:
do only use SSIS when you have to (fuzz algorithm or something similar). Replace SSIS packages as often as you can with SQL code (see Linked Server for datasync. and MEARGE Command for dimension/fact-table-creating for instance).
build your data warehouse structure as follows:
build 2 databases, one for the "raw source data" from the source systems and one (the "stage" database) for the dimension and fact views and tables
use procedures that can deploy the whole "stage" database
put the structure for the "stage" database into your Repository
build a C# application that build your dimensions and cubes via the AMO API (I know, that's a tough job at the beginning but it is it worth - think on what you gain - Look at the Pros below )
add the stage database and the C# application to your Repository (TFS/Git etc.)
Pros of that structure:
you have a merge-able structure you can put in your Repository
you are using the AMO API witch has
you can automate the generation of new partitions
you can use procedures to automate and clone measure groups to different cubes (what I think is sometimes a big benefit!)
you could outsource your translation and import it easily (the cube designer is probably not the best translator)
Cons:
the vendor would probably not adapt that structure
you have to pay more (because of either higher skill requirements or for teaching him your individual structure)
you probably need knowledge over a new language C# - if you don't already have
Conclusion:
there are possibilities to get a merge-friendly environment
you will get lost of nice click-and-run tools f.e. BIDS - but will get into process of high automation functionality
outsourcing will be maybe unprofitable because of high individualization
http://code.google.com/p/support/wiki/DVCSAnalysis
maybe a better tag is DVCS?
https://stackoverflow.com/questions/tagged/dvcs
As long as both teams are using bids and TFS this should not be a problem.
assuming that your tsql code is checked in to source control in a single file per object, merging TSQL code is straight forward since it is text based. I have found the VSTS Database projects help with this.
Merging the XML based source files of SSIS and the MSAS can be cumbersome as you indicate below. to alleviate some of the pain, I find that keeping each package limited to a single dataflow or logical unit of work helps reduce developer contention on packages. I then call these packages from one or more master packages. I also try to externalize all of my tsql source queries using sprocs, view or udfs so that the need to edit the package is further reduced. using configuration files and variables also helps to a smaller extent.
MSSAS cubes are a little bit tougher. My best suggestion is to look into a 3rd party xml differencing tool. I have been able to successfully merge small changes use the standard text based tools but it can be a daunting task.

Resources