26 Tips on Agile development

26 Tips on Agile development

I collect all kinds of words of wisdom. I've been working on Agile software Development lately. Here are 26 core principles that can guide Agile software development teams.

Use case one is fully capable of running and then developing use case two. There is a saying in the kitchen that the problem can be confirmed: "Make a dish and you'll do the next one." One of the biggest problems with software development is that people like to develop multiple tasks in parallel. Because inevitably, some of the features we design will be discarded and cut off, and if developed in advance, it is likely to be useless. Develop only one use case at a time (or very few use cases, depending on the size of your development team), make the use case functional, make the corresponding test cases pass, and the corresponding text will be completed; only after the current use case has been fully developed is it submitted to the repository as a whole for the next use case.

Avoid submitting a semi-finished product. This is a point that everyone seems to know, but this principle must be included in any development guide. The programmer who is able to listen to these tips for development testing and then submits the code will certainly not occur when the code is submitted to the repository so that the entire project cannot compile the code through the situation. If the system fails to compile, it must have been a shortcut.

Do not design a generic module without any use cases. You can implement a specific class only if you know of a specific use case, and you should only implement the methods that are required by the current use case in that class. You may think that in the future this class will have other uses, you can record it in the form of annotations, but do not implement it, only if you have a specific use case you can implement it.

Be sure not to add member methods to your class without using an example. This is very similar to the one above, except for data members. Developers can easily imagine that a ' customer record ' should have a ' shipping address ', but do not implement this attribute without any use cases requiring this attribute.

don't be afraid to make decisions, don't be afraid to change your previous decisions. The goal of agile development is to address the uncertainty of customer demand. You can't get all the information in the early stages of development. You should delay the decision as much as possible, but once you decide, you should make a decision to move the project forward. You can't say that you wait until you have enough information to make a decision. Instead, you rely on existing information to make the most correct decisions. Then, when new information appears, don't be afraid to make changes to the previous decision. (Elders people call it a trigger, but I call it change with the environment)

Constantly understand how to improve the system. There is no end to this work, you should be prepared to continue to look for improvements in the area, collect a variety of questions about how to find quality problems, solve the quality problem cases.

Review, review, review. Agile development can help us cope with the uncertainty of demand in the future, but there are uncertainties in the past. Test work can never be stopped. The performance of each run of the program is reviewed and recorded.

The design of software should be people-oriented, not system. Many developers retreat to the second, technology-centric, let the design for technical services. Never forget that the ultimate goal of software is to help people get the job done.

Testing is part of the product. Many developers and managers believe that the product is what you package to the customer, and the rest is unimportant. In fact, testing should also be regarded as the actual part of the product, should be given considerable attention in design, and even, in many cases, testing function should be submitted to the customer together with the product. (A lot of people don't agree with that, a built-in self-test package doesn't take up much extra resources, but when you need it, you'll find it's great value.) )

Write the test case first, then write the code. Test cases can be used to accurately describe our design needs. Many times we have found problems in our design by running test cases. Think about how much time you can save by writing a test case first. However: After writing test Case 1 and then writing use case 1, use case 2 is complete.

Clean up the junk code. Clearly, it is a well-known truth, but it must also be written into any development principle, because it is so important. Find the Junk code work never ends, find it, destroy it. To get rid of all the code that doesn't bring value to real users. If you can't point out that a piece of code is useful to the user, it's probably useless.

Cultivate the habit of immediately reacting to integration failures. You understand that when an integration build fails, it affects everyone in the project, so there's nothing more important than getting the core program to integrate and test correctly. I have seen some teams that have integrated builds that have been interrupted for months without taking care of it because they have other work to do. Everyone is suffering from this situation, but no one is taking action. We should understand that it is widely recognized that as long as a little bit of work is done, the whole team will get a great return.

Every member of the team needs to know what the customer wants. Large and complex projects have to be split into separate teams to develop and distribute to each developer, but this must not become a programmer who does not understand what the user's needs and goals are for the end product to be used.

Put things together that relate to meaning. Organize your code so that highly relevant things are put together, that is, in a class. This is the concept of encapsulation in the standard object-oriented design principle. Ideally, programs outside the class do not need to know the details of the work in the class. Some developers like to put the code in several files in order to organize them in another way: such as putting together the same data types, or sorting alphabetically. For example, someone would put all of the constants in a class under a single package, and they did so unnecessarily, adding to the complexity of the program. As a guideline, they should be grouped by relevance to reduce complexity.

Commit the code before testing. This guideline allows you to ensure that the "Never Let Integration Build fail" criterion.

Premature optimization is the source of the disaster. This is a quote from Don Knuth, and today sounds a bit good. The code in the kernel should do its best to avoid waste, but optimizations for levels higher than a single method should be done after the entire project test passes and the stress test case for the end-user is passed. It is often wrong to judge only the static code that is the main problem that affects the overall performance. Instead, review the performance of the system as a whole, and find the code that really affects 1% of the behavior, optimized for that code only.

