- Rapid Development: Taming Wild Software Schedules
- Preface
- I. EFFICIENT DEVELOPMENT
- 1. Welcome to Rapid Development
- 2. Rapid-Development Strategy
- 3. Classic Mistakes
- 4. Software-Development Fundamentals
- 5. Risk Management
- II. RAPID DEVELOPMENT
- 6. Core Issues in Rapid Development
- 7. Lifecycle Planning
- 8. Estimation
- The Software-Estimation Story
- Estimation-Process Overview
- Size Estimation
- Effort Estimation
- Schedule Estimation
- Estimate Refinement
- Further Reading
- 9. Scheduling
- 10. Customer-Oriented Development
- 11. Motivation
- 12. Teamwork
- Software Uses of Teamwork
- Teamwork's Importance to Rapid Development
- Creating a High-Performance Team
- Shared, Elevating Vision or Goal
- Sense of Team Identity
- Results-Driven Structure
- Competent Team Members
- Commitment to the Team
- Mutual Trust
- Interdependence Among Members
- Effective Communication
- Sense of Autonomy
- Sense of Empowerment
- Small Team Size
- High Level of Enjoyment
- How to Manage a High-Performance Team
- Why Teams Fail
- Long-Term Teambuilding
- Summary of Teamwork Guidelines
- Further Reading
- 13. Team Structure
- 14. Feature-Set Control
- 15. Productivity Tools
- 16. Project Recovery
- III. BEST PRACTICES
- Introduction to Best Practices
- 17. Change Board
- 18. Daily Build and Smoke Test
- Using the Daily Build and Smoke Test
- Managing the Risks of the Daily Build and Smoke Test
- Side Effects of the Daily Build and Smoke Test
- The Daily Build and Smoke Test's Interactions with Other Practices
- The Bottom Line on the Daily Build and Smoke Test
- Keys to Success in Using the Daily Build and Smoke Test
- Further Reading
- 19. Designing for Change
- 20. Evolutionary Delivery
- 21. Evolutionary Prototyping
- 22. Goal Setting
- 23. Inspections
- 24. Joint Application Development (JAD)
- 25. Lifecycle Model Selection
- 26. Measurement
- 27. Miniature Milestones
- 28. Outsourcing
- 29. Principled Negotiation
- 30. Productivity Environments
- 31. Rapid-Development Languages (RDLs)
- 32. Requirements Scrubbing
- 33. Reuse
- 34. Signing Up
- 35. Spiral Lifecycle Model
- 36. Staged Delivery
- 37. Theory-W Management
- 38. Throwaway Prototyping
- 39. Timebox Development
- 40. Tools Group
- 41. Top-10 Risks List
- 42. User-Interface Prototyping
- Using User-Interface Prototyping
- Managing the Risks of User-Interface Prototyping
- Side Effects of User-Interface Prototyping
- User-Interface Prototyping's Interactions with Other Practices
- The Bottom Line on User-Interface Prototyping
- Keys to Success in Using User-Interface Prototyping
- Further Reading
- 43. Voluntary Overtime
- A. Bibliography
- Index
Evolutionary delivery is a lifecycle model that straddles the ground between evolutionary prototyping and staged delivery. You develop a version of your product, show it to your customer, and refine the product based on customer feedback. How much evolutionary delivery looks like evolutionary prototyping really depends on the extent to which you plan to accommodate customer requests. If you plan to accommodate most requests, evolutionary delivery will look a lot like evolutionary prototyping. If you plan to accommodate few change requests, evolutionary delivery will look a lot like staged delivery. Figure 7-11 illustrates how the process works.
Figure 7-11. The evolutionary-delivery model. This model draws from the control you get with staged delivery and the flexibility you get with evolutionary prototyping. You can tailor it to provide as much control or flexibility as you need.
The main differences between evolutionary prototyping and evolutionary delivery are more differences in emphasis than in fundamental approach. In evolutionary prototyping, your initial emphasis is on the visible aspects of the system; you go back later and plug up holes in the system's foundation.
CROSS-REFERENCE
For details on evolutionary delivery, see Chapter 20, Chapter 20.
In evolutionary delivery, your initial emphasis is on the core of the system, which consists of lower level system functions that are unlikely to be changed by customer feedback.
Incremental Development Practices
The phrase "incremental development practices" refers to development practices that allow a program to be developed and delivered in stages. Incremental practices reduce risk by breaking the project into a series of small subprojects. Completing small subprojects tends to be easier than completing a single monolithic project. Incremental development practices increase progress visibility by providing finished, operational pieces of a system long before you could make the complete system operational. These practices provide a greater ability to make midcourse changes in direction because the system is brought to a shippable state several times during its developmentâyou can use any of the shippable versions as a jumping-off point rather than needing to wait until the very end.
Lifecycle models that support incremental development include the spiral, evolutionary-prototyping, staged-delivery, and evolutionary-delivery models (discussed earlier in this chapter).
-
No Comment