Agile Software Development-agile Declaration

Agile Software Development Declaration
We are working with hands-on and help others to demonstrate better software development methods.
Through this work, we think:
Human and Interaction Over Processes and tools
Software that can work Over all documents
Customer cooperation Over contract negotiation
Respond to changes at any time Over plan
Although the right item is also valuable, we think the left item is more important.

The agile declaration followsPrinciples

We follow the following principles:

• Our top priority is to deliver valuable software as early as possible and continuously to meet customer needs.
• We welcome changes in requirements, even after development. Agile processes can control changes and create competitive advantages for customers.
• Often deliver software that can work, from a few weeks to a few months, the shorter the interval, the better.
• During the entire project development, business personnel and developers must work together overnight.
• Build projects around highly motivated people. Provide them with the required environment and support, and trust them to complete the task.
• Within the team, the most efficient and effective way of communicating information is face-to-face conversations.
• Software that can work is the main metric of progress.
• The agile process advocates continuous development. Investors, developers, and users should always maintain a stable development speed.
• The constant pursuit of superior technologies and good technologies will help increase agility.
• Simplicity-the art of minimizing workload is crucial.
• The best architecture, requirements, and design are all from self-organized teams.
• At regular intervals, the team should summarize how to be more efficient and then adjust their behaviors accordingly.

Agile Software Development Declaration

1. Individuals and interactions are better than processes and tools
people are the most important factors for success. If there are no good members in the team, the good process cannot save the project from failure. However, the bad process can make the best team members lose their utility. If you cannot work as a team, even a group of outstanding members will be defeated. A good team member may not be a one-stream Program member. A good team member may be an average programmer, but can work well with others. Cooperation, communication, and interaction are more important than pure programming skills. A team composed of average-level programmers, with good communication skills, is more likely to succeed than a team that has a group of high-level programmers but cannot communicate with each other. Appropriate tools are very important for success. Such as compilers, ides, and Source Code control systems, it is essential for Team developers to correctly complete their work. However, the role of the tool may be exaggerated. It is not good to use too many large and bulky tools, just like a lack of tools. We recommend that you try a tool from using it until it is found to be unavailable. It is not a rush to purchase an advanced and expensive source Code control system, instead, use a free system until it proves that the system is no longer applicable. Before deciding to buy the best case tool license for the team, use the whiteboard and square sheet until there is enough reason to indicate that more features are needed. Before deciding to use a large, high-performance database system, use flat file ). Do not think that bigger and better tools can automatically help you do better. In general, they cause more obstacles than they do. Remember, team building is much more important than environment building. Many teams and managers have made the mistake of building the environment first and then expecting the team to automatically join together. Instead, we should first build a team and then let the team configure the environment as needed.

2. software that can work better than all-around documents
software without documents is a disaster. Code is not an ideal medium for conveying system principles and structures. The team needs to prepare easy-to-read documents to describe the basis for the system and its design decisions. However, too many documents are worse than too few documents. It takes a lot of time to compile a large number of documents, and it takes more time to synchronize these documents and code. If the synchronization between the document and the code is lost, the document will become a huge and complex lie, which will cause major misleading. For the team, it would always be a good idea to write and maintain a document on the system principles and structure, but that document should be short (short) and featured (salient ). "Short" means a maximum of 10 or 20 pages. The topic highlights the system's high-level structure and general design principles. If all we have is a brief document on system principles and structures, how can we train new team members to engage in system-related work? We will work very closely with them. We sat down next to them to help them and pass on our knowledge to them. We make them part of the team through close-up training and interaction. The best two documents for new team members are code and team. The Code actually expresses what it does. Although extracting system principles and structure information from code may be difficult, code is the only information source without ambiguity. In the minds of team members, the road map of the ever-changing system is saved ). Interactions between people are the fastest and most effective way to pass on the context map to others.
many teams are delayed due to focusing on documents rather than software. This is often a fatal defect. There is a simple rule called "Martin's first law of document" that can prevent the occurrence of this defect: The document is prepared until it is urgently needed and significant.

