Live XP: (2) Assessment and evaluation
Lin Xing (reprinted from www-900.ibm.com) October 27, 2003
Spiral, iteration, increment, different nouns represent the same meaning - phased development software. Numerous methodology has used this idea design software process. However, in practice, more time, phased development software brings pain. It seems that we are often confused by the beautiful narratives in the book, but there is no problem that really wants to implement the implementation. So how do you manage the development of software in phases? How to deal with the problem in reality? Assessment and evaluation
In performance management, there are two nouns: assessment and evaluation, respectively, in two performance management methods, respectively. What is the difference between the two?
We said that the assessment is a system, and the assessment is a process. How to understand? Many companies have a system of performance appraisal. This system is generally an assessment of employees at the end of the year. The assessment is a point. But the assessment is different, the assessment is aimed at the shortcomings in the employee work in a certain period of time, and it needs to be improved. Whether it is an assessment or an assessment, although they are designed to achieve the purpose of evaluating and improving employee behavior, the practice is different. Assessment for the past, it is easy to implement, but the effect is not good, because time is long, everyone may forget the previous things, and to be equally made to make a assessment of the past year, it is not an easy thing. The assessment is different, and the assessment is continuously carried out, and the evaluation of the just happened and found improved methods. It is like an example of our takeaway store in the first chapter, constantly analyzing and improves the process, which is an assessment. The evaluation is good, but it is difficult to achieve.
Assessment and evaluation in software development
This idea is direct as the idea of milestones and iterations during the software. We can think about it, milestones are not a system. At the end of the demand, we need a series of documents that require the statute document, risk list, etc., we also need other documents when design is over. This method of processing is the idea of assessment. But many times, this assessment is limitless:
The workpiece is designed to assist in the generation of the final code, but it tends to be designed by a milestone;
Milestone design is not fully captured, some of the risk is hidden; it is difficult to evaluate workload and work value; milestones have exposed problems far behind the time; here is some ways to do some ways analysis. Our understanding of the problem is often gradually deepening. There is problems in business and technology at the beginning of the project, there is uncertainty and risk, which is often the most important assessment and verification. However, milestones often require in-depth analysis needs, and many problems are not resolved, but they are quietly intended to cover up. Demand is not software, it is a model of different people with different understandings. At this time, the roles in the project are different, but this does not affect their consistent decisions - through demand milestones. The problem is still in the design phase. Some of the problems hidden in the demand phase began to appear, resulting in some workloads. But all issues have not been resolved, and there is still unknown risks. So when will I expose? The most optimistic situation is found during the coding period, the most pessimistic situation is found during the delivery period. We call this process as the curing assessment process. Where is the problem? In addition to the software itself, the model is good, the document will not be replaced by the final code. In lean principles, we said that waste must be eliminated. When we are developing a workpiece, our waste has arisen more or less. With the curing assessment process, we believe there is another dynamic evaluation process. Milestones or checkpoints are not not important. But we need to convert ideas to make better practices in miletones. We mention that the biggest problem in mid ways is to wait until the problem has accumulated to solve the problem, and this time often missed the best time to solve the problem. The meaning of the dynamic evaluation process is to discover and solve problems in the process, rather than waiting to have a certain degree of mass solving. Process As the environment changes continuously, the process is constantly adjusted to adapt to the needs of variations and uncertainty. The milestone is focused on providing a review opportunity to evaluate the software from a higher level. This process is the idea of phased development software, and we can also call it iteration, spiral, increment, has no relationship. The key is that we need to discover the problem that the customer is not satisfactory, find the method of improving the phone, discovering the way to improve the food, and find faster delivery. Implementation strategy
The dynamic assessment process has some basic implementation ideas, the first basic idea is to discover all the questions as early as possible, how to find it? Perform an exploration process. This process cycle is not too long, too long cycle is easy to out of control, and the initial number of projects may not be able to all in place; but this cycle is not too short, too short cycle can't find sufficient risks, unable to provide subsequent processes Rich data.
Sometimes we use prototypes to implement this mini process. The prototype method includes a demand prototype and a technology prototype, which is used to solve business risks and technological risks. A typical demand prototype is to build an interface prototype to help customers understand future software and avoid abstract thinking. I have seen many interface prototypes, with HTML, have the use of the drawing software, using the usage of XML. But no matter what, the main type can help users can understand the needs. The main goal of technical prototype is to solve technical risks, and any project may exist like such or such technical risks. The basic attitude towards the risk is as early as possible to assess risks and develop solutions, rather than bunch. The solution of technical risk is determined by specific situations, but it is worth noting that a project is not too much in a project. If this is true, you want to find an experienced mentor or a trainer, which is better than yourself to save many costs.
XP's evaluation of the exploration process mainly includes two aspects, spike solution and iteration. Spike Solution is actually the technology prototype we mentioned above. Its purpose is to make an unclear assessment becoming a clear assessment (see spike in the XP process diagram). Only the assessment is accurate, the plan can be accurate. So it is an input item for plans and iterations. As for iteration, it is an important concept in XP. Iteration Select the user needs (called user story) and designs, develops, tests, and iterates continuous repeat and solves a variety of problems. After passing by the user's test and recognition, a version that can be run is generated. This version is produced, marks a set of iterative cycles. The first small version is exactly the exploration process we emphasized. Its success and lesson is enough to let you understand the various knowledge of the project, including the complicated organization of the customer, the exact intention of the investor, find out all the people, discover the use case, make the team members and customers reach a preliminary consensus, verification Technical solutions, establish a preliminary software architecture, or preliminary mappings for existing architectures, programmers need additional training, the test power does not seem enough, the risk of deploying the environment needs to be resolved in advance. Only if you really do this in the complete life cycle, these issues will expose at the beginning, otherwise, many of them will give you a lot of trouble in subsequent phases. The second basic idea is incremental development. What is the difference between incremental and iteration? Alistair Cockburn In the Surviving Object-Oriented Projects book, the incremental description is amended or improved development process, and the image statement is gradually completing software development. Note that the small version in the XP process diagram is an increment. XP believes that an increment should be available. It is good to do this, but not all projects can achieve this goal. For example, the first incremental target may primarily define an architecture, which does not include the functions required by the user, but it is the basis of project development. The architecture may include a series of frameworks such as a business entity infrastructure, a data manipulation infrastructure. However, for XP, it is not worth speaking on the framework that the user cannot find value is not worth it. The XP advocates is gradually improved the architecture based on the development of demand, rather than spending energy development architecture at the beginning of the project. It is difficult to evaluate which statement is correct, I prefer to spend an architecture design in the previous period, but in practice, it has been designed to be more complicated to lead to high cost. After spending a large amount of time, I found that in fact, the simple attribute can handle most of the situation, no doubt, the previous design is put into drift. Therefore, it is important to trade in the early stage of input. Ideally, you already have a reusable framework (or architecture) so that you can map the demand for the project to the frame, instead take time to develop a framework at the beginning of the project. If you don't have a framework, take a certain time to develop the architecture at the beginning of the project, but this time should not be too long, you can improve the architecture in subsequent increments, so you don't have to rush. Moreover, a simple framework (architecture) is not a way to perform testing, and your test has to postpone the second increment. This reason also promotes us to shorten the period of the frame design.
It is iterative is improved or corrected software quality. This is also the third basic idea. We pay attention to iterations in the XP process diagram, multiple iterations constitute an increment (small version), each iteration is an improvement to the previous iteration, which may be amended, or demand defect . It is worth noting that new demand changes may occur in iterations (new demand or demand changes), and the project staff will understand the progress of the project (Project Velocity), which will in turn affect the planned correction. This reflects the attitude of our XP treated plan in the previous chapter. There is no legal provision for iterative needs and incrementation, but it is obvious that combining these two ways is an effective approach. The goal of increment is to allow the project to advance (this is like the road, the length of the road is growing), and the iteration goal is to make the software quality better (just like a roadbed on a road, Wash cement, building pavement facilities). This makes us think of what, good, refactorful two hat. A hat is adding new features for software, and a hat is an improved software quality. Very similar, just one is the process level, one is the program level. There is a basic assumption here, do not increase function and improve quality. The team is also good, personal, once only one target efficiency is the highest.
Think
And traditional definition issues, then solve the problem of different practices, XP is highly refined from step-by-step. The problem definition and mathematics in software development is different. It is often blurred, dynamic, and needs to continue to adjust the problem in the process of solving the problem. For XP, this solution idea reflects its feedback - obtaining customers' feedback on software as soon as possible.
