«Κάθε επιχείρηση μπορεί να επωφεληθεί σημαντικά αν υιοθετήσει τις βασικές αξίες της ευελιξίας που εμπεριέχονται στο Manifesto for Agile Software Development. Ωστόσο, η βιομηχανία της ανάπτυξης λογισμικού έχει πέσει σε κάποιες παγίδες, από τις οποίες και θα πρέπει να βγει για να πετύχει τους στόχους της». Το παραπάνω μήνυμα εκπέμπει ο συνυπογράφων του Agile Manifesto και ένας εκ των συγγραφέων του Pragmatic Programmer, Dave Thomas, σε συνέντευξή του στο Insider.gr, την οποία παραχώρησε με την αφορμή της ομιλίας του στο 4ο PLG Disrupt Summit –το πρώτο συνέδριο S/W Product Managers & Engineers - που θα πραγματοποιηθεί στις 30 Μαΐου στο Ωδείο Αθηνών.
O άνθρωπος που επινόησε τις φράσεις «code kata» και DRY που σε ελεύθερη μετάφραση στη γλώσσα των προγραμματιστών σημαίνει μην επαναλαμβάνεσαι (Don't Repeat Yourself) –– μιλά για την ανάγκη που χαρτογραφήθηκε το 1990 και δημιούργησε το Agile Manifesto και για τα πολλαπλά οφέλη της ευέλικτης ανάπτυξης λογισμικού.
Παράλληλα, αναλύει τις βασικές προκλήσεις που συνεχίζει να αντιμετωπίζει ο κλάδος των προγραμματιστών, εν μέσω της εν εξελίξει ψηφιοποίησης των πάντων, εξαιτίας της παρερμηνείας της ευέλικτης λογικής που προτείνει το Μανιφέστο του.
- Τι σας παρακίνησε να δημιουργήσετε το Agile Manifesto και ποιες ήταν οι βασικές προκλήσεις ή ζητήματα που ελπίζατε να αντιμετωπιστούν στον κλάδο της ανάπτυξης λογισμικού εκείνη την εποχή;
Η δεκαετία του 1990, ήταν μια εποχή κρίσης στη βιομηχανία ανάπτυξης λογισμικού. Τα πράγματα δεν λειτουργούσαν καλά - μόνο το 16% των έργων λογισμικού ήταν επιτυχημένα το 1995. Για να λυθεί αυτό λοιπόν έπρεπε να προσπαθήσουμε να ελέγξουμε καλύτερα τη διαδικασία. Σε άλλες βιομηχανικές διαδικασίες άλλωστε η παρακολούθηση, η εποπτεία και η χαρτογράφηση των διαδικασιών ήταν τα κλειδιά για την παραγωγικότητα. Η σκέψη δεν ήταν νέα, 100 χρόνια πριν την είχε επισημάνει ο Frederick Taylor και η μελέτη του για την «Επιστημονική Διοίκηση». Έκτοτε η ιδέα του ενσωματώθηκε σχεδόν σε όλες τις πτυχές των σύγχρονων οργανισμών και παραμένει μέχρι και σήμερα ο λόγος για τον οποίο υπάρχει η ιεραρχία ή οι διευθυντές και ο λόγος για τον οποίο οι οργανισμοί εξακολουθούν να αποκαλούν τους εργαζομένους τους «πόρους» και όχι «ανθρώπους».
Ωστόσο, αυτό που δεν καταλαβαίναμε τότε ήταν ότι αυτό το είδος της διαχείρισης λειτουργεί μόνο όταν ξέρεις τι πρέπει να κάνεις. Το να προσθέσεις ακόμα περισσότερη γραφειοκρατία σε ένα έργο που κατευθύνεται προς τη λάθος κατεύθυνση σημαίνει απλώς ότι θα απασχολείς περισσότερους πόρους – δηλαδή ανθρώπους - για να κάνεις κάτι λάθος. Το βασικό πρόβλημα λοιπόν ήταν ότι δεν ξέραμε τι κάνουμε.
- Γιατί συνέβαινε αυτό;
Για δύο λόγους. Αφενός γιατί λογισμικό είναι κάτι νέο και διαρκώς εξελισσόμενο. Ξεκινήσαμε να πειραματιζόμαστε με αυτό πριν από λιγότερο από 100 χρόνια, οπότε δεν αποτελεί έκπληξη το γεγονός ότι δεν έχουμε ακόμη μια σταθερή βάση για να χτίσουμε πάνω σε αυτήν. Το πρόβλημα δε, επιδεινώνεται καθώς το λογισμικό υφίσταται κομβικές αλλαγές κάθε λίγα χρόνια και οι άνθρωποι που ασχολούνται με αυτό πρέπει να επανεκπαιδευτούν από την αρχή.
Αφετέρου βέβαια, το πραγματικό πρόβλημα είναι πιο ύπουλο και συνοψίζεται στο ότι οι άνθρωποι απλά δεν ξέρουν τι χρειάζονται. Κανείς δεν ξέρει. Οι πελάτες ξέρουν τι «θέλουν», αλλά το τι θέλουν είναι πάντα μια εικασία που βασίζεται στα γεγονότα που είναι γνωστά εκείνη τη στιγμή. Κάθε προγραμματιστής λογισμικού έχει σίγουρα βιώσει το να παραδίδει κάτι που του έχουν ζητήσει και να παίρνει ως απάντηση: «Ξέρω ότι είναι αυτό που ζήτησα, αλλά τώρα που το βλέπω, δεν είναι αυτό που χρειάζομαι».
Έτσι, όταν προσπαθούμε να ελέγξουμε την ανάπτυξη λογισμικού θέτοντας σε εφαρμογή άκαμπτες διαδικασίες, και όταν αυτές οι διαδικασίες είναι ένας «καταρράκτης» εγγράφων που ξεκινάει με τις «Απαιτήσεις», συνεχίζει με τις «Λειτουργικές Προδιαγραφές», προχωρά στην «Αρχιτεκτονική» και ούτω καθεξής, στην πραγματικότητα κάνουμε τα πράγματα χειρότερα.
Ο πελάτης μπορεί κάλλιστα να υπογράψει τις απαιτήσεις, αλλά μέχρι να δει το τελικό λογισμικό δεν θα είναι σίγουρος ότι ζήτησε αυτό που πραγματικά χρειάζεται. Έτσι αν μια ομάδα προχωράει στο σκοτάδι, ακολουθώντας την προαναφερθείσα διαδικασία μέχρι που θα αποσταλεί το λογισμικό, τότε τα όποια λάθη έχουν γίνει εκ των προτέρων, μεγεθύνονται σημαντικά.
Κάπως έτσι, στα τέλη της δεκαετίας του '90 έγινε πλέον αρκετά σαφές ότι τα πράγματα έπρεπε να αλλάξουν. Κάποιοι από εμάς πειραματιζόμασταν με διαφορετικούς τρόπους αναθεώρησης της διαδικασίας ανάπτυξης λογισμικού και αυτά τα πειράματα ,συχνά θα έλεγα, παρήγαγαν εκπληκτικά (και θετικά) αποτελέσματα.
Καθώς λοιπόν συζητούσαμε σε ένα συνέδριο το 2000 για πρότζεκτ με τα οποία ασχολούμαστε έγινε σαφές ότι όσο κι αν διέφεραν οι προσεγγίσεις, οι ιδέες πίσω από τις επιτυχημένες υλοποιήσεις ήταν αρκετά παρόμοιες. Κάπως έτσι αποφασίσαμε να συναντηθούμε λίγους μήνες μετά το συνέδριο και να περάσουμε λίγες μέρες εξερευνώντας τις ιδέες αυτές και κάπως έτσι προέκυψε το Manifesto. Τότε, δεν είχαμε ιδέα ότι αυτό που επρόκειτο να κάνουμε θα είχε κάποιο πραγματικό αποτέλεσμα, και σίγουρα δεν θα μπορούσαμε ποτέ να φανταστούμε τον τρόπο με τον οποίο θα άλλαζε τη βιομηχανία.
- Κοιτάζοντας λοιπόν πίσω στο Agile Manifesto, πώς αντιλαμβάνεστε την επίδρασή του στην κοινότητα ανάπτυξης λογισμικού από την δημοσίευσή του μέχρι και σήμερα;
Η ερώτηση αυτή δεν μπορεί να απαντηθεί μέσα σε λίγες μόνο παραγράφους, οπότε αυτά που θα σας πω τώρα δεν θα είναι πλήρη. Πρώτον, και νομίζω όλοι μπορούν να συμφωνήσουν σε αυτό, η ανάπτυξη λογισμικού βρίσκεται σε καλύτερη κατάσταση από ό,τι ήταν πριν από 25 χρόνια. Τότε, το 15% των έργων πετύχαινε. Με την ίδια μέτρηση, σήμερα πετυχαίνει ένα ποσοστό της τάξης του 42%.
Το ποσοστό γίνεται ακόμα πιο εντυπωσιακό αν σκεφτεί κανείς ότι τα λογισμικά που γράφουμε σήμερα είναι μακράν πιο πολύπλοκα από τότε. Ωστόσο θα πρέπει να σημειωθεί ότι το 42% αφορά τις ομάδες που υιοθετούν agile -ευέλικτες δηλαδη - μεθόδους. Όσες δεν χρησιμοποιούν agile προσέγγιση έχουν χειρότερες επιδόσεις από ό,τι το 1995, με μόνο το 13% των πρότζεκτ να πετυχαίνουν.
Θα το αφήσω σε κάποιον ειδικό της στατιστικής να ποσοτικοποίησει την οικονομική επίδραση όλης αυτής της συνθήκης, αλλά εκτιμώ ότι ακολουθώντας τις αρχές της ευελιξίας, οι οικονομίες έχουν πιθανότατα εξοικονομήσει δισεκατομμύρια, αν όχι τρισεκατομμύρια. Κι αυτή είναι μόνο η πρώτη -εξωτερική θα έλεγα – ανάγνωση.
Εκ των έσω, οι ιδέες πίσω από την ευελιξία έχουν αλλάξει τον τρόπο οργάνωσης πολλών ομάδων και έργων. Αναμένουμε πλέον να γράφουμε και να παραδίδουμε λογισμικό πολλές φορές, με τον πελάτη να λαμβάνει νέα κομμάτια κάθε δύο έως τέσσερις εβδομάδες. Πλέον οι προγραμματιστές συμμετέχουν στον καθορισμό των στόχων και χρησιμοποιούν την ανατροφοδότηση για να μετράνε τόσο το λογισμικό όσο και τις διαδικασίες τους. Και αυτό είναι εξίσου σημαντικό.
Υπάρχει, όμως, και μια αρνητική πλευρά. Αντί να ερμηνεύσουν οι ίδιες τις αξίες του Manifesto, πολλές εταιρείες απλώς βρίσκουν ένα «έτοιμο» σύνολο πρακτικών τις οποίες χαρακτηρίζουν «ευέλικτες». Εξ ορισμού ένα σταθερό σύνολο πρακτικών δεν μπορεί να είναι ευέλικτο, επειδή η ευελιξία σημαίνει ακριβώς το αντίθετο: να ανταποκρίνεσαι δηλαδή στο άμεσο περιβάλλον με την πάροδο του χρόνου. Αν οι πρακτικές σου δεν αλλάζουν, τότε δεν προσαρμόζεσαι- επιστρέφεις στην κόλαση της δεκαετίας του 1990 που βασίζεται στις διαδικασίες.
- Άρα, απ’ ότι καταλαβαίνω το Agile Manifesto δίνει έμφαση στα άτομα και στην αλληλεπίδρασή τους, έναντι των διαδικασιών και των εργαλείων. Υιοθετείται αυτή η αρχή στη σημερινή κοινότητα ανάπτυξης λογισμικού;
Νομίζω ότι αυτό είναι το βασικό ερώτημα που πρέπει να εξεταστεί. Στην πράξη, οι εταιρείες που «τιμούν», εφαρμόζουν δηλαδή, αυτή την αρχή της ευελιξίας είναι σπάνιες. Μάλιστα, πολλές έχουν υπαναχωρήσει, βασιζόμενες πλέον στο δεκανίκι των σταθερών διαδικασιών. Οπότε τα άτομα απλώς ακολουθούν τα σενάρια που υπαγορεύουν αυτές οι διαδικασίες, καταλήγοντας σε μια «τραγωδία» του agile κινήματος.
Στο ίδιο σημείο βέβαια, βρίσκεται και η λύση του προβλήματος. Πιστεύω ακράδαντα ότι η επιτυχία σε οποιονδήποτε τομέα, έρχεται από την ευθυγράμμιση των πεποιθήσεων και των προσπαθειών των ανθρώπων που εμπλέκονται σε ένα πρότζεκτ. Συνίσταται δηλαδή στο να τους εφοδιάζεις με τα εργαλεία που χρειάζονται και, στη συνέχεια, να βγαίνεις από τη μέση.
Αν δημιουργήσουμε το κατάλληλο περιβάλλον, χρειάζεται μόνο ελάχιστη καθοδήγηση για να βοηθηθούν οι ομάδες και να ανακαλύψουν ότι μπορούν να είναι ευέλικτες. Αν δε αυτό συνδυαστεί με ένα περιβάλλον που τις ενδυναμώνει και τις υποστηρίζει καθώς προσαρμόζονται στις αλλαγές, τότε μπορούμε να ανεβάσουμε το ποσοστό επιτυχίας του 42% σε 60% ή και 75%, ποιος ξέρει. Στην πραγματικότητα, σε έναν ευέλικτο οργανισμό, το ποσοστό επιτυχίας μπορεί να είναι κοντά στο 100%, απλώς και μόνο επειδή η επιτυχία ορίζεται και βελτιώνεται καθώς το έργο προχωρά.
- Οι ευέλικτες μεθοδολογίες έχουν εξελιχθεί με την πάροδο του χρόνου. Με ποιους τρόπους πιστεύετε ότι οι βασικές αξίες και αρχές του Agile Manifesto έχουν παραμείνει επίκαιρες. Yπήρξε μετατόπιση κατά την ερμηνεία ή την εφαρμογή τους;
Η καρδιά του Agile Manifesto εδράζεται σε τέσσερις αξίες- όλα τα υπόλοιπα είναι απλώς συμπληρώματα.
Ανακαλύπτουμε καλύτερους τρόπους ανάπτυξης λογισμικού, καθώς το αναπτύσσουμε και βοηθώντας τους άλλους να κάνουν το ίδιο. Μέσω αυτής της διαδικασίας οι τέσσερις αξίες είναι οι εξής:
- Να ανταποκρινόμαστε στην αλλαγή αντί να ακολουθούμε ένα σχέδιο
- Τα άτομα και η αλληλεπίδραση υπερτερεί των διαδικασιών και των εργαλείων
- Ένα λογισμικό που λειτουργεί έναντι της αναλυτικής τεκμηρίωσης
- Η συνεργασία με τους πελάτες έναντι της διαπραγμάτευσης συμβάσεων
Βλέπουμε δηλαδή ότι ενώ υπάρχει αξία στα στοιχεία στα δεξιά, βαραίνουν περισσότερο τα στοιχεία στα αριστερά.
Είκοσι και πλέον χρόνια αργότερα, εξακολουθώ να πιστεύω σε αυτές τις αξίες. Για μένα αντιπροσωπεύουν μια πολύ ανθρώπινη και ανθρωπιστική προσέγγιση για την αντιμετώπιση οποιουδήποτε σύνθετου προβλήματος. Μια από τις χαρές που πήρα όλα αυτά τα χρόνια είναι να παρακολουθώ την υιοθέτηση αυτών των αξιών σε βιομηχανίες εκτός της ανάπτυξης λογισμικού.
Έτσι, νομίζω ότι οι βασικές αξίες εξακολουθούν να είναι επίκαιρες και θεωρώ ότι αποτελούν μια εξαιρετική βάση για τη λήψη αποφάσεων, καθώς εργαζόμαστε μαζί για να κάνουμε «αδύνατα» πράγματα. Τελικά, αυτή είναι η επιτυχία του Μανιφέστου για τo Αgile software development.
