Feature Driven Development for Web Developers
About 10 years ago, web projects for the most part were static, and sometimes the technological process was simple to disgrace. Now the line between web applications and desktop applications is erased, the functional complexity of web projects is growing. This dictates new requirements for web development. The usual situation today, in the era of “surprise me 2.0”, is when the project is long-term, many experts are involved in it (and not specialists as well) who generously irrigate the long-suffering product backlog with new ideas and goals, both before the development and after. As you understand, goals and stories mutate, and with them tasks. A preliminary estimate of time loses its usefulness. Etc. etc. Obviously, a special development methodology is needed. You can try to join the Rational Unified Process (RUP) or Process Mentor . However, not worth it. Among the now-popular Agile methods, there is what we need - Feature Driven Development (FDD).
In general terms, the approach can be described as follows:
Ideally, the output we get a platform, gradually overgrown with properties. It sounds somehow suspiciously simple. Let's still see what it is.
As the author of the methodology, Jeff Deluca ( http://www.jeffdeluca.com ) put it, the general model is more than a sketch or outline than a detailed content. However, to obtain this model, it is not enough just to the project requirements. The model is a project vision based on the results of preliminary studies. Thanks to Louis Rosenfeld (Louis Rosenfeld - http://louisrosenfeld.com ) - we know how important the role of information architecture is in web development. At the stage of the general model, we should have - analysis of the target audience, analysis of the content and context of its use, content structure, including metadata and thesaurus. There should be a document describing the principles of the user interface, a list of used UX-components, a description of their properties and behavior.
Fig.1. Information Architecture Pyramid
This approach implies that we proceed to the development, having only the outline of a system that, as far as the development is concerned, is overgrown with details. Thus, detailed wireframes will be developed at the entrance to creating appropriate properties (features) or, in other words, parts of the project. However, at the stage of a general model, the same “raw” frameworks of the main interfaces and a preliminary site map will be required.
All of the above are related documents. The main result of the stage is the domain model ( Domain model ). This is a static UML diagram that includes all the logical objects of the project defined at a given time and their interaction (the object is part of another object, the object extends another object, etc.).
')
I do not think that here I should go into detail. Most of you use the SCRUM technique, and the list of properties in FDD is the same as the product backlog in SCRUM. Unless it is worth reminding once again: when creating a list, it is necessary to operate precisely with goals and sub-goals, but not tasks.
Everything would be fine, but how can we estimate the development time of project properties when details are foggy. The associated tasks for developers will be extremely clear only when all the preliminary work on this property has been completed. How to plan? And here comes Story Point Estimation. We evaluate properties not in man-days, but in abstract points according to the complexity of the property. From the entire list it is proposed to choose the property of minimal complexity and assign it 2 points of difficulty. It is recommended to use an exponential scale, for example: 1, 2, 3, 5, 8. Then it is asked why we did not assign 1 to the most trivial property. Just in case. The list of properties is huge and at first glance it is unlikely that you will be as accurate as possible in the assessment.
All team members participate in the assessment. That is, each property is discussed from the standpoint of all stages of development until the team comes to a single assessment of the complexity. Tiring enough, I'll tell you, but - productively.
So, priorities are defined, property for implementation is selected. It's time to describe the requirements. For this, a model of use cases is created ( Use Cases ) relative to the selected property. This document would be well provided with an Activity Diagram to visualize the logic of related usage scenarios. The cases themselves can be reflected in the corresponding UML diagram (Use Case diagram). During the review (review) of the document, again, all members of the team participate.
Fig.2. The use case model adds detail to common model documents.
Further work can be carried out in parallel: part of the group is engaged in technical design, part of it works on frameworks (or on detailed elaboration of frameworks, if they have already been prepared at the stage of the general model).
Technical design assumes a UML diagram with entities of the domain model, a list and a class diagram (where appropriate), paired with the property of models, DAO, controllers, services, decorators (possibly helpers). It also presents the architecture of the database, covering the property in the form of the model "entity-relationship" ( ER Diagram ). If the property affects any external systems (for example, a user preference profiler), this should also be reflected in the technical design, say in the form of a sequence diagram ( Sequence diagram ).
Among other things, test cases should be prepared ( Test Cases ), which will allow QA specialists to fully appreciate the quality of the property implementation.
When the domain model entity diagram for the selected property is completed, the details that are not accounted for in the overall model appear. So it should be: you just reflect the new details on the overall model as they appear.
At the end of the stage, the entire development team takes part in the technical design review. In addition to "polishing" all aspects of the document, it provides a deep insight into the architecture ideas of all project developers.
While the visual designer will work on the user interface, programmers can create the components described in technical design as a prototype. Thus, after reviewing the visual design and prototype of the property, an xHTML layout and modification of the decorators (views) are made. Surely the creative genius of the visual designer will also require additional programming on the client side (JS). When the property is ready, it is transferred to the QA-department for testing.
After the property has been tested and put into the product, we take the following property in priority, we repeat the design / implementation cycle.
In general terms, the approach can be described as follows:
- Development of a general model
- Creating a property list
- Planning by properties
- For each property - technical design and implementation.
Ideally, the output we get a platform, gradually overgrown with properties. It sounds somehow suspiciously simple. Let's still see what it is.
Develop an overall model
As the author of the methodology, Jeff Deluca ( http://www.jeffdeluca.com ) put it, the general model is more than a sketch or outline than a detailed content. However, to obtain this model, it is not enough just to the project requirements. The model is a project vision based on the results of preliminary studies. Thanks to Louis Rosenfeld (Louis Rosenfeld - http://louisrosenfeld.com ) - we know how important the role of information architecture is in web development. At the stage of the general model, we should have - analysis of the target audience, analysis of the content and context of its use, content structure, including metadata and thesaurus. There should be a document describing the principles of the user interface, a list of used UX-components, a description of their properties and behavior.
Fig.1. Information Architecture Pyramid
This approach implies that we proceed to the development, having only the outline of a system that, as far as the development is concerned, is overgrown with details. Thus, detailed wireframes will be developed at the entrance to creating appropriate properties (features) or, in other words, parts of the project. However, at the stage of a general model, the same “raw” frameworks of the main interfaces and a preliminary site map will be required.
All of the above are related documents. The main result of the stage is the domain model ( Domain model ). This is a static UML diagram that includes all the logical objects of the project defined at a given time and their interaction (the object is part of another object, the object extends another object, etc.).
')
Build a Feature List
I do not think that here I should go into detail. Most of you use the SCRUM technique, and the list of properties in FDD is the same as the product backlog in SCRUM. Unless it is worth reminding once again: when creating a list, it is necessary to operate precisely with goals and sub-goals, but not tasks.
Property Planning (Plan by Feature)
Everything would be fine, but how can we estimate the development time of project properties when details are foggy. The associated tasks for developers will be extremely clear only when all the preliminary work on this property has been completed. How to plan? And here comes Story Point Estimation. We evaluate properties not in man-days, but in abstract points according to the complexity of the property. From the entire list it is proposed to choose the property of minimal complexity and assign it 2 points of difficulty. It is recommended to use an exponential scale, for example: 1, 2, 3, 5, 8. Then it is asked why we did not assign 1 to the most trivial property. Just in case. The list of properties is huge and at first glance it is unlikely that you will be as accurate as possible in the assessment.
All team members participate in the assessment. That is, each property is discussed from the standpoint of all stages of development until the team comes to a single assessment of the complexity. Tiring enough, I'll tell you, but - productively.
Technical design properties (Design by Feature)
So, priorities are defined, property for implementation is selected. It's time to describe the requirements. For this, a model of use cases is created ( Use Cases ) relative to the selected property. This document would be well provided with an Activity Diagram to visualize the logic of related usage scenarios. The cases themselves can be reflected in the corresponding UML diagram (Use Case diagram). During the review (review) of the document, again, all members of the team participate.
Fig.2. The use case model adds detail to common model documents.
Further work can be carried out in parallel: part of the group is engaged in technical design, part of it works on frameworks (or on detailed elaboration of frameworks, if they have already been prepared at the stage of the general model).
Technical design assumes a UML diagram with entities of the domain model, a list and a class diagram (where appropriate), paired with the property of models, DAO, controllers, services, decorators (possibly helpers). It also presents the architecture of the database, covering the property in the form of the model "entity-relationship" ( ER Diagram ). If the property affects any external systems (for example, a user preference profiler), this should also be reflected in the technical design, say in the form of a sequence diagram ( Sequence diagram ).
Among other things, test cases should be prepared ( Test Cases ), which will allow QA specialists to fully appreciate the quality of the property implementation.
When the domain model entity diagram for the selected property is completed, the details that are not accounted for in the overall model appear. So it should be: you just reflect the new details on the overall model as they appear.
At the end of the stage, the entire development team takes part in the technical design review. In addition to "polishing" all aspects of the document, it provides a deep insight into the architecture ideas of all project developers.
Build by Feature
While the visual designer will work on the user interface, programmers can create the components described in technical design as a prototype. Thus, after reviewing the visual design and prototype of the property, an xHTML layout and modification of the decorators (views) are made. Surely the creative genius of the visual designer will also require additional programming on the client side (JS). When the property is ready, it is transferred to the QA-department for testing.
After the property has been tested and put into the product, we take the following property in priority, we repeat the design / implementation cycle.
Source: https://habr.com/ru/post/70424/
All Articles