Video streamVideo streamVideo stream

Question indexQuestion indexQuestion index

Interview transcriptInterview transcriptInterview transcript	Discuss this interviewDiscuss this interviewDiscuss this interview
Eric Lee - Product Manager at Microsoft Eric Lee has worked in testing and development at Microsoft for just over four years. Before Microsoft, Eric worked at a small company in Toronto. Most of Lee's experience has been in GUI components and server-side programming. He holds a bachelor?s degree in Computer Science from the University of Western Ontario.

Hi, this is Paul Ballard, Editor for TheServerSide.NET, and I am here today with Eric Lee from Microsoft. So, Eric, tell us a little bit about who you are and what you do for Microsoft?

Thanks Paul. I am a Product Manager at Microsoft. I am a Product Manager for Visual Studio Team System and I have been in Microsoft for about seven years now and I started my career as a tester, I moved from test to dev, I did development for Windows for a while and then I moved to project management, which is kind of combination of test and dev, doing all the schedules and specifications and finally made the leap to marketing a couple of months ago.

Great. What areas within Team System are you specifically responsible for?

Looking at Team Foundation Server. The server side aspect of Visual Studio Team System, which is our first server side product.

Tell me a little bit about that. What are the aspects that make up or what are the products that make up Team Foundation Server?

Team Foundation Server is, I like to think it as a collaboration server. It's basically a centralized web service that contains our change management, source code control, our work item tracking, dynamic reporting and project portal as well as some team building functionality that we have and all the general infrastructure to link all of those features together. Basically a single place for work items, single place for your source code control, dynamic reports that we'll build out of that and a single place for you to build, to do team wide builds of your product.

With Visual Studio Team System Microsoft is getting into product lifecycle management arena, what made them decide that they wanted to get into that as opposed to development tools?

You know we will still always do development tool. Developer tools is really a core part of what Microsoft does, but the move to developmental process really came down from Bill and Steve. They really wanted to see us ship what we use and use what we ship. We've always used a lot of internal tools at Microsoft and we have had internal build process, we have had internal engineering tools, we have had internal testing tools, and internal source code control system and they really wanted to see us take those tools and technologies and bring them out for our customers. Team System is basically the culmination of those efforts.

Is Visual Studio Team System what you're using now?

A lot of the development teams. The development team that builds Team System is using Team System as well. There is a development team in Redmond, there is a development team in North Carolina, there is a group over in India and there is one guy in Alaska and they all use Team System. We use Team System to keep track of all their source code control, all their work items, all their bugs.

Tell me a little bit about the internals of Team Foundation Server, what does it consist of, SQL Server or you mentioned it as collaboration server with web services? What are the components that make up that server?

Basically, we are a web service exposed through IIS as a web service using SQL Server 2005 at the data store. We use that for a number of reasons, mainly for administrative purposes. Instead of giving you a proprietary database system to use, we are building on top of SQL Server 2005. If you already have database in your infrastructure, you probably already have a process for disaster coverage, database backup and what not. This is just one more database in the infrastructure that is easy to administer and same on the web service end it's not DCOM port or some special RPC port or something, It's just a web service that takes advantage of HTTPS for security, just one more web server to administer in your infrastructure.

Does the server software rely specifically on SQL Server 2005 and if so, what parts of SQL Server?

We take advantage of a lot of the new analysis tools that are part of SQL Server 2005. We'll take the data that you build up as you work naturally like checking a source code or creating bugs or fixing bugs, we take all that work and we build all OLAP cubes from that so it allows us to build some pretty complicated reports for you.

How are the reports delivered?

Using SQL Server 2005 Reporting Services. We will generate them there, then you can view the reports inside of Visual Studio if you want to. We will also build a project portal for you. We will populate that portal with some web parts that allow you to see those reports. You can roll out that on some kind of project portal and have a very good dynamic snapshot of how your project is going.

How did Microsoft come up with the process that they would implement through Team Foundation Server into the Visual Studio Team Systems?

Oh, there are a lot of ways, a lot of ways. We built a very generic methodology infrastructure. You can take any process that you have and use that to just sort of skin Team Systems. You change the way the work items look, you can change the work items that you have, you can change the workflow that you've got. The specific processes that we picked, we took Microsoft Solutions Framework from our consultant folks, and all of the years that they spent developing their techniques and their guidance, we've taken that and we baked it into the tools. That's one of the methodologies that we will ship and we have got two flavors of that. Agile, which is super, super lightweight, its almost like not having a process. There is just some basic bugs and tasks and scenarios, there is not a lot of workflow, basically just letting people work naturally. Another flavor of MSF is Complete, which is a little bit more process driven, little bit more workflow, little bit more check and policy, things of that nature. We're working with all those major GSIs to develop, to take their processes and build them into methodologies that Team System understands and we are working with a number of major consultant firms as well.

