Should an excellent team use agile development?

[[164863]]

After the collapse of the myth of CMM (Capability Maturity Model, a development model that focuses on the management of software development processes and the improvement and evaluation of engineering capabilities), agile development has gradually attracted people's attention and has been highly anticipated. Let's talk about some knowledge related to agile development.

The origins of agile development

Most of us have learned the waterfall development model, which is document-driven. Because in the entire waterfall development process, developers develop according to the requirements document, and everything is based on the document. Agile development is a people-centered, iterative, and step-by-step development method. It is a software development process that guides us to complete the project development step by step with prescribed links. The main driving force of this development method is people, and it focuses on face-to-face communication between people. It only writes necessary documents, or writes as few documents as possible. It adopts iterative development.

Agile development advocates dividing a complete software version into multiple iterations, with each iteration implementing different features. Important, high-priority features are implemented first, as are high-risk features. The software prototype is developed in the early stages of the project, and is continuously improved in subsequent iterations based on this prototype. The benefits of iterative development are: coding as early as possible, exposing the technical risks of the project as early as possible. Customers can see the runnable software as early as possible and make optimization suggestions. Available versions can be delivered to different customers in stages in advance.

In each iteration, the architect is responsible for breaking down all features into multiple Story Cards. Each Story can be considered an independent feature. Each Story should be developed and delivered within a maximum of one week for pre-testing. When all Stories in an iteration are developed, the test team will conduct a complete test. During the entire testing process (pre-test, test), based on the Daily build, the test team always takes the latest compiled version from the configuration library for testing every day. Developers also modify the problem tickets submitted by testers at any time and merge them into the configuration library.

One of the characteristics of agile development is open office and full communication, including testers working with developers. Based on the Story Card development method, the team will place a whiteboard in the open office area, on which all the Story Cards are pasted. They are posted in four areas according to the current development status: undeveloped, under development, pre-testing, and under testing. Story Card developers and testers move Story Cards on the Story Wall according to the development progress and update the status of Story Cards. This method can give a very intuitive understanding of the project development progress.

Agile Manifesto

Individuals and interactions over processes and tools

Working software is better than comprehensive documentation

Customer collaboration trumps contract negotiation

Responding to change is better than following a plan

Although the item on the right also has value, we believe that the item on the left has greater value.

Agile development approach

Agile development is a guiding ideology or development method. Scrum and XP (Extreme Programming) are specific methods of agile development. The difference between Scrum and XP is that Scrum focuses on process while XP focuses on practice. However, in practice, the two are applied together.

The Scrum Way

The English meaning of Scrum is a professional term in rugby, which means the action of "fighting for the ball". Name a development process Scrum, and everyone will be as fast and passionate as playing rugby. By using this process, you can see your team working efficiently.

The entire Scrum development process consists of several short iteration cycles, each of which is called a Sprint. The recommended length of each Sprint is 2 to 4 weeks (1-week Sprints can be used for Internet product development). In Scrum, Product Backlog is used to manage product requirements. Product Backlog is a list of requirements sorted by business value. The Scrum team always develops requirements that are of higher value to customers first. In Sprint, the Scrum team selects the highest priority requirements from the Product Backlog for development. The selected requirements are discussed, analyzed, and estimated at the Sprint planning meeting to obtain the corresponding task list, which we call Sprint backlog. At the end of each iteration, the Scrum team will submit a potentially deliverable product increment. Scrum uses an iterative and incremental approach to optimize predictability and control risks.

Three major roles in the Scrum development process

Product Owner

Mainly responsible for determining the product's functionality and meeting the required standards, specifying the software's release date and delivery content, and having the authority to accept or reject the work results of the development team.

Scrum Master

Mainly responsible for the smooth implementation and progress of the entire Scrum process in the project, as well as removing communication barriers between customers and development work, so that customers can directly drive development.

Development Team (Scrum Team)

Mainly responsible for the development of software products under the Scrum process. The number of people is controlled at around 5 to 10. Each member may be responsible for different technical aspects, but each member is required to have strong self-management capabilities and certain expressive skills. Members can adopt any working method as long as they can achieve the Sprint goal.

Scrum development process

1. We first need to determine a Product Backlog (a list of product requirements arranged in order of priority), which is the responsibility of the Product Owner;

2. The Scrum Team estimates and arranges the workload based on the Product Backlog list;

