Waterfall development mode
- Strictly divide the development of a software project into various development stages: requirements analysis, definition of elements, basic design, detailed design, coding, unit testing, combination testing, system testing, etc.
Using milestones, the inputs and outputs of each development phase are rigorously defined. If the required output is not met, the next phase of the work is not initiated.
- Focus on and emphasize the process documentation. The software prototype will only be seen in the middle and late stages of development, and the system can only be understood through the documentation early.
In this case, the documentation seems to be more important than the code.
- The waterfall model defines each development phase as a black box and expects people in each phase to only care about the work of their own phase and not the work of other phases.
The benefit is that it allows developers to focus more on their work and improve phase efficiency.
The downside is that:
A. Developers at all stages can only touch things within their work scope, so their understanding of customer needs varies from level to level. Developers are more defined as workers on an assembly line.
B. Coders tend to be more resistant to changes in customer requirements than designers.
C. At each stage of development, there is information that is deliberately kept from the people in other stages of development (the intention is to talk about efficiency, but in fact sometimes there is a mutual understanding bias).
The management documents (plan, schedule) produced by the waterfall model can make people who do not know much about the project understand the progress of the project (only if they can understand the percentage), which is very suitable for reporting to the leader. So managers prefer the waterfall model, but developers don’t, because it restricts developers’ creativity.
Since it’s called a waterfall, it means there should be no turning back. Otherwise, if rework occurs, the price will be very high.
The impact of bugs early in the software life cycle is much greater than later in the software life cycle.
The main reason for the high cost is that the pace of each development stage is too large, and each adjustment may break bones and muscles.
- It is more suitable for large projects with relatively stable demand.
Agile development model:
The core is to iterate quickly and embrace change.
Because the ultimate goal is to satisfy customers, they can take the initiative to accept changes in requirements, which enables the software to be designed with flexibility and scalability.
Individuals and interactions trump processes and tools
Software that works is better than well-written documentation
Customer cooperation trumps contract negotiation
Responding to change over following a plan
Agile development model has the following salient characteristics:
The story refinement.
Keep it simple and avoid overdoing it.
Reduce unnecessary documentation.
The functions that customers care about most should be completed first.
Customers are required to have time to confirm the results of each iteration and put forward suggestions for improvement.
Communication is very important, and all developers should have the same understanding of the project activities. Enhance communication between teams and customers.
Test Driven Development (TDD)
Strong individual and team skills are required.
Agile management is self-management of the team and service-oriented management of the project manager.
Agile development cannot provide a complete cost plan for the project at the beginning.
It is not appropriate to start an iteration when there are technical issues that have not been resolved.
Agile practices: Morning Meetings, Deadlines, Lead Management, etc.