A survey of Agile development methods

The agile development takes the user's demand evolution as the core, uses the iterative, the gradual step method carries on the software development. In agile development, software projects are cut into multiple sub-projects in the early stages of construction, and the results of each sub-project are tested for visual, integrated, and operational use features. In other words, a large project is divided into several interconnected, but also can be run independently of small projects, and completed, in the process of software has been in a state of use.

Agile Modeling,am's values include the four values of XP (Extreme Programming: Extreme Programming): Communication, simplicity, feedback, courage, and, in addition, a fifth value: humility.

Agile development is a new development model for the shortcomings of the traditional waterfall development model, and the goal is to improve the development efficiency and response ability. In addition to principles and practices, patterns are also important, and multiple research patterns and their applications can give you a deeper understanding of agile development.

Principle Agile Modeling (AM) defines a series of core principles and supporting principles that provide the cornerstone for modeling practices in software development projects. Some of these principles are drawn from XP and are described in detail in the extreme programming explained. Some of the principles in XP come from well-known software engineering. The idea of reuse is everywhere! Basically, the elaboration of these principles in this article focuses primarily on how they affect modeling work, so that we can look at it from another perspective for these principles of learning from XP. The core principle advocates simple when engaged in the development work, you should advocate the simplest solution is the best solution. Don't build too muchAgile Development(overbuild) Your software. With AM, if you don't need this extra feature right now, don't add it to the model. To have the courage to: you do not need to over-model the system now, as long as the existing requirements for modeling, future requirements change, then to reconstruct the system. Keep the model as simple as possible. Embracing change demands is changing, and people's understanding of demand is changing at times. Project stakeholder may change, there will be new entrants, and there will be old people leaving. The ideas of Project stakeholder may also change, and the goals and success criteria you strive for can change. This means that as the project progresses, the project environment is constantly changing, so your development approach must be able to reflect this reality. An important concept associated with incremental changes and modeling is that you don't have to get everything ready in the first. In fact, even if you want to do this, it's not likely. And, you don't have to contain all the details in the model, you just need enough detail. There is no need to try to build a model that encompasses everything in the first place, you just have to develop a small model, or a profile model, lay a foundation, and then slowly refine the model, or discard it when it is not needed. This is the idea of increment. Maximize your stakeholder investment your project stakeholder to develop software that meets your needs, with resources such as time, money, equipment, and more. Stakeholder should be able to choose the best way to invest, or ask your team not to waste resources. And they have a final say, and they decide how much to put in their resources. If these resources are your own, do you want your resources to be misused? Purposeful modelling for their own artifact, such as models, source code, documentation, many developers are not worried about whether they are detailed enough, whether they are too detailed, or whether they are correct enough. You should not make meaningless modeling, you should first ask, why build this artifact, for whom to build it. And modeling, perhaps you should learn more about some aspect of the software, perhaps to ensure the smooth progress of the project, you need to communicate with the senior manager of your method, perhaps you need to create a description of the system documents, so that others can operate, maintain, improve the system. If you don't even know why you're modeling, who you're modeling is unclear, why continue to fret? First of all, you need to determine the purpose of the modeling and the audience of the model, on this basis, then ensure that the model is adequate and detailed enough. Once a model achieves its goals, you can end the work and shift your energies to other tasks, such as writing code to verify the operation of the model. This principle can also be applied to changing existing models: If you are going to make some changes, perhaps a well-known pattern, you should have made the right changesReasons (perhaps to support a new requirement, or to restructure to ensure brevity). An important implication of this principle is that you should be aware of your audience, even if the audience is your own. For example, if you are building models for maintainers, what exactly do they need? Is it enough for a detailed document of up to 500 pages, or a 10-page job overview? You don't know? Go talk to them and find out what you want. Multiple model development software requires multiple models, since each model can only describe a single aspect of the software, "to develop today's business Agile development What kind of model do we need? "Given the complexity of today's software, your modeling toolkit should contain a lot of useful techniques (for a list of artifact, see AM modeling artifact). It is important that you do not need to develop all the models for a system, but that you should choose a part of the model for the specific situation of the system. Different systems use different parts of the model. For example, as with home repair work, each job does not require you to use every tool in the toolbox, but one tool at a time. For example, you might prefer certain tools, and you may prefer a model. How many modeling artifact are available, and if you want to know more about this, I've listed the relevant parts of UML in being realistic about the UML, and if you want to know more, you can refer to the white paper the Object Primer- An Introduction to techniques for Agile Modeling. High-quality work nobody likes rotten bad work. The person who does the job does not like it because there is no sense of accomplishment; the person responsible for refactoring the work (for some reason) does not like it because it is difficult to understand, difficult to update, and the end user does not like it because it is too fragile, prone to error, and does not meet their expectations. Quick feedback from the start of action to getting feedback on action, the time between them is crucial. By developing models with others, your ideas can get immediate feedback, especially when you work with shared modeling techniques such as Whiteboard, CRC cards, or sticky-stick-like basic modeling materials. Work closely with your customers to understand their needs, analyze them, or develop a user interface that meets their needs, so you have the opportunity to respond quickly. Software is the main goal of your main target software development is to create software that meets the needs of project stakeholder in an effective way, rather than making unrelated documents, unrelated to managing artifact, or even unrelated models. Any activity, if not in accordance with this principle, does not contribute to the achievement of the goal, should be audited, or even canceled. Move light you build a artifact and then decide to keep it, and as time goes by, these artifact need to be maintained. If you decide to keep 7 models, whenever there is a change (new demand, the original requirement, the team accepted a new approach, and adopted an advanced technology ...). , you need to consider the impact of the changes on these 7 models and take appropriate action. And if you want to keep only 3 models, it's clear that you'll have less effort to make the same change, and your flexibility will be enhanced becauseYou are moving lightly. Similarly, the more complex your model, the more detailed it is, the more likely it is that the change will be more difficult to achieve (each model is more "heavy", so the maintenance burden is greater). Every time you decide to keep a model, you weigh the benefits of the information that the model contains to the team (so you need to strengthen communication between teams, teams, and project stakeholder). Don't underestimate the seriousness of the trade-offs. A man must think of the desert, he will carry maps, hats, fine-quality shoes, kettles. If he had hundreds of gallons of water, all the tools he could imagine, a whole bunch of books about the desert, would he be able to survive the desert? In the same vein, a development team decided to develop and maintain a detailed requirements document, a detailed set of analysis models, and a detailed set of architectural models, as well as a detailed set of design models, and they soon discovered that most of their time was spent not on writing the source code, but on updating the document. The principle of manifesto is most important to meet customer needs through early and continuous delivery of valuable software. We welcome changes in demand, even in the late stages of development. Agile processes can harness change and maintain a competitive edge for customers. Often deliver software that works, from weeks to months, the shorter the time scale the better. Business people and developers should always work together during the entire project. Software development revolves around high-spirited people, providing developers with the right environment to meet their needs and believing they can accomplish their tasks. The most efficient and effective way to communicate in a development team is to talk to each other in person. The software that can work is the primary measure of progress. Agile processes promote sustainable development. Funders, developers and users should always maintain a constant rhythm. Continuous pursuit of superior technology and good design will help improve agility. Simple-the art of minimizing the amount of work is essential. The best architectures, requirements, and designs come from self-organizing teams. Every once in a while, the team summarizes how to be more efficient and then adjusts its behavior accordingly. Tools edit Visual Studio Team Foundation Servertfs, which is the Microsoft Application Lifecycle Management Server, is used to help teams collaborate on Visual Studio development. Recently, it has been upgraded to include work item execution improvements, Rich text editor improvements, and an improved hyperlink experience in the Rich Text editor. The Kanban panel in TFS has also been improved to increase the number of items that can be entered and tracked, and the server now has a "stakeholder" license to regulate the server's access rights. Atlassian Jiraatlassian is a popular tool for tracking product development, helping teams organize problems, arranging tools, and documenting team behavior. It jira Agile plug-ins to make it easier for developers to deploy key agile strategies, including user story development, Sprint module building, and visual team activities. Axosoftaxosoft formerly known as Axosoft OnTime scrum, this software suite has four functional modules: Scrum, bug tracker, helpdesk, and wiki. Built on HTML5, it helps development teams manage to-do lists, releases and sprints, with burndown charts, and a management dashboard to track when to encode and modify bugs. LeanKit teams using LeanKit can see the distribution of workloads and export historical data. Recently LeanKit has been upgraded with a single sign-on feature and additional reporting capabilities to provide finer-grained data details. The Planboxplanbox Agile Management tool tracks processes through Burndown charts and integrates customer feedback with a broad audience. Recently it has upgraded the front end and back end of the app, adding more powerful reporting capabilities and new dashboards to speed up the project. Time tracking features and tools allow users to get all the data they generate in Planbox. Principles of Agile Development 1. Fast iterations The requirements, development, and testing of a small version are much simpler and faster than that of a half-yearly large release. Some companies publish only two or three versions a year, the release process is slow, they still use the waterfall development model, more serious is the Agile development model has misunderstood. 2. Involve testers and developers in the requirements discussion requirements discussion in the form of a discussion group to be most efficient. Discussion groups, which need to include testers and developers, make it easier to define testable requirements, group requirements, and prioritize them. At the same time, this method can also make full use of the complementary characteristics between team members. The need for such certainty is often more efficient, more active and more participatory than the need to discuss the conference. 3. Writing a testable requirements document starts with a "user story" approach to writing the requirements document. This approach allows us to focusOn demand, not on solutions and implementation techniques. Premature mention of a technology implementation reduces the need for attention. 4. Multi-communication, minimizing documentation in any project, communication is a common problem. Good communication is a prerequisite for agile development. The longer you mix in a circle, the more you emphasize the importance of good and efficient communication. The team wants to make sure that everyday communication is much better than email. 5. Do a good job prototyping recommends using sketches and models to clarify the user interface. Not everyone can understand a complex document, but everyone will look at the picture. 6. Early consideration of testing in early consideration of testing is important in agile development. Traditional software development, test cases start writing late, which leads to late detection of problems in demand, making the cost of improvement too high. Start writing test cases earlier, and when the requirements are complete, the acceptable test cases are basically complete.  scrum is a framework for the development and maintenance of complex products and is an incremental, iterative development process. In this framework, the entire development process consists of several short iteration cycles, a short iteration cycle called a sprint, and the recommended length for each sprint is 2-4 weeks (Internet product development can use a sprint of 1 weeks). In scrum, the product backlog is used to manage product requirements, and the product backlog is a list of requirements sorted by business value, and the form of the list entry is typically a user story. The scrum team is always first to develop requirements that are of high value to the customer. In Sprint, the scrum team picks the highest-priority requirements from the product backlog for development. The selected requirements are discussed, analyzed and estimated at the Sprint planning meeting to get a list of tasks that we call the sprint backlog. At the end of each iteration, the scrum team submits a potentially deliverable product increment. Scrum originates from software development projects, but it is suitable for any complex or innovative project. Three roles for the  scrum team

