I would like to emphasize the following aspects of TFS, to which both developers and non-developers can relate and benefit from: web portal and Kanban, project management and version control. Some of these features require a stakeholder license, whereas others require a paid license, nevertheless these are arguments that should be taken into account when you think about employing TFS in your organization.
The TFS web portal is quite a versatile working area which adapts to each user based on the hub/tab he has selected (home, code, work, build, test), the access level he has (stakeholder, basic, advanced), and the options configured for the used deployment.
As a developer one would mostly use Visual Studio to complete its work or rely in the Code hub in the web access portal in order to view, download, and compare version-controlled files, find and view changesets and shelvesets, set up GIT or develop an app in a GIT repository.
As a non-developer one would focus on the Work hub and all the gems hidden beneath it: create new work items, query for work items, create a backlog, track progress using the using the task board and/or the Kanban board, define team favorites (queries, burndown reports, charts, diagrams etc.) which can be seen by the whole team when accessing the Home hub.
Most of the work performed in a project needs to be organized in some sort of manner. As far as my experience goes, planning usually involves at least some sticky notes and a decent sized whiteboard and its usually structured using a Kanban-like schedule:
Fig 2. "Simple-kanban-board-" von Jeff.lasovski - Eigenes Werk. Lizenziert unter CC BY-SA 3.0 über Wikimedia Commons
By using Kanban you can visualize and manage your team's workflow, set clear WIP limits in order to maintain the focus on the current open task and improve collaboration by creating opportunities for feedback, thus making identifying bottlenecks a lot easier.
Kanban boards are widely available, whether we speak of the open source variants like Trello and Taiga or Kanban Tool, Jira and TFS.
Kanban is becoming a process utilized by more and more development teams, as is the Kanban board. Microsoft added support for Kanban boards in TFS 2013, and continued to enhance that support for TFS 2015 as well as for the Visual Studio Online platform.
I will try to show you what, in my opinion, are the highlights of the TFS Kanban:
Easy 3-click/step setup:
3.Select 'New Team' and fill in the details
4.Click on 'Create new team' and within seconds your team is deployed and ready for use
Flexible access permissions structure. The permission must be defined twice:
By adding a user as a member of your team he can only see the home page of the Kanban team (it usually contains the workflow charts, some team queries and diagrams)
Fig4. Access permissions structure for area path nodes
In a best case scenario a stakeholder (a person who is not necessarily part of the project but who needs to be able to track work item progress, without needing to access source code or any administrative functionality) or a member from a different team will get member permissions and read permissions; the colleagues working in the team will be added as members of the team an receive at least read permissions.
Using work item tracking and the Microsoft Office suite, along data collection and reporting, the project manager and the team members have the necessary tools in order to be able to monitor a project's development.
TFS has the capabilities to cover the demand as well as the Request Tracking and Problem Report sides of the development environment. It also allows the user to access and manipulate its objects (collectively referred to as "work items") comfortably by using several products of the MS office family: they can be forwarded via MS Outlook, prepared for publication in MS Publisher and subjected to efficient mass changes in MS Excel.
Additionally, with Team Foundation's process template mechanism, you can customize the project process to your specific environment and needs. A process template consists of a set of instructions necessary for setting up a new project. These instructions include such items as work item types, project roles, permissions etc.
Default process templates are installed with Team Foundation Server but these templates can be modified and extended or a new templates can be created, in order to enable projects to define the development process according to their needs.
Siemens has created custom templates so that it best suites the methodology (agile/scrum) used by a certain team/project.
TF employs a standard version control mechanisms for branching, merging, version management, check-in and check-out. It also includes additional features such as shelving (the ability to store partial changes without performing a fully validated check-in) and dynamic check-in policies to address specific issues of large-scale development.
That sounds nice, but how does this help non-developers? Well… consider this scenario:
You are a trainer and must teach some new colleagues to work with TFS. This is usually done either during a workshop or by organizing a course which also has a hands-on part. As new versions of Visual Studio and TFS appear and functionality gets added/changed/removed, your course materials will also change. If you would maintain a copy of these documents in TFS, you could see the history of the documents and all the changes you have done throughout the years.
This might not seem important now, but, as with all software developing companies, Siemens must archive the released software in order to assure that, if needed, in 5-10 years the sources can be restored and a developer can start working on a new patch or fix that is needed by one of the customers. What if in 5-10 years nobody will know how to work with VS 2010, but VS 2010 is needed to build that patch - perhaps MS has removed the workflow editor or some CPP target files are missing and these are installed with .NET 4.0 and need a VS\TFS 2010 build environment in order to be correctly integrated in the .vcxproj. Wouldn't it be nice to have that really old training material lying somewhere in a corner or at least the project notebook?
Perhaps that assumption is a bit far-fetched, but consider a support team which has to constantly update its FAQ database - if an FAQ entry gets removed and is needed at a later time the team is forced to do some digging in order to find the solution to the problem. By checking-in that file in TFS, you would have its complete history. Should you consider that the file is not needed anymore, you can 'delete' it at any time (please note, TFS doesn't really delete items from version control, but instead hides them; if you want to completely delete an item, you would have to destroy it).
To sum it all up, adopting TFS in your organization can benefit a large range of colleagues, not only because of the unlimited free Stakeholder access, with which anyone on your team can track project priorities and provide direction, feature ideas, and business alignment to a team., but also because of the native extensibility capabilities of TFS. You can customize different aspects of TFS in order to extend existing features or to add new capabilities if you have special requirements in your project.
