The first three chapters of Agile Software Development (principles, models and practices)

Agile Software Development (principles, models and practices)
(US) by Robert C. Martin
Translated by Deng Hui
Mengyan Review

Notes

Excerpt: Eleven

Part 1 agile development

Chapter 2 agile practices

The wind icon on the top of the church, even made of steel, will be immediately destroyed by the storm if you do not understand the art of the wind.
-- Heinehi haane (1797-1856, German poet)

1 agile Alliance Declaration (the manifesto of agile Alliance)
We are exploring better software development methods through hands-on practice and helping others practice. Through this work, we believe that:
Individuals and interactions are better than processes and tools
Software that can work is better than comprehensive documents
Customer cooperation is better than contract negotiation
Responding to changes is better than following the plan

1.1 individuals and interactions outperform processes and tools
People are the most important factor in success.
A good team member may not be a top-notch team memberProgramPersonnel, a team of average level programmers, with good communication skills, will be more likely to succeed than those who have a group of high-level programmers but lack of communication and material flow.
A suitable tool is important for success, but its role cannot be exaggerated. We recommend that you try a tool from an early stage, it is not changed until it is found to be unsuitable. For example, if a large and high-performance database is not urgently required at the beginning, you can replace it with files first.
Remember, team building is much more important than environment building. In a project, you should first build a team and then configure the environment based on your needs.

1.2 software that can work better than comprehensive documents
Software without documentation is a disaster, but too many documents are worse than no documents, which wastes time and effort.CodeIf the file cannot be synchronized, it will cause more cost and misleading information.
For the team, it is always a good idea to write and maintain a document on the system principles and structure, but it must be short and highlighted, up to 10 or 20 pages. The topic highlights only the high-level structure and general design principles of the system.
The best two documents for new team members are code and team. (Code is the only information source without ambiguity). In the Team's mind, it stores the changing system context map (road map ). Interactions between people are the fastest and most effective way to pass on the context map to others.
Martin's first law of document: documents are not prepared until they are urgent and meaningful.

1.3 customer cooperation is better than contract negotiation
Successful projects require ordered and frequent customer feedback. The author believes that the key to John's success lies in the sincere writing with the customer, and the contract guides this writing, rather than trying to specify the details of the project scope and the progress at a fixed cost.

1.4 responding to changes is better than following the plan
The ability to respond to changes often determines the success or failure of this software project. When building a plan, we should ensure that the plan is flexible and easy to adapt to business and technical changes.
The author thinks that a better strategy 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 to be fulfilled in the next three months. There is a vague idea about what the system will do in a year. (Such a plan takes only a few weeks, and the rest of the plan remains flexible)

2 Principles
(1) What we have to do most is to satisfy our customers by delivering valuable software as soon as possible and continuously.
(2) even after development, you are welcome to change your requirements. Agile processes use changes to create competitive advantages for customers.
(3) regularly deliver software that can work. The delivery interval can be from several weeks to several months. The shorter the delivery interval, the better.
(4) During the entire project development period, business personnel and developers must work together on a daily basis.
(5) Build projects around motivated individuals. 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, and management-are considered secondary. When they have negative effects on people, they must be changed.
(6) In the team, the most effective and efficient way to transmit information is face-to-face conversations.
(7) software at work is the primary progress measurement standard.
(8) agile processes promote sustainable development speed. Owners, developers, and users should be able to maintain a long-term and constant development speed.
(9) constantly paying attention to excellent skills and good design will enhance agility.
(10) Simplicity-the art of maximizing unfinished work-is fundamental.
(11) The best architecture and demand design come from the teams of the Organization.
For an agile team, people are not assigned to a single team member from outside, but to the entire team, and then the team determines the best way to complete the task.
(12) at intervals of time, the team will reflect on how to work more effectively and adjust their behaviors accordingly.

3 conclusion
Agile process: scrum, crystal, feature-driven software development (FDD), adaptive software development (ADP ), and the most important eXtreme Programming (XP ).

Chapter 1 eXtreme Programming Overview

As developers, we should remember that XP is not the only choice.
-- Pete mabreen

1. Extreme programming practices
Extreme Programming (XP) is one of the most famous agile methods. It is composed of a series of simple but different practices. These practices are combined to form a whole better than partial integration.

1.1 customers as team members
Customers in an XP team are people or groups that define product features and prioritize these features. In the XP project, no matter who is a customer, they are all team members who can work with the team.
The best case is that the customer and the developer work in the same room. The next point is that the distance between the customer and the developer is within 100. The larger the distance, the more difficult it is for a customer to become a real team member, the author believes that if it is indeed unable to work with the customer, then it is necessary to find people who can work together, are willing to and can replace the real customer.

