

Green Energy Case Studies
Web Development Case Studies
Web Development Methodology
Successful Web Development Methodologies
Adopt, Adapt or Build Your Own
Once the decision had been made to find a better way of doing things, we realised we had three paths to choose from:
- adopt an existing methodology
- adapt from an existing methodology
- build our own methodology
The development team was divided on this issue. Some members believed we should make it up ourselves; others said we should avoid re-inventing the wheel. It was clear we had to do some research to work out which was the best path for us.
Methodologies Evaluated
We had two presentations from RUP representatives. The first was a one-hour session, the second a more detailed two-hour presentation. Both times, I was more confused after the presentation than before. I also spoke to a number of friends that had worked with RUP and had positive things to say about the process.
We also received a presentation from a Process Mentor representative. The process itself was more compact than RUP, and therefore easier to get one's head around. In essence it was a Website with a series of steps, forms and templates that could be used to run a project. We felt more comfortable with Process Mentor than RUP because it was less overwhelming, but it still wasn't quite right. There wasn't anything that stood out as a major issue, as had happened with RUP, but regardless, Process Mentor did not feel like the right approach.
An Overview of FDD
FDD is an agile development methodology created by Jeff Deluca to:
Strong Project Management
From the very beginning of a project it has a project manager so a client can solve all project-related issues through the only person. Project Manager is involved into requirements definition when a project starts up. His routine responsabilities are project planning, team management, early project risks definition / elimination and reporting to client. All projects are under CTO coordination.
Thorough Requirements Analysis
At Influxive we pay special attention to requirements definition process. This guarantees that we deliver final results that meet clients’ specific requirements. We use several levels of requirements description:
- Business Vision
- Product Vision
- Functional Specifications
- Use Cases
FDD for Web Development
Implementing a new way of doing things is much harder than it sounds. People don't like change, and even those who say they're willing to give something new a go can quickly change their minds and revert to the old way of doing things. Because of this, we knew that we as a development team would only get so far trying to apply FDD ourselves. Sooner or later, it was going to affect the project managers and eventually clients. We decided it was better to get everyone involved up-front to increase our chances.
Refined Development Process
Since this first application of FDD to Web development in 2000, I've worked to refine the process and have come up with an approach that has worked effectively on dozens of Web projects ranging in size from 2 weeks to 6 months. This refined approach uses the core of FDD, but introduces new elements to manage some of the areas that FDD doesn't cover. Below is a high-level overview of how FDD can be successfully applied to Web development.
Managing the Transition
The next step was to work out how to actually apply FDD to our work. There were many projects in production and we couldn't simply change our approach midstream. Nor could we expect all new projects to start using the new methodology, as not everyone on the team had had training. We were going to have to take a staged approach to implementing the methodology.
Functionality
This is where features come into play, and where the "application" aspect of the Website is defined. The key is to break the project into chunks of work that can be captured in the client's language, and to ensure that each "chunk" totals between 2 hours' and 2 weeks' work.
Features that may be required for the ACME site (each requiring no more than 2 weeks' of work) include:
- Subscription facility
- Distributor search
- Product search
- Feedback form
Daily Wraps
A Daily Wrap is a daily meeting with your team. It's a common task among agile processes. For example, in the Scrum framework it's called the Daily Scrum or Daily Stand Up Meeting.
In this short meeting, each person states what they did the previous day and what they plan to do today. The goals for this meeting are to:
- make sure no-one is falling behind
- make sure everyone knows what the rest of the team is working on
- ensure that any barriers or problems are raised and overcome quickly
- help foster collaboration within the team
Constant Quality Testing
At Influxive we have a dedicated quality department responsible for Quality Assurance at every project from its start up to delivery. Depending on a project size we allocate a testing team and define a timeframe for its work. This allows optimizing resources involvement and thus project costs. We use defect tracking systems like IBM Rational ClearQuest for professional problems tracking. QT experts work independently from development team yet in close cooperation with it.
Conclusion
There is still no silver bullet!
Adapting FDD for Web development goes a long way toward addressing many of the issues that arise in Web development, but it is not a complete answer. Areas such as requirements gathering, visual design, testing and deployment aren't covered even though they are needed for every project. But, given the lack of viable Web methodologies out there, having something that is effective, albeit incomplete, it is a big step forward.