Agile Software Development

1,
Agile Software Development Declaration

We are exploring better software development methods through hands-on practices and helping others. Through this work, we think:

Individuals and interactions are superior to processes and projects.

Software that can work is better than comprehensive documents.

Customer cooperation is better than contract negotiation.

Responding to changes is better than following the plan.

Although the right item is also valuable, we believe that the Left item has greater value.

 

2,
Principles observed in the agile Declaration

We follow the following principles:

L
Our top priority is to satisfy our customers by delivering valuable software as soon as possible and continuously.

L
Even after development, you are welcome to change your requirements. Agile processes use changes to create competitive advantages for customers.

L
The software that can work is delivered on a regular basis. The delivery interval can be from several weeks to several months. The shorter the delivery interval, the better.

L
During the entire project development, business personnel and developers must work together every day.

L
Build projects around motivated individuals. Provide them with the required environment and support, and trust them to complete their work.

L
In the Team, the most effective and efficient way to transmit information is face-to-face conversations.

L
The software used for work is the primary progress measurement standard.

L
The agile process advocates sustainable development speed. Owners, developers, and users should be able to maintain a long-term and constant development speed.

L
Constantly paying attention to excellent skills and good design will enhance agility.

L
Simplicity-the art of maximizing unfinished work-is fundamental.

L
The best frameworks, requirements, and designs come from self-organized teams.

L
At a certain time, the team will reflect on how to work more effectively, and then adjust their behaviors accordingly.

 

3,
Object-Oriented Design Principles

3.1
SRP-single responsibility principle, single Responsibility Principle

For a class, there should be only one reason for its change.

 

3.2
OCP-Open-Close principle, open-
Close Principle

Software entities (classes, modules, functions, etc.) should be extensible, but cannot be modified.

 

3.3
LSP -- liskov replacement principle, liskov substitution principle

Child types must be able to replace their base types.

 

3.4
Dip -- Dependency inversion principle, dependence inversion principle

Abstraction should not depend on details. Details should depend on abstraction.

 

3.5
ISP-interface isolation principle, interface separate Principle

Customers should not be forced to rely on methods they do not need.

An interface belongs to a customer and does not belong to its class hierarchy.

 

3.6
Rep -- reuse release Equivalence Principle

The granularity of reuse is the publishing granularity.

 

3.7
CCP-Principle of Joint Closure

All classes in the package should be closed for changes to the same class nature. If a change affects a package, it will affect all classes in the package, without affecting other packages.

 

3.8
CRP-principle of joint Reuse

All classes in a package should be reused together. If a class in the package is reused, all classes in the package must be reused.

 

3.9
ADP-no-environment dependency Principle

The package dependency graph does not allow loops.

 

3.10
SDP-Principle of stable dependency

Dependency in a stable direction.

 

3.11
SAP-Principles of stable Abstraction

The abstraction level of the package should be consistent with its stability.

 

4,
Extreme programming practices

4.1
Complete team

All participants of the XP Project (developers, business analysts, testers, etc.) work together in an open place where they are members of the same team. The walls of the place are displayed with a large number of notable charts and other things that show their progress.

 

4.2
Plan game

The plan is continuous and gradual. Every two weeks, developers estimate the cost of candidate features for the next two weeks, while customers choose the features to be implemented based on the cost and business value.

 

4.3
Customer Test

As part of selecting each desired feature, the customer defines an automatic acceptance test to indicate that the feature can work.

 

4.4
Simple Design

The Team maintains that the design exactly matches the current system functions. It passes all tests and does not contain any duplicates. It expresses everything the author wants to express and contains as few code as possible.

 

4.5
Pair Programming

All product software is built by two programmers sitting side by side on the same machine.

 

4.6
Test-driven development

Programmers work in a very short cycle. They first add a failed test and then make it pass.

 

4.7
Improved Design

Improve bad code at any time. Keep the code as clean and expressive as possible.

 

4.8
Continuous Integration

The team always makes the system fully integrated.

 

4.9
Collective code ownership

Any paired programmer can improve any code during the task.

 

4.10
Encoding standard

All the code in the system looks like being unique.
-- Very competent -- compiled by people.

 

4.11
Metaphor

The team proposed a public picture of how the program works.

 

4.12
Sustainable speed

The team can only achieve the hope of persistence. They work hard at a rate that can be maintained for a long time. They save their energy and think of the project as a marathon, not a full-speed sprint.