3. Customer cooperation is better than contract negotiation
software cannot be ordered like daily necessities. You cannot just write down a description of the software you want, and then let people develop it at a fixed price within a fixed period of time. All attempts to treat software projects in this way end with failures. Sometimes, failure is heavy. Tell the development team what they want and expect the development team to deliver a system that meets the needs after it disappears for a while, which is tempting for the company's managers. However, this operation mode will lead to poor quality and failure. Successful projects require ordered and frequent customer feedback. Instead of relying on contracts or statement about work, it allows software customers and development teams to work closely together and provide feedback as often as possible. A contract that specifies the requirement, progress, and project cost has fundamental defects. In most cases, the terms specified in the contract become meaningless long before the project is completed. ① Contracts that provide guidance for the collaborative work between the development team and the customer are the best contracts. In 1994, I made a contract for a large project that took years to complete and had 0.5 million lines of code. It can be used as an example of a successful contract. As a development team, our monthly payment is relatively low. Most of the payment is made only after we deliver some large functional blocks. The functional blocks are not specified in detail in the contract. The contract only claims that a feature block is paid when it passes the customer's acceptance test. The Acceptance Test details are not specified in the contract. We work closely with our customers during the development of this project. We submit software to customers almost every Friday. By Monday or Tuesday of the next week, the customer will give us a list of software changes. We will put these changes together to prioritize them and arrange them in the work of the next few weeks. The customer works closely with us so that
acceptance testing is not a problem at all. Because they observe the evolution of each feature block weekly and weekly, they know when this feature block can meet their needs. The requirements of this project are basically changing. Large changes are common. During this period, the entire function block will also be removed, and some other functional blocks will be added. However, both the contract and project have withstood these changes and succeeded. The key to success lies in the sincere collaboration with the customer, and the contract guides this collaboration, rather than trying to specify the details of the project scope and the progress at a fixed cost.

4. Responding to changes is better than following the plan
The ability to respond to changes often determines the success or failure of a software project. When building a plan, we should ensure that the plan is flexible and easy to adapt to business and technical changes. The plan cannot be considered too far. First, the business environment is likely to change, which will lead to changes in demand. Second, once the customer sees the system starting to operate, they are likely to change their needs. Finally, even if we are familiar with the requirements and are sure they will not change, we still cannot well estimate the time needed to develop them. For an inexperienced manager, it is tempting to create a beautiful pert or Gantt graph and paste it on the wall. They may think that this figure gives them the right to control the entire project. They can track individual tasks and remove them from the graph when the task is completed. They can compare the actual completion date with the planned completion date and respond to any deviations that occur. What actually happens is that the organizational structure of this image is no longer applicable. When the team increases their understanding of the system and the customer increases their understanding of the requirements, some tasks in the figure become dispensable. Other tasks will be discovered and added to the figure. In short, the plan will be changed on the shape, not just on the date. The best 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 rough plan in the future. We should clearly understand the tasks to be completed in the next two weeks, and roughly understand the requirements for implementation in the next three months. There is a vague idea about what the system will do in a year. This gradually reduced level of detail in the plan means that we only need to make detailed plans for urgent tasks. Once this detailed plan is developed, it is very difficult to make changes, because the team will start the work according to the plan and have the corresponding investment. However, since the plan takes only a few weeks, the rest of the plan is still flexible.

Principles observed in the agile Declaration

The following 12 principles are introduced from the above values, which are the characteristics of agile practices that are different from heavy processes.
1. Our top priority is to satisfy our customers by delivering valuable software as soon as possible and continuously.. MIT Sloan Management comment published a paper that analyzes software development practices that help companies build high-quality products. This paper finds many practices that have an important impact on the final system quality. One practice shows that early delivery of Systems with some features is highly correlated with system quality. This paper points out that the fewer functions contained in the initial delivery system, the higher the quality of the final delivery system. Another discovery in this article is that there is a strong correlation between the delivery of the system and the final quality on a regular basis in a way that gradually increases functionality. The more frequent the delivery, the higher the quality of the final product.
Agile practices will be delivered as soon as possible and frequently. We strive to deliver a system with basic functions within the first few weeks of the project. Then, we strive to deliver a function increasing system every two weeks. If the customer thinks that the current function is sufficient, the customer can choose to add these systems to the product. Alternatively, they can simply check the existing features and point out the changes they want to make.

