This action might not be possible to undo. Are you sure you want to continue?
Successful Web Development Methodologies
By: Martin Bauer May 13th, 2005 Reader Rating: 9
Commercial Web development has been around for more than 10 years. As an industry, this one's still fairly young when you consider others that have been around for centuries. But relative youth as an industry is no excuse for not doing better. Consider the number of sites that are rebuilt for clients every day, and you'll likely agree that there's still much poor quality work being done, which affects us all: it means that clients are more wary and less trustful of Web developers. Anything that tarnishes our industry can tarnish all of us individually. Having tried, trusted and standardised approach to Web development would go a long way to helping avoid the mistakes we all see over and over again. We need a Web methodology. However, finding a methodology that seems suited to Web development is not easy; making it work in the real world is even harder.
About the Author
Martin is the Managing Director of designIT, a Melbourne firm specialising in effective content management solutions using eZ publish. Martin is also co-author of the first eZ publish book and contributor to the Cutter IT Journal on agile project management and Web development. View all articles by Martin Bauer...
As the Development Manager for a team of 20, in the heady dotcom days, this was exactly the dilemma I faced. This article explores the issues that arose from our lack of a decent methodology, and how we as a team tried to resolve them. The result was the successful adaptation of an existing methodology for Web development.
A number of factors combined to force the Web development team to make a change in the way we did things. First and foremost, projects were constantly going over-time. There wasn't a specific reason for this; each project seemed to have its own particular issues. In some cases, the client changed his or her mind. In others, our team interpreted the client's requirements differently from the client's own interpretation. And for others it was a simple underestimation of the work required to complete the project. Regardless of the reason, the end result was the same: projects that go over-time go over-budget unless the client is willing to pay more. And each late project also impacts new projects. The more frequently this happened, the worse things got, until we had a situation in which almost every project became high risk and suffered scope creep, generated low staff morale, and was expected to have unrealistic deadlines. The answer was pretty simple: we needed a better way of doing things -- a proven way of delivering projects that met the client's needs on time, and on budget. The solution would also need to fit in with our organisational culture. We needed a Web methodology.
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. At the time, there were no recognised Web methodologies (although, from recent research it appears that the situation hasn't changed much). So, for adopting or adapting, we had little choice but to look at the existing software development methodologies.
When we started looking for methodologies, we decided that it was important to know what we were looking for. The first step was to decide on the criteria by which we would evaluate them. Complexity The solution had to be more than just a simple guide, but at the other end of the scale, if it was too big, there was no way it would work. We needed something that was easy to understand on the surface -- as both staff and clients had to be able to grasp it -- but had sufficient depth to give developers the guidance they needed. Size It's hard to get people to read documentation at the best of times, so a thick document explaining the methodology was unlikely to be effective. Chances
1 of 9
when all was said and done. rational rose. We felt more comfortable with Process Mentor than RUP because it was less overwhelming. requisite pro…etc) was high. which is both its strength and its weakness. given the context of our team. the second a more detailed two-hour presentation. 2 of 9 29/11/2010 17:49 . There were a number of techniques that sounded useful but. 2005 ) ranked trust as the number one factor and technical expertise as last. if we had a 100-page guide with a 10-page summary at the end. the less money that was required. In-House Methodologies Our team included a number of experienced developers who had worked with "home grown" processes from previous jobs with heavyweights such as IBM GSA. to implement RUP. It covers pretty much everything in the entire SDLC. http://articles. explaining what worked.. In essence it was a Website with a series of steps. yet our team was not! We had some team members who were still learning about the SDLC. one of the leading authorities on RUP. The scope of RUP is extremely broad.Sitepoint : New Articles. I was recently at a conference and attended a session by Phillipe Krutchen. A recent study of the most important factors in successful software teams (from Cutter Journal March. after many presentations. appeared to be a potentially complex. Why Traditional Methodologies didn't Fit There was no shortage of vendors willing to tout their processes and associated tools yet. complex and sophisticated. we didn't feel any the wiser. Nowhere in any of the presentations or literature for either RUP or Process Mentor was trust mentioned. and the key is to use only those aspects of the process that you need for your project. The process itself was more compact than RUP. difficult. This makes a lot of sense given that projects often vary and the same approach won't work in every case. and to try to introduce something as complex as RUP would require significant additional training. We had each of these developers talk about their experiences. not be based on theory. However. This was the same advice that I'd heard from friends who had used RUP. The first was a one-hour session. There wasn't anything that stood out as a major issue. Web development time frames are often shorter. Nothing seemed to address our needs. We'd then need to trial and refine the process over time. Overall. but regardless.. nor were any of the other soft skills that apparently have a huge impact on success. out of a total of 17 factors. His view was that the main problem that arose when people tried using RUP was that they tried to use all of it. The reasons varied but the underlying problem was that none of the methodologies took into consideration the way things worked in Web development. I also spoke to a number of friends that had worked with RUP and had positive things to say about the process.sitepoint. as had happened with RUP. The cost associated with the tools that were required to use RUP (eg. time-consuming and expensive process that had a high risk of failure. clients often have a poor understanding of what's possible. and therefore easier to get one's head around. Cost Anything that cost money would have to be justified. but it still wasn't quite right. In comparison to traditional software development. the overall feeling was that we weren't going to be able to "borrow" one of these in-house methodologies from another organisation. the experience levels of employees vary dramatically. There had to be real-world examples of projects to which it had been applied successfully. Both times. Fresh Thinking for Web Developers and Desi. more than once! Methodologies Evaluated Rational Unified Process  We had two presentations from RUP representatives. Another issue with traditional methodologies is that they failed to take into consideration the "soft" aspects of software development. most people would use only the summary. the better. the technology changes rapidly and everything comes down to a single user interface (the browser). Process Mentor did not feel like the right approach. It was extremely unlikely that I'd be able to convince people to go through the process of trying a second methodology if the first one didn't work. what they liked. That's not to say these elements don't exist in traditional software development. I was more confused after the presentation than before.com/print/successful-development were that. we would have to review it in depth before we could decide which elements we would apply to our projects. forms and templates that could be used to run a project. RUP presented a number of issues: RUP was large. however. the limitations are much more pronounced in Web development. and what they'd use again. Even though RUP was comprehensive. Risk We couldn't afford to get the methodology wrong. Pragmatic The solution had actually to work. or a scaled down version of RUP. It's large and sophisticated. Process Mentor  We also received a presentation from a Process Mentor representative.
a model that's more shape than content. (The details of Agile Methodologies and FDD are beyond the scope of this article but if you're interested to read more. the domain expert explains a part of the business domain. as they have made their contribution in Process 1.e. visit http://www.com/print/successful-development The short answer was that we couldn't either adopt or adapt a traditional approach. Creating the feature list is the task of the Chief Programmers involved in the modelling process. This means that the client will be able to understand and value each feature. The core of FDD is the concept of a feature which is a clearly defined Client-valued piece of functionality. so we decided to investigate further to see if we could adopt or at least adapt it to Web development. http://articles. but it should not be underestimated. The end result is an overall model of the entire domain. It didn't take long for the team to agree to give FDD a go. Process 2: Build a Features List This is an initial project-wide activity to identify all the features required to support the project requirements. There are many techniques in FDD that help to provide meaningful communication. FDD consists of 5 clearly defined processes that can be captured in 5 pages. The project team is broken up into groups (preferably 3 per group) to model that part of the domain. 3 of 9 29/11/2010 17:49 . This might sound simple and obvious. First. This is a highly collaborative process in which everyone has to work together to create the overall model. Briefly. some of the other popular agile methodologies are XP..pdf document . Process 1: Develop an Overall Model This is an initial project-wide activity with domain and development members under the guidance of an experienced object modeller in the role of Chief Architect.agile.not capturing every detail. Process 1 involves the project team creating an object model of the business domain -. The methodology in this case was Feature Driven Development (FDD). The language we choose has a significant impact on how effectively we communicate. we soon realised it wasn't a silver bullet. The most powerful of these is encapsulated in Process 2: defining the entire project in features using the language of the domain. For details. then designing and building each feature in an iterative manner. Poor communication is the basis of most problems in software and Web development. Fresh Thinking for Web Developers and Desi. Now's the time to capture the project in a list of features. This process is then repeated for each part of the domain until everything has been covered. review the FDD Overview Presentation . The key to this process lies in defining the project using the language of the business domain..Sitepoint : New Articles.featuredrivendevelopment. The groups then present their models and consensus is reached on which to use. using the client's language.com ) It was pretty clear that FDD was far better suited to Web development than anything else we had seen.org  and http://www. The client and stakeholders don't need to be a part of this process. The model is not fully defined with all attributes and methods. The processes that make up FDD are structured around defining every element of a project as a feature. An Overview of FDD FDD is an agile development methodology created by Jeff Deluca to: enable and enforce the repeatable delivery of working software in a timely manner with highly accurate and meaningful information to all key roles inside and outside a project. as this step is more about capturing correctly the shape of the business domain in an object model -. Scrum. Going Agile We were about to start defining our own process when I came across a lightweight methodology that's now known as the "agile" movement. It takes an iterative approach. i. This left us with the unenviable task of trying to create our own. This does not require collaboration: getting a group of people involved at this stage would not be productive or constructive. However.sitepoint. but it also enforces a common language across the project team and reduces the risk of miscommunication or assumptions. Crystal and DSDM. The high level structure of FDD is captured in the following diagram. The focus that this step brings is incredible and affects the project in many ways.
code inspection. designed and planned would be considered negligent. Process 3: Planning Process 3 is an initial project-wide activity to produce the development plan. at the order in which features will be built. Process 4: Design by Feature Process 4 involves a per-feature activity to produce the feature design package. everything is described as a feature. As with Process 4. balancing load within the team and providing strategies for delivering early results to keep the client happy. It might seem like commonsense to design. 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. According to Gerald Weinberg (Quality Software Management Vol. we knew that we as a development team would only get so far trying to apply FDD ourselves. but it's not a detailed design. more than 2 hours' work but less than 2 weeks' work). feature by feature. If the Project Manager doesn't get the interpretation exactly right. which is. As we have seen. However. In the walkthrough. Process 5: Build by Feature Process 5 involves a per-feature activity to produce a completed client-valued function (feature). immediately after the design has been completed and inspected. This means programmers don't feel like they're spending all their time designing and no time coding. This question often elicits a different response. it's just that. and the Project Manager has to continually interpret the two. in particular. Because of this. the programmer refers to it in another. design and inspection. Applying FDD to Web Development Implementing a new way of doing things is much harder than it sounds. It also breaks the design down into meaningful chunks. We decided it was better to get everyone involved up-front to increase our chances. programmers familiarise themselves with what they're about to build before starting on a detailed design. The other benefit of this process is that helps the Project Manager see clearly how much of the project has been completed. For code to be "promoted to build" it must be finished.com/print/successful-development In FDD. The first reaction of many programmers. Process 5 is also broken down into three steps: code. Putting the detailed design in this later stage ensures that it is considered at the right time: before the code is written. defined as: <action> the <result> by/for/to an <object> For example: calculate the total for a sale calculate the total sales for a cashier A feature is also defined in terms of size (e. It provides the Project Manager with a means of planning the development phase in a meaningful way for both the client and the programmers. Sooner or later. http://articles. If there's time to do this. "promote to build". This process is a great way to ensure that focus. it doesn't take long for the Project Manager to assess how much work each programmer is actually producing once the variances in feature size are taken into account. This process extends the benefits provided by Process 2. who look. Using the same language doesn't mean the problem disappears. in turn. the productivity difference between programmers can be as much as 20 to 1.. but this step is often ignored.. the idea of building something before it has been fully defined. the Project Manager then asks. Defining everything as a feature avoids the problems that occur whenever the client refers to a concept in one way. Fresh Thinking for Web Developers and Desi. many programmers will continue to work on code. given the chance. which is inspected before they start the build. If a feature takes more than 2 weeks' work. it should be broken into separate features. and inspect that design. but it reduces the risk of confusion considerably. 4 of 9 29/11/2010 17:49 .1). What makes Process 5 unique is the final step. tweaking. The approach taken by FDD is clear in the difference between Process 1 and Process 4. It's not that the programmer is being difficult or misleading. People don't like change. the converse can also be problematic: attempting to design everything up-front can often result in "analysis paralysis". The inspection of the design allows defects to be found and removed before a single line of code is written for that feature. The detail is left to Process 4. A feature is not finished until there is nothing else to be done. is to open their favourite editor and start coding. the Project Manager needs to focus programmers on getting the project completed. yet it happens all the time in Web development. optimising or trying to improve it ad infinitum. Exactly how much design should occur up-front is a hotly debated topic amongst advocates of agile methodologies. it's not a problem. the client expects another. and promote to build. it was going to affect the project managers and eventually clients. The issue is how to assess that productivity. The key to this is the definition of "finished". In many other industries. and how productive each programmer is. the programmer can start to code. The amount of risk to which this approach exposes any project is enormous. especially those in Web development. before building. the idea of collaboration and benefits inspections is enforced.Sitepoint : New Articles. but if there's a tight deadline.sitepoint. "There's nothing else to be done?". The way a Project Manager can test if a feature is truly finished is simply by asking if the work is finished. Process 1 includes design early in the lifecycle. This process is broken down into three steps: walkthrough. It is completed in conjunction with the Development Manager and Chief Programmers. If the programmer answers "yes".g. Even though features might range in size from 2 hours to 2 weeks of work. mistakes occur: the programmers think they're building one thing.
one of our best. Attending the course were representatives of all the groups that would be affected by a new methodology: developers. The developer. It was much easier to get a real idea of where each project was at. and how much work had actually been completed. Normally. the following aspects of FDD stood out as providing solutions for the symptoms we suffered: Excellent reporting and planning Disciplined and clear Customer-focused Risk reduction via: iteration of design and build in small chunks clarity of requirements better understanding of the system to be built no wiggle room. asking a programmer how 5 of 9 29/11/2010 17:49 . The project suffered from the same problems that many internal projects face: it lacked buy-in and a dedicated stakeholder. the client needs to have an understanding of the technique. Managing the Transition The next step was to work out how to actually apply FDD to our work. that project was destined to be difficult. FDD uses a modelling technique called colour modelling (as explained in the book Java Modeling In Color With UML ). Our intranet needed redevelopment and we thought this would be a good opportunity to give FDD a go. Even though we went through a fairly comprehensive requirements gathering process. Fresh Thinking for Web Developers and Desi. As FDD is simple to understand. did an excellent job in modelling the domain and the project manager was able to track the project easily. Explaining this to the client was the only real challenge.Sitepoint : New Articles. but they do at least need an idea of what's happening. The intranet project didn't go well for many reasons. we would run an internal test project. although it wasn't planned. project managers. as fewer assumptions would be made We also realised that FDD wasn't going to be the complete answer to our problems. This was risky: if he was not good at his job. In terms of projects. we obtained the funding to run a training course. a designer and a tester.. The simple fact that we had decided to improve the way we worked had a positive effect. The paper merchant project. business analysts. We decided to tackle the problem from a number of angles. modelling is not completed in collaboration with the client. assign features to individuals. though. we saw a significant improvement in the project's progress on a number of levels. At the end of the course. In particular. the project lacked clarity of purpose. once they understood it. but what we found was that the effect on morale was much more positive.sitepoint. Although most projects still had issues. But what it did indicate is that FDD works best when there are clear requirements to start with. The team experienced some challenges. on the other hand. and so on. it wasn't difficult for people to see that we would be better off if we used this approach. With most clients. This project had only one developer. interface design or testing. one designer and one project manager. who played chief architect. There were many projects in production and we couldn't simply change our approach midstream. chief programmer and developer. It didn't matter what development process was applied. you're in trouble! Overall. http://articles..com/print/successful-development The next step was all about internal politics and getting the key decision-makers on side. in FDD it does involve the client and. There was a palpable sense of focus and direction. everyone was keen. On this basis. Nor could we expect all new projects to start using the new methodology. we anticipated that this would be fairly straight-forward and. it went smoothly. there was also an improvement. We were going to have to take a staged approach to implementing the methodology. In defining the overall model. went extremely well. For instance. the project would be in big trouble. Thirdly. therefore. this is the case with all small projects: if you don't have a decent programmer. The new approach also helped to bring together the different disciplines (development and project management in particular) who had previously not always worked closely. FDD covered development well but it didn't address the tasks of gathering requirements. track progress of each individual. as well as a chance to try to work out how to deal with the interface and testing areas not covered. The things that concerned us about applying FDD were: its high reliance on technical leads it didn't deal with User Interface design and build it was less powerful on smaller projects than on large ones it didn't cover testing and deployment FDD was not a silver bullet! In the end. However. we were going to have to adapt the process to our situation and needs. Firstly. some of which were quite unexpected. One of the issues that arose in the FDD post-training workshop was the process's reliance on the chief architect. as not everyone on the team had had training. none of which had anything to do with FDD. they'd actually find it fun! As the project had a small project team of just one developer. we would slowly introduce a few of the key aspects of FDD into new projects: Define projects using features (customer-focused) Plan development based on features Implement new team structure. That doesn't mean they need to be UML experts. The goal was to find a way to deliver projects more effectively. the problems were lessened and easier to manage. a developer and project manager that had been through the training decided to use FDD on their next project for a paper merchant. The team was happier because we were doing something about the problems. design and code reviews Conduct weekly project status meetings Secondly. There was no need to create work packages.
the developer should answer with a figure between 1 day and 2 weeks. Unfortunately. as this knowledge can really help when it comes to the next step of working out the project's purpose. for smaller clients. It's understood that the impact of any methodology will decrease as the team size drops.Sitepoint : New Articles.0. and one which puts user-friendliness first. rather than the truth. However.sitepoint. it's well worth the effort to ask. advanced and confident tone. Fail to define the project up-front as features. Writing a single paragraph that explains why the organisation exists is an important step. tracking the project by features This seems very simplistic. but it's often much harder to define a project's purpose that it seems. This refined approach uses the core of FDD. this constitutes a very simple statement. it is an important that every FDD project has clarity of purpose. FDD for Web Development Since this first application of FDD to Web development in 2000. A feature should require no more than two weeks' work. Below is a high-level overview of how FDD can be successfully applied to Web development. we were unable to monitor the long-term impact of the introduction of FDD. a project that used 4 staff members (a project manager. so when asked how long it will take the developer to finished a feature (assuming it's been started!). Project Overview Although it is not explicitly stated among the 5 processes of FDD. some of which don't necessarily answer the question the client asked: when will it be finished? That's not to say that programmers deliberately try to avoid answering questions. but introduces new elements to manage some of the areas that FDD doesn't cover. FDD can scale down and still provide value to the Web development process. it's just that sometimes the questions are hard to answer: often. For Web development. this problem will only reveal itself once work is delivered. an auto parts manufacturer: "The objectives behind the redevelopment are as follows: Unify ACME's corporate image worldwide. expectations and desires wrapped up in what they describe as their "Website". although it might be obvious to the client. Project Purpose Once again. the work must be defined as a project. In reality. Ensure the design of the Website adheres to the ACME Group Website Basic Guide Version 1. Fresh Thinking for Web Developers and Desi. Build a commercially oriented Website projecting a simple. some of the complexity is removed from the questions the client asks. for example. the dotcom collapse hit the company and we saw a number forced redundancies. The Purpose should be a clear. concise and measurable statement of the business outcomes that the project is intended to achieve. a few days' extra work on a small project can mean a considerable percentage of extra work. Like most things in life. the purpose is not always clear and this question can sometimes generate a very blank look! Still. and designer) 3 weeks to complete. and FDD is no different. This need be no more than a simple statement to define what the project is. This approach actually helps developers to manage themselves. Organisation Purpose This might seem like a redundant element of a project. defining the project in features 2.. Project Objectives The specific objectives of the project must be clearly defined. getting started on the right foot is the best way to make Web projects work out well. and chances are that the client and team will be on a different page from day one. sharp. professional. which suggests objectives that might be identified for ACME. and can quickly eat into the profit margin. this is often easier said than done. Consider this example. correcting such errors is not a big task. and what it's supposed to achieve. and avoid trying to make project managers happy by telling them what they want to hear. The organisation's purpose should be clear but.com/print/successful-development they were going with database optimisation can lead to one of many responses. For small projects. Most clients have many thoughts. 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 was a key benefit of the feature-driven approach. Within 6 months of the training. When a project is defined in terms of "features". Usually. http://articles. Of course. however. A series of bullet points is fine. but it's that simplicity that makes FDD so effective. I have been able to successfully apply FDD to small teams and projects. it's often more important to see if a methodology can scale down and still retain its advantages. The two aspects of FDD that are of most value in small projects are: 1. developer. FDD for Small Teams One of the main criticisms of agile methodologies is that they don't scale up. it's not easy to say when something will be finished.. it might not be obvious to the developer. 6 of 9 29/11/2010 17:49 . with a clear purpose that everyone understands and agrees to. wishes. the act of thinking this through and getting the client's agreement is the most important aspect of this part of the project overview. Using the simple technique of defining the project in features using the client's language will make a big difference to small and large projects alike.
Content The main difference between traditional software projects and Web development projects is the nature of content. Here's how it might appear for our fictional ACME auto parts business: Target Market Once again. Once again. A well-structured site will be easier for people to use. systems and components. What proves to be a more practical approach is to think of it in terms of primary.Sitepoint : New Articles. Information Architecture In its most simple form. pages of content). The next level. Information Design Most people now understand the concept of a site map and many can put a reasonable one together. The current trend is towards the three column layout with a header and footer: 7 of 9 29/11/2010 17:49 . " Project Scope Understanding and defining a project's scope is a challenging task. information architecture can be thought of as a sitemap. http://articles.com/print/successful-development Use the Website as a positioning tool to position ACMO as a technology-driven.. A good example of a poorly architectured Website is one in which users quickly turn to the search facility to find the information they want. information architecture and design become important elements of the project's success. For projects with a large amount of content. Although this seems like a straight-forward task. and what might be considered. leading global supplier of automotive parts. We need to understand the demographics of that customer base and if we have to target one part of that customer base. A Website may be an application or a hypertext system (eg. what's out. This is a great tool for getting clients to understand all the elements involved in a project.sitepoint. Many sites are constructed without proper regard for the target audience.. clients usually want to include everything and expect everything to be done for them. this is an important consideration. is to look at the design of information on the page: the information design.anyone who's familiar with the concept of scope creep will understand my point here. Fresh Thinking for Web Developers and Desi. we need to know which one it is. I'm not bad-mouthing clients -. secondary and tertiary target markets. which is far more sophisticated. and will be much easier to maintain. Most projects are a combination of the two. In reality. I recommend the use of a technique that was defined many years ago and states simply what's in. the importance of this process should not be underestimated. Most Web projects entail a large amount of content. Provide the ability for ACME to update the site in-house using a content management system (CMS). most sites have a number of target markets that need to be addressed. The key is to get an idea of what's in and what's out of the Website. IA is the logical structuring of content to suit the purpose of the site. To say that a site is aimed at the client's customers is not enough. in which case both aspects must be addressed.
The key is to break the project into chunks of work that can be captured in the client's language. However. it simply needs to state what has been done and if there are any issues that need to be resolved. the dependency is something the client has to deliver. It's a common task among agile processes. the first of which is to provide the discipline necessary to allow the project manager to review the project on a high level. Often.com/print/successful-development Functionality This is where features come into play. For example. There are many reasons for this. the report would provide details of how many features had been started. and to ensure that each "chunk" totals between 2 hours' and 2 weeks' work. in the Scrum framework it's called the Daily Scrum or Daily Stand Up Meeting. By putting this down in writing. In small projects. 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 Project Management An integral part of FDD is the weekly report. an accurate "percentage complete" figure can be derived. they'll be asked in front of others whether it has been done. I use the following template. you make clear who is responsible for delays. each person states what they did the previous day and what they plan to do today. Achievements What has been completed in the past week? This section helps to generate a sense of progress and satisfaction. In a larger FDD project. Daily Wraps A Daily Wrap is a daily meeting with your team. and they know that tomorrow. In this short meeting. http://articles.sitepoint. which has proven to be very effective. which I've adapted for smaller projects. were in progress.Sitepoint : New Articles. and were late. the Wrap is an extremely effective tool to keep developers on track. Fresh Thinking for Web Developers and Desi. 8 of 9 29/11/2010 17:49 . which makes a huge difference to team work. the Wrap has a strong social aspect. When people promise to do something. The progress report doesn't need to be complex or comprehensive. Dependencies This technique is valuable in helping get things done. 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 From a project management perspective. Progress Reports The key here is to provide the client with progress updates on a weekly basis. it is important to track progress and report this to the client regularly. From this. and about not following through! Also. accountability results. had been finished. it's not always necessary to go to this level of detail. I recommend doing this in the following two ways. and where the "application" aspect of the Website is defined. had not been started. The Wrap certainly makes team members think twice about what they promise...
nebulon. For example. meeting notes.pdf  http://www.amazon. But.com/software/awdtools/rup/  http://www. Document all assumptions! Issues Every project has issues.com  http://www. the issues that are raised are resolved. in those projects.should be captured in an online location that both the project team and client can access at anytime.com/exec/obidos/tg/detail/-/013011510X/104-3565645-1171160 9 of 9 29/11/2010 17:49 . http://articles. In particular. Project Website This is a large part of all FDD projects and. should questions be asked down the track.sitepoint. is called the KMS (Knowledge Management System). visual design. progress reports and so on -.agile. This helps to ensure consistency by placing all information in a central repository. which need to be captured in a written issue report.. they can often cause major issues.com  http://www. testing and deployment aren't covered even though they are needed for every project. the client may deliver it as a Word file.org  http://www. having something that is effective.  http://www-306. it is a big step forward. a developer may assume that data provided will be in a tabular. albeit incomplete. given the lack of viable Web methodologies out there.cutter. this helps with clients who have a habit of changing their minds.Sitepoint : New Articles. All information for the project -. It's good form to capture those resolutions so that. as the project progresses.featuredrivendevelopment. you can always go back to the resolution noted on the progress report.com/print/successful-development Assumptions I can't stress enough how important it is to clearly state any assumptions you've made.ibm. Areas such as requirements gathering.com  http://www. Resolutions Hopefully. delimited format that is easy to import..all documentation. but it is not a complete answer. or worse: in a graphic format such as Quark or Pagemaker. 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. If they're not stated openly.processmentor. Fresh Thinking for Web Developers and Desi.com/articles/fdd/download/fddoverview.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.