How to create a workable ALM environment based on TFS

Team Foundation Server, like any complex tool, requires some organizational approaches to exploitation. Especially since it was created with the aim of giving the team the freedom to choose, or as Brian Harry put it in one of his notes, introduce “Your process, Our process, or No process”. In part, this freedom can play a bad joke when it seems to the team that TFS is used only in a very small range of its capabilities. This article will provide a number of recommendations for deploying a viable ALM environment.

Deciding on goals

The main “credo” of TFS is to increase the predictability in all organizational processes related to the development and partial operation of software. Predictability in this context means literally one thing - at any moment you can use TFS tools to see how things are going and make conclusions . How many mistakes you have, what requirements are not yet closed, and so on. The reliability of this information directly depends on the initial data - the more such data TFS collects, the better you will be able to make subsequent decisions. It is very correct to represent TFS as a database into which information from various sources continuously flows. Somewhere in the automatic mode, where it is demanding that people bring this information themselves. It should be understood that the more information you collect, the more it will be synergies and interrelations.


')
From this it follows that the main factor in the success of TFS implementation are primarily workable reports based on Reporting Services and OLAP, their informational fullness and ability to draw conclusions based on these reports with subsequent actions. In other words, if you don’t use Reporting Services, OLAP cubes using Excel and do not understand the list of indicators that TFS provides for analysis , then you hammer nails with a microscope.

Improving the quality of reports

Based on the above goal, it is possible to more thoroughly understand how to exploit TFS components more intensively, and what steps need to be taken in order to further increase the level of this exploitation.
Data that may appear in the reports can be grouped into a list, which may represent the stages of gradual improvement in the level of TFS operation:

1. Information about all the work items that appear on your projects. This data includes information about tasks, requirements, errors, and TFS stores the complete history of changes to the fields of these work items. Based on this information, you can understand what current tasks are ahead of you. At this point, you will be able to track time and schedule team loading. Do not forget that the quality of this data directly depends on people. And at this stage, it is imperative to learn how to work with queries in TFS, clarify the mechanism of transition of work item states, use integrated tools, such as Excel.
2. Information about changes in project source files. All added, modified, deleted lines of source code. Who, when and on what basis did this or that operation. It is important to note “based on” since TFS allows you to link (associate) changes in the source texts with errors, tasks and other work items. Already at this stage you will be able to see how many lines of code the implementation of this or that requirement or fixing an error required. It is also important to note the participation of a person in the formation of this information, to explain to programmers the importance of associating changes in code with the tasks they perform.
3. Build information. TFS includes a very flexible automated project building environment. As soon as you configure the automatic assembly, the information associated with the work items and changes in the code will be linked, which will accordingly enable you to understand the level and scale of changes in a particular build. At this stage, the mechanisms of continuous integration (“Continuous Integration”) are included, which allow you to understand project progress and make long-term forecasts at a higher quality level.
4. Information about tests and code coverage tests. Testing is a very important mechanism for ensuring the quality of your product. Tests can be linked to requirements, changes in the code and assemblies. As soon as these mechanisms are enabled, you will immediately get the opportunity to evaluate the capacity of your current build and not to give it to manual testing, since it did not pass the required automatic tests, thereby reducing the load from the testers. In addition, you will receive information about the quality level of testing (thanks to Code Coverage).

It is not necessary to strive to implement all these components and get full information in the reports immediately. Phased cyclical changes in the configuration of your projects and smooth organizational changes are quite possible. Do not be afraid of mistakes, as a rule, they are associated only with the lack of practical experience with TFS and quickly catch up.

Sample TFS Improvement Plan

The gradual, iterative inclusion of TFS capabilities into your ALM process can be divided into small cycles (something like “Kaizen”), in each of which you gradually connect functions and test their performance using reports:

Week 1:

1. Hold a half-hour workshop on work item states and query handling
2. Develop a list of project areas (Area)
3. Include in the work order with tasks mandatory filling in the Area field
4. Create the first automatic build system
5. Check whether the report includes information on changes in the build in the context of completed tasks.

Week 2:

1. Hold a half-hour workshop on linking work items (Master / Child)
2. Develop a list of iterations of the project (Iterations)
3. To include in the work regulations with subordinate tasks the mandatory filling in of the field of planned and spent hours
4. To introduce into the regulation a mandatory association of tasks and requirements with a variable code.
5. Check whether the report includes information on the amount of code changes by the requirements. We introduce KPI - the number of changes in the code without associations and require a decrease in this indicator from the team.

Week 3:

1. Hold a half-hour Code Coverage concept workshop
2. Create a primary list of tests, prepare 2-3 tests
3. Include in the work schedule with the requirements of the mandatory creation of a manual test for this requirement
4. Create a new definition of the build with the included test subsystem
5. Check whether the report includes information on the level of passing tests and the percentage of coverage codes

Thus, at each short stage a certain result is achieved, which is obvious for the team.

Process Changes and TFS Configuration

TFS is a flexible and versatile tool. The package includes two process templates (Agile and CMMI) in addition, you can install other process templates. Many teams are tempted to make improvements in these templates, since, in their opinion, the implementation in TFS does not correspond to the practices adopted in this organization. This is a perfectly acceptable situation, but you should not go to extremes, for example, completely reworking the state and base of transitions in work items. As a rule, this leads to very sad consequences if you have not had any serious experience with ALM automation systems at all.
In general, it may very well be that the practices that you use quite fall into the current implementation of the processes and you just have some terminological or different interpretations. In any case, try to evaluate the planned changes in the form of costs: what is easier, agree on a new organization of work at the meeting or make changes to the TFS.

Conclusion

Automating ALM might not be such a big deal if you use a gradual improvement approach. Due to the fact that TFS is an integrated complex that collects information from various components. The more data you can collect, the more effectively you can understand the current situation on projects, and therefore more effectively manage the software development processes. You can learn more about Application Lifecycle Management from the MSDN documentation and discuss it on the forum .