Agile Software Development (excerpt)

Document directory

• Agile principles
• About agile practice (Paul oldfield)
• Extreme Programming
• Effective Practice of Extreme Programming

What is agile software development?

Agile Software development is a conceptual framework for processing software engineering projects.Embrace and promoteDuring the entire project lifecycleEvolutionChange. Agile Software development is a conceptual framework for undertaking software engineering projects that embraces and promotes evolutionary change throughout the entire life-cycle of the project. (Wikipedia) Pay attention to the following three keywords: during the entire project lifecycle: this involves three main fields and processes: Agile Project Management, agile requirement acquisition, and agile software development in a narrow sense. Note that these three processes are not separated from each other, but you have me and I have you. Embrace and promote change: The only thing that remains unchanged in the world is change. Indifference, denial, and resistance to changes in any field are not a rational and serious attitude. Learn how to identify the major trend of change and, when possible, make changes better. This is the correct response to changes. Evolution mode: although it mentioned above to Promote the Development of changes, the software evolution process, I believe, has its own internal logic, there are some fundamental rules and guidelines; it is not completely dominated by subjective consciousness. I think it is a precise summary and guidance of the above two points.

Agile Software Development Declaration

Manifesto for Agile Software Development has four core values: change, which constitute the core values of Agile Project Management: we are uncovering better ways of developing software by doing it and helping others do it. through this work we have come to value: ☆Individuals and interactionsOver processes and tools☆Working SoftwareOver comprehensive documentation☆Customer collaborationOver contract negotiation☆Responding to changeOver following a planThat is, while there is value in the items on the right, we value the items on the left more. we are exploring ways to better develop software through practice and helping others practice. The values we obtained from practice are: ☆Human and InteractionFocuses on processes and tools.☆Software that can workFocuses on All-Around documents.☆Customer cooperationOver contract negotiation.☆Respond to changes at any timeMore than regular. Through practice and helping others practice, we can discover better [product] development methods. Through the above work, we form the following values: ☆Communication between people is better than process and Tool☆Commitment to [products] is better than preparing comprehensive documents☆Collaboration with customers is better than contract negotiation☆Adapting to changes is better than following the planThat is to say, although the entries on the right are valuable, we pay more attention to the entries on the left.

Debate on the "Agile Software Development Declaration"

Simon baker's idea is that some concepts in the agile Declaration are hard to understand by the business community. If some concepts in lean development (such as the pursuit of excellence, understanding and eliminating waste, overall Optimization and queuing theory) can be solved by joining the agile declaration. Brian Marick then gave the four concepts missing in the Declaration:Skills,Discipline,ComfortAndHappy. This is not "another type of agile ". This is actually a work room. By watching me work with Chet, people can learn agile in special ways and be interested in it. We believe that a complete software development process should include excellent development skills and strict discipline constraints, at the same time, we also need everyone to devote all their efforts in a relaxed environment-this is what we call "Fashion elegance ". Our plan is to help people understand our goals and accomplish their goals, and allow them to determine whether this method is applicable to their own development processes through full hands-on experience. (Ron Jeffries and Chet Hendrickson) Jason Yip's point of view is opposite. He gave a concise and funny version after the refactoring declaration:

• Let's talk to each other
• Let's build software for you to see
• Let us trust each other
• Let us respond to what is happening and what we have learned

Petit concluded: " A shortcut is the farthest route between two points ."It seems that the abandoned agile implementation is even worse than the complete process it wants to replace. The following agile principles constitute the basis of the agile Declaration and are also the source of best practices. 1. Our primary goal is to meet the customer's needs through continuous delivery of valuable software earlier. 2. Welcome demand changes, even in the late stages of project development. The agile process adapts to the changing characteristics, making the customer more competitive. 3. Frequent delivery of software that can work, from weeks to months, has a greater advantage in a shorter delivery cycle. 4. business personnel and developers must work together on a daily basis during the project process. 5. Mobilize personal enthusiasm, give them the environment and support they need, and trust them in their ability to complete their tasks. 6. Face-to-face conversations are the most effective and efficient way to transmit information between and within a project group. 7. Workable software is the main basis for measuring project progress. 8. The agile process advocates that development is a continuous process. The project organizer, developers, and customers should maintain stable project progress. 9. continuous optimization of technology and design, so that the project has higher agility. 10. it is a basic principle to simplify and not do the work that is not needed at present. 11. the best architecture, the best requirements and design come from self-organized teams .. 12. The project team should summarize and review regularly, think about how to make the team more effective, and make appropriate adjustments.

What is agility? (Ivar jacbson)

