Advertisement

Keywords

Team Leader Unit Test User Story Pair Programming Agile Software Development 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Reference

  1. 1.
    A similar list of problems is also given in Chapter 1 of Extreme Programming Explained. Google Scholar
  2. 2.
  3. 3.
    There’s a good discussion of risk management in Chapter 5 of Steve McConnell’s Rapid Development (Microsoft Press, 1996).Google Scholar
  4. 4.
    Alistair Cockburn, Agile Software Development ( NewYork, NY: Addison-Wesley, 2001 ), p. 142.Google Scholar
  5. 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. 6.
    See http://c2.com/wiki?XpXtude.
  7. 7.
    Chet Hendrickson, “When is it not XP?” http://www.xprogramming.com/xpmag/NotXP.htm December 5, 2000.
  8. 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. 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. 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. 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. 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. 13.
    For an example of test-first design in practice, see http://www.objectmentor.com/resources/ articles/tfd.pdf.
  14. 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. 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. 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. 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
  18. 19.
    Matt Stephens, “Automated Code Generation,” http://www.softwarereality.com/programming/ code_generation.jsp, May 6, 2002.Google Scholar
  19. 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
  20. 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
  21. 22.
  22. 23.
  23. 24.
  24. 25.
    See http://www.togethersoft.com/services/tutorials/jmcu/chapter6.pdf.
  25. 26.
    See http://www.rational.com/products/process.jsp.
  26. 27.
  27. 28.
    See http://www.iconixsw.com/ICONIXProcess.html.

Copyright information

© Matt Stephens and Doug Rosenberg 2003

Authors and Affiliations

  • Matt Stephens
  • Doug Rosenberg

There are no affiliations available

Personalised recommendations