3. With the Product Backlog list, we need to select a Story as the goal of this iteration through the Sprint Planning Meeting. The time period for this goal is 1 to 4 weeks, and then refine this Story to form a Sprint Backlog;

4. The Sprint Backlog is completed by the Scrum Team, and each member breaks it down into smaller tasks based on the Sprint Backlog (so detailed that the workload of each task can be completed within 2 days);

[[164864]]

5. When the Scrum Team completes the Sprint Backlog selected in the planning meeting, a Daily Scrum Meeting is required. Each meeting is controlled to about 15 minutes. Everyone must speak and report to all members in person what you have completed yesterday and promise all members what you will complete today. At the same time, you can also raise any unsolvable problems. After everyone has answered, they must go to the blackboard to update their Sprint burn down.

[[164865]]

6. Achieve daily integration, that is, there must be a version that can be successfully compiled and demonstrated every day; many people may not have used automated daily integration, but TFS actually has this function. It can support each time a member checks in, automatically obtain the latest version on the server, and then compile it on the server. If it passes, the unit test code will be executed immediately. If all of them pass, the version will be released. Only then will a formal check-in operation be saved in TFS. If there is any failure in the middle, the project manager will be notified by email;

7. When a Story is completed, that is, the Sprint Backlog is completed, which means that a Sprint is completed. At this time, we have to hold a Srpint Review Meeting (demonstration meeting), also known as a review meeting. The product owner and the customer must attend (it is best for the company's boss to attend as well). Every Scrum Team member must demonstrate their completed software product to them (this meeting is very important and must not be cancelled);

8. The last one is the Sprint Retrospective Meeting, also known as the summary meeting. It is conducted in a round-robin manner. Everyone must speak, summarize and discuss the areas for improvement, and put them into the product requirements for the next round of Sprint.

XP method

Extreme Programming is a lightweight and agile software development method; at the same time, it is also a very rigorous and thorough method. Its foundation and values ​​are communication, simplicity, feedback and courage; that is, any software project can be improved from four aspects: strengthen communication; start from simplicity; seek feedback; dare to seek truth from facts. XP is a nearly spiral development method that breaks down the complex development process into relatively simple small cycles; through active communication, feedback and a series of other methods, developers and customers can be very clear about the development progress, changes, problems to be solved and potential difficulties, and adjust the development process in a timely manner according to the actual situation.

The thirteen core practices of XP

Whole Team

Planning Strategy (The Planning Game);

Pair programming

Testing-Driven Development

Refactoring

Simple Design

Collective Code Ownership

Continuous Integration

Customer Tests

Small Release

40-hour work week

Code Standards

System Metaphor

About planning strategy: Planning is continuous and incremental. Every 2 weeks, developers estimate the cost of candidate features for the next 2 weeks, and customers choose features to implement based on cost and business value.

About test-driven development: Writing unit tests is an act of verification as much as it is an act of design. It is also an act of documentation. Writing unit tests avoids a lot of feedback loops, especially in terms of functional verification. Programmers work in very short cycles, they add a failing test first, then make it pass.

About metaphors: Metaphors are synonymous with architecture. Metaphors are used to describe the overall picture of a project, while stories are used to describe individual specific features. Metaphors are the global view that ties the entire system together; it is the future image of the system, and it makes the location and appearance of all individual modules obvious and intuitive. If the appearance of a module does not match the overall metaphor, then you know that the module is wrong.

One of the success factors of XP is the emphasis on customer feedback - the purpose of development is to meet customer needs. The XP method enables developers to always face changes in customer needs with confidence. XP emphasizes teamwork, and managers, customers, and developers are all members of the development team. Through full communication and cooperation with each other, the team strives to develop high-quality software using XP, a simple but effective method. XP's design is simple and efficient; programmers obtain customer feedback through testing, and modify the code and design according to the changes. They always strive to deliver the software to customers as early as possible. XP programmers are able to face changes in requirements and technology.

What is an excellent team?

A team in a company used the "agile development method" for a project. At that time, the company's philosophy was: open, collaborative, flat team, and user-centric; it was exactly the same as the agile method used by the team, and it won the Outstanding Team Award without any suspense. Even though the project was not very successful, the company needed a team to set an example and inspire other teams, and there happened to be such a team.

If you can't be an excellent team, then be a typical team. The company needs such a demonstration topic. An excellent team is not bound by a certain development method, but is most suitable for a certain method. I hope you can also be in an excellent team.