Agile vs Waterval: Waarom één methode volgen?

Bij de implementaties van zoekoplossingen speelt altijd het onderwerp “welke projectmethodiek hanteren we hierbij?”.

Het is niet te voorkomen dat je daarbij de op dit moment belangrijkste stromingen tegenover elkaar zet:

  • Waterval
    Design, Develop, Test and implement everything at once
  • Agile
    Design, Develop, Test, Adept, Implement in small steps

Het is ook bijna niet te voorkomen dat beide methodieken als “geloof” worden gezien en de aanhangers elkaar in de haren vliegen omdat de één “Agile” predikt, en de ander “Waterval”.
Deze tegenstelling komt soms voort uit een diepgewortelde wens voor controle en andere keren uit aangeleerde werkwijzen.

In het artikel “Agile vs Waterfall” staan enkele kenmerken van beide methodieken en voorbeelden van waarom je voor de ene of de andere (eigenlijk staat hier dat Agile altijd beter is) methode zou moeten kiezen.

Er staan in dit artikel enkele uitspraken over de nadelen van een waterval-aanpak die erg gechargeerd zijn.

Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method.

Het is natuurlijk onzin om te zeggen dat iedere wijziging zal leiden tot een complete herbouw. Je kan binnen de waterval methode gerust wijzigingen aanbrengen.
Ik heb bij het gebruiken van de Agile methodiek voorbeelden gezien van de noodzaak tot herbouw van complete delen van een applicatie omdat de opdrachtgever met aanvullende eisen / wensen kwam.

Een quote uit een ander artikel:

Agile and Prince2 are generally used to manage different sorts of projects: in my experience agile is for fast results-driven market-critical projects where many changes and flexibility are paramount, whereas Prince2 is more often used for projects that need a high level of accountability and paper-trails for all decisions and many stakeholder sign-off and overview procedures.

Er zijn echter ook artikelen gepubliceerd over het combineren van bijv. PRINCE2 en Agile.

Het is zeer goed mogelijk om PRINCE2 elementen te gebruiken als een schil rondom Agile uitgevoerde ontwikkeling. Als belangrijkste argument hiervoor wordt wel gegeven dat PRINCE2 de projectrisico’s beter afdekt en dat het beter past in een organisatie waar veel stakeholders goedkeuring moeten geven aan projectdoelstellingen en budgetten.
Daarbinnen kunnen iteraties een plek krijgen die via de Agile methodiek worden uitgevoerd. Het zal echter ongetwijfeld spanningen opleveren.

In conclusion, though on the plus side, waterfall’s defined stages allow for thorough planning, especially for logical design, implementation and deployment, Agile methodology is a sound choice for software development and web design projects.

Agile and Prince2 are generally used to manage different sorts of projects: in my experience agile is for fast results-driven market-critical projects where many changes and flexibility are paramount, whereas Prince2 is more often used for projects that need a high level of accountability and paper-trails for all decisions and many stakeholder sign-off and overview procedures.
This entry was written by Edwin Stauthamer , posted on dinsdag januari 03 2012at 02:01 pm , filed under Opinie and tagged , , . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

Geef een reactie

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>