Agile Software Development Reading notes (i)

The first part of Agile development

At the beginning of 2001, as many of the company's software teams were caught up in the growing process, a group of industry experts gathered together to summarize some of the principles of value that could enable software development teams to work quickly and respond to change. They call themselves the Agile Alliance. In the months that followed, they created a statement of values. The Agile Alliance Manifesto (the Manifesto of the agile Alliance).

The Agile Alliance Manifesto is as follows:

1. individuals and interactions outweigh processes and tools.

People are the most important factor for success. If there are no good members in the team, then it is not the right process to save the project from failure, but the bad process can make the best team members useless. If you cannot work as a team, you will fail even if you have a good group of members.

A team of average programmers who have good communication skills will be more likely to succeed than those who have a high level of programmer, but who cannot communicate with each other.

The right tools are very important for success. However, the role of the tool may be exaggerated. It is not good to use too many bulky, cumbersome tools like a lack of tools.

Team building is much more important than building the environment. You should focus on building your team first, and then configure the environment for your team based on your needs.

2. working software trumps all-encompassing documentation.

Software without documentation is a disaster. Code is not an ideal medium for conveying system principles and structures. However, too many documents are worse than too few documents. Compiling numerous documents takes a lot of time, and it takes more time to keep these documents and code in sync. If there is no synchronization between the document and the code, then the document becomes a huge, complex lie, which can lead to significant misleading.

It is always a good idea for a team to write and maintain a document on the principles and structure of the system, but that document should be short and subject to prominence (salient). "Short" means that there are up to ten or twenty pages. "Subject-prominent" means that only the highest level structure of the system and the principle of design should be discussed.

The best two documents for imparting knowledge to new team members are code and team. The code truly expresses what it does and is the only source of information that has no ambiguity. In the minds of team members, the context diagram of a system that is constantly changing (road map) is preserved. Interaction between people is the quickest and most effective way to impart this context to others.

Martin's first law of document: documentation is not prepared until it is urgently needed and significant.

3. customer cooperation is better than contract negotiation.

You cannot order software as you would order a commodity. You can't just write down a description of the software you want, and then let someone develop it at a fixed price for a fixed period of time. It is tempting for a company's managers to tell the development team what they want and then expect the development team to disappear for a period of time to deliver a system that satisfies the needs. However, this mode of operation will result in poor quality and failure.

A successful project requires an orderly, frequent feedback. Rather than relying on a contract or a statement about a job, let the software's customers and development teams work closely together and provide feedback as often as possible.

The key to the success of the project is a sincere collaboration with the customer, and the contract directs this collaboration, rather than trying to specify the project scope details and the fixed cost of progress.

4. Responding to change is better than following the plan.

The ability to change often determines the success or failure of a software project. When we build a plan, we should ensure that the plan is flexible and easy to adapt to changes in business and technology.

A good strategy for planning is to make a detailed plan for the next two weeks, make a rough plan for the next three months, and then make a very rough plan. We should be aware of the tasks to be completed in the next two weeks, and get a rough look at what needs to be achieved in the coming three months. As for what the system will do after a year, there is a vague idea.

This gradual reduction in the degree of detail in the plan means that we only spend time on detailed plans for urgent tasks. Once this detailed plan is in place, it is difficult to make changes because the team will start work and have a corresponding commitment based on the plan. However, the rest of the plan remained flexible because the plan had only been dominated for a few weeks.

Looking at the four processes above, agile development emphasizes people-centric rather than process-centric, emphasizing as much communication as possible (with customers, with team members), as much as possible with the simplest design to solve problems (and thus be able to embrace change).

So far, there have been a number of agile processes to choose from. Including Scrum,crystal, feature-driven software development (Feature Driven Development, FDD), Adaptive Software Development (Adaptive software Development, ADP), And the most important extreme programming (EXtreme Programming, abbreviated XP).

Agile Software Development Reading notes (i)