, there is some discussion about using ExtremeProgramming
for developing "products", as opposed to developing a system for in house use by a single corporate customer. I've never done any XP, but I thought it might be enlightening to describe how one real world product (Macromedia FreeHand
) is developed. -- CurtisBartley
Some caveats apply. I never worked on mainline FreeHand
development at Altsys/Macromedia, so although I think I understood how the development process worked, I never experienced it firsthand. It's also been a few years since I worked there, so although I think I remember what I thought I understood when I was there, my memory may be a little hazy. For purposes of expediency, I'm going to proceed like I actually know what I'm talking about. Just keep in mind that I only think
I know what I'm talking about.
My first job out of college was working for a small company in Dallas, Texas called "Altsys", whom you've probably never heard of. Altsys's major claim to fame was that they developed FreeHand
, which was originally licensed and sold by Aldus. FreeHand
is an application for doing PostScript
friendly illustrations and it is sold primarily to professional graphic designers. It competes head to head with Adobe Illustrator. As a consequence of Adobe's acquisition of Aldus, Altsys got the rights to market FreeHand
back and was then immediately acquired by Macromedia, so FreeHand
is now Macromedia FreeHand
rather than Aldus FreeHand
Prior to FreeHand
4.0, QA was handled by Aldus in Seattle. For every FreeHand
release Aldus would hire contract testers who would test until the product shipped, and then they'd all be let go. Then the whole process would be repeated for the next release with new testers. The lack of release-to-release experience on the test team compounded with the obvious communications difficulties of having the test team in Seattle and the development team in Dallas made the QA process a real burden.
4.0, Altsys took over the QA effort and hired permanent full-time testers. Testers were usually (if not always) professional graphic designers. These testers were themselves customers of the product, and they were familiar not just with previous versions of FreeHand
but other related applications such as Illustrator, PhotoShop
, and Pagemaker.
4.0 and FreeHand
5.0 Altsys attempted to do some serious process improvement. This effort was instigated by the CEO but the actual process changes were the responsibility of the FreeHand
development team. This all happened about the same time SteveMcConnell
came out, and that book was fairly influential on the process improvement effort.
At the highest level, the development process basically follows the waterfall model. The first phase consists of nailing down the requirements (usually expressed in terms of features that would be implemented). This is followed by a development phase and then a final testing and bug fixing phase.
Choosing of Features
The way features are chosen for a new release is probably pretty typical for the industry. A new development cycle would be kicked off by choosing a feature list for the next release and prioritizing it. At Macromedia, the FreeHand
product management staff in San Francisco was actually responsible for this list. This list of features would be drawn from a variety of sources, such as features that were dropped from previous releases, customer requests, sales and marketing requests, and suggestions from the development team. Another obvious source of feature ideas were other products FreeHand
users had exposure to, such as Illustrator, Pagemaker, Quark Xpress, and PhotoShop
. Some feature ideas were "well known" and would come up for every release.
The development phase is the most unusual part of the process, and to explain it it's necessary to describe the makeup of the development team. For FreeHand
5.0, the development team consisted of about 10 or 12 engineers and 8 or 9 full time testers. Four or five of the testers were "QA/Designers". As the name suggests, QA/Designers are responsible not just for testing, but also for design (in the user interface sense) of features. The FreeHand
5.0 QA/Designers didn't have any formal user interface design training, but then neither did the engineers that did feature design before them. They did have two important qualifications, though -- they were representative of customers of the product (who were themselves graphic designers) and by dint of their profession they at least had general design experience. It is this QA/Designer role that really distinguishes the FreeHand
process from other development processes.
Planning and scheduling is done in terms of features. Features are prioritized and highest priority features are implemented first. A QA/Designer and an engineer are assigned to each feature. The QA/Designer might be working on several features simultaneously, but an engineer would only work on one feature at a time. The development of a single feature follows this progression:
- QA/Designer specs the feature
- Developer implements the feature; QA/Designer writes test plan
- QA/Designer executes the test plan; Developer fixes bugs
- QA/Designer signs off on the feature
The developer does not proceed on to the next assigned feature until the QA/Designer signs off that the current feature is implemented as spec'd and passes the test plan. Since aggressive testing and bug fixing occurs all through the development phase the time spent in final integration testing is minimized. And since high priority features were scheduled first, it's easy at the end of the development period to defer features to the next release. This makes it possible to trade off low priority features for time, and reduces the likelihood of missing a scheduled ship date.
A final integration testing period is scheduled at the end of the development cycle. This period might last several months, but it is much shorter than the traditional testing period because so many bugs were fixed early in the development process.