The work package (backlog) that minimizes the unfinished coding task. When developers develop a design use case, some functionality involves all the modified code that is not fully developed and fully tested. Save the unmodified code to a local for days or weeks, which increases the risk of work waste and rework occurs. Imagine that there are three missions, each of which is estimated to be one day. If three are developed together, it takes 3 days for each of them to be parallel, so there is a risk of 9 ' units ' in total. If the sequence of development, one development after the completion of another, there will only be 3 ' units ' risk. This does not accord with our intuition. Our intuition tells us that when we are in this situation, we want three to be done together. But software doesn't look like a house. Small, fast, complete tasks not only reduce our cognitive load, but also reduce the interplay of ongoing development with the ongoing development of other people.

Do not over-function the paradigm. That's what we call "yagni–you aren t going to need It". Programmers like to expect when writing a class: This class might have other uses in other classes elsewhere. If these uses are used by the current use case, then this is true, but often developers think of these uses that are not currently present and may actually be used for ever. (This subject all reminds me of the classic Saturday night Live skit about the product which is both a floor wax, and A dessert topping.)

If two lines of code can be completed, do not write three lines. Concise code will always be good for those who need to read this piece of code. But don't compress the code hard to understand. Thin, well-written code is easy to maintain and find errors, and lengthy, much-modified code is the opposite. Be as simple as possible, but not excessive.

Never judge a terminal by the number of rows. The number of lines of code generated by writing a task varies by programmer, depending on the coding style. The number of lines in the code does not provide any information about the completion of the program and the quality of the code. Code quality can be 200 times times the difference, which is not the way to calculate the number of lines of code. You should calculate the number of functional cases.

We should continue to design, re-analysis. You should be very careful when applying this article, because some of the code is fragile and difficult to maintain. But don't be afraid to modify the code and make it fit the real needs. A data member was previously integer, but now there is a use case that requires it to be floating point, don't be afraid to change it, as long as you follow the steps: Test, write the document, deployment.

Delete the dead code. When we find that there is a large piece of code that we do not understand, we are accustomed to "where the dead Dog lies". For example, we need to add a new method to the class to replace the old method, and the general people will keep the old method ' safekeeping '. In fact, we should take some time to check to see if the old method is still useful, and if there is no evidence that it is useful, it should be deleted. A worse mistake is to comment out the code and leave a bunch of comment codes. Once the commented out code is deleted, it cannot be saved to the test and even submitted to the code base. It's always easy to add code, and it's always difficult to remove code. So, once you find a potentially useless code, you should spend some time confirming it, deleting it, and making the code more maintainable.

Don't be creative in your own language. Programmers like to use text files to achieve functional movement, which can make the program configurable. The consequences of changing software behavior through configuration files are not controlled. The advent of XML has prompted a series of special custom ' scripting languages ' that people try to configure in order for the end user to ' program ' to control the functionality of the software and to avoid recompiling. The flaw in this design is that the precise definition of the various operations in the software cannot be accurately defined without the specific implementation of the context. These various scripting languages are only valuable to those who have a background in the internal working mechanism of software code. Therefore, it is impossible for a real end user to know the internal working mechanism of the software, and it is impossible to infer what the expected result of these complex combinations of instructions will produce. Scripts have their uses and should not be resisted, but designers must use them in a very, very safe way, using the existing language as much as possible, without using the language of the new invention.

The design is determined only when it is ready for implementation and testing. I should have a general understanding of what we are going to do, there should be an overarching architectural goal, not a detailed design, a detailed approach to the implementation of the specific method, only when the development iteration to a certain extent, enough to let us set the design details before we go to show it as a document. The detailed design should include only those parts of the current requirements use case that need to be overwritten. The biggest waste in software development is that you spend time designing things and being told that you don't need them, or that your design is based on false assumptions from the start.

The software is plastic. Software is not like building a house, we can easily change beyond recognition. Countless facts indicate that the software is more fickle than its specifications. Moreover, the interaction between software products and designs is significantly more efficient than the specification. So, you should implement your design directly so that customers can easily understand the details of your design. When it comes to finding a problem and changing the design, it's much easier to modify the software than to modify the document. What's more, when a customer sees a program that can run, you'll be better able to figure out what the customer wants.

please spend a little more time describing the detected and reported anomalies. Programmers are generally very lazy, throwing exceptions to describe only the wrong surface phenomenon. Imagine that if only the author himself would encounter such a mistake, he would remember what it meant to have been using the error description information. But in the context of customer support, they wasted a lot of time with this inaccurate, incomplete description of the error. This information should reach the point where a person who has just walked into the house without any experience can see it clearly. Customers and customer service are basically people who do not understand the programming.

Copyright NOTICE: Welcome reprint, Hope in your reprint at the same time, add the original address, thank you with

26 Tips on Agile development