ce the requirements aren’t fixed, the developers and customers must work together to create the product.”

Rapid development methods themselves rarely lead to accomplishing work faster, according to Thompson. Instead, the parts of the system that deliver the most value are more efficient. “I think that people are missing the point when they treat rapid development as a technical exercise,” he says. “If you really look under the covers of any of the rapid methods, the emphasis is on time-boxing the work and controlling the scope to fit in the time-box. That can only be done by understanding the bigger picture and how this piece of work fits in and constantly communicating and setting expectations as the work uncovers issues that may threaten the time-box.”

The successes of rapid development methods can be attributed in part to small teams of developers and customers who are located at the same site and focused on the effort at hand – which naturally minimizes some of the communication challenges.

Deft and Deliberate

Work products like requirements specifications, architectural specifications and detailed designs are intended to record complex ideas so they can be reviewed for consistency and clarity, then communicated to others. When schedule pressure results in reduced clarity or content of the work products, misunderstandings snowball.

To avoid rework, resist pressure to get the developers working on the “easy parts” until the big picture is clearly defined, according to Robert Lew, an application development manager for the State of California in Sacramento. Describing a recent project to allow client data submission via the Internet that had a rocky start, Lew says, “Our biggest lesson learned is to take the time up front to develop the arc

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://opto-elec.com.cn/pmqhd/index.html