Managing the Risks of the Daily Build and Smoke Test
by Steve McConnell
Rapid Development: Taming Wild Software Schedules
- 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
The daily-build process has few drawbacks. Here is the main one.
CROSS-REFERENCE
The problems of premature releases are related to the problems of premature convergence discussed in "Premature convergence" in Overly Optimistic Scheduling.
Tendency toward premature releases. When people outside the development group see that the product is being built every day, pressure mounts to create frequent releases for outside groups. Creating external releases can look easy to a product manager, and it is easier than when you're not using daily builds, but it still sucks up developers' time in subtle ways:
Developers spend time preparing materials that are not needed for the final product but that are needed to support the release. These materials include documentation, interim versions of features still under development, stubbing out hazardous areas of the product, hiding debugging aids, and so on.
Developers make quick fixes so that features will work for a particular release rather than waiting until they can make more careful changes. These quick fixes eventually break, and the developers then have to make the more careful changes that they should have made in the first place. The net effect is that the developers waste time fixing the same code twice.
Developers spend more time responding to minor problems on an ad hoc basis early in the development cycle, problems that could be taken care of more efficiently as part of the developers' normal work cycle.
You wouldn't want to eliminate interim releases entirely. What you can do is to plan for a specific number of interim releases and then try not to increase that number.
-
No Comment