I've been on (and seen) projects that were so overburdened with processes and documents that it was like walking through a lake of molasses.
I've also been on (and seen) projects where there was so little process that life was exciting, interesting, crazy, but basically one chaotic scramble after another.
NetBeans follow a beautiful middle path - not too much process, but not too little. I'm sure I'm missing a lot of important points and aspects that make this all fall together, but these are the ones that stand out to me:
Planning
The planning phase is fast and lightweight. Each release is given a release boss, and the release boss works to define a theme for the release. The release boss also decides on the dates for milestones and the final release. Then each team is asked to decide what features they feel best meet the theme, and for what milestones those features will be delivered.
Normally the feature list is written up quickly on a Wiki page. Each feature is given an issue number in Issuezilla and is assigned a person who owns it and a milestone date.
The release boss uses reporting features in Issuezilla to track all of the features committed for a given milestone, and you have the plan. Pretty simple. We all know what to do, and when we have to do it by, and we get to work.
Specification and Design
You are expected to specify the user experience and interface for your features. But it's in a very lightweight manner, on a Wiki page. Here is an example UI Spec that I wrote. Pretty simple, but it gets the point across.
Certain defining features get a lot of attention and are reviewed carefully by our User Experience team, but for most smaller features you just need to write up a quick spec, have it reviewed by your team, and you are done.
Milestones
I love milestones. I think every large team should have milestones. Basically these are a mini-release, where everyone has to get features in by a certain date, there is a stabilization period with extended QA and bugs are fixed, and then it gets published on the NetBeans site. Milestones normally happen about once every 4-6 weeks.
The main reason why I like these as a developer is because it keeps me focused. A six month development cycle tends to make you be lazy early on in the cycle. With milestones coming at you once a month, you get very focused, and you are working hard all the way through the release, instead of working insanely at the end. This also means that it is much more likely that we deliver on time, or if we're late, we know sooner rather than later. And what I have seen is that NetBeans has consistently delivered what we say we deliver, when we say we're going to deliver it. There is a lot behind this, but milestones are a key part of this.
Simple, Strong Quality Criteria
Every release has quality criteria. These are soft and hard goals in terms of the number of P1, P2 and P3 bugs. There is a total overall goal, and each team is also assigned specific goals. For some reason a lot of projects I have been on have not been that strict about this, and it has affected the quality of their product
Nightly Builds Available to the Community
What this means is everybody is using our stuff all the time, all the way through the release process, and we hear from them. I think this is great. More and more projects are doing this, and I really can't recommend it highly enough. And if you don't know about Hudson, you really should check it out.
The Team
This is a lot harder to reproduce, but as usual is a key part of it.
The theme running through this all of this and a thousand more details and steps, is a dedication to quality and predictability, without overburdening the teams with process and busywork. It's a difficult balance, and it's executed quite well here.
So I think that is probably the underpinning of why NetBeans development process rock: the team. From developers to management to QE to release engineering, I have never seen such a smart, dedicated, hardworking group of folks. I am really honored to work with them.
No comments:
Post a Comment