Agility is about the following three things: 1. Most importantly, agility is a social engineering. This is the biggest feature of agility. It focuses on how to work in the form of a team, how to motivate team members, and how to cooperate with each other. 2. agility is lightweight. RUP relies entirely on explicit knowledge. In contrast, agility also relies on tacit knowledge. In RUP, we try to record what we think is the best practice. However, if people do not read any books about the development process, writing these books is meaningless. On the contrary, agility believes that as long as there are people with sufficient knowledge, they can develop excellent software. Of course, this point of view has been questioned, but it is true. 3. agile provides technical practices. This is actually the weakest contribution of agility. The technical practices it provides hardly include new technologies. Both iterative and incremental development have long existed. User stories are some special types of simplified use cases. The most interesting new idea is test-driven development. I am not saying that agile technology practices are of no value, but simply emphasizing that if it is just such content, we will not be so obsessed with agility. As you can see, software engineering and agility grasp different aspects of software development. The strength of software engineering lies in technical practice, while the advantage of agility lies in social engineering. Therefore, they complement each other. Software Engineering is like a tight-fitting outfit, and agile is very lightweight, but it is more difficult to control. The question is whether we can extract the essence from both worlds. Of course, we can! In the end, the software engineering camp has a series of technical practices, and different agile methods also have some slightly repeated practices. So can we find the way they coexist? Of course, we can! To do this, we must look at practice with new ideas. We will not talk about the process any more. Practice has been replaced and become a first-class citizen. The process is only a combination of practices. With regard to agile practices (Paul oldfield), I often encounter people who do not distinguish manufacturing from software development. They see best practices and highly automated production processes, and want to apply it in software development. I will not mention their names here. I have encountered a situation in which wages are paid by time and raw materials, and the profits are related to the number of people. Here, efficiency means that profits are reduced, in addition, the customer will not acknowledge the improvement in efficiency until they accept the fact that they no longer need so many workers. Sometimes I think of some practices that challenge my world view when I first came into contact with agile practices. Fortunately, my philosophy makes me happy to explore the part that challenges my world view. If I make a mistake on these issues, what if others are right. Each challenge begins with a new religion, but exploring will break the blind belief. As far as I can see, most people choose opinions that conform to their existing ideas. They accept or reject new ideas in almost religious ways. They may make some superficial reasoning, but they think it is a waste of time to make a detailed argument. This applies to the agile blind receiver and the destroyed hacker. Emergent architecture is part of what I initially thought was not in line with my world view. In the end, I found that the author suggested what I did during the last seven years of my research project. In this project, emergent architecture gradually becomes a molding solution. Of course, compared with the past, agile advocates have put forward more procedures. Application procedures will inevitably affect flexibility because they are much less innovative in modern systems than in the past. The procedures created by agile advocates are completely different from non-manufacturing perspectives, so they still maintain flexibility. It took me a long time to understand that no agile practice can work independently from other practices. Before trying to understand how a certain practice can guide development, I need to have a clear understanding of the global situation. Extreme Programming (XP) is one of the agile methods. Four core values of extreme programming are worth noting in development: communication, simplicity, feedback, and courage ). Effective Practice of extreme programming 1. All participants of the entire team's XP Project (developers, customers, testers, etc.) work together in an open place, they are members of the same team. The walls of the place are displayed with large, notable charts and other things that show their progress. 2. Plan a continuous and gradual game plan. 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. 3. The customer test is part of the selection of each desired feature. The customer can define an automatic acceptance test based on the script language to indicate that the feature can work. 4. The simple design team ensures 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. 5. Pair programming all product software is built by two programmers sitting side by side on the same machine. 6. Test-driven development unit testing is a verification and design behavior. Similarly, it is a kind of document writing behavior. Writing Unit Tests avoids a considerable number of feedback loops, especially feedback loops for functional verification. Programmers work in a very short cycle. They first add a failed test and then make it pass. 7. Improved Design: Use refactoring Methods to Improve corrupted code at any time to keep the code as clean and expressive as possible. 8. The continuous integration team always makes the system fully integrated. After a person pulls a check in, the other owner is responsible for code integration. 9. collective code ownership any paired programmer can improve any code at any time. No programmer is solely responsible for any specific module or technology, and everyone can participate in any other development. 10. All the code in the coding standard system looks like it was written by a single person. 11. metaphor is a global view that connects the entire system. It is the future image of the system and makes the position and appearance of all individual modules obviously intuitive. If the appearance of a module does not match the entire metaphor, you will know that the module is incorrect. 12. A sustainable speed team can only have the hope to win if it persists. They work hard at a speed that can be maintained for a long time. They save their energy and think of projects as marathon, rather than full-speed sprints.