Mike's Intro
Where to begin… I am one of the Program Managers working on the release of Whidbey. I started at Microsoft just over 9 years ago and I have been working on the Developer Division Release team for just over 2 years now. Prior to the DevDiv Release team I was working as a PM on the .NET Framework SDK team.
Since coming over to the release team I have grown a real appreciation for Release. In release you get a very a high-level picture of the work involved in shipping software, while at the same time owning many of the details it takes to get the software out the door. I would say this makes it somewhat difficult to really categorize the work we do. Which is why, I suppose, I and the “release_team’s weblog” are here. This is our opportunity to give those, that are interested, a look into what “releasing software” in one of the largest divisions at Microsoft is really like.
In my position it is probably best if I started with some of the areas I focus on: driving shiproom (also called warroom in many circles), Whidbey project status communications, product metrics/release criteria, Whidbey external partnerships, & legal rep (this should be a good list to start with…)
Driving Shiproom : best explained already below: “The purpose of Shiproom is to have a forum where each team from the division is represented. Shiproom is designed to track project/s status, go over blocking issues, and keep the division informed. During the endgame this includes making decisions on bugs and driving teams towards release. It’s regularly held twice weekly, until the end-game where Shiproom is held daily.” One additional comment I would like to make about shiproom is how we really focus on the customer, this may be easily missed or may even go unnoticed, but a great example of this is during the endgame. During the endgame (which may last 6 weeks – 2 years, ok maybe not 2 years…) we review every bug fix and the first questions is always, “What is the customer scenario?”. We find this to be the most important questions when trying to understand what it is the customer is experiencing, where is the pain!
Whidbey Project Status Communications: As part of the release process we focus a lot on bugs, user scenarios, quality of our features, product metrics (like stress, performance, security, compat, and many more), and driving towards milestones. I own the reports that generate a regular status for how we are progressing on each of these areas.
Product Metrics/Release Criteria: During each milestone we define a set of “release criteria” that are required for that milestones release. These include things like stress, performance, compatibility, side-by-side, security, localization, globalization, compliance, lint free source… At the end of a milestone the work begins to define what are the next milestones criteria, when and what sort of test passes are going to be required, and tripwires or checkpoints for make sure we are on track to hit a particular criteria. We track these release criteria through shiproom, our ddmetrics site, and at product unit reviews.
Whidbey External Partnerships: Products delivered from the devdiv have a large list of dependencies delivered by various other teams at Microsoft as well as partners outside the company. From the release team I manage these relationships, drive their integration into Whidbey, and division milestones working closely with the product teams requiring the dependency and the external partnering teams.
Legal Representative: I manage the division relationships through our legal rep. This includes legal questions that may come up around our requirements for shipping & owning the EULA plan for Alpha, community tech previews, Betas, & RTM.
In the upcoming weeks and months, I hope to bring more details on the areas I am working on and bring some day-to-day examples as we progress through beta2!!!