2. We welcome changes in requirements, even after development. Agile processes can control changes and create competitive advantages for customers.This is a statement about attitude. Participants in Agile processes are not afraid of changes. They think changing needs is a good thing, because those changes mean that the Team has learned a lot about how to meet market needs.
The agile team will work very hard to maintain the flexibility of the software structure, so that when the demand changes, the impact on the system is minimal. Later in this book, we will learn some object-oriented design principles and patterns that will help us maintain this flexibility.

3. The software can be delivered on a regular basis. The delivery interval can be from several weeks to several months. The shorter the delivery interval, the better.We deliver software working software that can work, and deliver it as early as possible (a few weeks after the beginning of the project) and regularly (every few weeks thereafter. We do not agree to deliver a large number of documents or plans. We don't think that is what we really want to deliver. Our goal is to deliver software that meets the customer's needs.
4. During the entire project development period, business personnel and developers must work together overnight.In order to be able to develop projects in an agile manner, customers, developers, and stakeholders must have meaningful and frequent interactions. Unlike the weapons that can automatically navigate a software project when it is launched, the software project must be continuously guided.

5. Build projects around highly motivated people.Provide them with the required environment and support, and trust them to complete their work. In agile projects, people are considered to be the most important factor for project success. All other factors ?? Process, environment, management, etc ?? They are considered secondary and must be changed when they have negative effects on people. For example, if the office environment hinders the work of the team, you must change the office environment. If some process steps impede the Team's work, they must be changed.

6. Within the team, the most efficient and effective way to communicate information is face-to-face conversations.In agile projects, people talk to each other. The first way to communicate is to talk. You may write a document but will not attempt to include all project information in the document. Agile teams do not need written standards, written plans, or written designs.Team members can write documents. If the requirements for these documents are urgent and significant, documents are not the default communication method. The default communication mode is conversation.

7. software that can work is the primary progress measurement standard.Agile projects measure the development progress by measuring the number of current software to meet customer needs. They do not measure the development progress based on the development stage, the number of documents that have been written, or the number of created infrastructure code. Only when the 30% feature is required to work can the progress be determined to be completed by 30%.

8. The agile process advocates sustainable development speed. InvestorDevelopers and users should be able to maintain a long-term and constant development speed.The Agile Project is not a 50-meter sprint, but a marathon. Teams do not start at full speed and try to maintain that speed during project development; instead, they travel at a fast but sustainable speed.
If you run too fast, the team may be exhausted, and short-term behavior may lead to a crash. The agile team will measure their own speed. They are not allowed to be exhausted. They will not use the power of tomorrow to finish more work today. They work at a speed that can maintain the highest quality standards throughout project development.

9. The disruptive pursuit of superior technology and good design helps improve agility.High product quality is the key to achieving high development speeds. Keeping Software as concise and robust as possible is a way to develop software quickly. Therefore, all agile team members are committed to writing only the highest quality code they can write. They will not create chaos and tell themselves to clean up when there is more time. If they create chaos today, they will clean up the chaos today.

10. Simplicity-it is essential to minimize the art of work.Agile teams will not try to build those flashy systems. They are always more willing to adopt the simplest method consistent with their goals. They do not focus on predictions about the problems that may arise tomorrow, nor do they defend against those problems today. On the contrary, they complete the simplest work with the highest quality today, and are confident that if there is a problem tomorrow, it will be easy to handle.

11. The best architecture, requirements, and design are all from self-organized teams.Minjie team is a self-organized team. The task is not assigned to a single team member from the external, but to the entire team, and then the team determines the best way to complete the task.
Members of the agile team work together to solve all problems in the project. Each Member has the right to participate in all aspects of the project. There is no single team member responsible for system architecture, requirements, or testing. The responsibilities shared by the entire team can be influenced by each team member.

12. at regular intervals, the team should summarize how to be more efficient and adjust their own behaviors accordingly.The agile team constantly adjusts the organization, rules, specifications, and relationships of the team. The agile team knows that the environment of the team is constantly changing and that to maintain the agility of the team, it must change along with the environment.

Conclusion
Every software developer and every development team's career goal is to deliver the greatest value to their employers and customers. However, our project fails at a frustrating rate or fails to deliver any price value. Although it is out of good intentions to adopt the process method in the project, the expansion process method should be at least responsible for our failure. The principles and values of agile software development constitute a method that can help the team break the expansion cycle of the process. This method focuses on some simple technologies that can achieve the goals of the team.

---- From: Agile Software development principles, models and practices (C # Edition)