Each practice described in a best-practice chapter has been chosen for one of the following reasons:
Reduction of development schedules
Reduction of perceived development schedules by making progress more visible
Reduction of schedule volatility, thus reducing the chance of a runaway project
CROSS-REFERENCE
For more on the three kinds of schedule-related practices, see Attaining Rapid Development, Attaining Rapid Development.
Some of the best practices are described in Part I of this book, and those best practices are merely summarized in this part of the book.
You might ask, "Why did you ignore Object-Structured FooBar Charts, which happen to be my favorite practice?" That's a fair question and one that I struggled with throughout the creation of this book. A candidate for best-practice status could have been excluded for any of several reasons.
Fundamental development practices. Many best-practice candidates fell into the category of fundamental development practices. One of the challenges in writing this book has been to keep it from turning into a general software-engineering handbook. In order to keep the book to a manageable size, I introduce those practices in Chapter 2, "Software Development Fundamentals" and provide references to other sources of information. A lot of information is available from other sources on the fundamental practices.
In a few cases, you might rightly consider a practice to be a fundamental one, but if it has a profound impact on development speed, I included it as a best-practice chapter anyway.
Best philosophy, but not best practice. Some best-practice candidates seemed to be more like theories or philosophies than practices. The distinction between theory, practice, and philosophy in software development is not clear, and so an approach that I call a "philosophy" you might call a "practice" and vice versa. Regardless of what it's called, if I considered it to be "best," I discussed it in the book somewhere. But if I considered it to be a philosophy, it's in the first or second part of the book. (See Table III-1 for a list of where each best philosophy is discussed.)
Best practice, maybe, but not for development speed. Some best-practice candidates might very well be best practices for their effect on quality or usability, but they could not pass the tests of improving actual development schedules, perceived schedules, or schedule volatility. Those practices were not included in this book.
Insufficient evidence for a practice's efficacy. A few promising practices were not supported by enough evidence to deem them to be best practices. If the development community has not yet had enough experience with a practice to publish a handful of experiments or experience reports about it, I didn't include it. Some of the practices that fell into this category will no doubt someday prove that they have large speed benefits, and I'll include those in a future edition of this book.
In a few instances in which published support by itself was not sufficient to justify treating a practice as a best practice, I had personal experience with the practice that convinced me that it was indeed a best practice. I included those in spite of the lack of published support from other sources.
Questionable evidence for a practice's efficacy. A few best-practice candidates seemed promising, but the only published information I could find was from vendors or other parties who had vested interests in promoting the practices, so I excluded them.
Not a best practice. A few best-practice candidates are highly regarded (even zealously regarded) in some quarters, but that does not make them best practices. In some cases, experience reports indicated that a well-regarded practice typically failed to live up to expectations. In some, a practice is a good practice, but not a best practice. And in some, the practice works fabulously when it works, but it fails too often to be considered a best practice.
In one case (RAD), the candidate practice consisted of a combination of many of the other practices described in this book. That might very well be an effective combination in some circumstances. But because this book advocates selecting rapid-development practices that meet the needs of your specific project, that specific pre-fab combination of practices was not itself considered to be a best practice.
I know that most readers will still wonder about how I categorized specific practices, Object-Structured FooBar Charts or whatever. (I would.) To satisfy that curiosity, Table III-1 summarizes the best-practice candidates and indicates where they are discussed in this book or why they were left out.
The table can also serve as a comprehensive reference to speed-oriented practices for someone planning a rapid-development project.
Table 32. Summary of Best-Practice Candidates
Best-Practice Candidate | Where Referenced or Reason Not Included |
---|---|
4GLs | Best practice. See Rapid-Development Languages (RDLs). |
Analysis, requirements | Fundamental. |
Architecture | Fundamental. |
Buy vs. build planning | Fundamental. |
CASE tools | Insufficient evidence for practice's efficacy. See "CASE tools" in Silver-Bullet Syndrome. |
Change board | Best practice discussed within another chapter. See Change board in Mid-Project: Feature-Creep Control and summary in Chapter 17. |
Cleanroom development | Best practice, maybe, but not for development speed. |
Code, readable, high-quality | Fundamental. |
Construction practices, effective | Fundamental. |
Customer orientation | Best philosophy. See Chapter 10, Chapter 10. |
Daily build and smoke test | Best practice. See Chapter 18, Chapter 18. |
Design storyboarding | Insufficient information available to consider it to be a best practice. |
Design, object-oriented, structured, etc. | Fundamental. |
Design-to-schedule lifecycle model | Not a best practice. See Design-to-Schedule, "Design to Schedule." |
Design-to-tools lifecycle model | Not a best practice. See Design-to-Tools, "Design to Tools." |
Designing for change | Best practice. See Chapter 19, Chapter 19. |
Education, management | Best practice, maybe, but not for development speed. |
Education, technical staff | Best practice, maybe, but not for development speed. |
Error-prone modules | Fundamental. |
Estimating tools, automated | Fundamental. |
Estimation and scheduling, accurate | Best philosophy. See Chapter 8, Chapter 8, and Chapter 9, Chapter 9. |
Evolutionary-delivery lifecycle model | Best practice. See Chapter 20, Chapter 20. |
Evolutionary-prototyping lifecycle model | Best practice. See Chapter 21, Chapter 21. |
Feature-set control | Best philosophy. See Chapter 14, "Feature- Set Control." |
Goal setting | Best practice discussed within another chapter. See Goal setting in Using the Top Five Motivation Factors and summary in Chapter 22. |
Hiring top talent | Fundamental. See People in Four Dimensions of Development Speed. |
Information engineering | Insufficient evidence for practice's efficacy. |
Inspections | Fundamental. Best practice discussed within another chapter. See Inspections in Quality-Assurance Fundamentals and summary in Chapter 23. |
Integration strategies | Fundamental. |
Joint Application Development (JAD) | Best practice. See Chapter 24, Chapter 24. |
Joint Requirements Planning (JRP) | Not a best practice. See JAD Planning in Using JAD. |
Leadership | Fundamental. |
Lifecycle model selection | Best practice discussed within another chapter. See Chapter 7, Chapter 7, and summary in Chapter 25. |
Measurement | Best practice. See Chapter 26, Chapter 26. |
Meetings, efficient | Fundamental. |
Milestones, major | Not a best practice. See Major Milestones sidebar on Using Miniature Milestones. |
Milestones, miniature | Best practice. See Chapter 27, Chapter 27. |
Minimal specification | Not a best practice. See Minimal Specification in Early Project: Feature-Set Reduction. |
Motivation | Best philosophy. See Chapter 11, Chapter 11. |
Object technology | Fundamental. See Technical Fundamentals, Technical Fundamentals. |
Outsourcing | Best practice. See Chapter 28, Chapter 28. |
Overtime, excessive | Not a best practice. See Organization of Best-Practice Chapters, Using Voluntary Overtime. |
Overtime, voluntary | Best practice. See Chapter 43, Chapter 43. |
Parallel development | Fundamental. |
Planning tools, automated | Fundamental. |
Planning, effective | Fundamental. |
Principled negotiation | Best practice discussed within another chapter. See Beating Schedule Pressure, Beating Schedule Pressure, and summary in Chapter 29. |
Process improvement | Best philosophy. See Process in Four Dimensions of Development Speed and Chapter 26, Chapter 26. |
Productivity environments | Best practice. See Chapter 30, Chapter 30. |
Productivity tools | Best philosophy. See Chapter 15, Chapter 15. |
Quality assurance | Fundamental. |
Rapid Application Development (RAD) | Combination of best practices—not a best practice itself. |
Rapid-development languages (RDLs) | Best practice. See Chapter 31, "Chapter 31. |
Requirements analysis | Fundamental. |
Requirements scrubbing | Best practice discussed within another chapter. See Requirements Scrubbing in Early Project: Feature-Set Reduction and summary in Chapter 32. |
Reuse | Best practice. See Chapter 33, Chapter 33. |
Reviews, walk-throughs, and code reading | Fundamental. |
Risk management | |
Scheduling tools, automated | Fundamental. |
SEI CMM Levels | Best philosophy. See Process in Four Dimensions of Development Speed and Further Reading in Chapter 2. |
Signing up | Best practice. See Chapter 34, Chapter 34. |
Software configuration management (SCM) | Fundamental. |
Software engineering process group (SEPG) | Best practice. Considerations involved are very similar to those in setting up a tools group. See Tools group in Productivity-Tool Acquisition and summary in Chapter 40. |
Source code control | Fundamental. |
Spiral lifecycle model | Best practice discussed within another chapter. See Spiral, Spiral, and summary in Chapter 35. |
Staff specialization | Best practice. See Chapter 13, Chapter 13. |
Staffing levels (how much and when to add) | Fundamental. |
Staged-delivery lifecycle model | Best practice. See Chapter 36, Chapter 36. |
Structured programming | Fundamental. |
Team structure | Best philosophy. See Chapter 13, Chapter 13. |
Teamwork | Best philosophy. See Chapter 12, Chapter 12. |
Testing | Fundamental. |
Theory-W management | Best practice. See Chapter 37, Chapter 37. |
Throwaway prototyping | Best practice. See Chapter 38, Chapter 38. |
Timebox development | Best practice. See Chapter 39, Chapter 39. |
Tools group | Best practice discussed within another chapter. See Tools group in Productivity-Tool Acquisition and summary in Chapter 40. |
Top-10 risks list | Best practice discussed within another chapter. See Top-10 Risks List in Risk Control and summary in Chapter 41. |
Tracking | Fundamental. |
User-interface prototyping | Best practice. See Chapter 42, Chapter 42. |
Win-win negotiating | See Chapter 29, Chapter 29. |
18.223.195.29