Live XP: (4) demand and story
Lin Xing (reprinted from www-900.ibm.com) October 27, 2003
How to analyze demand, how to record demand, how to map demand into design, which is always the most important issue in demand analysis. XP advocates demand in a simple and practical attitude, and demand analysis is the most important workflow in the history of software development. Who is right? story
Everyone likes to listen to the story, which may be the habit of developing from a small. If you can make the demand analysis work into the process of listening to the story, then how good it is. The demand analysts write a beautiful story, and the developers look at the story and the story is realized. Maybe this is the design idea of XP. User story, XP turns demand into a story, abandoning boring and tasteless demand stability. The role of the document is to pass the information, if this sense is lost, there is no use of good documents. However, is it true that the demand document is really meticulous to meet the goal of communication? For most, I am afraid I have seen the thickness of the document. Ok, we can force developers to invest in a lot of energy to study and learn complicated demand documents. But this thick demand document really can record all the needs? Worse, the demand will change, how to maintain this demand document? Recall the principle of lean, we can determine that this way of processing demand will have a lot of waste. The cost of doing demand is perfect, and the project team is familiar with the cost of demand, maintaining the cost of documentation, and solving inconsistent issues. So, we can do a analysis for these points:
Does the demand document have to be perfect? The biggest goal of the demand document is to transfer information from the business person to the developer (of course there will be other purposes, such as part of the contract). So, whether the document is perfect and whether the communication effect is not directly related. How can developers can quickly understand demand? The production of documents is integrated into the maker's idea, so others have always taken a certain amount of time. There are two ways to solve the problem: one is to provide standard general practices; the other is to simplify the document, simple things are always easy to understand, but simple things are not easy. Maintain the cost of the document. Regardless, maintenance costs are always unavoidable, the key is whether this part can be reduced? Maintenance cost and number of documents, complexity is proportional, so the number of documents should be as small as possible, complexity is reduced. In addition, the number of times to reduce maintenance is also one of the key factors. When discussing the principle of lean, we say that as delayed decision-making is this. In response to the above points, XP proposed its own ideas - user story. User story is simple, everyone will write, everyone can understand, it is easy to change. But the user story is just a simple description of the system function, and he does not provide all the requirements, so in XP, in XP, the practice of user story needs the support of the on-site customer. The reason why the user's story is simple, because it is just a contract between developers and customers, more detailed information needs to be supported through the site customers. From the perspective of XP, the user story has such a few effects:
Customers describe themselves, write demand. For any requirement, the most ideal state is the needs of the developer professor customers. The worst case is that developers have written demand instead of customers. There is no doubt that XP requires the best practice. Customers must be able to develop demand themselves, and the prerequisites are to write demand, it should be simple enough, it is easy to master, or it is easy to master. User story is such a simple mechanism. The user's point of view. Excellent demand should be to think about the problem in the user's perspective. It is the user who can use the system, rather than the system. User stories are very good to reach this principle. Because the user story is written on his own position, it shows the user's expectations and opinions. Pay attention to the overall situation, not detail. The difference in demand has precision, the most critical development in the early stages of software development is an overview of a high-order demand, rather than immediate detail. For XP, the most important details of the demand are available through site customers. Field customers provide guidance on demand details at any time. Therefore, the focus of user stories is to completely discover demand as much as possible, and maintain a list of simple demand. The basis for assessment. The need for users to write provides a basis for the estimation of software. Although this basis is relatively thick, with the development of the project, the estimation of development speed will become more accurate. Appropriate estimates in the initial demand, the purpose is to make users have a more intuitive cost concept. This provides guidance for the order in which the user has developed demand. User's own co-ordination arrangement. Developing a user story is like shopping shopping, although each item is useful, but the order and quantity of the last purchase will depend on the thickness of the wallet. After each user story has cost (ie, the estimated estimation), the user can weigh the actual cost and needs and scheduled a seat. Iterative Plan input. The selection of users directly affects the development of the iterative plan. In the first version, users want to implement which needs (by choosing user story), it is estimated, these needs can be implemented in this release, How long is it takes to work. These are the impact of demand for iterative plans. The shortcomings of the story are receiving foreign remittances, and the business people need to record the information about remittance. If the payee account specified by the remittance is the Bank account, the account is processed, if the payee account belongs to the same city's same city, other banks The payee is transferred to the payee by the same city's peers (how to deal with it?), If the payee account belongs to the same industry (other bank in the same place), the remittance will be transferred to the off-site through the bank's account line, and pay the account line Transfer cost (how to deal with it?).
The above is an example of a bank's international settlement business. The short narrative and informal form embodys the simple principles that emphasize XP. The story helps developers and users' relationships. In the above example, we see that the development of the two sides still have certain doubts (ie in parentheses, there is a question mark in parentheses), but this does not affect the creation of the user's story, because this version of the user story will change multiple times. However, from this simple example, we find that there are still some shortcomings in the form of the story: the form of the story is easier to accept, but there are irregular disadvantages. Any description of the needs of the description will save the cost of training, but it has caused a variability. Different people have different understandings about the story and have different understandings for demand. Negantity of demand is very simple, but it is necessary to talk about a demand story is definitely not an easy task. The demand statute is too formalized and formal, resulting in difficult to use, but do not do not have a good practice at all. Keeping balance between forms and usability, it is the key to demanding story. Although the demand story is easy to read, it is difficult to write well. How to control the description of the description, how to decompose demand, how to organize, how to determine the boundary. But XP does not care about this problem, as long as it can function, how to do it. Whether this attitude is correct, we will not evaluate it. However, in practice, a novice often takes a long time to learn the story from the lack of system guidance. For XP, the development of demand is only divided. And the order of order is responsible for being responsible by customers. However, in practice, identifying the order is not just the responsibility of the customer, and developers also need to provide demand priority and risk recommendations. There are some suggestions for the priority here:
The main design is included, or a large number of business entities and typical business rules are included. For such a system representative demand, a high priority should be given. There are major technical risks in demand, such as the needs of the OCR development kit, and the development team has not been related experience. The demand includes important business processes, representing the main design ideas of this software. Demand is representative and it is difficult to estimate, urgently need to be tested for the need to obtain a more precise speed value. Time urgent for demand. Use technology
Use case technology maintains the simple principles of demand, similar examples and forms and user stories very similar, but the use case has its own format, although this format is also defined arbitrary. The focus of use is to represent the behavior of the system. Let's take a look at how to use the case: Main roles: Business personnel level: Business process level front condition: Received funds Basic Process: 1 Business people choose to return the remittance service. 2 Business people enter the necessary remittance related information. 3 Business people will transfer money to the payee account. 3.1 If the payee is the bank account, you will enter the account directly. 3.2 If the payee is the same city's peer (other banks), through the same city's peers to the payee (after proceeding?) 3.3 If the payee account belongs to the same industry (other banks in the same place), then through the bank The account line transfers the remittance to the off-site and pays the cost of the account line transfer (how to deal with it?). Alternative process is missing
It can be seen that the content and user story representing the use case are not too big, but the use case is compared to the format. Although different teams have different formats, in the same team, all steps in the basic processes are used in the same team (different use cases may require different use case formats) represent the business person and system once. Interaction, the process is very simple, but has covered a successful process. We see that every step of the process is highly abstract because the level of this use is the level of business process. (Business process level is just a convention, not standard). The use of the level is divided into the use case. In the above example, the main goal of the use of low-precision is to grasp the system of the system. In RUP, this use case is also referred to as a business case. In the original user story, the description of the branch is relatively vague, but this description of the use case is adopted, the branch situation is clear, as in front, there are many forms of expression of the branch. Use the example technology from proposing now, there have been a lot of experience accumulation. It is not a new thing in the XP project. However, applications in XP must also follow the principles of XP and the idea of lean programming. Fortunately, these ideas are very natural, and the use of use techniques is fully implemented. This article does not intend to describe the use of use techniques. If you need to understand the use of the example technology, there are several books that are very worthwhile (see Appendix).
First grasp the whole picture of the system: When doing demand, a situation that often occurs is that the demand analyst spends a lot of mind to exceed the essence, improve an exemption. For XP, this practice does not recommend, and according to lean principles, this behavior has a waste of waste. Our understanding of the project is constantly in-depth. Therefore, we deepen the details, stories, or use cases at the beginning of the project, and the ability of analysts may be strong, and it is possible to capture the actual needs of users. But after a week, we have possible change in the understanding of the needs, perhaps the definition of the scope of the use case, maybe analyze the effect from another angle to analyze the effects, perhaps the idea of the original handling case is incorrect. Regardless, the possibility of demand variation is very large. The more detailed use of the case, the greater the possibility of change. At this time, it was wasted when it was originally used in the extrigeration case.
Therefore, do not refine the demand at the beginning, the focus of the beginning of the work should be to put as comprehensive collection of use cases, understand the overall business process, analyze the main business process, etc. After obtaining the entire system of the system, you will find that you are not sufficient for your understanding of the system. The use case requires rearrangement according to new ideas. The priority of the use case needs to be adjusted. In the UML map, there is often a system for use. Overview, this picture is shown in an overview of system behavior.
Looking for a high priority high use: we mentioned above to the judgment of demand priority, and the priority judgment of the use case is similar. When we discuss ite, we said that the primary purpose of the previous iteration is to identify the risk of projects. Therefore, looking for a representative, high priority, high-priority, can help developer's faster understanding, and build a preliminary domain model. Continue to the top international settlement example, after completing the total use case, we found that the bank's business is very complicated. If the area is missing, it is very difficult to trade in a short period of time. At the same time, we found that remittance The percentage of business in the daily business is very high, and the remittance business involves most of the domain knowledge, while business processes are relatively simple. Therefore, we decided to first use cases of remittance as a breakthrough. After completing this use case, our developers will have more in-depth understanding of the business field, and they can make more complex work: Main roles: business Personnel Level: Business Process Level Conditions: Received Basic Process: 1 Business Selection Remittance Service. 2 Business people enter the necessary remittance related information. 3 Business people will transfer money to the payee account. 3.1 If the payee is the bank account, you will enter the account directly. 3.2 If the payee is the same city's peer (other banks), through the same city's peers to the payee (after proceeding?) 3.3 If the payee account belongs to the same industry (other banks in the same place), then through the bank The account line transfers the remittance to the off-site and pays the cost of the account line transfer (how to deal with it?). Alternative flow 2. A At any time, business people can query the remittance bank at any time. 2. A1 After receiving the query response from the remittance bank, the reply information is recorded. 2. B At any time, the business personnel received the remittance bank asked to return the authorization of the remittance. 2. B1 If the remittance is not taken, returning the remittance bank as required. 2. B2 If the remittance has been taken, the notice bank cannot handle, the use case ends.
Note that in this example, we have a slightly different cases of the use case priority and the above, we choose representative, but relatively simple use as a high priority. This is because it is more unfamiliar to the business field, and it is very difficult to achieve complex demand at the beginning. So, although we provide some ideas for developing use case priorities, it still needs to be balanced according to the actual situation. Iterative refinement: The writing process of the use case is a process that is constantly familiar with the business. With the in-depth research, there is a continuous new problem revealed, and it is necessary to supplement or modify the original use case. There are two situations here, one is in the same increment, when the use case b is refinered, discovery is ignored in the use case A, which will need to add case A. For example, when we refine other use cases, we discovered the needs of the report in the exchange case, so our work must return to the remittance case. This is very common, which requires us not to excessively modify the use case, do not spend the energy in use case format, which only causes waste.
The second case is in different increments, this at this time will often join new demand, new situations. How do we control iterations during different increments? In general, there are two methods, one is to supplement the original use case, and the additional portion is used in different colors or marks. Another method is to establish a version for use, and the use cases of different versions correspond to different increment cycles. In this way, the corresponding use of N different versions of the use case (N ≤ N) corresponding to the N increment cycles. No matter which case, we have to use iteration ideas to handle the use case. The form is not the most important: in the team, it is meaningful to write a uniform writing format, but sometimes, this significance does not think so much. You can agree on the conditions of the conditions, or the level of division can also be agreed. But there is no significance of excessive mandatory forms.
