Application Architecture
In software development, several methodologies exist to plan, manage and execute the work. When searching for top best development methodologies, you notice the same ones regularly surface. They are for the most part Scrum, Extreme Programming (XP), Rapid Application Development (RAD), Spiral and of course Agile and Waterfall.
I am unsure why but it seems for a few years now I am often asked about only two, Waterfall or Agile. It could be because in essence Scrum and Extreme Programming are derivative of Agile. Whereas Spiral is of Waterfall.
Or maybe Agile and Waterfall are the most commonly known terms people associate with.
Waterfall – a linear process
The Waterfall methodology is very efficient when the development cycle can be defined as a linear process. It starts at the top with initiation and goes downwards until completion, like a waterfall. This means all the planning is done prior to initiating development, and tasks usually don’t begin until all previous ones are completed.
With this approach unforeseen changes are more likely to cause bigger disruption to the project as they were unplanned or the project does not allow for much flexibility.
Once the project initiates, the work begins and will usually stop once completed - at the bottom of the waterfall.
Barreling down the waterfall
This daredevil is wanting to go down a cliff. He’s assessed and decided that barreling down the waterfall is a valid solution.
He is spending an extensive amount of time planning, considering all the variables: weather, wind speed, his chosen tool kit, force at which he will hit the water, rocks at the bottom etc.
He knows the expected outcome - getting to the bottom alive. And once his plan completed he launches himself down the river, hoping for the best.
This is in essence what the Waterfall approach is.
There is a long and tedious planning phase at the very beginning. It is a rigid process not very flexible to make changes or adjustments once you engage down the chute. The project constraints are defined and agreed upon from the beginning.
Agile – an adaptive cycle
Agile is an umbrella term that encompasses different techniques, i.e. Scrum and Extreme Programming (XP) as listed earlier.
An Agile methodology differs from a Waterfall it the way it is planned - by breaking a lengthy project into smaller more manageable cycles.
In this case you know the project end goal, however the steps are not predefined. The purpose is to chunk out the work in iterations with smaller scope of work. This is very efficient when the sponsor is highly involve with the project team and participates in regular check points.
It allows for re-planning and addressing unforeseen challenges sooner. Thus a better ability to manage the overall budget, scope of work and timeline.
Completing one cycle does not make it a fully functional system, however at the end of each cycle there must be functional components delivered. Validation occurs faster and more frequently.
Barreling down the rapids
Our daredevil adjusted his project plan as he deemed the Waterfall approach too risky. He is now deciding to go down the same cliff but down the river just a few feet away.
His scope has not changed, get to the bottom alive. He’s also decided on utilizing the same took kit (his barrel). This river however has rapids.
He will need to readjust his plan regularly. The variables identified in the first plan are still valid, but also must factor new ones such as the speed of the current at each rapid.
With this method, he is able to plan, execute, validate and adjust after each rapid. He will eventually get to the bottom of the cliff, it just requires him to be more vigilant throughout the journey. And he likely increased his change of success to achieve his goal of arriving alive as well.
During an Agile development cycle, you will see calm waters and rapids. The calm waters is when you take time to refocus, the rapids is when you are in full development and validation.
Choose what's best for the project
In the end the methodology used to build a functional piece of software relies on the need of the project, its constraints, timeline, budgets and the comfortable level of risks.
From experience I don’t believe any given methodology is better over the other. It is not cookie cutter. It is for the project owners and delivery team to define the best approach to achieve the end goal.
I find a combination of both methodology to be efficient – a hybrid solution, where planning is still done on the full scope but then break the work and build the schedule into iterations.
It provides for a broader understanding of the project from the get go, with the added flexibility to address complexity as it surfaces and readjust accordingly.
In the next article I’ll touch on Requirements and the importance of understanding and defining them.
Brenda Bossé, BCSc Business Unit Manager – Software Development Missing Link Technologies Ltd.
Kommentare