For the last 5 months I have been working on a financial project using Flex. What separates this project from any other project is that my team is using the Agile methodology for application development. If you aren’t familiar with Agile, SCRUM, or XP methodologies, let me explain briefly.
Agile is a new approach to application development. It is an alternative to the classic waterfall development phases. In waterfall, the development is generally approached sequentially. Here are some possible steps to the waterfall approach:
- brainstorming, wireframing, requirements gathering, etc.
- client review of design
- internal QA
- client review process
- repeat steps 2-6 again if applicable (and yes it is applicable)
- have a huge final release
The first and most fundamental flaw with this approach is the inefficient use of a project’s assets. While design is in process, the dev team has to wait until steps 2 & 3 are done. Then when development starts, both the design and QA teams are waiting for work. Another flaw is that often times, project requirements are never really questioned until time has been spent on those requirements in question.
The Agile approach solves these issues by embracing the fact that a project’s requirement will change during its lifetime. It embraces change and anticipates it. This is done by breaking a project down into smaller pieces and ‘sizing’ them. Here is a breakdown of these smaller pieces:
- Project – contains…
- Iterations: 1-4 week phases which multiple…
- Stories: major features and requirements that can take one or several days consisting of one or more….
- Tasks: small developmental/design tasks that can take one or several days.
Sizing is where we assess the difficulty of a story and its subsequent tasks. This is done by using an arbitrary numbering system. In my team’s case, we give easy stories 3 or less, mediums stories 5 or 8 and very difficult stories 13 or above. The sizing and the numbers used will differ from team to team. So after a team works together through and iteration to two, they learn about how many points they generally can accomplish during an iteration. That might be only two very difficult tasks per iteration or it could mean 10 quick easy stories. That is determined by the client’s priority assessment during that iteration.
What really makes this work is that the client is involved in the process through out. The client is constantly assessing the priorities of the project’s stories. During and iteration, the client will pick stories that he finds important to the success of the project. And a developer such as myself can really benefit in this process because, we are simply not told to create something. We are involved in saying which tasks are easy or hard. What I really love is that generally, the Agile minded client will be open to suggestions.
Case in point: Our current project started off trying to make a Flex application look more like an HTML type project. Because the client values the developer’s input, we are able to present better options, thus influencing the direction the project takes.
This is just a quick introduction to Agile. If you are at all interested due to this article, there are plenty of in-depth web pages on Agile and other SCRUM like development methodologies.