- Before development begins
- Somewhere in between
Most developers will immediately choose "Before development begins" for simplicity. However, if you work in an agile environment that responds well to change then there are many advantages to "Never".
Advantages of Changing Requirements
- Changing requirements will improve the product and should give you a competitive advantage.
- Changing requirements will evaluate the efficiencies of your development, QA, and deployment processes. Highly effective or agile teams will deliver the new requirement relatively pain-free.
- Changing requirements encourage automation throughout the lifecycle. The important factor here is that it encourages automation across all departments (development, QA, deployment). The following attributes must exist within each department for this strategy to be successful:
- Automated JUnit tests - frequent changes must be tested efficiently.
- Continuous Integration - frequent changes require stable environments.
- Code reviews - This knowledge transfer session will give your team the flexibility of having anyone work any task more efficiently.
- Automated regression tests - frequent changes must be tested efficiently.
- Automated deployment scripts - simplify and more accurately deploy the changed release modules.
- Software must be delivered faster so the customer's can identify the change points sooner in the lifecycle. The goal is to deliver testable software quicker. How many of you deliver testable code after iteration one? How many of you have customer demos of working software after iteration one? The goal is to identify changes sooner in the lifecycle and this will help minimize the risk of failing to meet your production delivery date.
Disadvantages of Changing Requirements
- Changing requirements may delay the project. This is where the debate typically begins. However, if you initially plan for some percentage of change you should be fine. Identifying change early in the lifecycle will also help remedy the impact.