C# Status: 4/5/2004

Ahh, April appears followed by a week of downpour. Hordes of my friends disappeared this weekend to the slopes of Baker and Whistler, while I decided to run and play a bunch of sports instead. April seems like a nice fresh start on the C# team. Last week, Scottwil sent out a great kickoff mail outlining our Whidbey RTM plans. This came out of a couple of weeks of discussion with QA, Dev and PM. This mail contained a tentative schedule & goals...it specified when we plan to have our next zero bug bounce, when our QA will work on writing more test automation, when they will run a number of tests on the product (a fiersome time...the bugs start escalating rapidly at this time...) etc. This gives the team a good idea of what we are doing on a week to week basis.

Another item the mail contained that Steve & Jay & I worked on, were the weekly bug goals. On our team Dev has the most bugs by far, and QA & PM have a much smaller amount (say about 12%). PM & QA bugs are a concern as they represent potential work for devs - we put weekly goals that we wanted these bugs to be at and made sure we got to zero early, in case they ended up as work for Devs. The Dev team also took a good approach to their bug goals per week. They start out aggressively for the first couple of weeks - which means they have a high fix rate planned for the first couple of weeks and as they get to the end, their planned fix rate is smaller. We did this because as we shut down the product, we wanted the number of bugs we fixed to be much smaller, to minimize risk.

We've also planned to be much more risk aware this last milestone. We have a weekly leads meeting and we plan to have the teams come and talk about their high risk items. In Devdiv we also have a class of bugs called DCR's (design change requests)...these are potentially risky, high cost, cross team affecting, new feature sort of bugs. These represent new risk and if teams have them, we want them to tell us about it. Right now we are investigating a couple of issues that might turn out to be potentially troublesome, but we'll see.

Beta2 is still waiting on stress results. Teams worked the weekend this week to bring in their bugs.

I spent a ton of time last week and this week looking at our servicing story. I spent some time checking out the bugs reported to our Product Support Services (PSS) folks. The debugger is potentially troublesome and we are thinking of putting up a couple of troubleshooting documents. Where would you search for this content?  I'm thinking of msdn, but am interested in your feedback.


Comments (8)

  1. Odegaard says:

    So… what do your schedule say about the release of beta 2? 🙂

  2. Victoria French says:

    The first place I would look (after your blog of course) would be the readme file or a debugger.readme file.


  3. Cal says:

    looks like you are really bussy!! Great work!

    any idea when beta2 is going to be available?


  4. eAndy says:

    Would probably look to the help docs with the product and then


  5. Odegaard says:

    Most of my problems are usually resolved using Google, so putting them on the web is the way to go for me.

  6. anon says:

    Yeah! ScottGu’s gives a more definitive response on VS.NET 2005 beta2 ETA:


Skip to main content