Pro Team Foundation Service

Frontmatter

Chapter 1. Introduction to Application Lifecycle Management

Abstract

What comes to mind when you hear the term Application Lifecycle Management (ALM)? During a seminar tour in Sweden to present the Microsoft Visual Studio Team System, we asked people what ALM was and whether they cared about it. To our surprise, many people equated ALM with operations and maintenance. This is still often the case today when we visit companies, but more companies are aware of the term these days.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 2. Introduction to Agile Planning, Development, and Testing

Abstract

Through our experience, we have seen a great deal of improvement in the management of projects over the past few years. To be more specific, we have seen that the agile influence is making an impact on how projects deliver business value.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 3. Deciding on a Hosted Service

Abstract

Whether you have already decided to use Team Foundation Service (TF Service) or are still in the process of making a decision about that, you need to understand the differences between hosted TF Service and an on-premises installation of Team Foundation Server (TFS). This chapter will help you understand the benefits and trade-offs with the hosted TF Service and assist you in making (or verifying) a decision whether to go with a hosted service.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 4. Getting Started

Abstract

Once you have decided to use Microsoft’s Team Foundation Service (TF Service), it’s then time to create an TF Service account and get started. This chapter will guide you through the process of getting up and running with your project, including topics such as:

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 5. Working with the Initial Product Backlog

Abstract

In this chapter we will complete the startup of an agile project using TF Service. Many of the concepts covered in Chapter 3 are exemplified in this chapter, so you can see how we move from planning to implementation. We also look at how TF Service can support the agile project management process during sprints.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 6. Managing Teams and Alerts

Abstract

In Chapter 5 we followed a product owner (PO) preparing the backlog for a project. One part of the responsibilities of the PO is to staff the project, at least initially. After an initial team has been created, it is up to the team members to inform the PO about which competences they need to fulfill the project vision.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 7. Initial Sprint Planning

Abstract

This chapter starts right where we left Fiona at the end of Chapter 5. Fiona had done everything to build an initial product backlog and create the team. At this point she does not have any input as to how long the project will take or how much it will cost. In order to get this information so she can show it to the stakeholders, there are a few steps she needs to take. Let’s take a look at these because this will also involve planning the first sprint.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 8. Running the Sprint

Abstract

In Chapter 7 we followed Fiona, the product owner, as she prepared the backlog for the first sprint. Fiona and the team have also done an initial sprint backlog planning to estimate an initial velocity. The team is now ready to jump into the first sprint. We will now leave Fiona and the team and talk more in general terms about how you can use TF Service during your sprints, based on the Scrum process template.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 9. Kanban

Abstract

Although our preferred project management method for development projects is Scrum, we realized that Scrum is not perfect in every situation. Scrum can be somewhat scary in the sense that it could require major changes in the way we work in our organizations. The drawback of this can be that it is hard to implement Scrum fully because we as humans seem to have some inherent resistance to change. Wouldn’t it be great if we could find a process that is agile but made it possible for us to make the changes gradually? We’ll look at just such a process in this chapter.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 10. Engaging the Customer

Abstract

One could argue that the most important person or role in a software development project is the customer. The customer is ultimately who decides when a project or a feature is finished and when the quality is acceptable. Yet historically, involving customers in projects has proven to be problematic for various reasons. Often it is hard to get the customer to allocate enough time to actually participate in meetings and sprint demos. And when customers are included in the process, they often start participating too late, usually when it is time to start doing the acceptance testing. By that time all the decisions have already been made and changing the underlying requirements at this point often costs a lot of time and money.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 11. Choosing Source Control Options

Abstract

In TF Service you can choose which source control system to use on a team project level. You have the choice between:

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 12. Working with Team Foundation Version Control in Visual Studio

Abstract

Team Foundation Version Control (TFVC) is a centralized version control system designed and built for enterprises. Microsoft provides first-class integration and user experience in both Visual Studio and Eclipse and provides command line interfaces and other integration points for other environments.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 13. Working with Git in Visual Studio

Abstract

Git is a distributed version control system that has become very popular in the past few years. Microsoft has chosen to support Git to offer a distributed version control solution and is committed to provide a first-class, integrated user experience inside Visual Studio when working with Git.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 14. Working in Heterogeneous Environments

Abstract

This chapter will look at different ways to get to TF Service information when you’re not working on a Windows format or using Visual Studio. We can of course always use the Team Web Access to manage work items, look at code changes, work with testing, and manage builds, but sometimes it’s desirable to have the integration with TF Service right inside the development environment.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 15. Configuring Build Services

Abstract

Next to source control, many consider the most important part of running software projects successfully is usage of build automation. It is considered to be the heartbeat of the software development process, continuously compiling, testing, and analyzing projects as developers keep checking in changes to the codebase. If the project build succeeds, it is an indication that the project is healthy and can be built and tested on any computer. If the build fails, you will soon find out and be much more likely to fix the problem quickly. It is also an absolute necessity if you want to increase your release cadence and be able to deploy new versions to production more often. There is no or minimal room for manual processes when the release cadence increases.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 16. Working with Builds

Abstract

As mentioned in Chapter 15, using build automation is a very important part of the ALM process as it allows you to continuously integrate your software on every check in and also automate otherwise manual tasks. This will by itself raise the quality of your process and you will find that you spend less time on release software and more time on development and testing.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 17. Customizing Builds

Abstract

Chapter 16 discussed how to create new build definitions and how to run and track the status of your builds. After you start using automated builds, you will soon find that you want to do more than what is included in the default build process templates.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 18. Continuous Deployment

Abstract

Having automated builds is the most important part of the continuous integration process that we have discussed in other chapters. Being able to build, test, and integrate your software on every check in makes your software development process very effective with less time spent on fixing integration bugs.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 19. Agile Testing

Abstract

Agile projects are challenging. With a common mindset in which we embrace change and want to work incrementally and iteratively, we have good conditions to deliver what our customers ask for on time.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 20. Test Management

Abstract

In Chapter 19 we looked at testing using the TF Service and the Web Test Manager. Intentionally we wanted to show how to get started with testing in an agile, lightweight way. This chapter will explain how we can evolve our testing process into more structured testing, meaning we will create test plans for various purposes, use test suites to organize the test cases, and design test cases with all of the details needed for easy use by any tester.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Chapter 21. Lab Management

Abstract

It is desirable for most projects today to have short cycles and transparent development processes that allow us to change the plan after every cycle. This typically means that in two to four weeks a set of features needs to go from developers to testers to stakeholders and perhaps even to customers. To support this we need lots of different test environments to validate the development work. There is also a lot of work to keep the environment ready for testing, which includes not only making sure the right version of the product is there but also including test data and dependent services. If we want to succeed with agile projects, we must make sure to manage this complexity well. Unfortunately, it is often far from a simple process to implement in a project.

Mathias Olausson, Joachim Rossberg, Jakob Ehn, Mattias Sköld

Backmatter