Will there be a RUP process implemented in Team System?

There is. We've got a partner working on that actually. That will be neat to see. That will be taking RUP and taking that process and actually enforcing it inside the tools, that will be a neat thing to see.

Is it difficult to extend the tools for any processes?

Not at all. At VSLive I did that several times where in the 20-minute theater presentations, we've taken one of the methodologies because I kind of wanted to demystify all of this. So, we took Agile, we exported it in the native form, which is just XML, we added in one of the bugs, we added a couple of fields to the bug and we created a new project, a new work item based on that and we could see the change right there. It's a very, very quick process. Same with our underlying event infrastructure. We will ship out the box with notification, so you could say well give me an e-mail when my work item changes or give me an e-mail when a build is finished, things like that. That whole system is available for you to plug into. In one of the talks on Monday, I picked up Team System and plugged into the event system, so that we get an instant message when work item changes. When you can do it on stage, its pretty easy.

I have also heard that SharePoint portal server is part of this product and how does that plug in?

Yeah, when you create a team project, we do a number of things for you and the things will depend on the methodologies, but out of the box we will create a project portal for you. So, template is defined in the methodology, but we will populate that, its one place for your whole team to go for their documents, whether its developer documents or specifications or test specifications or vision documents, all in one place for your whole team to go. It's a place where we will show you reports so you can very quickly see how the project is going, whether you are a high level stake holder or you are one of the individual developers or testers.

What is the competitive landscape for this product?

There are a lot of tools in the software development lifecycle market. We like to think that we are first integrated software development lifecycle tool. So, we built Team System, from scratch, adding each technology one piece at a time with the idea that they would all work together. Your testing tools work with your profiling tools, your profiling tools work with your source code control system tools, your project management tools work with everything. So, just out of box, it's one integrated system. All the linking and all the synergy that you have just comes right out of the box. We would like to think we are the first integrated software developing lifecycle tool in the market.

What is the installation process for this server? It seems to have quite a few different components. What is the installation process?

We are still polishing our setup. It's actually not too bad. We will require SQL server 2005 and right now in our community technology previews and our pre-Beta builds, its a separate installation. You install SQL Server 2005, then you install the data tier, which is a really quick setup, that just sets up our tables and our schemas and what not. There is a separate middle tier installation so to speak that will install the web services and that's fairly quick as well. Then, you install the Visual Studio Team System Client SKUs, which is basically installation of the Visual Studio Professional with the added tool of architecture tools, development tools, and test tools. Once that's setup, you connect it to your middle tier.

You mentioned the Visual Studio Team System SKUs. What are those SKUs and what are the components of those? There seems to be a lot of confusion in the market right now.

I think a lot of the confusion has been our fault. We have not done a great job explaining. We've been really eager to explain all the new features and all the new pieces that we put in Team System and in doing that we made it sound a lot more complicated than it really is. Basically it boils down to two pieces. You have got Team Foundation Server and you have your Team System suite. Those are the basic two pieces and we refer to Team System as the whole thing, both of those pieces. Inside the Team System Client suite, there are three major aspects. One aspect is designed for architects, all the modeling pieces, there is one aspect designed for developers with engineering tools, profiling tools and there is one aspect designed for testers, load testing, web testing and test case management. There are shared features throughout all those SKUs and you can certainly mix them up. Most of our customers will probably go towards the Team System Suite, which is all three of those combined. That's what we have been using at most shows. To be able to show all of the technology that is part of Team System and all of those SKUs connect down in the Team Foundation Server.

Tell me a little about project integration. I know that a lot of project managers prefer to work in Project. How does that fit in with the Visual Studio Team System?

That's what we've seen. Internally at Microsoft and a lot of customers that we work with, we have seen them using Microsoft Project or Microsoft Excel, just these tools that they've become comfortable with to manage their project and we wanted to make sure we took advantage of that productivity. So, we took Project, we took Excel and we built plug-ins for them, that's past of Team Foundation Server. Literally it's one piece of data. You can look at it inside Visual Studio as a bug or as a work item, but inside of Excel it's an item inside the spreadsheet, inside of Project it's a task inside your plans. Anytime something in the project plan changes, everybody notices it inside Visual Studio and vice-versa.

Tell me a little bit about the process that is defined within, for instance, MFS Complete, what are the steps that you go through to the development lifecycle in that process?

In that process, MSF Complete is more of a process where it's much more detailed in terms of your requirements, tracing requirements back to source code, having some more strict policies in terms of what gets checked in. Code analysis being run, work items associated with each check-in, unit testing has been done for each new piece of code that is checked in. We've got policy inside of Visual Studio Team System that allows you to force that for each check in. The developers get a friendly reminder if they forget to run code analysis or if they forget to run unit testing with each check-in.

