Rolling with Team Foundation Service
This summer I had the chance to work on a Windows 8 Store reference app with a few of my colleagues at Microsoft. The opportunity to sling a little code and work with some world-class developers was too good to pass up. This is the first in a series of articles I'm going to write, describing how our Food and Dining reference app team used Team Foundation Service to assist us as we created our application. In this first post I'm we're going to look at why we chose Team Foundation Service and how we set it up for our use.
In future posts I'll discuss our source control strategy and (gasp!) how we handled bugs in our code.
A repository, please. . .
We were a distributed team and needed a centralized repository for source code, requirements, work items, and bugs. We were under tight time constraints and needed something that was easy to access, and couldn't afford the burden of trying to find and provision our own hardware. So, we looked to Team Foundation Service to help us out. Team Foundation Service gave us a powerful collaboration and agile planning environment in the cloud. It can do almost everything the on-premise Team Foundation Server can do. We simply registered on TFSPreview.com, selected a site name, and had our team project up and running within minutes.
Defining our team . . .
The team started with just three members, and two more of us were added over time. Adding team members to the TFS project was easy. Ian (our team leader and de-facto TFS admin) created accounts for us using our Microsoft IDs (you might know them as Live IDs). He use the online Administration tools to add team members and define security permissions for each of us. As a new team member came on board it only took a minute or so to make the entry and voila!
Once Ian added each us to the project, we were ready to go. We could access and update TFS through Visual Studio 2012 or the TFSPreview.com website. We now had our collaboration hub which allowed us to manage our PBIs and tasks; create, track, and close out bugs; and have visibility into how things were progressing throughout each sprint.
Defining our product . . .
When we created our Team Project we went with the Microsoft Visual Studio Scrum 2.0 process template. Since we didn't need to keep a rigorous audit trail and wanted to have the lightest amount of overhead possible, Scrum was the natural choice.
As we were trying to understand what we were going to build, we held Lync calls to discuss and refine details the vision of our Product Owner, Jit. At first we tried creating product backlog items in real-time using the TFS website, and I was acting as scribe and sharing my screen for everyone else on the call.
Depending on the amount of data we needed to capture we entered it directly into TFS via the website, or captured the data in Excel then published it directly from Excel to TFS. The options gave us flexibility and kept us focused on the task at hand.
Planning our sprints. . .
Once we had the PBIs defined, we organized them into sprints based on priority and size of the PBIs. We self-assigned PBI "owners" based on things we were interested in investigating, discovering, and coding. For example, Jerry wanted to work on the Hub page for the app, so he took that one; Ian wanted to work on the API layer that collected data from each of the data services we used; Jennifer wanted to work on Live Tiles and secondary tiles; I wanted to try out the Bing Maps control, so I took that one.
We weren't selfish about the items we'd chosen. We helped one another out as needed. For instance, Ian created some wicked-cool grouping code for restaurant "balloons" to keep the UI from becoming overly cluttered in areas where there was a large number of restaurants in close proximity to each other.
As part of the sprint definition we plugged our availability into TFS. We all have day jobs, so we wanted to make sure our sprint planning reflected the fact that we might only have a couple of hours every day or so to work on the project.
Team Foundation Service proved to be more than up to the job of allowing our distributed team to have visibility and insight into our current status and remained to be done.
Next post: keeping our source code in order.
(Want to learn more about the Team Foundation Service, such as how to get started, features, pricing, etc.? Here's your one-stop shop: https://tfs.visualstudio.com/)