The scrum team includes three roles, namely the product owner, the development team, and the scrum Master.

The Scrum team is a self-organizing, cross-functional, complete team. Self-organizing teams decide how best to complete their work, rather than being directed by others outside the team.

Cross-functional teams have all the skills they need to get the job done, without having to rely on people outside the team. The Scrum Team model is designed to maximize adaptability, creativity, and productivity.

The Scrum team maximizes feedback opportunities by iterating and incrementally delivering product functionality. Incremental delivery of potentially deliverable product increments ensures that each iteration has a potentially available release.

Scrum Role: Product Owner

The product owner is responsible for maximizing the value of the product and development team work. The way you do this will vary depending on your organization, your Scrum team, and your individual team members.

The product owner is the only person responsible for managing the product backlog list. The management of the Product Backlog list includes:

• Clearly express product-by-item list entries
• Order the items in the product list to best achieve your goals and mission
• Ensure the value of the work performed by the development team
• Make sure the Product list is visible, transparent, clear to everyone, and shows the next step of the Scrum team
• Ensure that the development team has a certain degree of understanding of the items in the product's list of agent items

The product owner can do the above work in person, or it can be done by the development team. However, the product owner is the responsible person.

The product owner is a person, not a committee. The product owner may reflect the needs of a committee in a list of product agents, but to change the priority of an item must first convince the product owner.

