敏捷开发之12条敏捷原则（12 agile principles for Agile Development）

敏捷开发之12条敏捷原则（12 agile principles for Agile Development） 敏捷开发之12条敏捷原则(12 agile principles for Agile Development) There are 12 principles in agile development, which are the characteristics of agile practices that differ from heavy processes. Patterns in "Agile Software Practices" (and, DevelopmentPrinciples, Chinese Title: "agile software development: principles, patterns and practices") of these 12 principles are described respectively, I am not here to explain the contents of the book, from my personal understanding to explain these principles, I hope everyone can supplementary insights. 1. our priority is to satisfy our customers by delivering valuable software as early as possible and continuously. When planning iteration stories, you must first provide the most valuable function for the customer according to the priority. Through frequent iterations, we can form good early cooperation with customers, and timely feedback to improve product quality. Agile teams focus on the completion and delivery of user value functions rather than isolated tasks. We used to write detailed requirements using requirements specifications or use cases, and agile used user stories to list requirements. User stories are lightweight techniques that represent requirements, and they have no fixed form and mandatory syntax. However, there are some fixed forms that can be used for reference or are more useful. This template is used in agile estimation: "as a user type, I want to be able to [business value]."". Using user stories based requirements analysis methods may still require prototyping and documentation, but more emphasis is shifted to verbal communication. 2., even after the development of the late, also welcome to change demand. Agile processes use change to create competitive advantage for customers. Agile process participants are not afraid of change. They believe that changing demand is good because these changes mean that we understand market demand better. 3. often deliver software that can work, and the delivery interval can range from a few months to a few months, and the shorter the delivery interval, the better. Iteration is restricted by the practice frame, which means that even if you give up some functions, you must end the iteration on time. As long as we can guarantee the delivery of software can work well, then the shorter the delivery time, the closer we work with customers, the more beneficial to the quality of products. Although we iterate many times, it is not the result of each iteration that needs to be delivered to the user, and the goal of agile development is to enable them to deliver. This means that the development team adds functionality to each iteration, and each of the additional functions is coded and tested to achieve a published quality standard. In addition to the agile development project development stage not what important early stage segmentation, there is no demand, then the analysis stage, architecture design phase, testing phase encoding, the project really started, will be carried out in the stage of all the works in each iteration. 4. during the whole project development, business people and developers must work together every day. The way of software project execution plan will not be in accordance with the set before, the intermediate solution understanding, business software will certainly have deviation, so demand among customers, staff, developers and stakeholders must interact with meaningful, frequent, so you can timely find and solve the problem. 5. build projects around people who are motivated. Provide them with the environment and support they need, and trust them to do the work. Business and technology are two major aspects of uncertainty. People are third aspects. And the business and technology must be implemented by people, so it is the key to solve the uncertainty by motivating people to solve these problems. As long as individual goals and team goals are aligned, we need to inspire everyone's initiative, build personal projects, and provide the environment, support and trust that we need. 6. within the team, the most effective and efficient way to deliver information is to talk face to face. In a large team of more than a dozen or more people, Documentation is a better way to pass on knowledge and communicate. Agile teams don't usually have many people (when teams are agile and are split into smaller agile teams), so a lot of documentation isn't very economical. Face to face conversation is quicker and more effective. 7. software for work is the primary metric of progress. General tasks are easier to measure the progress of a task, such as allowing you to carry 1 tons of stone. I just need to weigh the weight of the stones you've carried, so I know how much you've done. For software, we can't code the number of lines before the software is coded and tested, and how many test cases run to measure whether the function is complete. The primary criterion for determining whether this function is completed is that this function can work and can be applied to the user. 8. agile processes provide sustainable development speed. Responsible people, developers, and users should be able to maintain a constant and constant development speed. Many people think that overtime is normal in software development, and not working overtime is not normal. I don't understand it. This may be caused by national conditions. The agile process wants to be sustainable, and the speed of development does not vary with the task of iteration. It does not appreciate the attitude of "spelling, spelling, and spelling", and development should not be a shock. We cannot expect that this project can easily surprise, because after the completion of a project will come under a project, and as long as the spell or attitude, the next project will let your crew assault again. Then do not know who will say that we have to work overtime, but also "sustainable development", then to the attention of the people continued to work overtime wisdom leads to fatigue, boredom, keep constant speed is just an ideal. 9. constant attention to good skills and good design enhances agility. Agile processes have many good technical practices that can enhance product agility, and many principles, patterns, and practices can also enhance agile development capabilities. Agile software development - principles, patterns, and practices - introduces a number of designs that you can take a closer look at. 10. simplicity - the art of maximizing unfinished work - is fundamental. We can't expect how the requirements will change, so it's impossible to build a perfect architecture from the start to accommodate all future changes. Agile teams don't build tomorrow's software, but focus on the easiest way to complete the problems that need to be solved now. Then someone will say, "I've already predicted what expansion points must exist. Do we need to think about it at the start?" At this point, the team needs to make a decision based on its own understanding. If it is believed that this problem can be easily dealt with tomorrow, then it would be better not to consider it first. 11. the best architectures, requirements, and designs come from self-organizing teams. There are many kinds of practices in agile, and as you all know, iterative development is the primary practice approach, and self organizing teams are one of the main practices. In a self organizing team, managers don't give orders, but let the team find the best way to do it. It is difficult to form a self-organizing team. The first element of a self-organizing team is the need to have a team, not just a group of people, CSDN told Mishkin Berteig. A group of people are a group of people who work together. They don't have much communication with each other, and they don't see each other as one. At the very beginning of the project, we will form a team, but many times a group of architects, developers, developers, and testers are part of it. He also believes that the formation of the team must go through several periods. After an initial break in, members begin to develop a basic understanding and understanding of the team's work philosophy and culture. Rules are gradually formed within the team, And these rules speak for themselves. For example, everyone knows that when he comes to work at nine in the morning, he will ask whether he needs help or not, and he will also take the initiative and discuss the problem with others. If the team member can reach such a tacit understanding, then the team will become a truly efficient work team. In such a team, members understand each other and work very efficiently. In a self organizing team, team members do not need to follow other people's instructions. They need a higher level of guidance, which is more like a goal, a goal of developing better software. In short, a self-organizing team is a team of self - motivated, common - purpose and work - oriented cultures that are always committed to its organization. However, implementing these promises is important for a self-organizing team. Otherwise, if there is a problem, there will be a crisis of confidence among team members. While agile development teams work as a team, it is necessary to point out some roles that take on certain tasks. The first role is the product owner (Product Owner). The main duties of the owner of the product include: confirmation of all members of the team are prospects in the pursuit of a common project, determine the function of priority to be always in the most valuable processing functions, and decision making of project investment can produce good returns. Can be referred to as "product manager" in previous development". Another part is the development team (developer), the developers including architects, designers, programmers, testers, demand personnel, documentation writers, sometimes the product owner can also be seen as developers. Another important role is the project manager (Project Manager). Agile project managers pay more attention to leadership than management. In some projects, the project manager may also be a developer and, at the very least, a product owner. 12., at regular intervals, the team will reflect on how to work more effectively and then adjust their behavior accordingly. As a result of many uncertainties will lead to the failure of the plan, such as changes in the number of members of the project, technical applications, changes in user needs, competitors impact on us, etc., will allow us to respond differently. Agile is not based on predefined methods of work, but on an experiential basis. To these changes, the team maintains the agility of the team through constant introspection and adjustment.