A friendly reminder?

A friendly reminder, and they can override that. They can override if they need to and then an email is sent out so there are always exceptions to it.

Okay, so I am a developer and I decide to start doing development using Visual Studio Team System, how do I start, how I build my project structure, where do I go?

That's a good question. We have a wizard that will create a team project for you. The team projects are higher-level container than solutions have been. If you take today's Visual Studio, when you start with Visual Studio 2005, you create a solution and you add projects to that. In Team System, you create a team project and you add multiple solutions to that. It also holds all your work items, all your bugs, your tasks, your requirements, any documents that you might have, your developer design documents, your test specification documents, your project specification documents, all that goes into a team project. And we've got a wizard that will walk you through that and prompt you for things like, do you want to create a new source code control branch now, do you want to branch out of something existing or do you just want to come back to it later. It will ask you where you want your project portal to be created and what sorts of things do you want to see in your project portal, it will take all that information and its a lengthier process than creating a solution as today but it will take all the information that you give us and will create source code control for you, it will create a project site for you populate it with reports, will create document templates for you, based on your methodology choice, we will create the work items, the way they look as well as some default work items that are populated in your database initially.

You mentioned a couple of times default work items and work items specifically, what exactly qualifies as a work item? Is it specifically Visual Studio or are there work items that do not involve developer tasks?

Work items are really, really generic terms that we have, it is basically just an artifact that we store for you. In fact, everything inside of Team Foundation Server is just an artifact. An artifact can be a piece of source code, it can be a work item, it could be a bug, it could be a task, a scenario or it can be something that you define. We will give you a base schema, you can define your own schema and we will just store that for you. A work item, depending on your methodology choice, you pick Agile, your work items are a task, a bug, a quality service requirement and a scenario and when you create your team project, we will create a list of tasks for you, a list of work items for you. Things like "Create revision document", "Create your milestone one goals, your milestone two goals", things like that. Work items are really generic and those work items are everywhere in Team Foundation Server. They are inside of Visual Studio Team System, inside the IDEs, you will see a list of tasks they are inside, they could be like your Microsoft Project plan and you could pull in work items from there or it could be inside your Excel document as well. We've got a number of partners lined up to build the same sort of integration into various other tools. The other office tools, more traditional traceability tools like Caliber RM, they will be able to do the same sorts of things as well.

Okay, so I am a manager, I need to look into a project, where do I go in Visual Studio Team System to see how we are doing, if we are on schedule, if we are on budget?

There are a couple of places you can do it. If you are at a high level, you can look at the project portals. You just open up a browser, navigate to your project portal, and you have a number of reports there. You see very high-level reports like how well you are tracking in terms of your schedule, your bug trends, are you trending up or you're trending down. You can drill into each of those reports. You can literally go from here all the bugs in your entire project, all the way down till her is the last bug filed by the newest tester in your team. Inside Visual Studio Team System, you get access to the same sort of things. We will have UI pieces inside of Visual Studio Team System that will allow you to navigate the work items, the source code control, basically everything in your team project, and also view reports from there as well if you want to. Different tools for different types of people. If you are a manager but you like to use Visual Studio, you can certainly use that. If you just want to see a very high level view, open up a browser and you can navigate through the project portal.

Eric tell us what's next on the horizon for Visual Studio and Team System and Foundation Server post Whidbey?

A lot of plans. A lot of that depends on customer feedback, what people think of Team System in our current release, and what more we can do for them and a lot of those things just get rolled up into our next release, but long-term we are looking at doing more with Longhorn, doing more with Indigo, doing more with Avalon as those technologies develop and get released. We will be able to build technology for those products. Team Foundation, what we've done in this first release of Team Foundation Server is to start to normalize and aggregate a lot of server side technologies of Microsoft, your databases, your web servers, your project management, project tracking; we would like to continue to do that. Bringing in other server side technologies of Microsoft, maybe Microsoft Exchange or maybe a Microsoft Communication server and give that to you as both a programming tool being able to access those things, but also being able to utilize those things in your own development process, being able to send instant messages when things change, being able to populate exchange folders possibly with work items and what not. Just being able to add that BizTalk as well, just being able to give them one nice rational place to use it both from a traditional developer programming side as well as from a development process side as well, so being able to bring those together.

Then with the integration with Microsoft Project, does that basically kill off Project Server?

The most important thing, do you mean the most important technology?

That's a really good question. In our first release, we are doing integration with Microsoft Project, the client side Microsoft project if you will. We wanted to do integration with Microsoft Project Server but for resource constraints and some technology limitations, we couldn't do it this first release, but next release that's something we will definitely do. We will build the same type of integration that we have with traditional client side Microsoft Project, we will do the same with Project Server.