In order to ensure the success of the product owner's work, all the people in the Organization must respect his decision. The decisions made by the product owner are clearly visible in the content and sorting of the product backlog list. No one should ask the development team to work on a different set of requirements, and the development team will not be allowed to follow any other person's instructions.

Scrum role: the development team

The development team includes professionals who are responsible for delivering potentially deliverable "complete" product increments at the end of each Sprint. Only members of the development team can create increments.

The development team is built and empowered by the Organization to organize and manage their work. The resulting synergy can maximize the overall efficiency and effectiveness of the development team. The development team has several features:

• They are self-organizing, and no one (even Scrum Master can) tell the development team how to turn the list of product-handling items into potentially available functionality.
• The development team is cross-functional and the team as a whole has all the skills needed to create a product increment.
• Scrum does not endorse the titles of development team members, and they are developers regardless of which job they are responsible for. This rule is not an exception.
• Each member of the development team can have strengths and areas of focus, but responsibility rests with the entire development team
• The development team does not include sub-teams responsible for specific areas such as testing or business analysis.

Size of the development team

The optimal size of the development team is small enough to remain agile and large enough to accomplish important work. Development teams with fewer than 3 people do not have enough interaction to achieve a significant increase in productivity. Small teams may be subject to skill limitations in the Sprint, resulting in an inability to deliver a published product increment. Teams of more than 9 people require too much coordination and communication work. Large teams create too much complexity and are not easy to experience process management. The roles of the product owner and Scrum Master are not included in this number unless they are also involved in performing the work in the Sprint Representative list.

