Όχι, Agile δεν είναι ένας “έξυπνος” τρόπος να πιέσετε τον developer σας.

Όλο και περισσότερες φορές βρισκόμαστε “μάρτυρες” περιστατικών που ξεκινούν από την ανάγκη όλων να έχουν αποτελέσματα όσο το δυνατόν νωρίτερα, ακόμα και στιγμιαία, όπου η χρήση διάφορων “trendy” όρων γίνεται υπερβολική ακόμα και εκνευριστική.

Ένας από αυτούς τους όρους λοιπόν είναι το Agile Development. Ουσιατικά πρόκεται για έναν τρόπο ανάπτυξης κάθε είδους λογισμικού από σχετικά μικρές ομάδες προγραμματιστών όπου ένας από αυτούς ή κάποιος μη-προγραμματιστής είναι ο SCRUM master, δηλαδή ο “σύνδεσμος” επικοινωνίας με τον πελάτη αλλά και ο διαχειριστής της ομάδας.

Ο Scrum Master ουσιαστικά καθοδηγεί και προωθεί τις απαιτήσεις του πελάτη στην ομάδα. Κατά το agile development λοιπόν, σε τακτά χρονικά διαστήματα και εφόσον οι γενικότερες απαιτήσεις έχουν κατατμηθεί σε μικρά παραδοτέα, η ομάδα κάνει το λεγόμενο “sprint” δηλαδή το “τρέξιμο” έτσι ώστε να παραδόσουν το επόμενο μικρό παραδοτέο. Κατά το sprint καμία νεα απαίτηση δεν γίνεται δεκτή παρά μόνο μέχρι να ολοκληρωθεί το sprint. Κάθε νεα απαίτηση μπορεί να ενταχθεί στο επόμενο ή σε κάποιο επόμενο sprint.

Συνήθως τα sprints έχουν διάρκεια μιας ή δυο εβδομάδων, ανάλογα φυσικά με την πολυπλοκότητα του έργου. Όταν το spring ολοκληρωθεί, ο πελάτης επιβεβαιώνει το παραδοτέο και το έργο προχωραέι στο επόμενο sprint.

Φυσικά, για να περιγράψουμε και την πραγματικότητα, δεν νοείται Agile Team με έναν προγραμματιστή. Επίσης, δεν νοείται να χρησιμοποιείται ο όρος Agile και sprint σε μικρά έργα. Η πραγματικότητα όμως δεν είναι έτσι. Πολλοί προσπαθούν να χρησιμοποιήσουν τον όρο Agile, Scrum, Sprint σε προτάσεις για να πείσουν για την διάνοιά τους αλλά και για να σπρώξουν τον προγραμματιστή σε πιο “επαγγλεματικά” νερά. Fair enough αλλά αν ο πελάτης θέλει να δουλέψει με agile, πρέπει να δεχθεί και κάποιες υποχρεώσεις :

1. τα παραδοτέα του έργου πρέπει να είναι σαφώς ορισμένα από την αρχή
2. ανάμεσα από 2 sprints δεν μπορεί να εμφανισθούν νεες απαιτήσεις
3. νέες απαιτήσεις μη ορισμένες από την αρχή, θα επεκτείνουν το έργο
4. μετά από κάθε ενα sprint θα πρέπει να υπάρχει σαφής επιβεβαίωση ή όχι του παραδοτέου σύμφωνα με τις αρχικές απαιτήσεις, όχι σύμφωνα με νεες απαιτήσεις που στην πορεία εμφανίσθηκαν

Είναι σημαντικό δε, οι απαιτήσεις να ορίζονται όσο το δυνατόν περισσότερ και καλύτερα από την αρχή. Είναι μια διαδικασία δύσκολη αλλά αν δεν γίνει σε βάθος και με πολύ φαντασία, τότε θα οδηγήσει σε πολύ μεγάλα προβλήματα στην πορεία.

Φανταστείτε όχι ξεκινάτε να κατασκεάζετε μια ιστοσελίδα με κάποιον προγραμματιστή, του αναφέρετε γενικά πράγματα για τη σελίδα σας και ο προγραμματιστής σας δίνει ένα χρονικό περιθώριο για την ανάπτυξη και κάποιο κόστος. Για τη σελίδα σας επιλέγετε σε συμφωνία με τον προγραμματιστή σας την πλατφόρμα Α. Στην πορεία λοιπόν, σκέφτεστε πως τα μεταφορικά σας κόστη θα πρέπει να ορίγονται ανα ΤΚ και ταυτόχρονα ογκομετρικό βάρος, τυχαίνει η πλατφόρμα που έχετε επιλέξει ( την επιλέξατε για τα γραφικά, για την ευχρηστία και φυσικά ανάλογα με το κόστος της ) δεν υποστηρίζει τέτοιου είδουν μεταφορικά. Ή θα πρέπει να αλλάξετε πλατφόρμα, ή να επιλέξετε κάποια επέκτασή της που θα αγοράσετε ή θα πρέπει να γραφτεί κώδικας για να γίνει. Όλα τα παραπάνω θα απαιτήσουν παραπάνω χρόνο και χρήμα για το έργο που δεν είχε αρχικά προυπολογιστή.

Θα πρέπει λοιπόν, αν θέλουμε να εργαστούμε με κάποια φιλοσοφία ( πχ Agile ) να έχουμε μερικά βασικά στοχεία στο μυαλό μας :

1. να γνωρίζουμε τι σημαίνει
2. να γνωρίζουμε τις απαιτήσεις που θα έχει και απο τον πελάτη
3. να γνωρίζουμε τις απαιτήσεις που θα έχει και απο τον προγραμματιστή
4. να αναλύσουμε και να συζητήσουμε όσο το δυνατόν αναλυτικότερα τις απαιτήσεις ΑΠΟ ΤΗΝ ΑΡΧΗ για να μην υπάρξουν αρνητικές εξελίξεις στην πορεία.