Iteration 3: Spikes
| I l @ ve RuBoard |
| Welcome to your first high-risk iteration. Some of the best advice passed on to us was to do the easiest thing first and then the hardest. Iterations 1 and 2 broke in the team and hopefully worked out any kinks. Now we want to explore the risks of the project that pertain to technical difficulty and feasibility. Iterative development is first about reducing the risks of complex projects. Moving risk to the beginning of the project allows the team to find out early if something can't be done as planned or if it should reexamine the Release Plan. In iteration 3 we need to do a lot of what are called "spikes," or proofs of concept. We isolate the hardest, riskiest parts of the project and write enough tests and code to see that we can do it and to see what doing it entails. Can you get an important JavaScript function to work in all of the browsers you need to support? Can your server-side application dump a file into the company's legacy system? If you haven't done something before, add a spike for it. The design department can also do spikes, given the number of graphic design ideas that are tricky or impossible to do in a browser. In one of our recent projects, we wanted to put an animated menu on an angle without using Flash. We did a spike to see if it could be done in DHTML. It couldn't, so we had to change the plan to add stories for creating a different design for non-Flash users. At the end of iteration 3, leave time to update the release plan with the customer. You will be surprised how easygoing the customer is about changes when a launch date isn't just around the corner. We have never encountered a problem that couldn't be resolved if found early in a project. Here are some obligatory stories from a typical third iteration:
|
| I l @ ve RuBoard |
EAN: 2147483647
Pages: 95