Scrum role: Scrum Master

Scrum Master is responsible for ensuring that scrum is understood and implemented. To achieve this goal, Scrum master ensures that the scrum team follows the theory, practice, and rules of scrum. Scrum Master is a serviced leader in the scrum team.

Scrum Master helps people outside the scrum team understand how they interact with the scrum team. Scrum Master maximizes the value created by the scrum team by changing these interactions.

Scrum Master serves the product owner

Scrum Master serves the product owner in a variety of ways, including:

• Find tips for managing your product's list of agents
• Clearly communicate with the development team on the vision, objectives and product representative list entries
• Teach the development team to create clear and concise list of product representative items
• Understanding long-term product planning in an empirical environment
• Understanding and practicing Agility
• Drive scrum activities on demand

Scrum Master serves the development team

Scrum Master serves the development team in a variety of ways, including:

• Guide development teams self-organizing and cross-functional
• Educate and lead the development team to create high-value products
• Remove obstacles in the development team's progress
• Drive scrum activities on demand
• Guide the development team in an organizational environment where Scrum is not yet fully adopted and understood

Scrum Master serves organizations in a variety of ways, including:

• Leading and directing the organization to adopt Scrum
• Plan the implementation of Scrum in an organization-wide context
• Help employees and stakeholders understand and implement Scrum and experiential product development.
• Initiating changes that enhance the productivity of the Scrum team
• Work with other scrum Master to help organizations more effectively apply Scrum
• Other details about scrum are available at: http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-7

A survey of Agile development methods