Feature Driven Development for web-developers
About 10 years ago web-projects were mostly static and development process pretty simple. Now difference between web-applications and desktop applications disappears, functional complexity of web-projects grows up. It demands to new requirements. That’s usual now – the project is long-term , many of experts take part (non-experts as well). Everybody brings to the project backlog new ideas and goals, before the development stage as well as after. You see, goals and stories mutate and so the tasks. Preliminary estimation by time loses its reasonability. Obviously, it’s needed especial development methodology. One can try accustom to Rational Unified Process (RUP) or Process Mentor. However, among so popular nowadays Agile methods there are exactly what we need – Feature Driven Development (FDD).
Briefly the approach consists of:
- Develop Overall Model
- Build Feature List
- Plan By Feature
- Design and Build By Feature
Develop Overall Model
How the author of the methodology Jeff Deluca has put it – overall model is rather shape then content. Though to get the model it’s not enough only of projects requirements. Overall model is vision of the project, based on results of preliminary research. Thanks to Louis Rosenfeld we know how important for web-development the information architecture is. So for the stage we ought to have analyze of target audience, analyze of the content and context of its use, content structure, including meta-data and thesaurus. It’s good to have also the document describing principles of user interface, list of propose UI-components, description of their properties and behavior.
For the approach it’s meant we start the development having just shape of the system which is being covered by the details. Thus, detailed wireframes will be made during the creation of the features or, so to say, parts of the project.
All the told upwards is attended documents. The major result here is domain model. That’s a static UML diagram, which includes all the relevant for the stage logical objects of the project and their interrelations (one is part of another one, one extends another and so on)
Build a Feature List
I don’t think there are needed details, Most of us use SCRUM and the feature listof FDD is the same as product backlog of SCRUM. Just a reminder – creating the feature list, operate with goal and sub-goals, but not with tasks.
Plan By Feature
Here comes the question: how does one estimate development time when the details are obscure? Related tasks are fully explicit only when preliminary works of the feature are done. So, how to plan? The solution is called Story Point Estimation. We estimate features not in man-days, but in abstract points which represent complexity of the feature. It’s assumed you pick up the feature of the minimal complexity and assign 2 points to it. Then exponential scale of points should be used: 1, 2, 3, 5, 8. So, why didn’t we assign 1 to that trivial feature? Just in case. Feature list is huge and it’s hardly you can be absolutely accurate estimating the simplest feature.
For the estimation meeting all members of the team are attended. I.e. every feature is discussed of every aspect of development till whole the team comes to the integrated estimate. That is pretty exhausting, but yet it’s efficient.
Design By Feature
So, priorities are defined and the feature to be realized, are picked out. That’s the time to specify the requirements. Here for the feature Use Case model is created. Activity Diagram can be attached to the document as well to visualize the logic of involved use cases. Use cases themselves can be represented as diagram (Usa Case diagram). For the document review also all the team member are attended.
Then the works can be run paralleled: part of team makes technical design, part work on wireframes (or on wireframes refining if they are have been already made when Overall Model creation). Technical design is supposed to have UML-diagram with domain model entities, list and diagram of classes, related to the feature models, DAO, controllers, services. It contains also Db architecture, which covers the feature as ER Diagram. When the feature affects any external systems (e.g. user attention profiler) it should be put into design as Sequence Diagram.
Of course, Test Cases must be written, what will help QA-manager to check quality of feature realization.
When the domain model is completed, new details about overall model come out. That’s ok, you just add them to the overall model when encountering.
By the end of the stage the whole team takes part in review of the technical design. Besides the refining all the aspects of the document, it gives the deep penetration into the ideas of the project for all team members.
Build By Feature
While the visual designer works on user interfaces, programmers can make components of the prototype, described in the technical design. Thus after visual design and prototype of the feature reviewed, you can start xHTML-templating and modification of the prototype views., creating of JS (client-side) programming, When it’s done, QA-team test it.
After the feature is tested and went to the product, we take the next feature and repeat the cycle of feature development.