KeywordsBurning Marketing Hunt Defend Dial
Unable to display preview. Download preview PDF.
- 1.A similar list of problems is also given in Chapter 1 of Extreme Programming Explained. Google Scholar
- 3.There’s a good discussion of risk management in Chapter 5 of Steve McConnell’s Rapid Development (Microsoft Press, 1996).Google Scholar
- 4.Alistair Cockburn, Agile Software Development ( NewYork, NY: Addison-Wesley, 2001 ), p. 142.Google Scholar
- 5.This is referring to a quote from Kent Beck in Extreme Programming Explained,in which he states that we should “take all these good things and turn the knobs up to 10”—in other words, do all of them all the time.Google Scholar
- 6.See http://c2.com/wiki?XpXtude.
- 7.Chet Hendrickson, “When is it not XP?” http://www.xprogramming.com/xpmag/NotXP.htm December 5, 2000.
- 8.For an interesting discussion, see http://c2.com/wiki?xpCourageValue. We can see from this page that the Extremos were originally debating between courage and aggressiveness (not to mention confidence, fearlessness, boldness, and ruthlessness) as a possible name for the value. “Our chief weapons are.”
- 9.XP takes the approach that the software should be ready to release at any time, just in case the project is suddenly cancelled. We prefer to take a more realistic approach and plan ahead to specific release milestones.Google Scholar
- 10.XP recommends tailoring its practices to local conditions, although (as we describe in Chapter 3) it contains little guidance for doing so, and in many ways tailoring XP can be a risky business.Google Scholar
- 11.In XP, collective ownership also helps, in that sooner or later someone else on the team will notice some bad code and refactor it. This is a little too ad hoc, though—it leaves a lot to chance. A more rigorous approach is to schedule regular reviews (not necessarily with a big group of people, because this can be demoralizing for the person whose code is being analyzed). This coupled with up-front design reviews helps keep your code in shape.Google Scholar
- 12.Scott W. Ambler, Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process ( New York, NY: John Wiley & Sons, 2002 ), p. 188.Google Scholar
- 13.For an example of test-first design in practice, see http://www.objectmentor.com/resources/ articles/tfd.pdf.
- 14.Although we part ways again when XP goes really abstract and ascends into Zen-esque philosophy to justify its practices, as we discuss in the final chapter.Google Scholar
- 15.Luckily the Extremos have also seen the light and refactored the XP customer role to mean a team of analysts (as we discuss in Chapter 5).Google Scholar
- 16.This may sound blatantly obvious, but that’s possibly because it is such basic, profound advice. We’re still amazed at the number of projects we see or hear about that contain one or more bad programmers.Google Scholar
- 17.QA also has its own separate test environment, but running the tests regularly in Engineering means that not only are the functional tests testing our software early, but also the software is testing the functional tests early as well. This virtually eliminates the “big bang” delivery problem, which affects test scripts equally as much as it affects production software.Google Scholar
- 20.We’re using Java properties files for this purpose because they’re much simpler to work with than XML (not to mention easier to read and edit). If the project increases in complexity and demands more flexibility, we will change as needed.Google Scholar
- 21.XPers tend to view this practice with quaint amusement, and yet this was a primary factor in the early termination of the C3 project (as we discuss in the sidebar “Did Oral Documentation Kill C3?” in Chapter 7). Google Scholar
- 24.See http://www.dsdm.org.
- 25.See http://www.togethersoft.com/services/tutorials/jmcu/chapter6.pdf.
- 26.See http://www.rational.com/products/process.jsp.
- 28.See http://www.iconixsw.com/ICONIXProcess.html.
© Matt Stephens and Doug Rosenberg 2003