1.2 user Material
In order to carry out a project plan, you must know the content related to the project requirements, but you do not need to know too much. To make a plan, you only need to be able to estimate the extent of the requirement.
The specific requirements may change with practice. Therefore, it is very early to capture the specific details of a requirement, which may result in useless work and immature demands.
User material (user stories, of course, here I prefer to call it a user story) is a prompt for the ongoing demand talk. It is a planning tool that customers can use and arrange based on its priority and estimated cost to implement this requirement.

1.3 short delivery cycle
XP projects deliver software that can work once every two weeks. Every two weeks of iteration (interaction can also be turned into Oh your service cycle or cycle) has met some of the needs of the stakeholders, at the end of each iteration, the system generated by iteration will be presented to the stakeholders for their feedback.
iteration plan: each iteration usually takes two weeks. Is a small delivery, may be added to the product, or may not. It consists of the customer's selection of user materials based on the budget determined by the developer.
once the iteration starts, the customer does not modify the definition and priority of the user material in the current iteration. During the iteration, developers can freely break down user materials into tasks and develop these tasks in the most technically and commercial order.
release plan: the XP team usually creates a plan to plan the content of the next six iterations, that is, the release plan. A single release usually takes three months. It indicates a large delivery, which is usually included in the product.
a release plan is composed of a group of user materials selected by the customer based on the budget given by the developer, which are prioritized.
the release plan is not static. The customer can change the content of the plan at any time. The customer can cancel user materials, write new user materials, or change the priority of user materials. (Here I personally think that it is not possible to make changes at any time, but it should be said that the user materials used in the next two weeks, that is, the iteration plan, cannot be changed, subsequently, changes or other operations can be performed as needed.

1.4 Acceptance Test
You can capture details about user materials in the form of an acceptance tests specified by the customer. The user material acceptance test is written before the user material is realized or at the same time. (We can see that it is different from general functional testing or unit testing)
Acceptance Tests are written in a scripting language that enables them to run automatically and repeatedly. These tests work together to verify that the system operates according to the behavior specified by the customer.
Customers can use QA to develop acceptance testing tools and write acceptance tests.
Once an acceptance test is passed, it is added to the acceptance test set that has passed, and the test will never fail again. This acceptance test set is run multiple times a day. Each time the system is created, the acceptance test set needs to be run. If an acceptance test fails, the system creation fails. Therefore, once a requirement is met, it will not be damaged. The system changes from one State to another. During this period, the system cannot work for more than a few hours.

1.5 teaming Programming
The production code of all products is completed by the team-end programmers using the same computer. One of the team members controls the keyboard and enters the code. The other observes the entered code and looks for errors and improvements in the code. Two people are strongly engaged in interaction, and they are all devoted to programming the software.
Code is designed and compiled by the two teams. The two teams share the same credit.
The relationship between the teams changes at least once a day, so that each programmer can work in two different teams in a day. During an iteration, each team member should have worked with all other team members and should be involved in each task involved in this iteration.
This can promote the spread of knowledge in the team.
A study by Laurie William ANMs and Nosek shows that the formation will not only reduce the efficiency of the development team, but also greatly reduce the defect rate.

1.6 test-Driven Development Method
The purpose of writing all product code is to make failed unit tests pass. First, write a unit test. Because the function to be tested does not exist, it fails to run, and then write code to make the test pass. In addition, this method is very conducive to refactoring. In addition, this method can inspire programmers to release the coupling between modules, so that they can be tested independently. The principle of object-oriented design is of great help in decoupling.

1.7 Collective Ownership
Each pair in the teaming programming has the right to detach (check out) Any module and improve it. No programmer is solely responsible for any specific module or technology. Everyone is involved in Gui work, everyone is involved in middleware work, and everyone is involved in database work. No one has more authority than others in one module or technology.

1.8 continuous integration
The XP team builds the system multiple times a day and re-creates the entire system.

1.9 sustainable development speed
The XP team must move forward at a sustainable speed and consciously maintain a stable and moderate speed.
The rule of XP is that teams are not allowed to work overtime. One week before version release is the only exception to this rule. Overtime is allowed if the release target is ready and can be achieved overnight.

1.10 open workspace
A University of Michigan study shows that working in a "war room full of active discussions" will not reduce productivity, but multiply.

1.11 plan game
Planning games are essentially divided into duties between business personnel and developers. Business personnel (customers) determine the importance of features, and developers decide the cost of implementing a feature. At the beginning of each release and iteration, developers provide customers with a budget based on the workload they have completed in the last iteration or the most recent release. The customer selects user materials whose total costs do not exceed the budget.

1.12 simple design
The XP team made their design as simple and expressive as possible ). In addition, they only focus on the user Materials planned to be completed in this iteration. They will not consider future user materials. This means that the work of the XP team may not start from the infrastructure, and only when a user material urgently needs the infrastructure will they introduce it.
Three XP knowledge principles (mantras ):
(1) consider the simplest thing to do.
(2) You will not need it
(3) once, and only once

