Document directory
- What is feature:
- Feature-driven development definition:
- FDD process:
- Roles in FDD
- FDD-related measurements
- FDD Best Practices
- Views:
- Ozzzzzz:
- Coloruml can be expressed in one sentence.
- Develop a comprehensive model
- Ozzzzzz:
What is feature: the unit of development and thus an increment in an FDD project-a feature-is tiny ;... Features (tiny, granular pieces of client-valued function) are being completed every week in an FDD project. Feature feature, as a Development Unit, is also an increment in the FDD project. It refers to "the smallest useful feature in the user's eyes" and can be implemented within one week. Feature-driven development definition: The feature-driven development (FDD-feature Driven Development) method is a kind of agile software development process developed by Jeff De Luca, Eric Lefebvre, and Peter Coad. It emphasizes feature-driven and fast iteration, which ensures rapid development and proper documentation and quality, and is very suitable for Development and Management of Small and Medium teams. Each function is developed for no more than two weeks. It defines the granularity for each case user case and has good enforceability. It can also precisely and timely monitor the development process of the project. It captures the core issue areas of software development, that is, correct and timely construction of software. FDD also breaks the traditional barrier of isolating domain and business experts/analysts from designers and implementers. Analysts are freed from abstract work and directly involved in system construction work by developers and users. FDD process: FDD is a model-driven and short-term iteration process. Note: FDD is a development process with a starting point and an ending point. The starting point of FDD is to create a global model profile (which is not required to be accurate, but probably looks like it ), then there is a series of "Design by feature, build by feature" iterations with a cycle less than two weeks, gradually enriching the model features. The development process of an FDD is shown in figure 1 in attachment. It consists of five activities: 1. develop a global model (develop an overall model) four-color prototype (http://www.jdon.com/mda/archetypes.html) Field drive design 2. build feature list describes features in the following format:-For features: <action> the <result> <by | for | of | to> A (n) <Object>-for function set: <action> <-ing> A (n) <Object>-for main function set: <Object> Management 3. plan by Feature 4. design by feature 5. build by feature: role 1 in FDD. domain expert (s): domain expert 2. chief arc Hitect (s): lead architect 3. chief programmer (s): The main programmer feature team is generally composed of domain expert, Chief programmers, and class owners. One chief programmers can lead multiple class owners. When FDD-related measurements are developed using the FDD method, the cost allocation for each phase is roughly as follows: 1. develop a global model (develop an overall model) 10% initial, 4% on-going 2. build feature list 4% initial, 1% on-going 3. plan by feature 2% initial, 2% on-going 4. build 77% (2-week iteration) FDD best practices based on feature design and feature • continuous integration. • domain object modeling for domain (business) object modeling. • Develop developing by Feature Based on features. • Class owner individual class ownership. • Organize the team feature teams according to characteristics. • Source Control. • Report/result visibility reporting/visibility of Results views: 1. in FDD, it considers:
Only well-defined and simple processes can be well executed. 2. However, FDD does not have a low barrier because it must have two key figures-the chief architect and the chief programmer. At the same time, because FDD's customer engagement can be very high, the team culture is vulnerable to the influence of the customer's document. In addition, FDD may have a long preliminary work, so it is easy for people to develop a heavy-duty method exhibition with agile flag. Fortunately, if you are aware of these three problems in advance, they can be prevented. Ozzzzzz: FDD does not require you to use color UML, but I cannot find a Domain Modeling method that is simpler and clearer than this method. There are four kinds of templates in the problem field: pink moment/interval, yellow role, green ppt (party, place, thing), and blue description. Domain neutral component is a pattern that appears repeatedly in the business system. In my words, it is what people do at what time and at what identity. I believe that some people may not know what a noun is, but they can also express one thing in the above format. When I handed it to my customers for CRC card modeling, they didn't think it was complicated. When I gave them color UML, the customer thought it was simpler and clearer than CRC and felt that they could also be a programmer. Feature -- <action> <resule> <Object> is also very simple and clear. However, many people may misunderstand that feature is a means to express their needs, just like use case and usestoris. In fact, they are all necessary analysis methods. However, the feature is closer to the program, while the use case is closer to the business. usestory can be used in these two styles-but there is only one usestory style. That is to say, a use case or usestory can be constructed using several feature values. What's even more amazing is that using feature can quantitatively represent your development progress. The field goes through 1%, the design 40%, the design review 3%, the Code 45%, the code review 10%, and the commit construction 1%. Of course, you can adjust this data according to your organization's actual situation. However, as long as you do not adjust it too frequently, anyone can instantly know whether you have actually done well. With feature, you will find that the customer can directly understand the structure and progress of your program, not just the estimation of your submitted documents. Of course, this capability is terrible for many people who are used to spoofing. At the same time, we will find that if FDD is used for program development in one or more related fields for a long time, the domain model will become more and more fixed, and the people who use this as the basis will become more and more experts in some areas. At the same time, more similar feature will appear frequently. So that when you only use the previous feature, you can analyze the problems existing in the customer's business. That is to say, the use of color UML and feature can not only sort out requirements, but also sort out services. And if you are sensitive enough, you will find that FDD is called processes. It is true that FDD is used for the first time in a large project and the final result is successful. In addition, like lean, FDD has many examples of large projects, regardless of the number of codes, the complexity of requirements, the number of participants, and the time of execution, in these aspects, large projects are not lacking in FDD. In small and medium-sized projects, FDD can well record experience and achieve good results. At the same time, because the FDD process is too small (only 10 pages of A4), few people have the desire to crop him. At the same time, the technology used in this method is simple and clear, and it is rarely criticized for its difficulty in learning and mastering. However, the content of FDD does not include SCM and coding, but you can combine XP's continuous integration, TDD, and refactoring to perfect it. In addition, because the feature structure is uniform, it is more instructive to construct test case based on it. Moreover, because FDD uses mild code responsibilities, you will not experience over-refactoring issues. Because of the uniform granularity of feature, it is convenient to control check in and check out. Therefore, at least daily building is easy. Coloruml can be expressed in one sentence. Any requirement (in fact, anything) can be expressed as: WHO (or when) at what time (or during what time) in what way is a behavior performed. Of course, you can also use different tenses to construct this expression. In fact, this is the basic form of statements in our language. Of course you can use OO to construct sentences. However, I think the basic elements of FP are also rooted in it. That is to say, this basic model, in fact, oop and FP are a projection of this basic realistic form. Developing a comprehensive model Jeff De Luca believes that, compared with other agile methods, FDD allows the project team to master the entire project in the initial stage (developing a comprehensive model, in order to answer questions such as "how many projects are left unfinished": if we are purely incremental iterative development-that is, we are limited to the needs and analysis in the iteration-then, of course, it is difficult for us to answer "how much we have done for the entire project" and "How many projects have not been completed ". Because we have not browsed the remaining requirements. Therefore, we must start some information collection or analysis activities so that we can understand and set baselines for tracking and feedback so that we can answer the above questions. FDD is the only agile method that can achieve this correctly. This issue at this stage can be seen as a large number of pre-designs (big design up-front, bduf): it is not the class of bdup that is despised as a "comprehensive pre-design ", instead, we will design exactly enough ". At the same time, it should be noted that this first activity in FDD not only includes high-level design, but also needs and needs analysis. Ozzzzzz: 1. FDD is iterative development, which must be emphasized. 2. The overall model is more an analysis model than a demand model. More about what will happen, rather than what capabilities will be achieved. This model is more from the perspective of business analysis, rather than from the perspective of software system implementation. This overall model is not a framework, but the Department content is a part of the framework. This is very important. Basically, FDD is very powerful in dealing with complex problems, starting from here. 3. Create a feature list according to action result object. In terms of habits, we translate feature into features. This shows that feature is some of the capabilities of object, rather than some software features. Software functions often require some features to work together. In fact, if the overall model is constructed according to the correct principles, there is very little chance of a obese feature. Basically, each feature is completed in less than 2-3 days, many of which may be several hours, but only a few minutes. 4. The primary programmer is often responsible for familiar and interesting analysis classes. The project manager has no right to assign jobs to them, rather than specifying the classes they are responsible. In fact, FDD has three key management roles: Project Manager, primary designer, and Development Manager. These three roles can be assumed by three people, two people, and one person. However, in any case, the tasks and work of these three roles are different and must be noted. The feature must be owned by a specific person, but note that this must be done when the class has a master. 5. The previous article shows the origins of the class owner. The key is that everyone must understand that no detailed design exists in agile. In fact, the so-called design at this stage is more about identifying the classes involved in a feature, and the class owners will participate in the construction of the feature according to the protocol, when can these people participate in this feature and how protocols between them can be checked and implemented. 6. at this stage, the tasks are relatively clear, but remember not to influence the so-called traditional software engineering methods. The so-called review and review should not be carried out, instead, TDD and PP should be used in a more efficient way. Especially because of the existence of primary programmers, PP can be fully carried out in the brainstorming at the previous stage. It can be said that the design and construction phases do not have clear boundaries when there are more, or there is no clear stage when there are more design phases. This actually reflects the durable design style that agiler generally prefers. As for the last question, it is not a problem at all. It is a misunderstanding of the role and iteration of FDD. As for milestones, it is easy to determine in FDD. Each iteration should be a milestone, and each submission to the customer should be a major milestone. The so-called plan is to determine the feature priority implementation level, and the priority implementation level is actually the customer's function priority list. The two lists here are dynamic and will be adjusted regularly. In many complex cases, the analysis model will also be adjusted, and more analysis classes may appear, that is to say, the class responsible for the primary programmer will be adjusted according to the situation. FDD is actually a complicated system, at least I think it is not simpler than the RUP. FDD has many policy and technical issues, which are not so easy to understand. It can be said that FDD is a professional development method for professional programmers. In fact, all the time agile is the development method of professional programmers. In general, there should be a coach role, and the primary designer often assumes this role. I stress that the overall model is based on several considerations, not the demand model. 1. Does a Project allow you to easily create an overall model at the beginning? At least from the perspective of customers in the domestic software development industry, they will not give you this opportunity. Therefore, in most cases, this model should already exist before you start the project. This model does not come from a specific "requirement", but from a broader "domain ". In fact, I prefer to call him a domain model or domain analysis model. 2. Because of the 1 viewpoint, most development groups work within a relatively fixed field. Their work should be able and accumulated to a certain extent. This domain analysis model is a good medium. 3. Because the domain analysis model emphasizes the concepts that appear in the domain, it can be used as a basis to establish a better and simpler understanding of the domain. If you focus too much on the needs of the process, the complexity and recognition will be greatly reduced. At the same time, we should also understand that the domain analysis model is the basic dependency of the organization structure of the FDD team, and it is necessary to maintain a relatively stable model. One of the key points that are prone to errors here is to systematize the models in this field to a specific software architecture system, that is, the so-called "system model diagram ". In our specific practice, the system architecture used by the development team is usually another relatively stable system, this system also has many similar characteristics like the analysis model of that field. Therefore, we can sum up and refine the two of them to establish a more targeted rapid development framework. Once the two structures are confused, the complicated business and system structures will become more complex and difficult to understand. At the same time, it should be clear that if the business is too closely coupled with the specific technical implementation, it will cause business changes in the future development process and the consequences of the technical structure adjustment. If you look at the FDD above, you will find that FDD has a lot of traps and necessary skills in implementation and implementation. These methods and methods cannot be realized simply by reading books and thinking. Even if there is training in this area, it is difficult for people who are not really familiar with this method to provide guidance on the on-site process. At the same time, we should also understand that the content of many statements in Agile's method system is different from the traditional concept. In particular, FDD, the refinement of methods and the normalization of the structure, it is easy for users to go into agile in the guidance of their inherent heavy-duty ways of thinking. This is also a manifestation of its complexity.
