First, introduction
In the past decade, many agile software development methods have been seen, and these methods have hoped to replace traditional waterfall development models. In the waterfall development model, software development is divided into a series of phases, including:
l Collect user needs
l system design
l development
l test
l Deployment
The waterfall development model is based on such a hypothesis that: each stage of the development process is 100% completed at the next stage. This also leads to a biggest shortcoming of the waterfall development model: Design error is often necessary to discover when the program is deployed, and at this time, the project has been close to the end, and the cost of repairing the error is huge.
XP and FDD are wanted to avoid the shortcomings of the waterfall development model through iterative development, each iteration means that all the steps described above (usually 1-3 weeks), this is guaranteed Even if there is an error in design, it can also be discovered in the development.
Extreme Programming
XP was originally an development method that tried to simplify and improve software development. Most software project development is seen as a careful demand for users, while XP focuses on emphasizing users' greatest.
The start of the XP project is to collect the user material (User Story), and the user material is written by the user, which is a text-independent text that provides a detailed description of some special scenes, not the complexity of the system. All details of the user material must be confirmed by the customer before it implements.
Then, it is a development plan. Publishing Plan determines which user material needs to be implemented in the release version of the system. Each release has several iterations, each iterates some user material. One iteration includes the following stage:
l Program: Select the user material to be implemented and the details it wants to be clear
l Encoding: implementing user material
l Test: At least Each class has the corresponding unit test
l Acceptance test: If the test is successful, the new function development is completed; if it fails, enter the next iteration
The essence of XP is mainly:
l Simple: the simplest design, you can work for Work. In most projects, developers often use most of the time to design some universal solutions to adapt to future user needs, run platforms, etc. It is important to know that most changes are not the initial imagination of developers.
l Communication: This includes communication between developers, as well as communicating with developers and customers. Communication is the key to success, as developers often do not understand or misunderstand the needs of users, resulting in inconsistency in developing systems and customers.
l Test: Test is the foundation of XP. XP Practice is that each developer can modify any code when any need, if bug is introduced, the unit test should be able to understand the capture bug.
2. Feature Driven development
FDD is made by Jeff de Luca and Peter Code. FDD is more formal than XP on demand and development steps and also has accurate tracking progress.
The FDD development process mainly includes two stages:
l Determine the character set to be implemented
l Take a set of characteristics at a time
Determine the feature set is a very stringent process. The quality of this step will affect the accuracy of the project being tracked, and the code has maintainable and scalable capabilities. This process requires customers to participate in full-time, and the product of this process is a set of UML diagrams that describe the problem domain.
A series of features from the UML diagram, which is described in the language that customers and developers can understand. Example of a shopping cart: Customer wants to log in to the online store to buy goods, the UML map may include these types of pictures: shopping car, item item, customer class. The character set of this UML map may be as follows: l Create a shopping cart for customers
l Add a new item to the shopping cart
l Recount items in shopping carts
l Check the price of all items in the shopping cart
These features are very valuable to users because it directly reflects the functions of this software, which is also small enough, which can be completed in one development iteration.
Before the feature is achieved, it is first set to the related feature into one work bag, and a work package should be completed in one iteration, usually take 1-3 weeks. Each iterative content includes:
l Starting meeting of Workpack: Detailed description of features included
l Design: Create a must-have class, method, and related documentation
l Design review: review the design, or accept, or refuse
l Develop: implementation and unit test
l Code Review Conference: Execute Code Same Journal
l Release meeting: Integrate the features that have been implemented
3. Vision Statement
Whether FDD, or XP, is a lightweight software development method. Using traditional software development methods, projects have never been well managed because there are too many rules that need to be observed. FDD and XP only contains traditional waterfall development process activities, although the number of activities selected are different, this decides that there are different applicability these two methods:
l XP is more suitable for unstable projects, and users' demand may be very unclear. XP can be handled well for such projects because it deliberately postponed the current unnecessary activities to the back.
l Compared to FDD, XP is suitable for small-scale development. Because XP is largely dependent on the communication of the project group, however, the greater the team, the more difficult communication will
l For FDD, if the demand is relatively stable, it has a good predictability.
l FDD can track the progress of the project, which is necessary for project development in many companies.
Second, collect user needs
This chapter mainly describes the process of user demand collected in software projects. Traditional user needs are written on the document and have a detailed description of the system to be implemented, and as an important basis for the follow-up development phase:
l Must implement all listed needs on this document
l Compare the document and the actual development of the system to perform the acceptance test.
Use examples, using scenarios, non-functional needs, and many other methods are used to describe the interaction of users and systems to achieve user needs.
The main disadvantage of this method is to collect all the needs of the user in advance, and then the customer stops participation. In this way, once the user needs to have erroneous or misunderstood, only the later period of the project can only be found. At this time, it is necessary to fix it.
XP and FDD collect user needs are different from traditional user needs collection methods, but both have great differences.
1. XP: Collect User Material (User Story)
XP is quite small in collecting time in collecting user needs. Users' needs are expressed in a short story. The purpose of these stories is to understand the scope of the project and can be more accurately estimated. The collection process of the user material is largely dependent on the specific item, generally no more than two weeks. 60-100 user material in each release plan is enough. The details of each material will be discussed with our customers before each iterative schedule meeting. The collection process of this lightweight user needs can be facilitated. 2. FDD: Build a problem domain
However, for the FDD project, it is very important to collect the user's demand process. It is the key to the success of the project, so we usually call him "process one". Process One's work product is a UML diagram and a set of feature sets, and the UML diagram defines the problem domain of the software system. If this process can be achieved well, it should cover most of the business, and it is easy to add new features in subsequent versions. The generated feature is also the basis for the project time range, so that the project can be easily tracked. Therefore, FDD is the same as the dependence of user needs and waterfall development. Since the demand collection process is important, we can better improve this process, allowing developers and customers to fully participate in this process.
This process requires developers to be familiar with UML, and at the same time, customers representatives and domain experts must participate. The modeling process can use UML in Color, which is a variant of the UML introduced by Peter Code.
Modeling itself also requires multiple iterations, and each iteration begins with a user material of a business piece. The development group can be divided into several modeling groups: Each team includes developers and domain experts. Each group uses UML modeling to express the same user material. Various groups can present and discuss their models at any time. At the end of the iteration, select a better model from these models. This construction model will continue until the entire problem domain model of reacting all user materials.
A good problem domain model should completely cover the customer's business, it should be stable: the user may change the demand for the application, but the business should be constant, stable. In addition to establishing an object-oriented model of the business, Process One can indirectly see the time continuing during the development phase. The FDD's thumb rule is said: Two weeks modeling should allow the development team to work for 6 months.
Third, design and documentation
XP will jump this process. Personnel developed with XP recommendation to react to design, write documents as possible.
FDD does not have to write design documents. After Process One, developers tend to document the description of the UML map and some alternatives. This document may have a lot of use in the later stage, especially for projects with long development cycles, developers often forget the original design, and the document can be reminded. If the customer requires, formal user needs can also be written in this document.
However, FDD requires many formal documents, which is the purpose of trying to make the information information to be disclosed. These information can be placed on the company's internal Internet, the public information can be: developer list, sponsors, and domain experts, UML models and annotations, code specification, tools, unit test reports, progress reports, and more.
Fourth, development and testing
FDD and XP are developed in a short ate. This chapter explains the content iteration of these two development methods, mainly the difference between the two in development practices.
FDD and XP first have different structures on the team. FDD requires a few CP (Chief Programmer) and requires CP to have extensive experience in the team, which can act as a technical leader's role, and you can assume some other responsibilities. In the team's hierarchy, CP should live between project managers and developers. However, there is no such hierarchy in the XP team.
Iterative plan
Both development methods are the beginning of an iteration in a formal planning meeting, but it is slightly different in the implementation. 1) XP plan
First, customers choose a subscriber material to be implemented, and the development team discusses and determines the details of the user material with the customer, then rewriting the user material in the developer, and estimates the time required for this iteration. For the bugs and failed unit tests that appear in the previous iteration, you can add this iterative task.
2) FDD plan
CP first prepares an iterative planning meeting to organization the appropriate quantity related feature into a work package. Usually a team has several CPs, each CP is responsible for an iteration alone. Whenever the new iteration begins, CP selects a developer to organize an iterative group according to the situation, and then each developer is responsible for some feature sets. In FDD, the code responsibility system is strongly recommended. The entire team finally completed all the character sets of iterative iterative. If necessary, developers should contact the customer at any time to confirm the fuzzy feature. When encountering complex situations, the team also needs to draw a sequence map. The planned meeting also needs to establish time constraints to iteration milestones.
3) The difference between the two
The main difference is that in XP, iterations are performed throughout the team, while the FDD is a temporary team that makes up 3-5 people to be responsible for each iteration, so the advantage of FDD is: because the team is small, communication is very convenient.
Iterations in XP have self-adjusting features, each iteration, bugs can wait until the next iteration is repaired, failing unit tests can be managed in the next iteration to pass. In this way, if the user's material selected in one iteration is too much, it will continue until the next iteration, resulting in the next iteration, will not increase too much user material.
FDD has two more good mechanisms:
l CP's rich experience
l If a developer can't complete the task, it will not reduce the progress of the entire development team, because other teams are in parallel.
XP is divided into a clear stage during the entire iteration, and the daily activities seem to be almost. And FDD is different, it has many milestones:
l Iterative Planning Conference
l design phase
l Design Review Meeting
l coding stage
l code evaluation meeting
l integration
FDD allows us to track the entire iterative process, especially the cycle of iterations (such as 3 weeks). However, if the iterative cycle is very short (such as one week), the management cost of frequent meetings will be high.
2. Design and review
XP has no formal design phase, and the design is generally only performed when it iterates and later.
FDD has a design phase and design review meeting. In the design phase, developers declare the main types, methods, and attributes of the features to be implemented, and it is best to document according to the form of code annotation, and want Java DOC. When the design is over, each member of the team can get a copy of the design of others, and everyone can provide advice on each other at the design review meeting, but in order to save the meeting time, the review work should be completed before the meeting. .
The FDD Design Review Conference is designed to discover some of the wrong decisions in iteration to avoid the entire iteration deviation direction. If each member is designed, there is no problem, then it can be developed. In order to prevent the scope of the conference, it is recommended that the iterative team should be small, including CP, preferably no more than 5 people. One advantage of FDD is to generate a certain amount of code document.
XP does not believe in code documentation. Although XP does not have a specific design phase, its development process is also controlled in a daily meeting, and the knuckle programming also prevents the risk of erroneous design.
3. Coding stage
XP and FDD are very concerned about this stage, although the process of both is very different. They all emphasize the preparation of standard code so that the developer will be easier to read each other, the code is not easy to errors, and the code evaluation efficiency will increase. XP and FDD also emphasize unit testing, and the test code can be done before encoding (TDD) or after it is completed. XP strongly requires the test code to be written, and then the encoding is completed. The FDD does not have this requirement, as long as each class has a test case.
1) Encoding in XP
XP only code, XP encoding process contains many activities. The most famous is the knuggling programming proposed by XP, two developers sit in front of the computer, one in writing code, two people are thinking. At first glance, it seems to be wasted, but the actual situation is the opposite. The reason is as follows:
l In completed code, two people can communicate at any time
l The process of encoding is also the process of code review
l This will grow faster developers who have less experience.
L people often take some time in other things, such as reading the email, browse some webpages, etc.
XP advocates reconstruction. Reconstruction is to increase code quality without changing the function.
XP refuses the code responsibility system, and everyone else can modify each person. By browsing and modifying other people, it is sometimes increasing the system's comprehensive understanding of the system. If someone leaves the team, it will not have a lot of impact. Of course, it must be limited to: No code to understand is not allowed to modify it.
2) Coding in FDD
The encoding in the FDD is not exciting and challenging. Because the feature to be implemented before the coding begins, there is already a full discussion in the Process One process, iterative launch conference, and design review conference. The class and methods are completely defined, and they are described in detail in the code document, and the encoding is basically mechanical activity.
Unlike XP, FDD does not agree with reconstruction. The main debate against the reconstruction is that people think that the reconstruction costs do not bring the value of a dock to customers. The code evaluation meeting should ensure the quality of the code.
FDD strongly recommended code responsibility system, the main reason is that each developer is familiar with your own code, which can better facing a series of changes.
What should I do if the team member left? FDD provides guarantees from the following aspects:
l Sufficient code document, so understanding the code of others is relatively simple.
l Developers generally know what others do, because they all participated in design reviews.
l When the code is evaluated, the developer can read the code of others.
4. Code review
There are several important goals in the code review:
Discover the error in the code. The code review is the error in the code, especially when the unit test is more suffering, especially the unit test, such as the UI, and discovered that the code error mainly rely on code review.
l Strengthen code specification
l Get rapidly improved developers, share best programming practices
l Make developers familiar with each other's code
FDD has a formal meeting called "Code Review Conference". During the iterative process, each developer prints its own code and then distributes it to other members. The code review should begin before the Code Review Conference, and the meeting should only use it to discuss the proposed issues and propose solutions.
In terms of code review, XP and FDD have their own advantages and disadvantages:
l In XP, the code review is completed when the knuckle is programmed.
l In FDD, the code is reviewed by many people. Because in general, in the knuckle programming, a person can review another special problem can only find some special issues, and there may be some other questions that cannot be found that the code review in L FDD is separated. In this way, if the iterative development is longer, or if the team member exceeds 5, the code review will be very inefficient. Because a large number of code needs to be reviewed during a long iteration, people's attention may be dispersed when the code is evaluated, and the potential bug will increase.
V. Deployment
During the waterfall development process, the deployment is usually the final stage of project development. When all the code is completed and the test is completed, the deployment begins. The deployment phase may not have much relationship with the development method used in the development phase. Typically, some major companies will establish a separate environment for product deployment, testing, and integration.
XP and FDD include deployment in their iterative cycle, but because of the above reasons, it is generally not true deployment to the product environment. However, the application needs to be integrated and running, to the customer, by the customer uses the implemented features and then feedback.
However, sometimes some special situations are constant integration that cannot continue.
XP's practice requires customer representatives to be members of the development team, and one of their responsibilities is to use the system being developed. However, FDD does not require customers to participate, because many of the FDD can ensure timely feedback.
Six, tracking progress
The ability to track the project is very important. Only those small items or internal projects may not have to progress. For large projects or external projects, their progress must be tracked. One feature of the waterfall model is that progress tracking is relatively rough. Generally, all phases of a project must explicitly give the percentage of completion so that the project manager can report to the management layer above. The new development method is still better in this area.
1. Foundation tracking in XP
XP does not provide anything for progress tracking, which ensures that progress is visible. New features of each new iteration increase can be tested through the user's acceptance test. However, if you want to find out when the project is completed, XP is more difficult. One way is to compare the completed user material and unfinished user material to calculate. However, it is obvious that this is very incorrect, because sometimes it may generate a new user material in achieving a user material.
XP is and agile, it is only applicable to projects that require unclear or demand, in which case the date of the project may not make much sense.
2. Progress tracking in FDD
FDD improves the ability to accurately track progress, which is based on the following facts:
l After the Process One, all the features to be implemented have been clear.
l Each iteration has a defined period and gives the percentage of completion. As shown below
Domain Walkthrough Design Despect Code Code Inspection Promote To Build 1% 40% 3% 45% 10% 1%
This way we can calculate the date of the project, and generate progress tracking reports. Handmade these reports are relatively high, so the FDD project requires tools to automatically generate these reports.
FDD is also facing the problem of project completion. Jeff DE LUCA refers to the FDD method allows items to have 10% change without postponed the final deadline of the project. He believes that changes in the software system should not change the business itself. Therefore, the problem domain should always reflect the correct business view. The increase in new demand should not affect most of the features that have been implemented.
Seven, summary and conclusion
This chapter mainly summarizes the main contents of other chapters. Since the author personally participates in XP and FDD project, there is the following conclusions:
l XP and FDD are the shortcomings of waterfall development by iterative development.
L Both are light design methods, but XP is more "light", it does not need to generate code documentation, and the code review is a project that is unaptified L XP more suitable for demand variations or very unclear demand.
l FDD is not good at shooting the moving target, but once the demand is quite stable, its success is much higher than the waterfall model
l FDD has a better team size, the development team's hierarchy makes the project, it, iterative team can still maintain a small scale.
l FDD provides good progress tracking capabilities and reporting capabilities, so that high-level leaders can understand the progress of project progress.
l FDD can also be manually managed, but if there is an auxiliary tool, it can reduce the maintenance of the feature database and automatic generation schedule report. XP doesn't seem to need any special tools
l The FDD method is very suitable for the case of team membership, because the most experienced can do CP. However, if you are in a small team, everyone is similar, and there may be resource waste.
l The two methods require strict discipline, and the project manager needs
l The two methods have absorbed many other technologies that have excellent development methods. My favorite is the unit test and code review
