Iterative development and incremental development

"Iteration" and "increment" are two important concepts in agile software development. By figuring out the "iteration" and "increment" and their basis, we can follow the rules in actual operations.

Why iteration?

Why should we implement iterative development? You must have encountered this situation:
"We know what we want. But can you estimate how long it will take to build it ?"
"Before starting development, we must clarify these requirements ."
"Customers don't know what they want"
"Customers often change their minds"

"I
Although I don't know what the customer wants, I know how to get it ." How can we get what the customer wants? -- Iteration! We don't expect that the software we build is exactly what customers (or users) want, But we
You can build and modify the software, and find the software that is suitable for the customer (User) through multiple iterations. Of course, we must ensure that the solution we first determined is correct and feasible, so the subsequent iterations are repeated refinement.
The process is to constantly improve the alternatives and select a better solution. It is to replace the previously barely feasible solution with a better solution.

Basis of iteration

The iterative development process is the process of constantly refining software functions. Therefore, the basis of iteration is the "functional refinement principle": necessity-> flexibility-> Security-> Comfort/interest.

Necessity: The minimum features that support users to complete tasks;

Flexibility: allows you to complete tasks in multiple ways or to make additional options;

Security: to avoid mistakes made by users and ensure the security features of users' operations during software use;

Comfort/Fun: it is a feature that enables users to complete tasks in a simpler, faster, and more interesting way.

Each iteration may contain multiple user stories, but in the same iteration, we develop different levels of perfection for each user story. As shown in:

With
With the in-depth development of software, we will find in every user story that more functions may be comfort/fun, or necessary functions. Or, in the process of software development, competition
The competitor's software products have new features, new feedback on market sales, and new demands from users, we need to constantly enrich and refine the user stories supported by our software to add/improve new features.
After multiple iterations, we can complete all the functions, from multiple layers (necessity, flexibility, security, comfort/Fun) to meet user needs and support user stories.

In the iteration process, the uncertainty of the function is gradually reduced, and our description of the function is becoming clearer and clearer.

Why incremental?

No matter which type of software, once its business goals or user goals are determined, we will prepare an "ideal" solution and implementation means for this. However, the project duration is limited and the budget is
There are also a number, and there is no way to increase manpower without limit. Why is the project duration always short? Capital shortage? Insufficient manpower? Because our "ideal" solutions are costly! In addition, the "ideal" SOLUTION
There are also great risks in the solution: during the implementation of such a long "perfect" solution, external factors such as market conditions and user needs will change; not released in time, not immediately reversed from the market/users
Feedback, our "ideal" Liberation solution cannot be verified if it is really perfect. If iterative development is designed to cope with uncertainties in software products, then the incremental release of software products is
Other uncertainties beyond software products should be addressed.

Incremental basis

Since the incremental release of software products is to cope with uncertainties beyond the software products, we determine the incremental release process, that is, the project risk control process. When determining the version plan, we
What kind of scale is used? The consideration is too rough, so our version planning will not be too accurate, and there will be a large risk in the project implementation process; "Then let's think about it more ", we have to consider this very well.
It will certainly take too much time in planning. Where is the "degree? The first thing we will think of is to sort the priority of the function, and then, depending on the situation, by the end of the project period
We can deliver as much as we can. Yes, most of our software projects are so dead that we will give them a memorial service on the product release day!

Press
Is there anything wrong with importance? Let's make an analogy. We want to build a car. First, sort the car's functional items: Engine, chassis, drive shaft, wheel, brake, steering wheel ....... Fans and friends
A longer and more detailed list of vehicle functions sorted by priority is displayed. With a half-year construction period, we built an engine in the first month. It was a very good and powerful engine. In the second month, we not only took the vehicle chassis as planned
Well, we have another week. We can get the drive shaft in advance ...... (Black and white text on the TV screen fade in and out a few words "4 months later ......") We are about to deliver our car in one month. I
Why are their car wheels not good? The steering wheel didn't turn around either. By the way, there was still a windshield, the door was not equipped with a handle, and the steering lights were bright, but the four of them were bright together ...... Now, the delivery period for half a year is up
. Our desired car is ready for the factory: Awesome streamlined, powerful engine power, 4-wheel drive, XYZ security system, however, But, yesterday, I said that the installed windscreen was not safe:
You have time to get a piece of plastic cloth before the acceptance! Presumably, such a "pull Wind" car will be killed by the boss and the customer.

Now
Now, I have a bit of understanding. Do you feel it? Yes, we can do things according to the importance level. However, before all the necessary functions are implemented, no one pays for any important functions you have implemented.
Value. This is also a common problem in software requirements: There are many functional considerations, high priority levels, and detailed descriptions of each function. However, each function is isolated from each other and is not systematic,
There is even a lack of many necessary functions. Therefore, the users of our software products have gone crazy. This has also led to the "reflection" of many boring people who are worried about the problems: "Is Science and Technology Innovation truly changed?
It improves human life ". (Shanzai, shanzai, I accidentally mentioned the unlucky character "Brick House)

Planning
In the first version, we must implement all the "necessity" functions. Otherwise, our software cannot reflect the bid value. In each subsequent version, we should refer to the "function refinement principle ",
This allows all features of our software products to achieve the same user experience level. (We will introduce the "Realm" of user experience in detail in the UCD idea.) If the user body of each function in each version
The "Realm" is inconsistent, and it is easy to see "a luxury Mercedes-Benz car with a plastic cloth as the windshield ". We can use the "version map" shown in to demonstrate the basis for incremental release of software products-version Calculation
Stroke.

Of course, we will also find new market/user requirements and new user stories after completing the previous software version. The incremental version release process is shown in:

Summary: iteration vs. Increment

To thoroughly understand "iteration" and "increment", we 'd better compare them.

Iteration is the process of repeatedly improving each function of the software. It is the process of improving the software quality, from fuzzy to clear, it means that when different versions of software are released, a little more is released each time. This is the process of increasing the number of software functions. For example:

This entry was posted on Sunday, July 26 th, 2009
And is filed under agile, guiding ideology. You can follow any responses
To this entry through the RSS 2.0 feed. You can leave
A response, or trackback from your own site.