1.13 refactoring)
Reconstruction is a series of small transformations without changing the code behavior. It aims to improve the system structure. Each transformation is insignificant, but these transformations are combined to form a significant improvement in the system design and architecture. (That is, as long as you think that improvements can be made, you must not hesitate to make improvements)
After each reconstruction, you must run the unit test to ensure that the reconstruction does not cause any damage, and then perform the next reconstruction. In addition, refactoring continues.

1.14 metaphor
Metaphore is the most difficult to understand in all XP practices. Metaphor is a global view that connects the entire system. It is the future of the system, and it makes the position and appearance of all individual modules obviously intuitive.

2 Conclusion
The limit is a set of simple and specific practices. These practices are combined to form an agile development process.

Chapter 4 Plan

when you can measure what you say and express it with numbers, it means you understand it. If you cannot measure it, you cannot express it with numbers, it means that your knowledge is lacking and unsatisfactory.
-- Lord Kevin, British physicist, 1883

1 Initial Exploration
At the beginning of the project, developers and customers will try to determine all really important user materials. However, they will not try to determine all the user materials. As the project progresses, the customer constantly writes new user materials. The compilation of materials continues until the project is completed. (This is mainly because the demand changes along with the progress of the project)
Developers jointly continue to estimate these user materials. Estimation is relative, not absolute. We write some "points" on the card that records the clip to indicate the relative time to implement the clip. We cannot determine the time represented by each point, however, we know that the time required for the 8-point clip is twice that of the 4-point clip.
Any large material should be divided into smaller parts, and any small material should be merged with other small materials.
To know the absolute size of the user's materials, a factor of speed is required.
As the project progresses, since we can measure the number of user material points that have been produced in each iteration, the speed measurement will become more and more accurate. Generally, it is enough to prototype one or two user materials to understand the speed of the team. Such a prototype process becomes a spike ).

2 release plan
The sequence of user material implementation is not simply based on the priority. Some important but costly materials may be postponed, and some less important materials will be implemented first, however, the cost is much lower. Such selection belongs to business decision-making. Let the business personnel select the materials that will bring the greatest benefit to them.
When the development speed becomes accurate, you can adjust the release plan accordingly.

3. Iteration plan
When selecting user materials, you are not allowed to select more materials that do not match the current development speed.
The implementation sequence of user materials during the iteration belongs to the scope of technical decision-making. developers use the most technically meaningful sequence to implement these materials.
As mentioned above, Once iteration begins, the customer cannot change the material to be implemented during the iteration period.
Even if all the materials are not completed, the iteration ends on the date specified previously. Developers sum up the estimated values of all finished materials and then calculate the development speed of this iteration, which will be used for the next iteration. The rule is simple: the development speed adopted during each iteration is the development speed tested in the previous iteration.

4. Task Plan
At the beginning of a new iteration, developers and customers work together to develop a plan. Developers break down materials into development tasks. A person is a feature that a developer can implement within 4-16 hours.
Every developer knows the number of task points completed in the last iteration. This number can be used as a personal budget for the next iteration.
Select a task until all tasks are assigned, or all developers have used up their budget. If the task has not been assigned, it will negotiate with each other and developers will exchange corresponding tasks based on their respective expertise. If there are still redundant tasks, you will be asked to remove some tasks or materials from this iteration. If all tasks have been assigned and developers still have budget space to complete more tasks, they will ask customers for more materials.
When the iteration is half done, the team must hold a meeting to view the finished materials (not the task, because the task is half completed, but the materials are not completed, is meaningless) the number of materials should be half of the total. If not, the team should try to reassign unfinished tasks and responsibilities, to ensure that all the materials can be completed at the end of the iteration.

5 iterations
At the end of each iteration, the customer will be presented with a demo of the currently executable program. The customer will provide new user materials based on the feedback they have seen.

6 Conclusions
through repeated iterations and releases, the project enters a predictable and comfortable development pace.
using agile methods does not mean that stakeholders can get what they want. It means they will be able to control the team to maximize business value at minimal cost.