Το IT Project Success Survey 2011 που έκανε ο Scott Ambler και παρουσιάζεται στο Dr Dobbs βρήκε ότι το κλασσικό μοντέλο είναι ίδιο ή και χειρότερο ακόμα και από το ad-hoc development, ενώ η σημαντική γραφειοκρατία που απαιτεί έχει ως αποτέλεσμα να είναι οικονομικά ασύμφορο (αρνητικό ROI, Value, Time ακόμα και σε σχέση με το ad-hoc). Παλαιότερα surveys (2010,2008) δείχνουν αντίστοιχα αποτελέσματα, με το κλασσικό μοντέλο να μην αξίζει το μπελά του (μικρότερο ROI από τις άλλες μεθόδους).
Αντίθετα, σε όλες τις περιπτώσεις οι καλύτερες μεθοδολογίες σε ποσοστά επιτυχίας αναδεικνύονται οι iterative και αμέσως μετά οι agile. Από την άλλη, αν δει κανείς πως τα πάνε οι διάφορες μεθοδολογίες όσον αφορά χρόνους και ποιότητα θα δει ότι οι lean έχουν καλύτερους χρόνους και ποιότητα ενώ οι agile καλύτερο ROI και απόδοση.
Το καημένο το waterfall τα πάει πολύ χάλια σε όλους τους τομείς: Σε χρόνους (πόσο έγκαιρα παραδίδεται το έργο) το waterfall βγαίνει χειρότερο και από το "χύμα" (ad-hoc) development, ενώ σε κόστος και απόδοση είναι επίσης χάλια.
Προκαλεί εντύπωση πόσο άσχημα τα πάει το waterfall στους χρόνους, ειδικά αν σκεφτείς πόση δουλειά απαιτεί για τη συλλογή λεπτομερών requirements και εκτιμήσεων για κάθε βήμα του υπερλεπτομερούς project plan. Είναι λογικό όμως αν σκεφτεί κανείς ότι οι χρόνοι στους οποίους βασίζεται το waterfall είναι πλασματικοί. Η καλύτερη δυνατή εκτίμηση στην αρχή ενός έργου δεν μπορεί να είναι καλύτερη από ±4 φορές του πραγματικού χρόνου ενώ ακόμα και μετά τα requirements η αβεβαιότητα περιορίζεται μόλις στο 0.67 - 1.5 φορές. Ακόμα και σε αυτό το σημείο, οι πιθανότητες να βγει το έργο στον υπολογισμένο χρόνο ( μέχρι 1.1 φορές) είναι ελάχιστα καλύτερες από κορώνα-γράμματα.
Υπάρχει όμως ένα σημείο στο οποίο το Waterfall υπερτερεί: Σε εξασφαλίζει αν το έργο καταλήξει στα δικαστήρια. Από τη στιγμή που ο πελάτης έχει αναγκαστικά συμφωνήσει με τις αρχικές προδιαγραφές (ακόμα και αν αυτές αλλάξουν μετά) και εφόσον έχεις "φουσκώσει" αρκετά τους χρόνους, μπορείς να πας στο δικαστήριο και να αντιμετωπίσεις τυχόν απαιτήσεις. Ειδικά αν ο πελάτης θα έχει ζητήσει αλλαγές (που πάντα ζητάει) θα μπορέσεις να πεις ότι οι αλλαγές ευθύνονται για τυχόν καθυστερήσεις.
Εξάλλου ο δικαστής δεν θα κοιτάξει τον κώδικα. Τα requirements και τα change requests θα διαβάσει ....
Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos