 Video streamVideo streamVideo stream |
 |
 |
|
|
|
| Question indexQuestion indexQuestion index |
|
|
|
|
|
| Interview transcriptInterview transcriptInterview transcript |  Discuss this interviewDiscuss this interviewDiscuss this interview |
|---|
|
Sure, I'm Lori Lamkin, I started at Microsoft in 1990, and I've been with Developer Tool the whole time,
really, on C++ and Visual Studio. I recently came over as the Group Program Manager for Visual Studio Team
System because I was so excited about the ability to make teams collaborate better at shipping software,
specifically with the project lead being enabled to communicate better with the team and that sort of thing.
Not so much. We've been working a lot with partners and working a lot with other customers and been pretty
clear about what we're doing and trying to get a lot of feedback. But we haven't gone out and announced it
because we wanted to hold a big event to do that. So, in the past, Visual Basic Studio made the individual developer productive in the edit, debug, and build
cycle, getting their work done. But we've heard a lot of feed back that this certainly doesn't help me with my
team. Things like source code control and dealing with my bugs, and the issues that come in, the tasks that I'm
scheduled. Visual Studio isn't helping me with it. And so, what we've done is created some tools for the team
for the whole IT organization: So architects, developers, testers, and project leads, and integrated those
together inside of Visual Studios so that the developer from that perspective can focus on his tasks at hand,
and yet, can communicate more effectively with receiving and sending work to other people on the team. The tools for the Project Manager, involve several things. First of all, we're not introducing new tools,
we're using the tools that Project Managers use today, which are Office applications, and Windows SharePoint
Services, and lots of reports out of [...] Server. And so, what we're doing is taking all this information
that's collected throughout the team: bugs, test results, [...], and we're making sure that they can service up
to the Project Lead in the report, in project plans, in spreadsheets and schedules. So when you go through and
you create a project schedule and you assign tasks to people, when you publish it, it goes automatically into
the work item cues and people receive new tasks to do. And then when they go and update those tasks, the
Project Lead just refreshes the project plan and they get a live update on how things are progressing. So, there's a level of flexibility here. If you really don't like Project and you tend to so your list
tracking and scheduling in Excel, then use Excel. All you have to do is create your list of the tasks I want to
get done, and show the state and all the information from the work item database can show up right in your
spreadsheet. So, the difference is that you can choose the tool that you feel most comfortable in. And it works with the
next version of Project, if you are a Project fan--a lot of people are--we work with the project in the next
generation of Project just to make that data more alive, because people tend to like Project for scheduling but
not for tracking. And we're making that data live so that you're not always holding the static meeting to say,
"Hey, how's everything going?" and then manually updating your project plan. It just reflects the reality of
what's happening. A work item is a task, a bug, a feature, a risk, a requirement, or a scenario. You can create your own work
item types as well. But these are just elements of work that get transferred around and establish a common
language that your team uses. Ya. So, we're not integrating with Word in a deep fashion. You're able to attach documents, and get status on
documents in SharePoints, but we're not integrating like we are in Excel or Project, where, at a row-by-row
record level the information is automatically updated. Well, we have two ways to navigate project information. One is what we're calling the Portfolio Explorer,
which is an Explorer in Visual Studio that enables you to route the build status, test results, bugs and
queries, and things like that. We also have a Project Team Portal where you can browse all the exact information. The Project Lead will need
to have a copy of the license for Team Foundation Client. But it's up to them and we'll have a light weight
install in Visual Studio where we're really using it as a shell and you can see the Portfolio Explorer, if you
don't want to have all the language packages installed and things like that. Some Project Managers are also the Development Manager, or also the person doing work so it's very handy to
have that integrated in the same environment they're getting their other work done. So, Project Manager can
choose use the light weight version of Visual Studio or have all the languages installed in there as well, or
go out on the portal and be navigating information there. It's based on Window's SharePoint Services. It contains all the documents, template, and reports, and it's a
more of a dashboard view of your project and the ability to drill through and analyze information and
manipulate work items. So, what we have is we built a base methodology framework in the product. So, on top of that you can set the
reports or templates, or none of that, or the base work flow of your team to do whatever works for your
organization. So, there's a high level of flexibility in tuning and customizing the methodology for your
organization's needs. And we are coming out of the box with two to choose from. We're integrating two
instantiations of that framework. One is for a more formal CMM level of methodology. Another on is Agile. So it's more scenario based, more
iterative, more short-term. And both of those things sit on top of the same framework. And you can tweak and
tune those or you can wipe them clean and start from scratch. Once you've created a project you can decide that, "you know, I'd like to change the check in policy," so
that people need to resolve work items before they check in or you can get rid of that kind of limitation and
say, "no, I'm just going to have a more free form environment here." So there's a high level of flexibility;
you can start with our basics, or you can create your own. In fact, we have a lot of global interface integrators doing exactly that, including creating methodologies
for deployment and IT organizations and they're building on top of this framework radically different
methodologies We're working with it. We're trying to just pull a more generic version. We do have a demo; we're building an
XP version demo in my session at TechEd just to show the flexibility of the framework but we're trying to go
for more of a common grounds here just to appeal to more people at the starting point. From a developer's perspective, what we're trying to do is take all the pain of providing status out of their
way. So, instead of, "here's your new task, go look there, I sent them to you in Outlook," or "Go look at the
project plan," or "go look in the work database," it's all centrally located for you to plow through. This is
the set of work; it's all coming through one channel. And then, it's easy to provide the update. We've
integrated deeply into Visual Studio so that you can be resolving work items while you're coding. That when you
do a check in that work items can get automatically resolved. And then all those updates are automatically
reflected in the project plans. So, we're hoping that this reduces that noise level of just the basic, "Are you done yet, can I start,
because I'm waiting for you to be done," and that whole "what have you done this week," and all the basic,
general status. A lot of time you are just suppose to remember the process and we're having a more automated workflow, so
that when that bug is closed, you're suppose to sign it back to a tester. Well, that can just happen
automatically. So, you don't have to remember a lot of these procedures. And whenever you want to remember one,
or you feel like, "why is that working that way?" you can hit F1, it's integrated into the Help system, it's
not just how to enter the fields in a database but the process steps behind it. So, it's more at your fingertips when you need it, instead of, "Oh, I've got to remember the [...] process
for the bugs or something like that. So, we're trying to make it more handy and available for people that
choose to run their organizations like that. But people who have a more light weight process; this is just a
[port] set as well. You just don't have a lot of that going on. Well, it should be a great story because before it was really hard. You integrated with Visual Studio and we
provided API for you to integrate with the IDE. But now you can integrate on--we've created this platform, this
foundation of services, of eventing and workflow, an historical warehouse of data. And the way our tools are
plugging in to each other, we're exposing all that API for our partners. And we've been meeting with them for over a year to discuss what we're doing and to let them know about the
API that's coming forth so that it should be a great opportunity for them to plug in and build a deeper
integration that makes their customers more productive and should be more excited about those tools. Ya, as a project management tool, I mean, Project is the world's leading project management software. All the
leading API that we use to plug in is exposed to partners for them to do the same. You know, I don't know the answer to that. I do know that our Visual Studio VSIP program is how people get
the API and all of the documentation. I'm not sure how people get it. That's true and we do find that happening a lot as I talk to Project Leads. That with all the tacking
information, they can get buried just trying to find out what's going on, that they loose sight of the big
picture. And one of the ways we'd like to solve that is through, what we're calling our "exit criteria". So with any project when you start it up, or you create an iteration or a milestone, you say, "What are the
key things I need to get done in this milestone?" And there's some standard things: there's work, dev work, and
test progress, and test results, and scenarios you want enabled. And by establishing that exit criteria, people
can walk through and say, "This is a key list of things that really need to be done. And these are the things I
should be checking on, on a regular basis." And will come out, based on your methodology, some standard
information. But you can add to it. Again, it's pretty flexible, you can go ahead and remove things you think don't apply,
that's not how you work. But the intent is to be able for you to keep going back to this and go, "what should I
be doing next? What should I be looking at?" It's in XML actually. So, you can customize these business rules that operate on work items so that work can
flow amongst people automatically. Absolutely. Well, requirements are another work item type, so you absolutely can set rules on all those different things,
it's as rich as describing it in XMLs Absolutely. I mean, you can just clear the slate and have no process in your organization. We do find that
people tend to learn from the last time that they did something, and say, "you know, next time, let's set up a
checkpoint," or "next time, let's make sure that we test this in a deeper way." And that enables the process to
grow with this organization with this base frameworks so that you can slowly add, or not, best practices that
you found yourself that worked for your organization. And we do have two methodologies out of the box that we think will work for most people if they prefer the
more traditional or the more Agile version. But that is just a starting point and people can take that and go
and create a very heavy process or they can take it and create a very light process for their organization. But the process is suppose to be the stage hand not the star of the show. The process is suppose to be
something that maybe the developer doesn't even know about and the integration in the tools should make it so
they don't have to instead of something there is forms and things to fill out. It's the data that gets captured
from doing their work that they no longer have to go and do, and say, "Oh, this is what I just did." Ya, you can go, and when you create a project, pull in the work items that you are going to resolve, and you
can resolve them as part of doing your work. And when you do a check in all of that happens; it gets associated
with your change set, you know what bugs get fixed, and which build. All that information is collected just by
saying, "I'm going to work on these bugs, and now, I'm not," as a batch. So, a lot of that information is just
captured for you instead of having to go out and fill it out again. Absolutely. And you can create a complete XP process on top of this framework. You can create a Scrum process
on top of this framework. You can create a CMM level 2 process on top of this framework. It's just a base level
of eventing and workflow and collection of data and reporting that's available to you. Right. Because all these tools are integrated, we have information--in the past, it's been pretty easy to
know how many bugs you have, and so, a lot of Project Managers tend to look at [fine] rates and fixed rates,
and that's pretty much the end of the boat. But because we're collecting all this other information, I can look
at a team and say, "They have a really low book count, but their test results are failing, so what does this
mean". Well, it could mean that if I fix a few bugs a bunch of tests are going to pass and the test team is
unblocked. And so you have this new angle on the project that helps you make better decisions, and gives you more
information rather than saying, "Well, that team, no problem there, don't bug them, they have hardly any bugs."
Maybe they have a low code coverage and that's not being tested. And so, we have information on test results, code coverage, task progress, requirements being changed. We
have information on [...] on the component, and so all these things can be overlaid and you can look at these
reports overlaid on the same kind of access. So, I think that, I don't want social interaction to be based on: Are you done yet, are you done yet, nag,
nag, nag. I think it's much better to sat, "I'm having trouble with this," or "I need someone' help," or "how
are these two pieces going to integrate better?" And the social interaction amongst the team should center on
that sort of communication, and a lot of noise and time is spend right now just to say, "Ya, what I said I was
going to do is now done, so you can start." And so, that's what these reports and workflows can really automate
so that people can have a deeper conversation about the content of the project and the components and the
scenarios they're building. Certainly, we have the team portal that's available. Costumers can see progress reports on their requirements
Or you can expose any kind of information, metrics, announcements to the customer in that fashion. I also think
that it's important to iterate frequently with your customers. So our best practices in the phase exit criteria
have several check points: to go talk to your clients about your requirement, show the build, things like that,
go and do some walkthroughs of screenshots with customers, that we found, in designing our own products, and
that we've found talking to other customers, that these are really useful checkpoints to have along the way.
My favorite feature is the integration with Excel, because I am a big lover of Excel. I track issues there, I
write my list of my key exit criteria for milestones there, and I like to have my charts, and check on my
states, and that's how I track my project. So, it is so handy for m not to be forced to go into Microsoft
Project. It's handy for me to just get my updates without having to run around to people and say, "Hey, are you
done with that yet?" And so, that's my favorite feature. Thank you. |
