As Microsoft is close to finalize the feature set for next version of Visual Studio Team System (VSTS), I’m noting down my wish list of the features that i would like see in the next version. As i could not participate in SDR, thought this could be another way to give my feedback. Hope that some of this finally make to the released VSTS V2. It is little long, but i wanted to cover all that i had in mind. Here the list goes:
Work Items Related Improvements
Field Rules that I missed a lot
I consider work items as the most useful feature of VSTS. It provides large number of field rule to define the behaviors and constraints on fields. The following is the list that I missed a lot:
- Minimum and Maximum Values: There could be many integer fields where customers need to limit the value of integer fields of a WIT between some minimum and maximum values. But WIT schema does not provide any such rule. For example, We are using Percentage Complete field in Task WIT. So we need to limit this field between 0 and 100
- NotLessThan, NotGreaterThan rules: We have many work item types that have "Start Date" and "End Date" fields. The obvious constraint for "End Date" is that it can not be less than "Start Date". I'm sure, this would be very common requirement for many customers.
But there is not tag to define above rule in WIT definition language. Can't we have tags like <NOTLESSTHAN field="Example" /> and <NOTGREATERTHAN field="Example" /> added to the language?
Allow Schema Changes for work item types
There are some scenarios, where you need to add extra elements or attributes to the default WIT schema. For example, I’ve provided my wish list of two field rules above. Others would have their own list. It’s not feasible for a product to fulfill everyone’s wish list.
If VSTS can allow developers to extend the WIT schema, they can add extra fields or attributes on their own. This becomes important, when some organization is using its own custom client for work items. TFS and Visual Studio can ignore such additional fields, but custom clients can make use of these. It would be great for such custom “work item clients” developers if such WIT extension can be allowed.
Programmable capability to hook on to work item changes before commit
Allow schema change will help only those customers who have their own custom UI. It won’t help customer who use Visual Studio as their work item UI (which would be the case most of times). It is because the solution does not stop users for entering wrong values through Visual Studio. So customers get limited only to the rules that are available in WIT schema.
One solution for this could be providing “WorkItemChanging” event, which is fired before the changes to a work item are committed to the TFS. Customers can subscribe for this event and verify their business rules in the handler for this event. If the changes do not comply with business rules, there should be mechanism to throw a particular type of exception. This exception should cancel the work item commit operation and send appropriate messages back to the caller. This will make work item types definitions very extendible and customers would be able to add any kind of business rule.
Just check with any developer who had to change design of his work item type because he/she didn’t find a particular “field rule” in the schema. They would rate this as high priority enhancement.
Work Item Type based authorization
The way authorization is implemented currently in VSTS, a user can either write to all types of the work items or can not write to any type of the work items. It’s not possible to specify that a user can write to one type of work item and can not write to the other type of work item. But, generally most customers would need that kind of flexibility. For example, it is okay to allow developers to write to Task type work items but they should not be allowed to write to some other types of work items e.g. Risk
Work Items Delete
At present, if a WIT is imported into a team project, it can not be deleted. All the work items in a team project show up in the Add New Work Item menu option. So if a WIT is imported into a team project by mistake, you don’t have straight forward way to restrict users from adding work items of that type. This utility can be added in the next version.
MS Project Integration
This is one of features in VSTS that I liked most. You can also find my article on this area. I’d like to see the following features in next version
- Support for hierarchies: Project Managers (PMs) use “Summary Tasks” in MS Project a lot. We generally use “indent” and “outdent” commands to change the level of tasks to give a hierarchical structure to our project plan. But the support for storing these hierarchy levels is not there in Work Items in the current version. You can use hierarchies as long as you store a local copy of that plan that synchronizes with TFS. But, other team members who don’t have access to that local file and take the work items from TFS won’t be able to see the hierarchies.
- Multiple Resource Names: Another common thing that PMs do in MS Project is to assign a particular task to multiple resources. But, because a work item can only be assigned to one person, you can not assign multiple resources for a work item in MS Project also.
I feel, the multiple resource assignment should not only be added in MS Project Integration, but also in Work Items.
- Using Display Name: One good feature that was added in Release Candidate was support for “Friendly Name” for “assigned to” field in work items. Earlier, the field supported only “Windows Account Name”. It made assignment much more meaningful. But for the organizations that use “comma” (,) in friendly names, it created a bit of problem in MS Project Integration. For example, if my friendly name is “Narang, Sanjay”, MS Project doesn’t accept that because “Resource Names” field of MS Project doesn’t allow “comma”. It treats it as two separate resources “Narang” and “Sanjay”
Although there are work around available for this problem, but I’d like to some better solution in the next release.
Web Based Client
Team Explorer and Work Item related tools in Visual Studio are awesome! But still, if we can have a web based client for accessing Team Foundation data – nothing like that. It would allow even non Microsoft developers who don’t want to install Visual Studio to make use of TFS. Although there are some third party tools like TeamPlain available, but there is no match for Microsoft’ own product.
Integration with Microsoft Project Server
I feel it’s very important to provide integration with Project Server; as that will help VSTS to gain much wider acceptance from customers. I understand that efforts are already going on in this direction both inside Microsoft as well as outside with the community. I’m adding this point here just to emphasize that it is important feature that we are looking for.
Support for organization Structure
Each Team Project is an independent entity without any relationship with the other one. So when you need consolidated data (e.g. total active review work items) or a drill down or drill up report (schedule variance) for a particular organization unit, there is no out of box way available for that. It would be much easier, if they can introduce some way to associate Team Projects to a particular organization unit of the organization structure.
The Classification service does the similar job for project work items and does a very good job. If this can be extended to one level higher to support organization structure, nothing like that!
Multiple Instances of TFS
In the current version, if you deploy two different instances of TFS in your organization, there is no out of box way to relate the data between the two instances. There could be number of areas, where you would like to have this synchronization:
- Using Global Lists from one instance in other
- Writing reports that collect data from multiple projects across the instances
- Support for having single project span across different instances (could be required for big team or distributed teams)
Global List synchronization with External Sources
Most of times, the members of Global Lists would come from database or third party tool. It becomes painful for TFS Administrators to keep the Global List updated, if the main source changes frequently. There is way to have this kind of synchronization as explained in Team Foundation Blog. But, it would be great, if some “automatic” synchronization can be provided with external sources.
WSS Plug-In: Document Libraries should take source from web sites
WSS plug-in takes the location of documents to be uploaded to the team site from relative paths in the local machine. Most Customers would upload the document libraries with organization’s standard checklists and templates. Generally, such standard documents are stored in some central web site that is regularly updated with newer versions of those documents. But because WSS Plug-in takes source files locations only from local machine, TFS Administrator need to first copy the documents to local machine and then run the PCW. This may also be reason of inconsistencies between the latest version in central documents web site and team sites.
Is should be possible that “source” attribute in WSS Document Library elements to take HTTP based documents links so that PCW can automatically downloads the document from central web site and upload that to the team site.
Sanjay Narang\'s Blog 