What are the real problems of agile development? In fact, agility is mainly a concept, a consciousness, promoted by people.
This article summarizes 26 key principles related to agile development. It provides readers with reference to how to develop quickly and iteratively to guide the Agile Software Development Team.
1,After completing one task, start another task.: In the kitchen metaphor, it is: "First this dish, then start to make the next one ". The biggest problem with software development is to start a few things at the same time, which will inevitably lead to the waste of some work. Focus on one thing; Fully implement its functions; run tests; write documents; check in all, take this as a task, and then start the next thing.
2,
Do not destroy the build: Obviously, but must be included in any software development suggestion list. The build will never be broken if Programmers take all the appropriate preventive actions for testing before checking in. If the build is damaged, it is usually because someone is lazy.
3,
Do not implement programs before use cases are required.: When you implement a specific class, you should have a specific use case in your mind. At the same time, you should only implement the methods required by the use case. You can consider the potential features of this class and write them into comments, but it should not be implemented until the use case is actually needed.
4,
Do not add data members before use cases are required.: Same as the previous one, but this is from the perspective of data members of the class. It seems obvious that the "customer" record requires a "shipping address", but it should be implemented until the useful example explicitly requires a shipping address.
5,
Don't be afraid to make decisions, don't be afraid to change previous decisions: Agile development is about changes and quick responses. You do not have complete information at the initial stage of development. You should postpone the decision as much as possible until you have to make the decision. Without information, you cannot make your decisions. On the contrary, you can make the best decisions based on valid information. With new information, do not be afraid to change previous decisions. (Some "dinosaurs" are called swinging, but I call it an environment that responds to changes)
6,
Continuous learning how to improve quality: This work will never end, so you should always pay attention to the things that can be improved and collect the cases of quality problems being confirmed and handled.
7,
Measurement, measurement, and measurement: Agile development helps to deal with future uncertainties, but there should be no uncertainty in the past. The test should run continuously, and the performance of each operation should be measured and recorded.
8,
Designed for humans, not Systems: Developers often make design mistakes due to technology. Never forget the ultimate goal of design, that is, to help people complete their work.
9,
Testing is part of the product: Many developers and managers think that a product is something delivered to the customer, and everything else is not that important. Testing should be considered as a real part of the product, and should be carefully considered during design, or even, in many cases, delivered together with the product to the customer. (The second half is controversial, but built-in testing, as part of Software Delivery, only takes up insignificant space, but provides obvious benefits when necessary. This approach should be taken into consideration .)
10,
Write and test before code: The test itself can be used to explain the design that is really needed. Design defects are often discovered through test cases. Think about how much time can be saved through these use cases before coding. However, write a test for example 1, encode it, and then start Example 2.
11,
Eliminate waste: Frankly speaking, this is another cliché that must be included in any list of development principles, because it is too important. This work has no end to discovering and eliminating waste. Eliminate anything that cannot increase customer value. If you cannot confirm the customer value, you probably don't need it.
12,
Build a culture that destroys Immediate Response: It should be clear that when the build is destroyed, it will affect everyone in the project. Therefore, the most important thing is to confirm that the core code is built and properly tested. I have seen some teams that have failed tests for several months because they are the work of others. Everyone is suffering, but no one is taking action. To counter this, a consensus must be formed, that is, a small job can earn a big return for the team.
13,
All team members should understand customer needs: Large and complex projects are naturally divided into independent teams and then assigned to developers. However, what we should not do in this scope is to lose the expectations and objectives of paying attention to the real users of the final project.
14,
Put related definitions together: Organize code to make highly relevant things together, or in a class. This is a standard object-oriented design encapsulation principle. Ideally, all code outside the class does not need to know the internal work details. Some developers are happy to spread the details to multiple files so that they can be organized in different ways, such as putting all the same data types together or organized alphabetically. For example, placing all constants in a class in different packages they are using increases unnecessary program complexity. The guiding principle should be to group by relevance to hide complexity.
15,
Always run the test before checking in: This rule helps you meet the "Do not break the building" principle.
16,
Sources of evil in premature optimization: Reference the example of Gartner: the code should be well written to avoid waste at the micro level, however, optimization beyond the independent method level should be conducted during stress tests based on actual end user scenarios of the entire program. Just based on the static understanding of the Code, it intuitively judges what is important to the overall performance, and the conclusion is almost always wrong. Instead, measure the behavior of the entire system, identify the code that really affects performance by 1%, and focus on this.
17,
Reduces the backlog of unfinished coding tasks: When a developer starts a use case, the cost is associated with the code that has been modified but not completed and tested. Days or weeks with unfinished changes will generate a huge redo risk. Consider that each Estimation requires three tasks a day, start these three tasks at the same time, and carry out at the same time within three days, which means the cumulative cost of nine units. However, each task is executed sequentially, And the next task is completed and then started, which means there are only three units of cost. This is not intuition. Intuition tells us that we may wish to do three things at the same time before the work is completed. But the software is not physically structured. Short, fast, and complete work not only reduces the burden of cognition, but also reduces the possibility of conflicts between unfinished work and unfinished work of others.
18,
Do not overemphasize code versatility: This is the famous "yagni-you don't need it ". When writing a specific class, programmers always like to think that this class may be used for other purposes. This is good if the current use cases require these purposes, but programmers often consider unmentioned purposes, or those that are never actually needed. (This often reminds me of the classic pop-up on Saturday. A product is not only floor wax, but also a sweet tooth on cakes .)
19,
Only two lines of code can be used.: Simple code always returns when someone reads it. But do not compress the code into a hard-to-read version. Smaller, well-written code is more lengthy, and it is easier to maintain and discover errors when writing gorgeous code. Always simplify it as much as possible, but never overdo it.
20,
Do not use the number of lines to measure the code: The number of lines of code required to complete a specific task. There is a big difference between programmers and coding styles. The number of lines of code cannot tell you about Code Completion and quality. The code quality can be 200 times different, which is enough to offset the number of lines of code. The number of function cases should be counted.
21,
Continuous re-design and Reconstruction: Use this criterion with caution, because some code is fragile and difficult to change, but you should not be afraid to change the code to conform to actual use conditions. A data member may have been an integer in the past, but when a use case requires that it be a floating point number, do not be afraid to change it.
22,
Delete dead code: There are a lot of codes that are hard to understand. There is a tendency to be difficult to find. One example is to add a new method to the class to replace the other. Developers often leave the old method just in case. Efforts must be made to check whether the method is required. If there is no evidence that it is required, delete it. The worst thing is to comment out a lot of code and leave it there. The commented out code should be deleted as soon as possible after the test is passed. Of course, the code should be deleted before it is checked in. Therefore, you may find that something is unnecessary at some time, and make little effort to verify and eliminate this code to make the code baseline easier to maintain.
23,
Do not create new languages: Programmers love to use text file configuration to drive at runtime. No configuration file can change the behavior of the program without compilation. The emergence of XML has pushed the endless wave of specialized scripting languages, so that functions can be customized by end users without compilation. The defect of this reasoning lies in that, leaving a specific implementation environment, the operation behavior is almost never well defined. At the same time, those scripting languages are only useful for those who have a deep understanding of the internal operation of the problematic domain code. Therefore, real end users without detailed internal knowledge will never be able to know what the expected results of complex command combinations are. Script languages are useful and cannot be eliminated. However, designers must adopt a very conservative attitude and try to use existing languages to avoid new inventions.
24,
Do not design before you prepare for implementation and testing.: You should have a general idea of moving forward and an overview of the system architecture. However, do not design in detail until development iterations allow the design to be implemented and tested, do not write detailed descriptions of function implementation. The detailed design should only deal with the current use cases. The biggest waste in software development comes from spending time designing things that are not needed or that need to be re-designed due to wrong design assumptions.
25,
The design is plastic.: Unlike physical manufacturing, software can easily achieve significant changes. In fact, there is a lot of evidence that the software itself is easier to change than the design specification that describes the software. In addition, the software communicates the design more effectively than the specification. Therefore, you should use the time to directly implement the design so that the customer can see the design details. If you make mistakes and change the design, it is easier to change the software than to change the specifications. But the most important thing is that after the customer sees the code running, you have a great deal of information about what the customer wants.
26,
Complete problem description in code that takes the time to write and report exceptions: Programmers tend to be very lazy and throw an exception that is a rough description error. I think they will always be the only one who will see the problem, and they will remember the meaning of the problem from a vague description. However, in the customer support environment, inaccurate or incomplete error reports waste more time than other reasons. Write every error message as if you are explaining the situation to someone who just walks into the room and has no experience with this code. After all, the customer and customer support team have no experience in this Code.
There is no specific sequence for these introductions. You can leave a message to discuss the principles that I ignore, or (if this is the case) agile development principles that you do not agree.
Summary of the 26 best sayings about rapid iterative development and usage of agile development
