Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού

Transcript

1 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Δρ. Βασίλης Γερογιάννης Καθηγητής ΤΕΙ Θεσσαλίας Η εφαρμογή αποτελεσματικών διαδικασιών για την ανάπτυξη λογισμικού τα τελευταία χρόνια αποτελεί ένα θέμα που απασχολεί τόσο τους ερευνητές στην Τεχνολογία Λογισμικού όσο και τις εταιρείες που αναπτύσσουν λογισμικό. Η γενικότερη τάση τόσο στη θεωρία όσο και στην πράξη είναι προς την κατεύθυνση της εισαγωγής και της υιοθέτησης των λεγόμενων Ευέλικτων Διαδικασιών Ανάπτυξης Λογισμικού (Agile Software Development Processes). Μια ευέλικτη διαδικασία ορίζει ένα σύνολο ενεργειών και βημάτων κατά την ανάπτυξη ενός έργου λογισμικού, έχοντας ως βάση δοκιμασμένες στην πράξη αρχές και πρακτικές. Οι στόχοι μιας ευέλικτης διαδικασίας είναι να υποστηριχθεί: η ανάπτυξη όσο το δυνατό πιο «ποιοτικού» λογισμικού, η ολοκλήρωση του έργου ανάπτυξης και η παράδοση του λογισμικού μέσα στα προβλεπόμενα χρονικά όρια, η δυνατότητα προσαρμογής του λογισμικού σε συνεχείς αλλαγές, π.χ. η απόκριση σε μεταβολές στις απαιτήσεις των χρηστών και γενικότερα σε αλλαγές που δημιουργούνται από το διαρκώς μεταβαλλόμενο επιχειρησιακό περιβάλλον μέσα στο οποίο ένα σύστημα λογισμικού εντάσσεται και λειτουργεί. Για να πετύχει αυτούς τους στόχους, μια ευέλικτη διαδικασία δίνει έμφαση κυρίως σε παράγοντες που σχετίζονται με το ανθρώπινο δυναμικό του έργου, δηλ. επικεντρώνεται στους συμμετέχοντες-stakeholders στο έργο και στην επικοινωνίασυνεργασία μεταξύ τους, και όχι σε γραφειοκρατικές διαδικασίες διαχείρισης του έργου (π.χ. στη συγγραφή των παραδοτέων, τεχνικών αναφορών, εγγράφων 1

2 2 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού τεκμηρίωσης κλπ.). Μια ευέλικτη διαδικασία στηρίζεται και ευνοεί την ομαδική και συντονισμένη συνεργασία μεταξύ των διάφορων συμμετεχόντων σε ένα έργο λογισμικού. Χαρακτηριστικά παραδείγματα διαδεδομένων ευέλικτων διαδικασιών είναι ο Ακραίος Προγραμματισμός (Extreme Programming), η διαδικασία Ανάπτυξης που είναι προσανατολισμένη στα Χαρακτηριστικά του Λογισμικού (Feature Driven Development) και η διαδικασία Ανάπτυξης Δυναμικών Συστημάτων (Dynamic Systems Development). Οι διαδικασίες αυτές περιγράφονται συνοπτικά στο παρόν κεφάλαιο του βιβλίου. Με περισσότερη λεπτομέρεια και πιο αναλυτικά στο παρόν κεφάλαιο του βιβλίου παρουσιάζονται οι διαδικασίες Scrum και Kanban, δύο ιδιαίτερα δημοφιλείς ευέλικτες/επαναληπτικές διαδικασίες που χαρακτηρίζονται από μεγάλη αποδοχή διεθνώς κυρίως από μικρομεσαίες εταιρείες ανάπτυξης λογισμικού. Οι διαδικασίες Scrum και Kanban έχει αποδειχτεί στην πράξη ότι είναι κατάλληλες για έργα ανάπτυξης που υλοποιούν μικρές-συνεκτικές ομάδες ανάπτυξης λογισμικού και, για το λόγο αυτό, υιοθετούνται από μικρομεσαίες εταιρείες ανάπτυξης λογισμικού. Ολοκληρώνοντας τη μελέτη των σημειώσεων ο αναγνώστης: Θα κατανοήσει τις βασικές αρχές και τα χαρακτηριστικά των ευέλικτων μεθοδολογιών. Θα γνωρίσει τα βασικά χαρακτηριστικά του Ακραίου Προγραμματισμού (Extreme Programming), της διαδικασίας Ανάπτυξης που είναι προσανατολισμένη στα Χαρακτηριστικά του Λογισμικού (Feature Driven Development) και της διαδικασίας Ανάπτυξης Δυναμικών Συστημάτων. Θα μάθει τις πρακτικές και τις ενέργειες που εφαρμόζονται στη διαδικασία Scrum. Θα μάθει τις πρακτικές και τις ενέργειες που εφαρμόζονται στη διαδικασία

3 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 3 Kanban. Μέσα από τη σύγκριση των διαδικασιών Scrum και Kanban, ο αναγνώστης θα είναι σε θέση να μπορεί να τις εφαρμόζει συνδυαστικά, αξιοποιώντας τα πλεονεκτήματα καθεμιάς. 1. Βασικές Αρχές των Ευέλικτων Διαδικασιών Ανάπτυξης Λογισμικού Οι εταιρείες ανάπτυξης λογισμικού προσπαθούν διαρκώς να αυξήσουν την παραγωγικότητά τους και παράλληλα να διατηρήσουν την ποιότητα των παραγόμενων προϊόντων-υπηρεσιών λογισμικού σε υψηλά επίπεδα [Bowers, 2002]. Η διαπίστωση αυτή είναι ένας από τους σημαντικότερους λόγους που οδηγεί τις εταιρείες ανάπτυξης λογισμικού στη συνεχή αναζήτηση νέων διαδικασιών (δηλ. συνόλων ενεργειών-βημάτων) που αν υιοθετηθούν θα συνεισφέρουν στην αποτελεσματική υλοποίηση των έργων τους. Ιδιαίτερα ισχυρό κίνητρο για την υιοθέτηση νέων διαδικασιών είναι και τα προβλήματα που συνεχώς προκύπτουν σχετικά με ανικανοποίητες ανάγκες των χρηστών από συστήματα λογισμικού που δεν πληρούν τις αρχικές απαιτήσεις για τις οποίες σχεδιάστηκαν. Το χρονοδιάγραμμα ενός έργου ανάπτυξης λογισμικού ορίζει πότε θα παραδοθούν συγκεκριμένα τμήματα (εκδόσεις releases) του τελικού λογισμικού, το καθένα από τα οποία παρέχει συγκεκριμένες λειτουργίες ικανοποιώντας αντίστοιχες απαιτήσεις των χρηστών από το λογισμικό. Κάθε έκδοση παράγεται μετά από ένα επαναληπτικό κύκλο που περιλαμβάνει δραστηριότητες υλοποίησης (development) και δραστηριότητες ελέγχου (testing) (Σχήμα 1). Παρατηρείται όμως στην πράξη πως οι απαιτήσεις των χρηστών από το λογισμικό να μη δύναται να προδιαγραφούν πλήρως από την αρχή του έργου. Συνεπώς, κατά την υλοποίηση ενός έργου ανάπτυξης ενός λογισμικού, θα πρέπει ο υπεύθυνος για τη διαχείριση του έργου (project manager) να εξετάσει τρόπους ώστε να διαχειριστεί αποτελεσματικά πιθανές ελλείψεις στις απαιτήσεις. Εκτός από τη μη γνώση των απαιτήσεων, σημαντικός κίνδυνος για την επιτυχία του έργου παρουσιάζεται όταν οι απαιτήσεις από το λογισμικό ενδέχεται να τροποποιηθούν μερικώς ή ακόμη και να αλλάξουν ριζικά κατά τη διάρκεια του έργου.

4 4 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Σχήμα 1: Το λογισμικό αναπτύσσεται σε εκδόσεις (releases) (Προέλευση εικόνας: Οι κίνδυνοι αυτοί συναντώνται περισσότερο σε περιπτώσεις ανάπτυξης λογισμικού για την ευρεία αγορά (market driven software development) και λιγότερο σε περιπτώσεις ανάπτυξης λογισμικού για συγκεκριμένους πελάτες (customer driven software development). Ελλείψεις και μεταβολές στις απαιτήσεις από το λογισμικό επιφέρουν συνεχείς αλλαγές στον προγραμματισμό του έργου ανάπτυξης. Οι αλλαγές στον προγραμματισμό με τη σειρά τους συνεπάγονται μεγαλύτερη απαιτούμενη προσπάθεια, αύξηση του κόστους της ανάπτυξης και σημαντικές χρονικές καθυστερήσεις για το έργο. Η αντιμετώπιση των αλλαγών αποτελεί μια πρόκληση ειδικά για εταιρείες που αναπτύσσουν λογισμικό για ευρεία χρήση (για την αγορά) ώστε να μπορούν να εντοπίζουν έγκαιρα και με πληρότητα τις ανάγκες των δυνητικών πελατών-χρηστών. Η ανάπτυξη λογισμικού για ευρεία αγορά είναι μια συνεχής, αδιάλειπτη διαδικασία (Σχήμα 2).

5 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 5 Σχήμα 2: Η ανάπτυξη λογισμικού για την αγορά είναι μια συνεχής διαδικασία (Προέλευση εικόνας [Pikkarainen et al., 2011]) Οι γρήγοροι ρυθμοί με τους οποίους αλλάζουν οι απαιτήσεις των χρηστών από το λογισμικό, σε συνδυασμό με τις συνεχώς μεταβαλλόμενες τεχνολογικές λύσεις αλλά και το διαρκή ανταγωνισμό, δημιουργούν την αναγκαιότητα σε μια εταιρεία που αναπτύσσει λογισμικό να υιοθετήσει και να ακολουθήσει ένα πιο «ευέλικτο» πλάνο για τη διαχείριση της υλοποίησης των συστημάτων (προϊόντων - υπηρεσιών) λογισμικού που αναπτύσσει. Οι ευέλικτες διαδικασίες ανάπτυξης λογισμικού (agile software development processes) εμφανίστηκαν σχετικά πρόσφατα στο πεδίο της Τεχνολογίας Λογισμικού [Beck, 1999] και έρχονται να καλύψουν τις προαναφερόμενες ανάγκες των σύγχρονων εταιρειών ανάπτυξης λογισμικού. Ο όρος «ευέλικτες» χρησιμοποιήθηκε για να χαρακτηρίσει διαδικασίες ανάπτυξης οι οποίες διέπονται από κοινές «αρχές», αρχές που δεν έχουν ένα θεωρητικό χαρακτήρα αλλά ουσιαστικά συνδέονται με πρακτικούς στόχους και ενέργειες που μπορούν να εξυπηρετήσουν τις διαρκώς μεταβαλλόμενες ανάγκες που προκύπτουν κατά τη διάρκεια της ανάπτυξης ενός συστήματος λογισμικού. Για παράδειγμα, πρακτικά προβλήματα που ανακύπτουν είναι η κατανόηση, η εκμαίευση και η ιεράρχηση των απαιτήσεων των χρηστών, η

6 6 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού έγκαιρη υλοποίηση - παράδοση του λογισμικού στους πελάτες-χρήστες και η άμεση απόκριση σε αλλαγές/διαφοροποιήσεις των απαιτήσεων και των προδιαγραφών του λογισμικού. Επίσης πρακτικός στόχος είναι η αύξηση της παραγωγικότητας της εταιρείας μέσω της αποφυγής «περιττών» (και συνήθως γραφειοκρατικών) δραστηριοτήτων (π.χ. συγγραφή μακροσκελών παραδοτέων, τεχνικών αναφορών, αναφορών προόδου, εγγράφων τεκμηρίωσης κλπ.) οι οποίες δύναται να επιβαρύνουν ένα έργο ανάπτυξης λογισμικού, είτε από πλευράς κόστους, είτε από πλευράς χρόνου. Οι ευέλικτες διαδικασίες είναι ιδιαίτερα δημοφιλείς στις μέρες μας (σε αντίθεση με «αυστηρές-δύσκαμπτες» διαδικασίες όπως αυτή της Δομημένης Ανάλυσης και Σχεδίασης [Davis, 1992] που η αποδοχή τους συνεχώς μειώνεται) και υιοθετούνται από όλο και περισσότερες εταιρείες που αναπτύσσουν λογισμικό.

7 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 7 2. Το «Μανιφέστο» των Ευέλικτων Διαδικασιών (Agile Manifesto) Μια ευέλικτη διαδικασία «υπόσχεται» (όσο το δυνατόν πιο) άμεση απόκριση στις αλλαγές, παραγωγικότερες πρακτικές και λιγότερη γραφειοκρατία. Ο χαρακτηρισμός «ευέλικτη» αναφέρεται κυρίως στη συνολική ικανότητα της διαχείρισης ενός έργου να προσαρμόζει κατάλληλα τις αποφάσεις που αφορούν το πλάνο της ανάπτυξης του έργου όταν προκύπτουν αλλαγές κατά την πρόοδο του έργου [Cockburn, 2002]. Οι πρώτες ευέλικτες διαδικασίες εμφανίστηκαν στη δεκαετία του 1990, ως εναλλακτική πρόταση έναντι των έως τότε παραδοσιακών, «δύσκαμπτων» (από άποψη διαχειριστικής εφαρμογής) διαδικασιών της ανάπτυξης λογισμικού (π.χ. τη διαδικασία της Δομημένης Ανάλυσης και Σχεδίασης (Structured Analysis & Design Technique) [Davis, 1992] ή τη Διαδικασία της Ενοποιημένης Προσέγγισης (Unified Process) [Kruchten, 2004]). Στις αρχές του 2001, 17 ειδικοί και «υπέρμαχοι» των ευέλικτων διαδικασιών για την ανάπτυξη λογισμικού συναντήθηκαν στην περιοχή Snowbird της Πολιτείας Utah των ΗΠΑ για να συζητήσουν και να συμφωνήσουν τελικά πάνω σε ένα σύνολο κοινών αρχών που πρέπει να διέπουν κάθε ευέλικτη διαδικασία. Αποτέλεσμα της συνάντησης εργασίας ήταν η συγγραφή ενός κειμένου θέσεων, το λεγόμενο «μανιφέστο» των ευέλικτων διαδικασιών (Agile Manifesto, 1. Στο κείμενο αυτό καθορίζονται τέσσερις βασικές θέσεις που διέπουν τις ευέλικτες διαδικασίες [Beck et al., 2002]: 1. Τα άτομα και οι αλληλεπιδράσεις τους έχουν προτεραιότητα σε σχέση με τις διαδικασίες και τα εργαλεία (individuals and interactions over processes and tools). 2. Ένα σύστημα λογισμικού που λειτουργεί έχει προτεραιότητα σε σχέση με την εκτενή και λεπτομερή τεκμηρίωση του συστήματος (working software over comprehensive documentation). 1 Οι συγγραφείς του Agile Manifesto ήταν οι Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Ken Schwaber, Jeff Sutherland, Dave Thomas (

8 8 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 3. Η συνεργασία με τον πελάτη έχει σημασία και όχι οι συμβατικές διαπραγματεύσεις (customer collaboration over contract negotiation). 4. Η απόκριση στις αλλαγές είναι πιο σημαντική σε σχέση με την αυστηρή τήρηση ενός προδιαγεγραμμένου πλάνου (responding to change over following a plan). Οι βασικές αυτές θέσεις αναλύονται περαιτέρω στη συνέχεια: Πρώτον, τονίζεται η ανάγκη για συνεχή συνεργασία μεταξύ των συμμετεχόντων σε ένα έργο λογισμικού, κάτι που αποτελεί το σημαντικότερο παράγοντα για την επιτυχία του έργου. Οι διαδικασίες και τα τεχνολογικά εργαλεία δεν πρόκειται να συνεισφέρουν ουσιαστικά, αν η συνεργασία μεταξύ των συμμετεχόντων στο έργο δεν είναι διαρκής, αποτελεσματική και επιτυχής. Δεύτερον, το μανιφέστο υπογραμμίζει τον πρωταρχικό στόχο του έργου, ο οποίος είναι η παραγωγή ενός συστήματος λογισμικού που λειτουργεί δηλ. δεν παρουσιάζει σφάλματα και παρέχει λειτουργίες που πληρούν τις απαιτήσεις από το λογισμικό και κατ επέκταση τις ανάγκες των πελατώνχρηστών. Οι προγραμματιστές ενθαρρύνονται να διατηρήσουν τον κώδικα τους όσο πιο απλό γίνεται, με αποτέλεσμα το ίδιο το λογισμικό να είναι κατανοητό ώστε να τίθεται σε δευτερεύουσα προτεραιότητα η συγγραφή μακροσκελών εγγράφων και αναλυτικών διαγραμμάτων τεκμηρίωσης. Η λεπτομερής τεκμηρίωση είναι σημαντική για να εξηγήσει το στόχο και τις λειτουργίες του λογισμικού, αλλά ο ρόλος της θα είναι πάντα δευτερεύων και συμπληρωματικός σε σχέση με τον κώδικα και το τελικό προϊόν/υπηρεσία λογισμικού που ζητάει ο πελάτης-χρήστης. Τρίτον, η συνεργασία και η επικοινωνία μεταξύ των μελών μιας ομάδας ανάπτυξης και ιδιαίτερα η συνεργασία με όλους τους πελάτες-χρήστες (ή με αντιπροσώπους τους, αν δεν είναι δυνατή η συνεργασία με όλους τους πελάτες-χρήστες) προτιμάται σε σύγκριση με αναλυτικά έγγραφα ανάλυσης

9 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 9 απαιτήσεων, λεπτομερή συμβόλαια εκπόνησης του έργου, αυστηρά χρονοδιαγράμματα και συμβάσεις (εκ των προτέρων) για όλα τα παραδοτέα του έργου. Η συνεργασία αυτή είναι πρέπει να είναι διαρκής και συστηματική, αφού ο πελάτης αλλάζει συχνά απόψεις και γνώμες σχετικά με τις απαιτήσεις του από το λογισμικό. Η ύπαρξη ενός συμβολαίου και γενικότερα η συγγραφή εγγράφων τεκμηρίωσης είναι σημαντική, ωστόσο δεν μπορεί να υποκαταστήσει την επικοινωνία και τη συνεργασία. Τέταρτον, οι συμμετέχοντες στο έργο πρέπει να είναι καλά ενημερωμένοι και προετοιμασμένοι ώστε εξετάζουν και να αντιμετωπίζουν νέες απαιτήσεις που θα εμφανιστούν κατά τη διάρκεια του έργου. Οι απαιτήσεις των πελατών, το επιχειρηματικό περιβάλλον ακόμα και η ίδια η τεχνολογία (τα εργαλεία που χρησιμοποιούνται για την ανάπτυξη λογισμικού π.χ. προγραμματιστικά περιβάλλοντα ή εργαλεία ελέγχου) μεταβάλλονται συνεχώς και αυτές οι αλλαγές δεν μπορεί να αφήνουν ανεπηρέαστες τις αποφάσεις της διαχείρισης του έργου. Η διαχείριση του έργου πρέπει να ικανοποιεί άμεσα κάθε ανάγκη για αλλαγές. Αυτό δεν σημαίνει ότι δεν είναι χρήσιμο ένα πλάνο προγραμματισμού των διαθέσιμων πόρων και του χρονικού προγραμματισμού των δραστηριοτήτων του έργου, ειδικότερα, αλλά κάθε πλάνο προγραμματισμού θα πρέπει να είναι περισσότερο ευέλικτο και εύκολα προσαρμόσιμο σε αλλαγές. Εκτός από τις παραπάνω τέσσερις βασικές θέσεις, η ομάδα των συγγραφέων του Agile Manifesto καθόρισε επιπλέον δώδεκα αρχές που καθοδηγούν τη διαδικασία της ανάπτυξης ενός λογισμικού ( Αυτές είναι οι ακόλουθες: 1. Βασική προτεραιότητα αποτελεί η ικανοποίηση του πελάτη με τη συνεχή παράδοση τμημάτων-εκδόσεων (releases) λογισμικού υψηλής αξίας (valuable software) από τα πρώτα κιόλας στάδια/φάσεις της ανάπτυξης. 2. Οι μεταβαλλόμενες απαιτήσεις είναι καλοδεχούμενες ακόμα και σε ένα προχωρημένο στάδιο της ανάπτυξης. Οι διαδικασίες, που εφαρμόζονται έχουν την

10 10 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού δυνατότητα να λάβουν υπόψη και να διαχειριστούν τις αλλαγές προς όφελος του πελάτη. 3. Το λογισμικό αναπτύσσεται αυξητικά. Η παράδοση τμημάτων-εκδόσεων του λογισμικού γίνεται σε τακτά και σύντομα χρονικά διαστήματα (π.χ. ανά δύο-τρεις εβδομάδες έως και ανά δύο-τρεις μήνες). Κρίσιμος παράγοντας για την επιτυχία του έργου ανάπτυξης είναι η συχνότερη παράδοση τμημάτων του λογισμικού σε όσο το δυνατό συντομότερα διαστήματα. 4. Οι πελάτες-χρήστες (ή εκπρόσωποι αυτών) και οι υπεύθυνοι-διαχειριστές του έργου της ανάπτυξης του συστήματος θα πρέπει να συνεργάζονται συνεχώς (και αν είναι δυνατόν καθημερινά) σε όλη της διάρκεια της υλοποίησης του συστήματος. 5. Σημαντική είναι η ανάθεση των τμημάτων του συστήματος σε προσωπικό-μέλη της ομάδας έργου που έχουν κίνητρα, ικανότητες και αποτελεσματικές δεξιότητες. Θα πρέπει να εξασφαλίζεται ένα ευχάριστο κλίμα συνεργασίας σε ένα εργασιακό περιβάλλον που χαρακτηρίζεται από εμπιστοσύνη και συνεχή υποστήριξη των μελών της ομάδας. 6. Ο καλύτερος και πιο αποδοτικός τρόπος επικοινωνίας, μεταβίβασης και ανταλλαγής απόψεων και πληροφοριών μεταξύ των μελών της ομάδας έργου είναι οι διαπροσωπικές (καθημερινές) συζητήσεις. 7. Η καλύτερη και πιο αξιόπιστη μετρική, που επιβεβαιώνει την πρόοδο ενός έργου, είναι η λειτουργικότητα του συστήματος δηλαδή το να λειτουργούν σωστά (χωρίς σφάλματα) και σύμφωνα με τις αρχικές απαιτήσεις οι εκδόσεις λογισμικού οι οποίες και παραδίδονται στους χρήστες-πελάτες. 8. Οι ευέλικτες διαδικασίες υποστηρίζουν ένα συνεχές (αδιάλειπτο) ρυθμό ανάπτυξης, ο οποίος πρέπει να ακολουθείται από τους πελάτες-χρήστες, τον υπεύθυνο για τη διαχείριση του έργου και από τα μέλη της ομάδας έργου σε όλη τη διάρκεια της ανάπτυξης του συστήματος.

11 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Η ευελιξία ενισχύεται από την συνεχή προσπάθεια για τεχνική αρτιότητα, καλό σχεδιασμό και αποφυγή λαθών στο υπό ανάπτυξη λογισμικό. 10. Κάθε απλοποίηση (simplicity), με την έννοια της υλοποίησης των απαιτήσεων των χρηστών άμεσα και με αποτελεσματικό τρόπο, είναι σημαντική. 11. Οι καλύτερες απαιτήσεις, σχέδια αρχιτεκτονικής και σχέδια του συστήματος προκύπτουν από ομάδες ανάπτυξης που αυτο-οργανώνονται και αυτοδιαχειρίζονται (self-organizing teams). 12. Σε τακτά χρονικά διαστήματα, τα μέλη της ομάδας ανάπτυξης συζητούν αναζητώντας τρόπους ώστε ως ομάδα να γίνουν περισσότερο αποτελεσματικοί και επαναπροσδιορίζουν πρακτικές και συμπεριφορές που οδηγούν σε λάθη, χρονικές καθυστερήσεις και σε αύξηση κόστους της ανάπτυξης. Η τήρηση των προαναφερόμενων βασικών αυτών αρχών σε ένα έργο ανάπτυξης λογισμικού μειώνει την πιθανότητα να εμφανιστούν κίνδυνοι και αποτυχίες κατά τη διαδικασία ανάπτυξης του λογισμικού. Οι ευέλικτες διαδικασίες δείχνουν μια σαφή προτίμηση στην πρόσωπο με πρόσωπο επικοινωνία για τον περιορισμό των παραγομένων εγγράφων τεκμηρίωσης (στα απολύτως απαραίτητα έγγραφα). Βρισκόμενοι σε στενή και συνεχή συνεργασία με τον πελάτη-χρήστη, τα μέλη της ομάδας ανάπτυξης και ο διαχειριστής του έργου επικεντρώνονται στην ανάπτυξη λογισμικού που λειτουργεί (working software), που θεωρείται το πρωταρχικό μέτρο της προόδου του έργου. Σύμφωνα με τους [Highsmith and Cockburn, 2001] «η καινοτομία των ευέλικτων διαδικασιών δεν έγκειται κυρίως στις πρακτικές που χρησιμοποιούν, αλλά περισσότερο στο γεγονός ότι αναγνωρίζουν ότι τα μέλη της ομάδας έργου είναι οι κύριοι συντελεστές της επιτυχίας του έργου, σε συνδυασμό με την έμφαση που δίνουν στην αποτελεσματικότητα και την ευελιξία των ενεργειών τους». Μια ευέλικτη διαδικασία είναι κατά βάση ένα σύνολο από προσαρμόσιμες (adaptive) πρακτικές που «επιζητούν» τις αλλαγές στις απαιτήσεις των πελατών-

12 12 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού χρηστών που τις διαχειρίζονται κατάλληλα. Και αυτό σε αντίθεση με «αυστηρές» διαδικασίες, με αντιπροσωπευτικότερη αυτή της Δομημένης Ανάλυσης και Σχεδίασης, που παραδοσιακά υιοθετούν τον ακολουθιακό κύκλο ζωής του μοντέλου του καταρράκτη (waterfall process life cycle) [Royce, 1970] κατά το οποίο οι αλλαγές στις απαιτήσεις είναι κατά βάση «ανεπιθύμητες» καθώς επιφέρουν περισσότερη απαιτούμενη προσπάθεια, αύξηση του κόστους της ανάπτυξης και χρονικές καθυστερήσεις. Συνοψίζοντας, οι ευέλικτες διαδικασίες υιοθετούν μια ευρεία συλλογή από καλές και δοκιμασμένες στην πράξη θέσεις-αρχές που βοηθούν στην ανάπτυξη ποιοτικού λογισμικού. Η ανάπτυξη του λογισμικού γίνεται σε σύντομους επαναληπτικούς (iterative) και αυξητικούς (incremental) κύκλους, παρέχοντας τη δυνατότητα προσαρμογής και απόκρισης στις αλλαγές των απαιτήσεων που προέρχονται από τους πελάτες-χρήστες μέσα σε ένα διαρκώς μεταβαλλόμενο επιχειρησιακό περιβάλλον. 3. Χαρακτηριστικά των Ευέλικτων Διαδικασιών Μια διαδικασία μπορεί να θεωρηθεί ως ευέλικτη όταν είναι αυξητική (παραδίδονται μικρά τμήματα του λογισμικού, σε τακτά χρονικά διαστήματα), συνεργατική (υπάρχει συνεχής επικοινωνία μεταξύ της ομάδας ανάπτυξης και των πελατών), απλή (είναι εύκολη, κατανοητή και τροποποιήσιμη) και προσαρμοστική (μπορεί εύκολα να προσαρμόζεται σε απρόβλεπτες αλλαγές). Τα ακόλουθα χαρακτηριστικά θεωρούνται ως οι κύριες διαφορές μεταξύ ευέλικτων και παραδοσιακών (αυστηρών) διαδικασιών [Miller, 2001]. Προσανατολισμός στον άνθρωπο: Οι ευέλικτες διαδικασίες θεωρούν τους τους συμμετέχοντες στο έργο (πελάτες, χρήστες, προγραμματιστές, διαχειριστές του έργου), τις ικανότητες και τη συνεργασία μεταξύ τους, ως τους σημαντικότερους παράγοντες για την επιτυχία ενός έργου ανάπτυξης λογισμικού. Προσαρμοστικότητα: «Επειδή οι εξωτερικές αλλαγές σε κάθε έργο λογισμικού δεν μπορούν να περιοριστούν, κάθε προσπάθεια ώστε να αντιμετωπιστούν αυτές οι αλλαγές με το λιγότερο δυνατό κόστος, είναι η μόνη βιώσιμη στρατηγική»

13 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 13 [Highsmith, 2000]. Οι συμμετέχοντες σε μια ευέλικτη διαδικασία δεν φοβούνται τις αλλαγές αλλά τις «καλωσορίζουν» σε όλα τα στάδια του έργου. Αντιμετωπίζουν τις αλλαγές στις απαιτήσεις θετικά, γιατί αυτό σημαίνει ότι η ομάδα ανάπτυξης έχει κατανοήσει καλύτερα τις ανάγκες του πελάτη και συνεπώς γνωρίζει πώς να τις ικανοποιήσει και να καταλήξει σε ένα ολοκληρωμένο προϊόν. Στις ευέλικτες διαδικασίες, σκοπός δεν είναι να περιοριστούν οι αλλαγές στις απαιτήσεις, αλλά η εύρεση τρόπων που θα επιτρέψει τον καλύτερο δυνατό χειρισμό τους. Έμφαση σε πρακτικές αποφάσεις: Οι ευέλικτες διαδικασίες δίνουν έμφαση στις ιδιαίτερες απαιτήσεις κάθε φάσης της ανάπτυξης και όχι στην τήρηση ενός καλά ορισμένου πλάνου. Κάθε επανάληψη προσθέτει αξία (value) στο διαρκώς αναπτυσσόμενο και εξελισσόμενο σύστημα λογισμικού. Ωστόσο η τελική κρίση για το αν τελικά στο σύστημα έχει προστεθεί ή όχι μια αξία δεν θα ληφθεί από τους προγραμματιστές-μέλη της ομάδας ανάπτυξης, αλλά από τους χρήστες-πελάτες. Εξισορρόπηση μεταξύ ευελιξίας και προγραμματισμού: Ο χρονικός προγραμματισμός είναι σημαντικός, αλλά πολλές φορές το συνολικό χρονοπρόγραμμα ενός έργου ανάπτυξης λογισμικού δεν μπορεί να προβλεφθεί με ακρίβεια από την αρχή του έργου. Μια πιο αποτελεσματική επιλογή είναι να σχεδιάζονται λεπτομερή χρονοδιαγράμματα για το άμεσο μέλλον (π. χ για τις εργασίες που θα λάβουν χώρα στις επόμενες εβδομάδες του έργου), λιγότερο λεπτομερή χρονοδιαγράμματα για τους επόμενους μήνες κλπ. Η ευελιξία στην αλλαγή των αποφάσεων και τον προγραμματισμό είναι σημαντική για ένα έργο ανάπτυξης λογισμικού. Κάθε απόφαση για ένα μελλοντικό πλάνο του έργου πρέπει να ληφθεί με τρόπο ώστε να εξασφαλιστεί το ενδεχόμενο μελλοντικής αλλαγής του πλάνου χωρίς ιδιαίτερες δυσκολίες. Εμπειρική διαδικασία: Οι ευέλικτες διαδικασίες ανάπτυξης λογισμικού είναι κατά βάση εμπειρικές διαδικασίες (empirical processes). Η ανάπτυξη λογισμικού δεν μπορεί να θεωρηθεί ως μια αυστηρά, εκ των προτέρων καθορισμένη ακολουθία βημάτων γιατί αλλαγές συμβαίνουν κατά τη διάρκεια της ανάπτυξης. Είναι εξαιρετικά απίθανο οποιοδήποτε αρχικό σύνολο προκαθορισμένων βημάτων να οδηγήσει σε ένα επιθυμητό, προβλέψιμο αποτέλεσμα, επειδή οι απαιτήσεις αλλάζουν, παρουσιάζονται αλλαγές στην χρησιμοποιούμενη τεχνολογία, μέλη

14 14 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού προστίθενται και αφαιρούνται από την ομάδα ανάπτυξης του έργου κλπ. [Williams and Cockburn, 2003]. Κατανεμημένη και αποκεντρωμένη προσέγγιση: Η ανάθεση αρμοδιοτήτων σε όλα τα μέλη της ομάδας έργου οδηγεί σε καλύτερα αποτελέσματα συγκριτικά με συγκεντρωτικές προσεγγίσεις (centralized decision making) κατά τις οποίες η λήψη αποφάσεων περιορίζεται σε ένα μόνο πρόσωπο (στο πρόσωπο του διαχειριστή του έργου-project manager). Η ευέλικτη ανάπτυξη λογισμικού ενθαρρύνει την αποκεντρωμένη λήψη αποφάσεων (de-centralized decision making) π.χ. από τους προγραμματιστές, χωρίς αυτό να σημαίνει ότι οι προγραμματιστές θα αναλάβουν και το ρόλο της διοίκησης-διαχείρισης του έργου. Η διοίκηση-διαχείριση του έργου είναι πάντοτε αναγκαία για την αντιμετώπιση προβλημάτων που παρουσιάζονται κατά την ανάπτυξη του λογισμικού αλλά θα πρέπει να αναγνωρίζει τις ικανότητες των μελών της ομάδας έργου να λαμβάνουν από μόνοι τους αποφάσεις και πρωτοβουλίες. Απλότητα: Μια ομάδα ανάπτυξης λογισμικού, για να είναι ευέλικτη, θα πρέπει να λαμβάνει εκείνες τις αποφάσεις που οδηγούν τελικά στην ανάπτυξη ενός απλού συστήματος (και όχι πολύπλοκου και δύσκολου στη συντήρηση συστήματος). Η απλότητα (simplicity) στο τελικό σύστημα είναι αναγκαία ώστε να είναι εύκολο να αλλάξει το σύστημα ενσωματώνοντας αλλαγές στις απαιτήσεις. Ποτέ δεν παράγεται κάτι περισσότερο από ό,τι είναι απαραίτητο και το τι είναι απαραίτητο συνήθως καθορίζεται αποκλειστικά από τους χρήστες-πελάτες. Συνεργασία: Η συνεχής συνεργασία μεταξύ συμμετεχόντων - μελών της ομάδας έργου είναι απαραίτητη με σκοπό την κατανόηση των προβλημάτων που ανακύπτουν και την κατανόηση των απαιτήσεων των χρηστών-πελατών. Οι ευέλικτες ομάδες δεν μπορούν να λειτουργήσουν μόνο με περιστασιακές συναντήσεις και κατά περίπτωση επικοινωνία. Απαιτείται η συμμετοχή όλων των μελών της ομάδας έργου και στις διαδικασίες της επιχείρησης-οργανισμού για τον οποίο προορίζεται το σύστημα λογισμικού. Επίσης, οι πελάτες-χρήστες πρέπει να συνεργάζονται στενά με την ομάδα ανάπτυξης, παρέχοντας συχνή ανατροφοδότηση και τις απόψεις τους για το υπό ανάπτυξη σύστημα.

15 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 15 Μικρές ομάδες έργου που αυτο-οργανώνονται: Οι ευέλικτες διαδικασίες της ανάπτυξης λογισμικού εφαρμόζονται καλύτερα με μικρές (σε πλήθος) ομάδες έργου οι οποίες οργανώνονται από μόνες τους (self-organizing teams). Είναι συνηθισμένη η πρακτική να κοινοποιούνται από το διαχειριστή του έργου οι ευθύνεςαρμοδιότητες στην ομάδα ως σύνολο, και έπειτα τα μέλη της ομάδας να συζητούν και να συμφωνούν μεταξύ τους για το πως θα καθοριστεί η ανάθεση των ευθυνώναρμοδιοτήτων στα διαφορετικά μέλη της ομάδας. Στη συνέχεια των σημειώσεων παρουσιάζονται περιληπτικά τις ακόλουθες τρεις διαδεδομένες ευέλικτες διαδικασίες που πληρούν τις προαναφερόμενες αρχές και ενσωματώνουν τα παραπάνω χαρακτηριστικά: Ακραίος Προγραμματισμός (Extreme Programming) Διαδικασία Ανάπτυξης προσανατολισμένη στα Χαρακτηριστικά του Λογισμικού (Feature Driven Development) Διαδικασία Ανάπτυξης Δυναμικών Συστημάτων (Dynamic Systems Development) Μετά την συνοπτική παρουσίαση των τριών αυτών διαδικασιών, θα περιγραφούν με περισσότερη λεπτομέρεια και πιο αναλυτικά πιο σύγχρονες διαδικασίες. Συγκεκριμένα, θα παρουσιαστούν οι διαδικασίες Scrum και Kanban, δύο ιδιαίτερα δημοφιλείς 2 ευέλικτες/επαναληπτικές διαδικασίες που τυγχάνουν μεγάλης αποδοχής διεθνώς κυρίως από μικρομεσαίες εταιρείες ανάπτυξης λογισμικού. 4. Ακραίος Προγραμματισμός (Extreme Programming) 2 Πρόσφατες σχετικά έρευνες ([Version One, 2009] [Behrens, 2006]) κατατάσσουν τη Scrum και τις παραλλαγές της (π.χ. Kanban) στις πιο διαδεδομένες ευέλικτες διαδικασίες της ανάπτυξης λογισμικού.

16 16 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Ο Ακραίος Προγραμματισμός (Extreme Programming - XP) αποτελεί μία από τις πρώτες διαδικασίες που χαρακτηρίστηκε ως ευέλικτη αφού προσπαθεί να βελτιώσει την ποιότητα του λογισμικού και επιτρέπει τις συχνές αλλαγές στις απαιτήσεις των χρηστών. Προτάθηκε αρχικά από τον Kent Βeck [Beck, 1999]. Τα βήματα και οι πρακτικές του XP περιγράφονται αναλυτικά στο βιβλίο Extreme Programming Explained [Beck and Anders, 2004]. Η διαδικασία XP χαρακτηρίζεται από σύντομους κύκλους ανάπτυξης, δημιουργία αυξητικών εκδόσεων, συνεχή ανατροφοδότηση (feedback), συνεχή επικοινωνία και «επαναστατικό» σχεδιασμό [Beck and Anders, 2004]. Οι όροι «ακραίος» και «επαναστατικός» προέρχονται από τη θεώρηση των αρχών των ευέλικτων διαδικασιών σε «ακραία» επίπεδα. Συγκεκριμένα, η διαδικασία XP βασίζεται στην πεποίθηση ότι τα πλεονεκτήματα των αρχών μιας ευέλικτης διαδικασίας (π.χ. η συμμετοχή του χρήστη-πελάτη στην ανάπτυξη), πρέπει να εφαρμόζονται στο μέγιστο δυνατό βαθμό, θεωρώντας ότι «αν κάτι είναι καλό, τότε η μέγιστη αξιοποίησή του θα επιφέρει ακόμη καλύτερα αποτελέσματα» [Beck, 1999]. Ο κύκλος ζωής του XP περιλαμβάνει έξι φάσεις όπως αυτές παρουσιάζονται στο Σχήμα 3 [Beck and Anders, 2005] οι οποίες και αναλύονται ακολούθως: 1. Διερεύνηση (Exploration) 2. Προγραμματισμός (Planning) 3. Επαναλήψεις (Iterations to release phase) 4. Δημιουργία «Προϊόντος» - Παραγωγή (Productionizing) 5. Συντήρηση (Maintenance) 6. Απόσυρση (Death)

17 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 17 Σχήμα 3: Κύκλος ζωής της διαδικασίας του Ακραίου Προγραμματισμού [Beck, (Προσαρμογή εικόνας από [Beck and Anders, 2005]) Στη φάση της διερεύνησης (διαρκεί από λίγες βδομάδες έως λίγους μήνες) πραγματοποιείται η αρχική καταγραφή των χαρακτηριστικών και των λειτουργιών που θα περιλαμβάνει το σύστημα. Οι πελάτες-χρήστες καλούνται να καταγράψουν σε ειδικές κάρτες (τις λεγόμενες «κάρτες ιστορίας» (story cards)) τις «ιστορίες χρηστών» (user stories) δηλ. τα χαρακτηριστικά γνωρίσματα και τις επιθυμητές λειτουργίες που θέλουν να προστεθούν-ενσωματωθούν στο σύστημα (Σχήμα 4). Η ομάδα ανάπτυξης εξοικειώνεται με τα αναγκαία εργαλεία, επιλέγει τις κατάλληλες πρακτικές και καθορίζει τις τεχνολογικές λύσεις που θα χρησιμοποιηθούν στο έργο. Μετά τον καθορισμό των τεχνολογιών που θα χρησιμοποιηθούν αναπτύσσεται ένα πρωτότυπο του συστήματος.

18 18 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Σχήμα 4: Παράδειγμα «κάρτας ιστορίας» χρήστη (user story card) (Προέλευση εικόνας: Στη φάση του προγραμματισμού (διαρκεί μερικές μέρες) ιεραρχούνται οι ιστορίες χρηστών (λαμβάνουν προτεραιότητα αναφορικά με τη σειρά υλοποίησής τους) και συμφωνείται μαζί με τους πελάτες-χρήστες τι θα παρέχει η πρώτη έκδοση (release) του συστήματος. Η ομάδα ανάπτυξης αξιολογεί τις ιστορίες, εκτιμάται η προσπάθεια και η εργασία που απαιτείται για να υλοποιηθεί κάθε ιστορία και στη συνέχεια συμφωνείται με τον πελάτη ένα πρώτο χρονοδιάγραμμα (πλάνο) εργασίας που καταλήγει στην πρώτη έκδοση του συστήματος. Στη φάση των επαναλήψεων γίνεται παράδοση της πρώτης έκδοσης του συστήματος μετά από ένα σύνολο επαναληπτικών δραστηριοτήτων. Κάθε επανάληψη προσθέτει νέες λειτουργίες στο σύστημα. Συνεπώς, το αρχικό χρονοδιάγραμμα που αποφασίστηκε στην προηγούμενη φάση «αποσυντίθεται» σε διαφορετικές επαναλήψεις, κάθε μια από τις οποίες διαρκεί από μια έως τέσσερις εβδομάδες. Η πρώτη επανάληψη συνήθως καταλήγει στον καθορισμό της αρχιτεκτονικής του συστήματος και στη συνέχεια ακολουθεί η αναβάθμιση του

19 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 19 συστήματος με την ενσωμάτωση των ιστοριών. Στο τέλος κάθε επανάληψης δοκιμάζεται-ελέγχεται το σύστημα σε συνεργασία με τον πελάτη-χρήστη. Να σημειωθεί ότι κάθε περίπτωση ελέγχου που πραγματοποιείται έχει ήδη καθοριστεί από τον πελάτη-χρήστη στην αντίστοιχη κάρτα «ιστορίας χρήστη». Κάθε επανάληψη ολοκληρώνεται με την παραγωγή μιας αντίστοιχης λειτουργικής έκδοσης του συστήματος. Στη φάση της δημιουργίας προϊόντος (παραγωγής) διεξάγονται περισσότεροι έλεγχοι και δοκιμές ώστε να εξασφαλιστεί ότι το σύστημα είναι κατάλληλο να παραδοθεί στον πελάτη. Κατά τη διάρκεια της φάσης αυτής μπορεί να εντοπιστούν αλλαγές και ανάγκες για λειτουργικές βελτιώσεις-επεκτάσεις για τις οποίες πρέπει να αποφασιστεί (σε συνεργασία με τον πελάτη-χρήστη) αν θα ενσωματωθούν στην παρούσα έκδοση του συστήματος (και τότε πρέπει η διαδικασία να επιστρέψει στη φάση των επαναλήψεων) ή θα πρέπει να ενσωματωθούν σε μια επόμενη έκδοση του συστήματος. Στη φάση της συντήρησης πραγματοποιούνται διορθώσεις σφαλμάτων και καταγράφονται καινούριες ιδέες και προτάσεις για την υλοποίηση νέων εκδόσεων του συστήματος. Όταν αποφασιστεί μια νέα έκδοση του συστήματος τότε η φάση της συντήρησης θα συμπεριλάβει ξανά τις προηγούμενες τέσσερις φάσεις. Στη φάση της απόσυρσης του συστήματος ο πελάτης-χρήστης δεν έχει άλλες ιστορίες προς υλοποίηση. Αυτό συνεπάγεται πως το σύστημα ικανοποιεί όλες τις απαιτήσεις του πελάτη-χρήστη και συνεπώς θα πρέπει να καταγραφεί η απαραίτητη τεκμηρίωση (documentation) του συστήματος. Σε αυτή την περίπτωση δεν είναι αποδεκτές αλλαγές στην αρχιτεκτονική, στο σχεδιασμό ή στον κώδικα του συστήματος. Είναι ωστόσο δυνατό η απόφαση για την απόσυρση του συστήματος να ληφθεί πριν να ολοκληρωθεί το σύστημα, εάν παρατηρηθεί και συμφωνηθεί ότι (για οποιοδήποτε λόγο) δεν είναι εφικτό να υλοποιηθούν οι ιστορίες των χρηστών. Κατά την υλοποίηση των φάσεων εφαρμόζεται ένα σύνολο βασικών πρακτικών (XP practices), οι σημαντικότερες από τις οποίες είναι οι ακόλουθες [Beck, 1999]:

20 20 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού «Παιχνίδι» Προγραμματισμού (Planning Game): Οι προγραμματιστές εκτιμούν την προσπάθεια που απαιτείται για την υλοποίηση των ιστοριών των χρηστών και σε συνεργασία με τους πελάτες-χρήστες αποφασίζεται το πλάνο (χρονοδιάγραμμα) υλοποίησης των ιστοριών (δηλαδή συμφωνείται ποιες ιστορίες χρηστών θα υλοποιηθούν σε κάθε επανάληψη ή/και σε κάθε έκδοση του συστήματος). Μικρές εκδόσεις (Small releases): Το σύστημα αναπτύσσεται σε μια σειρά μικρών, επαυξητικών εκδόσεων που παράγονται το δυνατό γρηγορότερα. Οι εκδόσεις μπορεί να αναπτύσσονται ανά λίγες ημέρες, ανά εβδομάδα μέχρι και ανά μήνα/δύο μήνες. Περιγραφή του συστήματος με μεταφορές (Metaphors): Μια μεταφορά αποτελεί ένα συμβολισμό παρομοίωση για ένα τμήμα του συστήματος ή για μια λειτουργία του συστήματος. Το σύστημα χαρακτηρίζεται από ένα σύνολο μεταφορών που αποφασίζονται μεταξύ πελατών και προγραμματιστών. Με τον τρόπο αυτό είναι ευκολότερη η επικοινωνία μεταξύ τους αλλά και η κατανόηση για το πώς λειτουργεί το σύστημα. Απλή σχεδίαση (Simple design): Δίνεται έμφαση στον σχεδιασμό απλών λύσεων οι οποίες και υλοποιούνται με την ελάχιστη δυνατή πολυπλοκότητα. Περιττά τμήματα κώδικα πρέπει να αφαιρούνται. Ο σχεδιασμός πρέπει να είναι απλός ώστε να επιδέχεται αλλαγές και να ενσωματώνει εύκολα νέες λειτουργίες. Αναδιάρθρωση-επανακατασκευή του κώδικα του συστήματος (Code refactoring): Κάθε αλλαγή σε ένα τμήμα κώδικα μπορεί αναπόφευκτα να επιφέρει αλλαγές σε άλλα τμήματα του κώδικα. Το γεγονός αυτό αντιμετωπίζεται με τη συνεχή αναδιάρθρωση του κώδικα δηλαδή τη βελτίωση του κώδικα προκειμένου να αφαιρεθούν περιττές επαναλήψεις, να εξαλειφθούν ισχυρές εξαρτήσεις μεταξύ κλάσεων αντικειμένων, να μειωθεί η πολυπλοκότητα και να απλουστευθεί η σχεδίαση του κώδικα. Προγραμματισμός σε ζεύγη (Pair programming): Ο κώδικας συγγράφεται από δύο προγραμματιστές οι οποίοι δουλεύουν μαζί και ταυτόχρονα σε ένα υπολογιστή. Ο ένας εκ των δύο συγγράφει τον κώδικα καθώς ο δεύτερος

21 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 21 αναθεωρεί-αναδιαρθρώνει-ελέγχει άμεσα τον κώδικα. Ο προγραμματιστής που συγγράφει τον κώδικα έχει τον ρόλο του «οδηγού» ενώ αυτός που ελέγχει τον κώδικα ονομάζεται «παρατηρητής» ή «πλοηγός». Οι ρόλοι μεταξύ των δύο προγραμματιστών συχνά πρέπει να αλλάζουν. Συλλογική ιδιοκτησία (Collective ownership): Δεν υπάρχει ένα μοναδικό πρόσωπο που να είναι απολύτως αρμόδιο και υπεύθυνο για οποιοδήποτε τμήμα του κώδικα. Κάθε προγραμματιστής μπορεί να αλλάξει οποιοδήποτε τμήμα του κώδικα, ανά πάσα στιγμή. Ένα σημαντικό πλεονέκτημα αυτής της πρακτικής είναι το ότι επιταχύνεται η όλη διαδικασία της ανάπτυξης γιατί εάν ένας προγραμματιστής εντοπίσει ένα λάθος ή ασάφεια σε κώδικα που συνέγραψε κάποιος συνάδελφός του τότε μπορεί άμεσα να προχωρήσει σ τη διόρθωση-αλλαγή του συγκεκριμένου κώδικα. Συνεχής ολοκλήρωση (Continuous integration): Κάθε αλλαγή που γίνεται στον κώδικα πρέπει να ενσωματώνεται στην παρούσα έκδοση του συστήματος το συντομότερο δυνατό. Όταν πραγματοποιηθεί μια οποιαδήποτε αναβάθμιση-βελτίωση του συστήματος (π. χ. με την προσθήκη μιας νέας λειτουργίας) τότε το σύστημα θα πρέπει ξανά να «περάσει» τη διαδικασία ελέγχου και τότε οι αλλαγές γίνονται (ή όχι) αποδεκτές. Ο στόχος είναι όλες οι περιπτώσεις ελέγχου (test-cases) να εξετάζονται και να είναι απολύτως επιτυχείς. Το πλεονέκτημα της πρακτικής είναι ότι το σύστημα είναι λειτουργικό και διαθέσιμο σε οποιαδήποτε φάση της ανάπτυξης του έργου. 40 ώρες την εβδομάδα (40 hours week): Ο μέγιστος χρόνος εργασίας είναι 40 ώρες την εβδομάδα και πρέπει να αποφεύγονται υπερωρίες. Ο στόχος είναι να δημιουργείται ένα ευχάριστο, δημιουργικό και αποδοτικό περιβάλλον εργασίας. Επίσης στόχος είναι να ελέγχεται αν η ομάδα έργου εργάζεται χωρίς καθυστερήσεις και το σύστημα αναπτύσσεται χωρίς προβλήματα (π.χ. λάθη, παραλείψεις). Αν παρατηρείται υπέρβαση των 40 ωρών εργασίας/εβδομάδα τότε το γεγονός αυτό θα πρέπει να εξεταστεί γιατί μπορεί να δημιουργήσει προβλήματα στο έργο. Εμπλοκή του πελάτη (On-site customer): Ο πελάτης-χρήστης έχει

22 22 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού σημαντικό ρόλο στην ανάπτυξη του λογισμικού. Δεν αντιμετωπίζεται σαν αυτός που θα δώσει τα χρήματα για να αγοράσει το λογισμικό αλλά σαν αυτός που θα χρησιμοποιήσει το τελικό προϊόν. Ο πελάτης πρέπει να είναι διαθέσιμος ανά πάσα στιγμή και πρέπει να συνεργάζεται στενά με την ομάδα ανάπτυξης. Ο πελάτης-χρήστης πρέπει να είναι έτοιμος και διαθέσιμος ώστε να απαντήσει σε κάθε απορία οποιουδήποτε μέλους της ομάδας ανάπτυξης. Ο στόχος είναι να αναπτυχθεί ένα σύστημα που καλύπτει τις απαιτήσεις των πελατών και το οποίο δεν θα βασίζεται σε παραδοχές-αποφάσεις-επιλογές-προτιμήσεις της ομάδας ανάπτυξης. Πρότυπα κωδικοποίησης (Coding standards): Υιοθετούνται κανόνες για την κωδικοποίηση (δηλ. για τη συγγραφή του κώδικα) και ακολουθούνται από τους προγραμματιστές έτσι ώστε να υπάρχει συνέπεια, επαρκή επικοινωνία και αλληλοκατανόηση μεταξύ των μελών της ομάδας ανάπτυξης. Τα πρότυπα καθορίζονται συναινετικά από κοινού από όλα τα μέλη της ομάδας έργου. 5. Ανάπτυξη προσανατολισμένη στα Χαρακτηριστικά του Λογισμικού (Feature Driven Development) Η Ανάπτυξη με Βάση Χαρακτηριστικά (Feature Driven Development - FDD) είναι μια ευέλικτη διαδικασία που περιγράφεται αναλυτικά στο βιβλίο [Palmer and Felsing, 2002]. Η διαδικασία FDD περιλαμβάνει πέντε φάσεις (Σχήμα 5). Οι τρεις πρώτες φάσεις εκτελούνται στην αρχή του έργου ενώ οι δύο τελευταίες φάσεις αποτελούν το στάδιο της διαδικασίας που εκτελείται επαναληπτικά. Στο στάδιο αυτό λαμβάνονται υπόψη οι αρχές της ευέλικτης ανάπτυξης καθώς δίνεται έμφαση στη γρήγορη προσαρμογή και απόκριση σε τυχόν μεταβολές που δημιουργούνται στις απαιτήσεις. Η διαδικασία FDD οδηγεί σε συχνές παραδόσεις-εκδόσεις του λογισμικού, δεν δίνει έμφαση σε αναλυτική τεκμηρίωση της ποιότητας των παραδοτέων αλλά εστιάζει στη λεπτομερή παρακολούθηση της προόδου του έργου. Σε σύγκριση με άλλες ευέλικτες διαδικασίες (όπως η διαδικασία XP που παρουσιάστηκε προηγουμένως), η διαδικασία FDD δεν εφαρμόζεται σε όλο τον

23 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 23 κύκλο της ζωής λογισμικού αλλά επικεντρώνεται στη φάση του σχεδιασμού και της υλοποίησης [Palmer and Felsing, 2002]. Σχήμα 5: Διαδικασία ανάπτυξης με βάση τα χαρακτηριστικά (Προέλευση εικόνας: [Palmer and Felsing, 2002]) Ακολούθως παρουσιάζονται συνοπτικά οι φάσεις της διαδικασίας FDD (Σχήμα 5): Ανάπτυξη ενός γενικού προτύπου (Develop an Overall Model): Με την έναρξη τα φάσης αυτής γίνεται μια πρώτη γνωριμία με το πεδίο, το πλαίσιο εφαρμογής και τις απαιτήσεις του συστήματος. Ενδέχεται 3 να προδιαγραφούν αναλυτικά απαιτήσεις στη μορφή περιπτώσεων χρήσης (use cases) και λειτουργικές προδιαγραφές (functional specifications). Σχεδιάζεται ένα λεπτομερές «πέρασμα» (αναπαράσταση-walkthrough) του συστήματος το οποίο είναι συνήθως ένα διάγραμμα κλάσεων (class diagram) που χρησιμοποιείται από τον υπεύθυνο για την αρχιτεκτονική 3 H διαδικασία FDD δεν προσδιορίζει με λεπτομέρεια τον τρόπο εκμαίευσης-συλλογής των απαιτήσεων, τον τρόπο προδιαγραφής των απαιτήσεων και γενικότερα τον τρόπο διαχείρισης των απαιτήσεων. Σε αντίθεση είδαμε ότι η διαδικασία XP καθορίζει κάθε απαίτηση να προδιαγράφεται με ένα user story.

24 24 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού σχεδίαση του συστήματος (software architect) σε συνεργασία με όλα τα μέλη της ομάδας έργου ως βάση για να συζητήσουν και να κατανοήσουν αναλυτικά τις λειτουργίες του συστήματος. Το σύστημα διαιρείται περαιτέρω σε υποσυστήματα και για καθένα υποσύστημα σχεδιάζεται ένα ξεχωριστό walkthrough. Κάθε επιμέρους walkthrough αποτελεί ένα οδηγό για τις υπευθυνότητες καθεμιάς υπο-ομάδας του έργου. Δημιουργία μια λίστας χαρακτηριστικών (Build a Features List): Παράγεται μια κατηγοριοποιημένη λίστα με τα χαρακτηριστικά που πρέπει να ενσωματωθούν στο υπό ανάπτυξη σύστημα. Τα χαρακτηριστικά του συστήματος ιεραρχούνται σε συνεργασία με τον πελάτη-χρήστη ως προς την αξία-σημασία-προτεραιότητά τους. Η λίστα χαρακτηριστικών αναλύεται περαιτέρω σε σύνολα χαρακτηριστικών που ελέγχονται σε συνεργασία με τον πελάτη-χρήστη. Προγραμματισμός οδηγούμενος από τα χαρακτηριστικά (Plan by Feature): Η ομάδα ανάπτυξης συνεργατικά ταξινομεί τα χαρακτηριστικά του συστήματος ανάλογα με τις προτεραιότητες και τις μεταξύ τους εξαρτήσεις και αυτά ανατίθενται σε επικεφαλής προγραμματιστές (chief programmers). Επιπλέον, οι κλάσεις αντικειμένων που προσδιορίστηκαν στην πρώτη φάση της διαδικασίας ανατίθενται σε συγκεκριμένους προγραμματιστές (τους ιδιοκτήτες κλάσεων - class owners). Επίσης, προσδιορίζεται ένα γενικό χρονοδιάγραμμα και καθορίζονται τα ορόσημα (milestones) του έργου. Τα ορόσημα συνδέονται με τα χαρακτηριστικά του συστήματος. Σχεδιασμός και Κατασκευή του συστήματος οδηγούμενος από τα χαρακτηριστικά (Design & Build by Feauture): Στο στάδιο αυτό επιλέγονται συγκεκριμένα χαρακτηριστικά (ένα υποσύνολο χαρακτηριστικών) προς υλοποίηση. Η υλοποίηση των χαρακτηριστικών γίνεται με επαναληπτικές δραστηριότητες (σχεδίαση, κωδικοποίηση, έλεγχος, ολοκλήρωση) αποτέλεσμα των οποίων είναι η υλοποίηση του συνόλου των χαρακτηριστικών που επιλέγονται κάθε φορά. Μια ομάδα ανάπτυξης αναλαμβάνει να αναπτύξει σε κάθε επανάληψη ένα συγκεκριμένο υποσύνολο χαρακτηριστικών. Μπορεί να υπάρχουν πολλές ομάδες που εργάζονται ταυτόχρονα για την υλοποίηση διαφορετικών χαρακτηριστικών.

25 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 25 Μια επανάληψη διαρκεί από ορισμένες μέρες μέχρι το μέγιστο δύο εβδομάδες. Όταν ολοκληρωθεί μια επανάληψη τότε το σύστημα αναβαθμίζεται με τις νέες λειτουργίες και έτσι προκύπτει μια νέα έκδοση (release) του συστήματος. 6. Ανάπτυξη Δυναμικών Συστημάτων (Dynamic Systems Development) Η διαδικασία ανάπτυξης δυναμικών συστημάτων (Dynamic Systems Development - DSD), εμφανίστηκε για πρώτη φορά στο Ηνωμένο Βασίλειο στiς αρχές της δεκαετίας του Η διαδικασία βασίζεται και ταυτόχρονα επεκτείνει προσεγγίσεις γρήγορης ανάπτυξης πρωτοτύπων (rapid prototyping) και πρακτικές επαναληπτικής ανάπτυξης (iterative development) [Stapleton, 1997]. Βασικός στόχος στη διαδικασία DSD είναι να καθοριστεί αρχικά ο διαθέσιμος χρόνος και οι πόροι του έργου, και στη συνέχεια να προσαρμοστεί και να αποφασιστεί το «ποσοστό» των λειτουργιών του συστήματος που θα υλοποιηθεί (με βάση το διαθέσιμο χρόνο, προϋπολογισμό και ανθρώπινο δυναμικό). Η προσέγγιση αυτή διαφοροποιεί τη διαδικασία DSD σε σχέση με τη διαδικασία FDD και τη διαδικασία XP στις οποίες είδαμε ότι ορίζονται πάντοτε αρχικά τα χαρακτηριστικά (λειτουργικές απαιτήσεις) του συστήματος και στη συνέχεια το πλάνο της ανάπτυξης του έργου και το πλάνο ανάπτυξης των επιμέρους λειτουργιών. Η DSD είναι μια ευέλικτη διαδικασία καθώς (i) εκτελείται επαναληπτικά, (ii) δίνει έμφαση στη συνεργασία καθώς εμπλέκει τους πελάτες-χρήστες με τα μέλη της ομάδας έργου, (iii) εστιάζει στην ιεράρχηση των απαιτήσεων και στην απόδοση προτεραιοτήτων στις απαιτήσεις, (iv) οδηγεί σε σταδιακή-αυξητική ανάπτυξη του συστήματος κατά την οποία δημιουργούνται λειτουργικά πρωτότυπα (working prototypes) του συστήματος, και (v) βασίζεται στην αξιοποίηση των γνώσεων δεξιοτήτων των μελών της ομάδας έργου. Η DSD συνίσταται σε πέντε φάσεις (Σχήμα 6). Οι δύο πρώτες φάσεις εκτελούνται ακολουθιακά και μόνο μια φορά. Οι υπόλοιπες, όπου και αναπτύσσεται το σύστημα, είναι, επαναληπτικές και αυξητικές. 4 Η αρχική ονομασία της διαδικασίας ήταν Rapid Application Development (RAD) [Kerr and Hunter, 1993].

26 26 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Ένα σημαντικό γνώρισμα της διαδικασίας DSD είναι ότι δίνει έμφαση στο χρόνο. Οι επαναλήψεις εκτελούνται σε χρονικά παράθυρα (time boxes). Ένα χρονικό παράθυρο ορίζει συγκεκριμένα χρονικά όρια και κάθε επανάληψη επιβάλλεται να ολοκληρωθεί μέσα στα χρονικά αυτά όρια. Ένα χρονικό παράθυρο μπορεί να διαρκέσει από μερικές μέρες έως κάποιες εβδομάδες. Σχήμα 6: Διαδικασία Ανάπτυξης Δυναμικών Συστημάτων (Προέλευση εικόνας: [Stapleton, 1997]) 1. Μελέτη σκοπιμότητας (Feasibility study): Λαμβάνεται η απόφαση για το αν θα υιοθετηθεί ή όχι η διαδικασία DSD. Αυτό καθορίζεται από τον τύπο του έργου, οργανωτικά θέματα και κυρίως τον ανθρώπινο παράγοντα. Στη φάση αυτή

27 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 27 παράγονται δύο παραδοτέα, η έκθεση σκοπιμότητας και ένα γενικό πλάνο για την ανάπτυξη. 2. Επιχειρησιακή μελέτη (Business study): Σε αυτή τη φάση πρέπει να κατανοηθεί το πλαίσιο λειτουργίας (επιχειρηματικό πλαίσιο) του συστήματος. Τα βασικά αποτελέσματα αυτής της φάσης είναι ο καθορισμός της υψηλού επιπέδου αρχιτεκτονικής του συστήματος και ένα πλάνο για την κατασκευή των πρωτοτύπων του συστήματος. 3. Επανάληψη του λειτουργικού μοντέλου (Functional model iteration): Είναι η πρώτη επαναληπτική φάση. Περιλαμβάνει την ανάλυση, την κωδικοποίηση και την προτυποποίηση. Δημιουργούνται επαναληπτικά και διαδοχικά τα λειτουργικά πρωτότυπα του συστήματος. Επίσης δίνεται έμφαση στην ιεράρχηση των απαιτήσεων που κατατάσσονται σε κατηγορίες με βάση την αξία (value) κάθε απαίτησης. Συγκεκριμένα, εφαρμόζεται η κατάταξη MoSCoW που διακρίνει τις απαιτήσεις σε τέσσερις συγκεκριμένες κλάσεις (Must, Should have, Could have & Won t have requirements). 4. Επανάληψη σχεδίασης και δοκιμών (Design and build iteration): Το σύστημα δημιουργείται ουσιαστικά σε αυτή τη φάση. Ο σχεδιασμός και η λειτουργική αξιολόγηση-έλεγχος των πρωτοτύπων γίνονται από τους χρήστες και οι αλλαγέςβελτιώσεις βασίζονται στα σχόλια των χρηστών. 5. Υλοποίηση (Implementation): Το σύστημα παραδίδεται στους χρήστες και τίθεται σε λειτουργία στο περιβάλλον της επιχείρησης-οργανισμού για τον οποίο προορίζεται. Υποστηρίζεται η κατάρτιση των χρηστών αναφορικά με τη χρήση του συστήματος. Δημιουργούνται εγχειρίδια χρήσης (user manuals) και μια έκθεση ανασκόπησης του έργου (project review). O επαναληπτικός και αυξητικός χαρακτήρας της DSD σημαίνει ότι η υλοποίηση-χρήση-συντήρηση μπορεί να θεωρηθεί ως μια συνεχιζόμενη διαδικασία. Εάν υπάρχουν απαιτήσεις που δεν υλοποιήθηκαν, αντί να τελειώσει το έργο, η διαδικασία μπορεί να επιστρέψει σε κάποια από τις προηγούμενες φάσεις, έτσι ώστε το σύστημα να εμπλουτιστεί με τις απαιτήσεις που τυχόν υπολείπονται. Συνήθως η διαδικασία επιστρέφει στη φάση

28 28 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού της επανάληψη του λειτουργικού μοντέλου εκτός και αν υπάρχει ένα μεγάλο πλήθος ανικανοποίητων απαιτήσεων οπότε εκτελούνται οι φάσεις της DSD εξαρχής. 7. Η Διαδικασία Scrum Οι Takeuchi και Nonaka [Takeuchi and Nonaka, 1986] ήταν οι πρώτοι που περιέγραψαν με τον όρο Scrum μια νέα διαδικασία η οποία βελτιώνει αισθητά την ταχύτητα ανάπτυξης και τον βαθμό ευελιξίας στην κατασκευή ενός βιομηχανικού προϊόντος (όχι κατ ανάγκη προϊόντος λογισμικού). Πολύ αργότερα οι Schwaber και Beedle προδιέγραψαν τη διαδικασία Scrum για την ανάπτυξη λογισμικού στο βιβλίο Agile Software Development with Scrum [Schwaber and Beedle, 2002]. Στη διαδικασία Scrum η ανάπτυξη ενός προϊόντος (εν προκειμένω του λογισμικού) σε όλες τις επί μέρους φάσεις της (που συνήθως επικαλύπτονται) εκτελείται από μία λειτουργική «ομάδα έργου» που μεταφορικά συγκρίνεται με μια ομάδα του παιχνιδιού ράγκμπι 5. Όλα τα μέλη της ομάδας μαζί σαν μια οντότητα προσπαθούν να διανύσουν την απαιτούμενη απόσταση (να κατασκευάσουν το προϊόν), περνώντας την μπάλα του παιχνιδιού μπρός-πίσω. Η Scrum εστιάζει στην ευελιξία, στην οργάνωση και στη διαχείριση της διαδικασίας ανάπτυξης λογισμικού ενώ παράλληλα επιδιώκει να αυξηθεί η παραγωγικότητα της ομάδας έργου και η ικανότητα προσαρμογής της στις εκάστοτε (μεταβαλλόμενες) ανάγκες. Οι ανάγκες αυτές αφορούν απαιτήσεις των χρηστών, το διαθέσιμο χρόνο και προϋπολογισμό, τις ικανότητες των μελών της ομάδας έργου, τις διαθέσιμες τεχνολογικές λύσεις και το επίπεδο της κατάρτισης των μελών της ομάδας έργων επί αυτών. Στη διαδικασία Scrum δίνεται έμφαση στο τρόπο με τον οποίο πρέπει να οργανωθεί η ομάδα έργου ώστε να αυξήσει την αποτελεσματικότητά της. 5 Ο όρος Scrum στο παιχνίδι ράγκμπι σημαίνει «βάζουμε μια εκτός παιχνιδιού μπαλιά, πάλι μέσα στο παιχνίδι» [Schwaber and Beedle, 2002].

29 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 29 Η Scrum προτείνει ένα διαφορετικό τρόπο οργάνωσης και διοίκησης ενός έργου ανάπτυξης λογισμικού σε σχέση με τις υπόλοιπες ευέλικτες διαδικασίες. Πιο συγκεκριμένα, η Scrum έχει ως στόχο να μειώσει (όσο είναι δυνατό) το χρονικό διάστημα του κύκλου ανάπτυξης και της παράδοσης των τμημάτων-εκδόσεων του συστήματος λογισμικού που είχαν συμφωνηθεί αρχικά με τους χρήστες-πελάτες. Σημαντική πρακτική της διαδικασίας είναι η καθημερινή συνεδρίαση (Scrum meeting) των μελών της ομάδας έργου με σκοπό την επίτευξη καλύτερης συνεργασίας και αποτελεσματικότερου συντονισμού των εργασιών τους. Η Scrum είναι στις μέρες μας η πιο δημοφιλής από τις ευέλικτες διαδικασίες ανάπτυξης λογισμικού και υιοθετείται από μεγάλες αλλά και μικρές εταιρείες πληροφορικής ([Version One, 2009] [Behrens, 2006]). Βασικά Χαρακτηριστικά της Διαδικασίας Scrum Όπως και οι υπόλοιπες ευέλικτες διαδικασίες, η Scrum είναι μια επαναληπτική και αυξητική διαδικασία ανάπτυξης λογισμικού. Βασικός σκοπός είναι ο έλεγχος των κινδύνων και η προσαρμογή στις αλλαγές των απαιτήσεων των πελατών-χρηστών που προκύπτουν κατά την υλοποίηση του έργου. Η διαδικασία εκτελείται σε επαναληπτικούς κύκλους ανάπτυξης, οι οποίοι ονομάζονται Sprints. Οι επαναλήψεις δεν πρέπει να διαρκούν περισσότερο από ένα μήνα και εκτελούνται ακολουθιακά χωρίς χρονικές καθυστερήσεις μεταξύ τους. Τα Sprints έχουν συγκεκριμένο χρονοδιάγραμμα το οποίο ποτέ δεν παρακάμπτεται, ακόμη και αν η προγραμματισμένη δραστηριότητα δεν έχει ολοκληρωθεί. Στην αρχή κάθε Sprint η ομάδα έργου επιλέγει τις απαιτήσεις των χρηστών-πελατών, από μια λίστα στην οποία είναι ταξινομημένες με βάση προτεραιότητες (Backlog). Οι απαιτήσεις αυτές δεν μπορούν να αλλάξουν κατά τη διάρκεια κάθε Sprint. Κάθε μέρα τα μέλη της ομάδας έργου συμμετέχουν σε σύντομες συνεδριάσεις για να ελεγχθεί η πρόοδο των εργασιών της ομάδας και για να προσδιοριστούν από κοινού τα επόμενα βήματα που χρειάζονται για την ολοκλήρωση της εργασίας. Στο τέλος κάθε Sprint, η ομάδα παρουσιάζει το τελικό αποτέλεσμα (έκδσση του συστήματος λογισμικού) στον πελάτη και συγκεντρώνει σχόλια, διορθώσεις και παραλήψεις που θα ενσωματωθούν στο επόμενο Sprint. Η διαδικασία Scrum

30 30 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού στοχεύει στο τέλος κάθε επανάληψης να υπάρχει διαθέσιμο ένα λειτουργικό σύστημα λογισμικού που έχει περάσει επιτυχώς δοκιμές-ελέγχους. Για το λόγο αυτό τα μέλη της ομάδας συμφωνούν για το πότε μια εργασία θεωρείται ολοκληρωμένη (Done). Το πότε μια εργασία θεωρείται ολοκληρωμένη περιγράφεται σε ένα αντίστοιχο έγγραφο (στο έγγραφο Definition of Done ) και αυτή η περιγραφή χρησιμοποιείται για να αξιολογηθεί πότε μια εργασία έχει ολοκληρωθεί και μπορεί να ενσωματωθεί στη νέα έκδοση του συστήματος λογισμικού. Με τον αυτόν τον τρόπο εξασφαλίζεται η ποιότητα για το τελικό προϊόν [Schwaber and Sutherland, 2011]. Στο έγγραφο Definition of Done παρουσιάζεται η συμφωνία που πραγματοποιείται μεταξύ της ομάδας Scrum και του Product Owner δηλ. των μελών της ομάδας με τον υπεύθυνο του έργου, το άτομο που έχει ως αρμοδιότητες τη διαχείριση και τον έλεγχο της προόδου του έργου. Το έγγραφο περιλαμβάνει ένα κατάλογο δραστηριοτήτων (σύνταξη κώδικα, σχόλια κωδικοποίησης, έγγραφα σχεδιασμού, κλπ.) που συμφωνείται ότι προσθέτουν αποδεδειγμένη αξία στο σύστημα λογισμικού. Έτσι η ομάδα έργου επικεντρώνεται σε δραστηριότητες που πρέπει να ολοκληρωθούν για τη δημιουργία της επόμενης έκδοσης του λογισμικού και παράλληλα αποφεύγει την υλοποίηση περιττών δραστηριοτήτων που περιπλέκουν και αυξάνουν την πολυπλοκότητας της διαδικασίας ανάπτυξης. Χαρακτηριστικό γνώρισμα της Scrum είναι ο έλεγχος και η προσαρμοστικότητα στις αλλαγές. Η ανάπτυξη συνεπάγεται διαρκή μάθηση, έμφαση στην καινοτομία και προσαρμογή σε απρόσμενες αλλαγές. Η Scrum δίνει έμφαση στην ανάπτυξη ενός μικρού τμήματος του συστήματος κάθε φορά, στον έλεγχο και στις βελτιώσεις κάθε έκδοσης που παράγεται. Η διαδικασία αυτή επαναλαμβάνεται συνεχώς μέχρι το σύστημα να ολοκληρωθεί. Οι δραστηριότητες και τα βασικά δομικά στοιχεία της διαδικασίας Scrum, παρουσιάζονται στο Σχήμα 7.

31 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 31 Σχήμα 7: Η διαδικασία Scrum (Προέλευση εικόνας: [Deemer et al., 2012]) Ρόλοι και Ευθύνες των Μελών της Ομάδας Έργου στη Διαδικασία Scrum Ο ρόλος του Project Manager στη διαδικασία του Scrum δεν ορίζεται διότι υπάρχει οι υπευθυνότητες ενός Project Manager έχουν διαμοιραστεί ανάμεσα στους τρείς ακόλουθους ρόλους. Product Owner: Είναι ο υπεύθυνος του έργου με κύριες υπευθυνότητες τη διαχείριση του έργου. Ο ιδιοκτήτης του έργου ευθύνεται για το τελικό αποτέλεσμα (επιτυχία ή αποτυχία) του έργου [Hundermark, 2009]. Εντοπίζει τα επιθυμητά χαρακτηριστικά του συστήματος, και τα καταγράφει σε μια λίστα απαιτήσεων κατά

32 32 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού προτεραιότητα. Ο Product Owner έχει καθοριστικό ρόλο στην ανάπτυξη του συστήματος και σε ορισμένες περιπτώσεις μπορεί να είναι και ο πελάτης. Πρέπει να σημειωθεί ότι στη Scrum τον ρόλο του Product Owner μπορούν να τον αναλάβουν και περισσότερα από ένα πρόσωπα. The Team (η ομάδα): Μια ομάδα Scrum συνήθως απαρτίζεται από επτά άτομα και μπορεί να περιλαμβάνει άτομα με δεξιότητες-εμπειρία στην ανάλυση απαιτήσεων, στη συγγραφή κώδικα, σε δραστηριότητες δοκιμών-ελέγχων, στο σχεδιασμό των διεπαφών, στην ανάπτυξη και βάσεων δεδομένων κά. Είναι μια αυτό-οργανωμένη (self-organizing team) με υψηλό βαθμό αυτονομίας και υπευθυνότητας. Η ομάδα αποφασίζει πως θα αναπτυχθεί το σύστημα και παρέχει ιδέες στον Product Owner για το πως θα βελτιώσει την ανάπτυξη του συστήματος. Η ομάδα αναλαμβάνει την εκτέλεση όλων των δραστηριοτήτων της ανάπτυξης (ανάλυση και προγραμματισμός, σχεδιασμός, υλοποίηση και έλεγχος). Μια ομάδα είναι πιο παραγωγική και αποτελεσματική εάν όλα τα μέλη της είναι αφοσιωμένα στην κατασκευή του λογισμικού κατά τη διάρκεια κάθε Sprint και γενικά αποφεύγονται ανακατατάξεις και αλλαγές στη σύνθεση της. Οι ομάδες με πολλά άτομα συνήθως οργανώνονται σε μικρότερες ομάδες και καθεμιά αναλαμβάνει την ανάπτυξη διαφορετικών χαρακτηριστικών του συστήματος ενώ ταυτόχρονα διατηρούν την μεταξύ τους επικοινωνία. Scrum Master: Είναι υπεύθυνος της διαδικασίας και έχει ως αρμοδιότητα τη διασφάλιση της ορθής ανάπτυξης του έργου. Ο Scrum Master βοηθά τα μέλη της ομάδας να μάθουν ώστε εφαρμόζουν αποτελεσματικά τις πρακτικές που ακολουθούνται στη διαδικασία του Scrum. Συνεργάζεται με την ομάδα και με τον Product Owner. Ως Scrum Master επιλέγεται κάποιος που να μπορεί να δώσει ουσιαστικές λύσεις σε προβλήματα ώστε η ομάδα να διατηρήσει όσο το δυνατό υψηλά επίπεδα παραγωγικότητας και αποτελεσματικότητας. Συνήθως ένα α τομο με αυτά τα χαρακτηριστικά αναλαμβάνει το ρόλο του Scrum Master, ενώ υπάρχουν περιπτώσεις (σε μικρές ομάδες) που κάποιο μέλος της ομάδας με γνώση πάνω στην εφαρμογή της διαδικασίας Scrum να αναλάβει το ρόλο του Scrum Master.

33 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 33 Τα Βήματα της Διαδικασία Scrum Αρχικά ο Product Owner ορίζει μια ιεραρχική λίστα με τα χαρακτηριστικά που θέλει να ενσωματωθούν στο σύστημα η οποία ονομάζεται Product Backlog (κατάλογος των ανεκτέλεστων εργασιών-εκκρεμοτήτων του προϊόντος) (Σχήμα 8). Η λίστα αυτή ενημερώνεται κατά τη διάρκεια ανάπτυξης του προϊόντος (δηλ. του συστήματος λογισμικού) και περιέχει τις γνωστές, μέχρι εκείνη τη στιγμή, απαιτήσεις. Οι απαιτήσεις μπορεί να προέλθουν από τον πελάτη, το τμήμα πωλήσεων, το τμήμα μάρκετινγκ μιας επιχείρησης ή ακόμη και όσους εμπλέκονται στην ανάπτυξη του λογισμικού. Οι απαιτήσεις κατατάσσονται ανάλογα με την προτεραιότητα τους και υπολογίζεται η προσπάθεια που απαιτείται για την υλοποίηση τους. Ο κατάλογος των απαιτήσεων στο Product Backlog ενημερώνεται και ενημερώνεται σε κάθε επανάληψη με νέες απαιτήσεις, με ακριβέστερες εκτιμήσεις για την απαιτούμενη προσπάθεια υλοποίησης των απαιτήσεων καθώς και με νέες τιμές προτεραιότητας/αξίας για τις απαιτήσεις στο Product Backlog. Το Product Backlog περιλαμβάνει κυρίως τα χαρακτηριστικά του προϊόντος όπως αυτά ορίζονται από τον πελάτη αλλά μπορεί να περιλαμβάνει και βελτιώσεις ή σημεία γενικά που θα πρέπει να τύχουν προσοχής. Τα χαρακτηριστικά που περιλαμβάνονται στη λίστα του Product Backlog, μπορούν να διατυπωθούν με οποιονδήποτε σαφή τρόπο, όπως για παράδειγμα μέσω σεναρίων περιπτώσεων χρήσης (use cases) ή με ιστορίες χρηστών (user stories). Το σύνολο των χαρακτηριστικών του Product Backlog που επιλέγονται σε μια επανάληψη (sprint), ονομάζεται Release Backlog. Η σειρά με την οποία επιλέγονται προς υλοποίηση τα χαρακτηριστικά (απαιτήσεις) εξαρτάται από την προτεραιότητα που έχει δοθεί σε αυτά. Μία καλή πρακτική κατά τη διαδικασία ανάθεσης προτεραιοτήτων στα χαρακτηριστικά-απαιτήσεις, είναι να επιλέγονται πρώτα χαρακτηριστικά με μεγάλη αξία (value) και λιγότερη απαιτούμενη προσπάθεια (cost) για υλοποίηση. Όσο αφορά στην εκτιμώμενη προσπάθεια που απαιτείται για την υλοποίηση κάθε χαρακτηριστικού που περιλαμβάνεται στην λίστα, η ομάδα Scrum ενημερώνει τον Product Owner.

34 34 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Σχήμα 8: Παράδειγμα Product Backlog (Προέλευση εικόνας: [Deemer et al., 2012]) Η διαδικασία Scrum δεν καθορίζει με σαφήνεια με ποια κριτήρια θα γίνει η ιεράρχηση των απαιτήσεων στο Product Backlog. Η ασάφεια αυτή καλύπτεται από τις τεχνικές που θα χρησιμοποιηθούν για την ιεράρχηση των απαιτήσεων (requirements prioritization techniques). Για παράδειγμα, μια συνήθης τεχνική είναι εκτιμηθούν οι πιο σημαντικοί παράγοντες (απαιτούμενη προσπάθεια, πολυπλοκότητα, αβεβαιότητα) και να αποδοθεί μια τιμή-βάρος σε κάθε ένα από τους παράγοντες αυτούς. Η διαδικασία επαναλαμβάνεται για κάθε χαρακτηριστικόαπαίτηση ξεχωριστά και οι τιμές που δίνονται ονομάζονται Βαθμοί (Points). Με την εμπειρία που αποκτά κάθε ομάδα μπορεί να εκτιμήσει πόση εργασία (προσπάθεια) απαιτείται σε κάθε Sprint. Καθορίζεται έτσι ένας μέσος όρος από points για κάθε Sprint. Για παράδειγμα, αν ο μέσος όρος αυτός οριστεί στα 20, τότε αυτό σημαίνει πώς το άθροισμα των points των χαρακτηριστικών-απαιτήσεων που θα επιλεγούν προς υλοποίηση στο Release Backlog δεν θα πρέπει να υπερβαίνει το 20. Έτσι μπορεί να εκτιμηθεί ο χρόνος που χρειάζεται για την ολοκλήρωση ενός Sprint ή επίσης να εκτιμηθεί πόσα χαρακτηριστικά (κατά μέσο όρο) μπορούν να υλοποιηθούν σε ένα Sprint. Ο μέσος όρος αυτός ονομάζεται velocity (ταχύτητα της ομάδας). Η πληροφορία αυτή είναι σημαντική για την ομάδα γιατί εάν το velocity είναι γνωστό τότε μπορεί να προγραμματιστούν κατάλληλα οι εργασίες της ομάδας. Ο Product Owner χρησιμοποιεί την τιμή του velocity για να προβλέψει το ρυθμό με τον οποίο η ομάδα θα παραδίδει τμήματα-εκδόσεις του συστήματος.

35 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 35 Τα χαρακτηριστικά (απαιτήσεις) που περιλαμβάνονται στο Product Backlog μπορεί να διαφέρουν αρκετά ως προς το μέγεθος και την απαιτούμενη προσπάθεια. Τα πιο σύνθετα-πολύπλοκα από αυτά αναλύονται σε επιμέρους απλούστερα χαρακτηριστικά κατά τη διάρκεια της συνεδρίασης προγραμματισμού του επόμενου Sprint (Sprint Planning Meeting) ενώ τα απλούστερα χαρακτηριστικά μπορούν με τη σειρά τους να ενοποιηθούν σε πιο σύνθετα. Προγραμματισμός του Επόμενου Sprint (Sprint Planning) Στην έναρξη κάθε Sprint πραγματοποιείται μια συνεδρίαση με στόχο τον προγραμματισμό του Sprint. Η συζήτηση στη συνεδρίαση επικεντρώνεται σε δύο ερωτήματα [Schwaber and Sutherland, 2011]: 1. Τι θα παραδοθεί στον πελάτη-χρήστη μετά το τέλος του Sprint; 2. Πώς θα προγραμματιστεί η δουλειά ώστε να επιτευχθεί η παράδοση των χαρακτηριστικών που αποφασίστηκαν; Συγκεκριμένα, η συζήτηση στο Sprint Planning Meeting επικεντρώνεται στην κατανόηση του τι ακριβώς ζητά ο Product Owner. O Product Owner κατά τη διάρκεια της συνεδρίασης διαπραγματεύεται το τι θα υλοποιηθεί κατά το επόμενο Sprint επανεξετάζοντας τα υψηλής προτεραιότητας χαρακτηριστικά που βρίσκονται στο Product Backlog. Οι εμπλεκόμενοι στη συνεδρίαση (μέλη της ομάδας & scrum master) συζητούν για τους στόχους και την λειτουργία των απαιτήσεων που θα υλοποιηθούν. Επίσης η συνεδρίαση εστιάζει στον λεπτομερή προγραμματισμό των εργασιών (tasks) που πρέπει να γίνουν κατά το Sprint. Η ομάδα επιλέγει τα χαρακτηριστικά από το Product Backlog και δεσμεύεται να τα ολοκληρώσει έως το τέλος του Sprint, ξεκινώντας από την κορυφή της λίστας, δηλαδή από τα χαρακτηριστικά με μεγαλύτερη προτεραιότητα. Η ομάδα, όπως αναφέραμε, αυτo-οργανώνεται. Τα μέλη της ομάδας αποφασίζουν και συμφωνούν μεταξύ τους το ποσοστό της εργασίας που πρόκειται να ολοκληρώσουν αντί αυτό να τους ανατεθεί από τον Product Owner. Επιπλέον η ομάδα έχει τη δυνατότητα να

36 36 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού αλλάξει την σειρά προτεραιότητας των χαρακτηριστικών στο Product Backlog, εφόσον αυτό κρίνεται απαραίτητο. Κατά τη διάρκεια της συναδρίασης επίσης καθορίζονται πόσες εργασιακές ώρες διαθέτει κάθε μέλος της ομάδας. Συνήθως κάθε μέλος δουλεύει περίπου από 4 μέχρι 6 ώρες την ημέρα. Έπειτα συναθροίζονται οι ώρες κάθε μέλους ξεχωριστά και προκύπτει ο συνολικός χρόνος σε ώρες κατά τον οποίο θα πρέπει να ολοκληρωθεί το Sprint. Εφόσον ο συνολικός αυτός χρόνος καθοριστεί, τότε η ομάδα υπολογίζει πόσα χαρακτηριστικά από το Product Backlog μπορεί να υλοποιήσει μέσα στα χρονικά πλαίσια του Sprint και πως θα υλοποιηθούν αυτά. Η ομάδα ξεκινά με την υλοποίηση των χαρακτηριστικών που έχουν μεγαλύτερη προτεραιότητα και αποσυνθέτει κάθε χαρακτηριστικό σε επιμέρους εργασίες (Tasks) οι οποίες συγκεντρώνονται και καταγράφονται σε μια λίστα η οποία ονομάζεται Sprint Backlog (Σχήμα 9). Στο τέλος κάθε συνεδρίασης, θα πρέπει να προκύψει ένας κατάλογος (το Sprint Backlog) με όλες τις εργασίες που πρέπει να γίνουν και τις εκτιμώμενες ώρες εργασίας που απαιτούνται για κάθε μια από αυτές. Σχήμα 9: Παράδειγμα Sprint Backlog (Προέλευση εικόνας: [Deemer et al., 2012]) Στο ενδεικτικό Sprint Backlog που παρουσιάζεται στο Σχήμα 9 στην πρώτη στήλη φαίνονται τα χαρακτηριστικά το οποία επιλέχθηκαν από το Product Backlog και αναλύθηκαν σε επιμέρους εργασίες (που απαιτούνται για την υλοποίηση κάθε χαρακτηριστικού) οι οποίες φαίνονται στη δεύτερη στήλη. Στην τρίτη στήλη αναγράφονται τα μέλη της ομάδας στα οποία έχουν ανατεθεί οι εργασίες. Στην τέταρτη στήλη παρουσιάζεται η εκτίμηση για την προσπάθεια που απαιτείται για την ολοκλήρωση κάθε εργασίας. Στο συγκεκριμένο παράδειγμα, η συνολική εκτίμηση για την προσπάθεια που απαιτείται είναι 50 ώρες.

37 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 37 Κατά τη συνεδρίαση για τον προγραμματισμό του επόμενου Sprint Planning δεν είναι απαραίτητο τα μέλη της ομάδας να επιλέξουν να υλοποιήσουν τις εργασίες που γνωρίζουν καλύτερα (έχουν μεγαλύτερη εμπειρία σε αυτές) γιατί οι συμμετέχοντες στην ομάδα συνεργάζονται ανεξαρτήτως της ειδικότητας και της εμπειρίας που έχει ο καθένας. Βασική αρχή είναι τα μέλη της ομάδας να (αλληλο-) υποστηρίζονται μεταξύ τους. Με τον τρόπο αυτό τα άτομα της ομάδας έχουν την δυνατότητα να διευρύνουν τις γνώσεις και τις δεξιότητες τους σε διάφορους τύπους εργασιών. Ακόμη αν η ομάδα χρησιμοποιεί ένα εξειδικευμένο λογισμικό διαχείρισης έργων (project management software) για τη διαχείριση των Sprint, καλή πρακτική είναι να υιοθετούνται πιο «άμεσοι» και περιγραφικοί τρόποι ειδικά για τη διαχείριση των Tasks. Αυτό επιτυγχάνεται με την χρήση ενός συμβατικού πίνακα (Task Board) στον οποίο παρουσιάζονται οι εργασίες προς διεκπεραίωση κατά τη διάρκεια του Sprint σε μορφή σημειώσεων (notes) (Σχήμα 10). Ο πίνακας εργασιών αναπαριστά τις εργασίες που η ομάδα έχει δεσμευθεί να υλοποιήσει κατά τη διάρκεια του τρέχοντος Sprint. Κάθε χαρτί στoν πίνακα αναγράφει ένα σύνολο εργασιών. Κάθε Task είναι γραμμένο σε ένα post-it αυτοκόλλητο χαρτί, στο οποίο σημειώνεται και η εκτιμώμενη προσπάθειας που απαιτείται. Στην πρώτη στήλη στον πίνακα παρουσιάζονται οι εργασίες που δεν έχουν αρχίσει ακόμη (Waiting ή To do tasks). Στη δεύτερη στήλη, παρουσιάζονται οι εργασίες που είναι σε υλοποίηση από την ομάδα (In progress tasks). Τέλος, στην τρίτη στήλη παρουσιάζονται οι εργασίες που έχουν ολοκληρωθεί (Done). Κατά τη διάρκεια του Sprint τα αυτοκόλλητα χαρτάκια μετακινούνται από τα αριστερά προς τα δεξιά ανάλογα με την πρόοδο των εργασιών [Kniber, 2007]. Με τον τρόπο αυτό ο πίνακας εργασιών αναπαριστά τις εργασίες που έχουν προγραμματιστεί σε ένα Sprint και την τρέχουσα κατάστασή της προόδου εκτέλεσης των εργασιών.

38 38 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Σχήμα 10: Παράδειγμα Sprint Task Board (Προέλευση εικόνας: [Hundermark, 2009]) Ένας από τους βασικούς πρακτικούς κανόνες που εφαρμόζει η διαδικασία Scrum είναι ότι όταν έχει ξεκινήσει η υλοποίηση ενός Sprint, τυχόν προσθήκες ή αλλαγές χαρακτηριστικών θα πρέπει να περιμένουν μέχρι το επόμενο Sprint. Υπάρχει όμως η περίπτωση ένα Sprint να τερματιστεί πρόωρα, εάν προκύψουν νέα δεδομένα και αλλαγές που μεταβάλλουν σημαντικά τις προτεραιότητες των χαρακτηριστικών. Σε αυτή την περίπτωση η ομάδα θα σπαταλήσει πολύτιμο χρόνο εάν συνεχίσει να εργάζεται στο τρέχον Sprint. Το ενδεχόμενο να συμβεί αυτό είναι βέβαια μικρό γιατί η Scrum είναι μια καλά δομημένη διαδικασία και «προστατεύει» την ομάδα από τις αλλαγές των στόχων κατά τη διάρκεια εκτέλεσης ενός Sprint. Αν παρόλα αυτά χρειάζεται να διακοπεί η εκτέλεση του Sprint, τότε πραγματοποιείται ξανά ένα Sprint Planning Meeting και καθορίζεται ένα νέο Sprint.

39 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 39 Καθημερινή Συνεδρίαση Scrum (Daily Scrum Meeting) Κατά τη διάρκεια ενός Sprint η ομάδα εφαρμόζει μια ακόμη από τις βασικές πρακτικές της διαδικασίας Scrum, την καθημερινή συνεδρίαση Scrum (το λεγόμενο Daily Scrum Meeting). Είναι μια σύντομη συνεδρίαση, η οποία συνήθως διαρκεί 15 λεπτά και πραγματοποιείται καθημερινά. Στη συνεδρίαση αυτή λαμβάνει μέρος όλη η ομάδα ώστε τα μέλη της να συγχρονιστούν μεταξύ τους και σε όλα τα μέλη της ομάδας να γίνουν γνωστά τυχόν προβλήματα και δυσκολίες που συναντήθηκαν. Κατά τη συνεδρίαση αυτή κάθε μέλος της ομάδας πρέπει να κοινοποιήσει τρεις βασικές πληροφορίες: 1. Τι νέο έχει κάνει από την τελευταία συνεδρίαση. 2. Τι εμπόδια και δυσκολίες αντιμετώπισε. 3. Τι σκοπεύει να ολοκληρώσει μέχρι την επόμενη συνεδρίαση. Στο Daily Scrum Meeting μόνο τα μέλη της ομάδας Scrum και ο Scrum Master επιτρέπεται να παρευρίσκονται. Η συνάντηση πραγματοποιείται την ίδια ώρα και στον ίδιο χώρο κάθε μέρα. Σκοπός της συνάντησης είναι να βελτιωθεί η επικοινωνία μεταξύ των μελών της ομάδας και να υποστηριχθεί η λήψη πρακτικών αποφάσεων σχετικά με την επίλυση προβλημάτων που ανακύπτουν. Η καθημερινή συνάντηση ελέγχει την τρέχουσα πρόοδο και επικεντρώνεται στο να επιτευχθούν οι στόχοι του Sprint. Η συνάντηση είναι σημαντική όσον αφορά την αυτό-οργάνωση της ομάδας. Εάν ένα Daily Scrum Meeting δεν πραγματοποιηθεί με επιτυχία τότε η ομάδα είναι πιθανό να αγνοεί την τρέχουσα κατάσταση του έργου και να αντιμετωπίσει στο άμεσο μέλλον σημαντικές δυσκολίες στην επίτευξη των στόχων της που έχουν καθοριστεί στην αρχή του Sprint. Κατά τη διάρκεια του Daily Scrum Meeting πραγματοποιείται και η ανανέωση του Task Board με τα νέα στοιχεία που έχουν προκύψει από την εκτέλεση του έργου. Ενημέρωση των Sprint Backlog και Burndown Chart

40 40 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Καθημερινά τα μέλη της ομάδας ενημερώνουν τον εκτιμώμενο χρόνο που χρειάζεται για την ολοκλήρωση της κάθε εργασίας τους. Μετά την ενημέρωση των επιμέρους εργασιών, προκύπτει ο συνολικός χρόνος που απομένει ώστε να ολοκληρωθεί το Sprint (Σχήμα 11). Σχήμα 11: Ανανέωση της εργασίας που απομένει να εκτελεστεί σε ένα Sprint Backlog (Προέλευση εικόνας: [Deemer et al., 2012]) Το αποτέλεσμα της ενημέρωσης αποτυπώνεται σε ένα γράφημα, το λεγόμενο Sprint Burndown Chart. Στο γράφημα αναπαριστάται η υπόλοιπη εργασία που απομένει να εκτελεστεί στο Sprint Backlog. Το γράφημα αυτό ενημερώνεται καθημερινά καθώς πρέπει να παρουσιάζει την τρέχουσα πρόοδο σε κάθε Sprint. Το γράφημα παρουσιάζει, κάθε μέρα, μια νέα εκτίμηση για το πόση εργασία απομένει μέχρι η ομάδα να ολοκληρώσει όλα τις εργασίες (Tasks) σε ένα Sprint. Ονομάζεται «Burndown» γιατί αναπαριστά το φόρτο εργασίας που απομένει σε συνάρτηση με το χρόνο σε μια καμπύλη που έχει κλίση προς τα κάτω. Η γραφική αυτή αναπαράσταση ενημερώνεται κατά τη διάρκεια του Daily Scrum Meeting [Kniber, 2007]. Στο Σχήμα 12 απεικονίζεται ένα παράδειγμα Sprint Burndown Chart.

41 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 41 Σχήμα 12: Παράδειγμα Sprint Burndown Chart (Προέλευση εικόνας: [Deemer et al., 2012]) Κάθε μέρα η τρέχουσα κατάσταση σημειώνεται στο γράφημα με μια τελεία, οι τελείες ενώνονται μεταξύ τους και προκύπτει έτσι μια καμπύλη που κλίνει προς τα κάτω (κόκκινο χρώμα). Επίσης, στο γράφημα, υπάρχει άλλη μια γραμμή (γκρι), η «ιδανική γραμμή», που αναπαριστά την ιδανική πρόοδο που η ομάδα θα έπρεπε να πετύχει. Η γραμμή αναπαριστά μια γραμμική πρόοδο των εργασιών από την πρώτη μέρα του Sprint μέχρι και την τελευταία μέρα. Πρέπει να σημειωθεί ότι το Burndown Chart «υπενθυμίζει» στην ομάδα την πρόοδο τους προς τον στόχο, όχι από την άποψη του τι έχει ολοκληρωθεί μέχρι τώρα αλλά όσο αφορά στην προσπάθεια που απομένει για την επίτευξη του στόχου τους, ο οποίος είναι η επιτυχής ολοκλήρωση του Sprint. Εάν η καμπύλη δεν κλίνει προς τα κάτω τότε αυτό σημαίνει πως η ομάδα θα πρέπει να ανασυνταχτεί και να εντοπίσει τρόπους ώστε να εργάζεται αποτελεσματικότερα διατηρώντας παράλληλα ένα σταθερό ρυθμό. Παρόλο που το Burndown Chart μπορεί να δημιουργηθεί και να προβληθεί χρησιμοποιώντας ένα ειδικό λογισμικό δημιουργίας γραφημάτων, πολλές ομάδες έχουν διαπιστώσει ότι είναι πιο αποτελεσματικό να χρησιμοποιούν ένα πιο φυσικό τρόπο αναπαράστασης του γραφήματος, όπως σχεδιάζοντας το σε ένα συμβατικό πίνακα. Η λύση αυτή είναι γρήγορη, απλή, και συχνά πιο κατανοητή από ένα διάγραμμα στον υπολογιστή. Συνήθως το Burndown Chart τοποθετείται κοντά στο Task Board ώστε να είναι προσβάσιμο και ορατό από όλους ανά πάσα στιγμή [Schwaber and Sutherland, 2011].

42 42 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Αναθεώρηση του Product Backlog Μια από τις λιγότερο χρησιμοποιούμενες πρακτικές στο Scrum είναι η αναθεώρηση του Product Backlog στο τέλος κάθε Sprint. Η αναθεώρηση αυτή περιλαμβάνει λεπτομερή ανάλυση των απαιτήσεων, τη διάσπαση πιο σύνθετων χαρακτηριστικών του συστήματος σε απλούστερα, την εκτίμηση των νέων στοιχείων που ενδέχεται να προκύψουν, και την εκ νέου εκτίμηση των υφιστάμενων απαιτήσεων. Η εργασία αυτή γίνεται προς το τέλος κάθε Sprint με τη συμμετοχή της ομάδας Scrum και του Product Owner. Για ένα Sprint που διαρκεί 2 βδομάδες, το 5% (περίπου μισή εργάσιμη μέρα) της διάρκειας αυτής αφιερώνεται στην αναθεώρηση του Product Backlog. Η αναθεώρηση δεν αφορά τα χαρακτηριστικά που επιλέχθηκαν για το τρέχον Sprint, αλλά αυτά που πρόκειται να συμπεριληφθούν στα αμέσως επόμενα Sprints. Με τον τρόπο αυτό ο προγραμματισμός ενός Sprint γίνεται σχετικά απλός και ο Product Owner και η ομάδα έχουν στην διάθεση τους ένα σύνολο από καλά ορισμένες απαιτήσεις των πελατών. Ολοκλήρωση ενός Sprint Η χρονική διάρκεια ενός Sprint ποτέ δεν επεκτείνεται και για κανένα λόγο. Ολοκληρώνεται πάντα στο προκαθορισμένο χρονικό όριο ανεξάρτητα από το αν η ομάδα έχει ολοκληρώσει το έργο που δεσμεύτηκε να ολοκληρώσει. Συνήθως, μια ομάδα δεν κατορθώνει να ολοκληρώσει όλη την εργασία που έχει αναλάβει από τα πρώτα Sprints. Με την πάροδο όμως του χρόνου, η ομάδα «βρίσκει» το ρυθμό της και μπορεί πιο εύκολα να προσδιορίσει την προσπάθεια που χρειάζεται για να ολοκληρώσει με επιτυχία κάθε Sprint. Είναι καλύτερο για τις ομάδες να επιλέξουν μια σταθερή διάρκεια για τα Sprints (π.χ. τρεις εβδομάδες) γιατί αυτό συντελεί στο να επιτευχθεί ένας σταθερός ρυθμός εργασίας, δηλαδή να γνωρίζει η ομάδα πόση δουλειά μπορεί να υλοποιήσει μέσα σε αυτό το προκαθορισμένο χρονικό περιθώριο. Ο ρυθμός εργασίας της ομάδας Scrum είναι γνωστός ως «Heartbeat».

43 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 43 Επανεξέταση του Sprint (Sprint Review) Μετά την ολοκλήρωση ενός Sprint, ο Product Owner μαζί με την ομάδα Scrum επανεξετάζουν και ελέγχουν (review) την επανάληψη που μόλις τελείωσε. Η διαδικασία αυτή ονομάζεται Sprint Review. Η ομάδα παρουσιάζει τα αποτελέσματα του Sprint και εξετάζεται κατά πόσο οι στόχοι που είχαν τεθεί στο Sprint Planning έχουν ολοκληρωθεί με επιτυχία. Μια βασική αρχή στη διαδικασία Scrum είναι ο έλεγχος και η προσαρμοστικότητα (Inspect and Adapt). Αυτό σημαίνει πως αφού εξεταστεί το αποτέλεσμα που έχει προκύψει μετά από κάθε Sprint τότε εντοπίζονται οι αλλαγές ή προσαρμογές που θα πρέπει να γίνουν στο σύστημα κατά τις επόμενες επαναλήψεις. Για το σκοπό αυτό, γίνεται μια διεξοδική συζήτηση μεταξύ του Product Owner και της ομάδας ώστε να προσδιοριστεί η κατάσταση στην οποία βρίσκεται η όλη ανάπτυξη του συστήματος. Επίσης, κατά τη διάρκεια της επανεξέτασης του Sprint παρουσιάζονται τα αποτελέσματα στους χρήστες-πελάτες του προϊόντος (του συστήματος λογισμικού). Οι συμμετέχοντες αξιολογούν την ανάπτυξη του έργου και λαμβάνουν αποφάσεις που αφορούν τις επόμενες λειτουργικές απαιτήσεις που θα πρέπει να υλοποιηθούν. Αυτή η συνεδρίαση είναι σημαντική για την πορεία του έργου καθώς μπορεί να δημιουργήσει νέα στοιχεία στον κατάλογο του Product Backlog αλλά και αναθεώρηση των υπαρχόντων. Ακόμη καθορίζονται οι στόχοι για το επόμενο Sprint [Schwaber and Sutherland, 2011]. Sprint Retrospective Το Sprint Retrospective είναι η συνάντηση εργασίας που ακολουθεί της επανεξέτασης του Sprint. Αφορά την εξέταση και την αναθεώρηση της διαδικασίας που εφαρμόστηκε κατά το τελευταίο Sprint. Χρησιμοποιείται για να εντοπιστούν οι καθοριστικοί παράγοντες επιτυχίας και πιθανά σημεία της διαδικασίας που μπορούν να βελτιωθούν. Στο στάδιο αυτό η ομάδα έχει τη δυνατότητα να συζητήσει τι λειτουργεί καλά και τι όχι και να καταλήξουν σε τυχόν αλλαγές που μπορούν να εφαρμόσουν στο επόμενο Sprint. Στη συνάντηση αυτή λαμβάνουν μέρος ο Scrum Master και η ομάδα Scrum ενώ η παρουσία του Product Owner δεν είναι υποχρεωτική. Μια πρακτική για την οργάνωση της συνάντησης, είναι να σχηματιστούν δύο στήλες σε ένα πίνακα. Στη

44 44 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού μια στήλη να παρουσιάζονται οι παράγοντες επιτυχίας (What is working well) και στην δεύτερη οι πιθανοί τομείς βελτίωσης (What could work better). Τα μέλη της ομάδας προσθέτουν στον πίνακα ένα ή περισσότερα στοιχεία (χαρακτηριστικάαπαιτήσεις του λογισμικού) σε οποιαδήποτε από τις στήλες. Έπειτα γίνεται καταμέτρηση και προκύπτουν τα δημοφιλέστερα προβλήματα ή παράγοντες επιτυχίας αντίστοιχα. Τα ζητήματα, που αφορούν βελτιώσεις στην διαδικασία κατατάσσονται με σειρά προτεραιότητας και εφαρμόζονται στα επόμενα Sprints. Στην αναφορά [Kniber, 2007] προτείνεται η ομάδα να επικεντρώνεται μόνο σε μια περιοχή βελτίωσης ανά Sprint. Επίσης, είναι σημαντικό να διαχωρίζονται προβλήματα που αφορούν την εφαρμογή της διαδικασίας Scrum από τους υπόλοιπους παράγοντες (π.χ. ελλιπή υλοποίηση ή δυσκολία στην υλοποίσηη των χαρακτηριστικών απαιτήσεων). Ενημέρωση των Release Backlog & Burndown Chart Στο στάδιο αυτό κάποιες εργασίες έχουν ολοκληρωθεί, κάποιες έχουν προστεθεί στο Product Backlog ενώ μερικές έχουν αναθεωρηθεί. Ο Product Owner είναι υπεύθυνος για την ενημέρωση του Release Backlog (του κατάλογου των ανεκτέλεστων εργασιών του προϊόντος σε ένα Sprint) και κατ επέκταση του Product Backlog. Επιπρόσθετα, οι ομάδες ενδέχεται να ενημερώνουν και το γράφημα Release Burndown Chart, το οποίο αποτελεί μια προέκταση του γραφήματος Sprint Burndown Chart με τη διαφορά ότι επικεντρώνεται στις απατήσεις και όχι στα Tasks. Ουσιαστικά ένα Release Burndown Chart είναι μια γραφική αναπαράσταση στην οποία αναπαριστάται η συνολική πρόοδος της ομάδας. Παρουσιάζεται ως ένα γράφημα που αναπαριστά την αναθεωρημένη υπολειπόμενη συνολική ανεκτέλεστη εργασία σε σχέση με τον αριθμό των Sprints που απομένουν (Σχήμα 13). Το γράφημα αυτό είναι επίσης γνωστό και ως Product Burndown Chart [Hundermark, 2009] και απεικονίζει τον ρυθμό παράδοσης τμημάτων του συστήματος. Χρησιμοποιώντας αυτό το διάγραμμα o Product Owner είναι σε θέση να προσδιορίσει την πρόοδο και να καθορίσει τις επόμενες ημερομηνίες παράδοσης.

45 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 45 Σχήμα 13: Παράδειγμα Release Burndown Chart (Προέλευση εικόνας: [Deemer et al., 2012]) Ολοκλήρωση της Διαδικασίας Κύριος σκοπός της Scrum, είναι να παραδίδονται λειτουργικά τμήματα του τελικού προϊόντος στο τέλος κάθε Sprint. Το αποτέλεσμα κάθε επανάληψης, είναι μια προσθήκη στο τελικό προϊόν. Στο τέλος του Sprint, η νέα προσθήκη (άθροισμα όλων των εργασιών που περιλαμβάνονται στο Sprint Backlog) θα πρέπει να μπορεί να δοθεί στον πελάτη (Shippable Product Increment) και να ανταποκρίνεται στον ορισμό του «ολοκληρωμένου» (Definition of Done). Όπως έχει προαναφερθεί η Scrum είναι μια επαναληπτική διαδικασία. Όταν ολοκληρωθεί ένα Sprint, το επόμενο βήμα είναι να ξεκινήσει η διαδικασία από την

46 46 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού αρχή. Οι επαναλήψεις συνεχίζονται μέχρι οι απαιτήσεις των πελατών να ικανοποιηθούν πλήρως και να προκύψει ένα ολοκληρωμένο προϊόν. 8. Η Διαδικασία Kanban Στα τέλη της δεκαετίας του 1940, η Toyota άρχισε να μελετά καταστήματα σούπερ μάρκετ με σκοπό την εφαρμογή τεχνικών που χρησιμοποιούσαν τα καταστήματα αυτά, στα εργοστάσιά της. Σε ένα σούπερ μάρκετ, οι πελάτες λαμβάνουν την απαιτούμενη ποσότητα στον απαιτούμενο χρόνο, τίποτα περισσότερο και τίποτα λιγότερο. Επιπλέον, τα σούπερ μάρκετ αποθηκεύουν μόνο ό,τι αναμένεται να πωληθεί εντός ενός συγκεκριμένου χρονικού διαστήματος, και οι πελάτες λαμβάνουν μόνο ό,τι χρειάζονται, αφού η προσφορά στο μέλλον είναι εξασφαλισμένη. Ένα σύστημα Kanban, όταν συνδυάζεται με εργαλεία προγραμματισμού, μπορεί να μειώσει δραματικά τα επίπεδα των αποθεμάτων, να ενισχύσει τις σχέσεις του προμηθευτή με τους πελάτες και να βελτιώσει την ακρίβεια των χρονοδιαγραμμάτων κατασκευής. Η Kanban ευθυγραμμίζει τα επίπεδα αποθέματος με την πραγματική κατανάλωση. Όταν ένα υλικό έχει καταναλωθεί, αποστέλλεται ένα σήμα για να παραχθεί και να παραδοθεί ένα νέο. Αυτά τα σήματα παρακολουθούνται από τον προμηθευτή και τον αγοραστή μέσω του κύκλου αναπλήρωσης. Η Kanban χρησιμοποιεί το ποσοστό της ζήτησης για τον έλεγχο του ρυθμού παραγωγής, μεταφέροντας τη ζήτηση από τον τελικό καταναλωτή στην αλυσίδα των διαδικασιών πελάτη-καταστήματος. Το 1953, η Toyota εφάρμοσε αυτή τη διαδικασία στο χώρο παραγωγής των εργοστασίων της. Η παραγωγή προσδιορίζεται σύμφωνα με την πραγματική ζήτηση των πελατών με αποτέλεσμα τα ενδιάμεσα αποθέματα που διατηρούνται στην αλυσίδα εφοδιασμού να είναι πιο διαχειρίσιμα και συνήθως μικρότερα σε ύψος [Ohno, Taiichi, 1988]. Παρά το γεγονός ότι η παραγωγή λογισμικού είναι μια δημιουργική δραστηριότητα και ως εκ τούτου διαφορετική από την μαζική παραγωγή αυτοκινήτων, ο βασικός μηχανισμός της Kanban για τη διαχείριση της ροής εργασιών μπορεί να εφαρμοστεί με επιτυχία και στην ανάπτυξη λογισμικού. Στην ανάπτυξη λογισμικού, η διαδικασία Kanban, όπως διατυπώθηκε από τον Anderson [Anderson 2003], είναι μια προσέγγιση για τη σταδιακή, εξελικτική ανάπτυξη συστημάτων.

47 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 47 Τα Βασικά Χαρακτηριστικά της Διαδικασίας Kanban Η ονομασία Kanban προέρχεται από τα Ιαπωνικά, και μεταφράζεται ως "κάρτα σε πίνακα". Σε φυσικά συστήματα μια κάρτα συνδέεται με μια μόνο εργασία και περιγράφει τη θέση που αυτή βρίσκεται σε συνάρτηση με την όλη διαδικασία. Έτσι και στην ανάπτυξη λογισμικού κάθε kanban αντιπροσωπεύει ένα μόνο τμήμα μιας εργασίας και ο αριθμός των διαθέσιμων kanban ισοδυναμεί με τη συμφωνηθείσα δυνατότητα (σε πλήθος) εκτέλεσης εργασιών. Μια νέα εργασία μπορεί να αρχίσει μόνο όταν υπάρχει κάποια διαθέσιμη κάρτα, και μια κάρτα είναι διαθέσιμη μόνο όταν η προηγούμενη εργασία έχει ολοκληρωθεί, πράγμα που σημαίνει ότι οι νέες εργασίες θα πρέπει να περιμένουν στην ουρά μέχρι οι υπάρχουσες εργασίες να έχουν ολοκληρωθεί. Αυτή η διαδικασία είναι γνωστή και ως ένα σύστημα pull, αφού οι εργασίες εισέρχονται στο σύστημα από τα άτομα που έχουν αναλάβει την εκτέλεση των εργασιών, σε αντίθεση με τα "συστήματα push" όπου κάποιος παράγοντας έξω από την ομάδα εργασίας προωθεί εργασίες το σύστημα. Η διαδικασία Kanban είναι μια συλλογή από αρχές και στρατηγικές που χαρακτηρίζονται από τις παραπάνω αξίες. Η ευέλικτη διαδικασία Kanban είναι λιγότερο ακριβής από ό,τι ο ακραίος προγραμματισμός (Extreme Programming), που διαθέτει μια συλλογή από αξίες, αρχές και πρακτικές και σίγουρα περισσότερο ασαφής από ό,τι η Scrum, η οποία και προβλέπει ένα κύκλο ζωής, διάφορους ρόλους, διάφορες πρακτικές, καθώς και μια συλλογή από φιλοσοφίες. Η Kanban ξεκινά με την υπάρχουσα ροή εργασιών και την υπάρχουσα διαδικασία και στη συνέχεια προσπαθεί να βελτιώσει τα πράγματα από εκεί. Μια κύρια διαπίστωση για τη διαδικασία Kanban είναι ότι η μπορεί να εφαρμοστεί και σε άλλες περιπτώσεις εκτός από ευέλικτες καταστάσεις και είναι, πιθανώς, πολύ εύκολο να υιοθετηθεί. Βασικά χαρακτηριστικά της μεθόδου είναι ο περιορισμός των εργασιών σε εξέλιξη (WIP) και η «έλξη» (pull) εργασιών από την ομάδα με τη βοήθεια μιας διαγραμματικής αναπαράστασης. Η Kanban προωθεί επίσης τόσο τις ευέλικτες (agile) όσο και τις λιτές (lean) στρατηγικές για τον εξορθολογισμό της διαδικασίας ανάπτυξης. Επίσης προωθεί την μεταφορά μικρών παρτίδων για να μειωθεί ο χρόνος απόκρισης και την τήρηση προτεραιότητας με βάση την αξία για να μεγιστοποιηθεί η απόδοση της επένδυσης (ROI). Ακόμη προωθεί τη διαχείριση του κινδύνου για να αυξηθεί η πιθανότητα επιτυχίας και την επίτευξη της προόδου

48 48 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού βασιζόμενοι σε ελλιπή ενημέρωση. Τέλος, η Kanban προωθεί την ανταπόκριση στις αλλαγές για να αυξηθούν οι πιθανότητες παράδοσης λειτουργικού προϊόντος και την διατήρηση ενός περιβάλλοντος υψηλής εμπιστοσύνης για τη βελτίωση της συνεργασίας μεταξύ όλων των εμπλεκομένων. Παρότι η Kanban είναι και αυτή μια ευέλικτη διαδικασία, υπάρχουν αρκετές διαφορές ανάμεσα σε αυτήν και τις υπόλοιπες διαδικασίες. Πρώτον, η Kanban δεν χρησιμοποιεί την πρακτική των επαναλήψεων (επίσης γνωστή ως «sprint» ή «κουτιά χρόνου»), αλλά τάσσεται υπέρ της συνεχούς ροής των εργασιών. Αυτό με τη σειρά του αποσυνδέει το ρυθμό εργασίας από διάφορες κοινές δραστηριότητες ή εκδηλώσεις όπως η ιεράρχηση της εργασίας, η ανάπτυξη και η παράδοση. Για παράδειγμα, μπορεί να επιλέξετε να γίνεται μια συνεδρίαση για τον καθορισμό των προτεραιοτήτων κάθε Δευτέρα πρωί, μια δοκιμαστική έκδοση για εσωτερική χρήση κάθε δεύτερη Τετάρτη το απόγευμα, μια αναδρομική συνάντηση όποτε κρίνεται αναγκαίο, και έκδοση λειτουργικών τμημάτων του προϊόντος την πρώτη εργάσιμη ημέρα κάθε δεύτερου μήνα. Δεύτερον, οι ομάδες Kanban αντλούν εργασίες στο σύστημα, τοποθετώντας τις σε διαφορετικές κατηγορίες. Το γεγονός αυτό μειώνει κάποιες από τις εγγενείς γραφειοκρατικές διαδικασίες που συναντώνται σε άλλες ευέλικτες διαδικασίες, όπως για παράδειγμα η Scrum, επειδή απαλλάσσεται από την έννοια της εκτίμησης των εργασιών για τις περισσότερες κατηγορίες, ενώ την ίδια στιγμή επικεντρώνεται στη χρήση των διαθέσιμων πόρων, με στόχο τη συνεχή παράδοση. Αυτή η συνεχής ροή της παράδοσης, ενισχύει την προβλεψιμότητα, μειώνοντας τον επιχειρηματικό κίνδυνο που συνδέεται με την προσπάθεια, η οποία με τη σειρά της οδηγεί σε μεγαλύτερη εμπιστοσύνη στην ομάδα. Τρίτον, ο συνδυασμός των ρητών πολιτικών της διαδικασίας, η διαφάνεια και η οπτικοποίηση δίνει τη δυνατότητα στα μέλη της ομάδας να κατανοήσουν τη συνολική διαδικασία, να πάρουν τις δικές τους αποφάσεις, και να διαχειριστούν τον κίνδυνο. Αυτό έχει ως αποτέλεσμα, οι ομάδες Kanban να μην είναι μόνο αυτόοργανωμένες αλλά επίσης και αυτό-επιταχυνόμενες.

49 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 49 Ένα σημαντικό πλεονέκτημα της Kanban είναι ότι παρέχει απλούς μηχανισμούς για τις ομάδες, ξεκαθαρίζοντας τα θέματα που επηρεάζουν την απόδοσή τους και τις παρακινεί να επικεντρωθούν στην αντιμετώπιση του πραγματικού προβλήματος, και όχι στα συμπτώματά του. Επίσης, εκθέτει στην ομάδα τα στοιχεία εργασίας τα οποία παρουσιάζουν πρόβλημα, με σαφή τρόπο και επειδή τα στοιχεία αυτά δεν είναι εύκολο να αγνοηθούν, τα μέλη της ομάδας που έχουν ελεύθερο χρόνο παρακινούνται να αντιμετωπίσουν ένα πρόβλημα γρήγορα για να αφαιρεθεί η κάρτα από τον πίνακα. Επιπλέον, η Kanban παρέχει διαφάνεια τόσο για την εργασία και τη διαδικασία, δείχνοντας πώς μια εργασία έχει περάσει από τη μία ομάδα στην άλλη, βελτιώνοντας έτσι την κατανόηση και την ομαδική εργασία. Αυτό βοηθά τις ομάδες να οργανωθούν πιο αποτελεσματικά και παρέχει στα ανώτερα στελέχη την απαραίτητη οπτική πληροφορία που θα τους βοηθήσει να διαχειριστούν πιο αποτελεσματικά το έργο. Τέλος, ο συνδυασμός της βελτιωμένης ροής και της βελτιωμένης ποιότητας έχει ως αποτέλεσμα τη μείωση του χρόνου αντίδρασης της ομάδας. Αυτό με τη σειρά του οδηγεί στην βελτίωση της απόδοσης και της προβλεψιμότητας. Η βελτιωμένη απόδοση και προβλεψιμότητα δίνουν τη δυνατότητα στους διαχειριστές να αντιμετωπίσουν τη διαδικασία σαν μια επιχείρηση και όχι σαν ένα αδιαφανές τέλμα από ανεκπλήρωτες υποσχέσεις. Βασικές Αξίες της Διαδικασίας Kanban Στο βιβλίο Kanban - Successful Evolutionary Change for your Technology Business [Anderson, 2010], περιγράφονται τρεις θεμελιώδεις αρχές για την υιοθέτηση τη μεθόδου και πέντε βασικές πρακτικές που συναντώνται σε πετυχημένα έργα στα οποία χρησιμοποιήθηκε η Kanban. Για μια επιτυχημένη μεταφορά στη ευέλικτη διαδικασία Kanban o Anderson προτείνει πρώτα την υιοθέτηση των τριών θεμελιωδών αξιών και έπειτα την χρήση των πέντε βασικών αρχών. Οι τρείς θεμελιώδεις αξίες, για την υιοθέτηση της μεθόδου είναι [Anderson, 2010]:

50 50 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 1) Ξεκινήστε με ό,τι γνωρίζετε Η διαδικασία Kanban δεν ζητάει από μια ομάδα να αλλάξει τη διαδικασία της ριζικά αλλά βασίζεται στην ιδέα ότι μπορεί να εξελίξει την τρέχουσα διαδικασία. Δεν υπάρχει η έννοια της σαρωτικής, μηχανικής αλλαγής σε μια νέα διαδικασία ή στυλ εργασίας. Όπως επίσης δεν υπάρχουν ορισμοί όπως Η διαδικασία ανάπτυξης λογισμικού Kanban ή Διαδικασία Διαχείρισης Έργων Kanban. 2) Συμφωνήστε να ακολουθήσετε την αυξητική, εξελικτική αλλαγή Η ομάδα θα πρέπει να καταλήξει στην παραδοχή ότι οι τρέχουσες συνθήκες της εγγυώνται μια ομαλή, εξελικτική προσέγγιση για την βελτίωση της διαδικασίας ανάπτυξης. Ίσως μια πρόσφατη σαρωτική αλλαγή να απέτυχε λόγω της αντίστασης από τα μέλη της ομάδας, ή ίσως η πολιτική του οργανισμού να μην υποστηρίζει τους διαχειριστές ώστε να προτείνουν και να εφαρμόσουν σαρωτικές αλλαγές. Γενικά, αν δεν υπάρχει συμφωνία ότι μια αργή, ομαλή, εξελικτική, σταδιακή προσέγγιση είναι ο σωστός δρόμος, τότε δεν υπάρχει και το κατάλληλο περιβάλλον ή η κατάλληλη υποστήριξη της διαχείρισης για μια πρωτοβουλία χρησιμοποίησης της Kanban. 3) Σεβαστείτε την τρέχουσα διαδικασία, τους υπάρχοντες ρόλους, τις ευθύνες και τους τίτλους θέσεων εργασίας Είναι πιθανό πως ο τρόπος με τον οποίο ήδη οργανώνεται η ομάδα, να έχει κάποια στοιχεία που λειτουργούν αποδεκτά και αξίζει να διατηρηθούν. Θα πρέπει επίσης να επιδιωχθεί η αποβολή του φόβου, προκειμένου να διευκολυνθεί η μελλοντική αλλαγή. Η συμφωνία για σεβασμό των ρόλων, των ευθυνών καθώς και των τίτλων εργασίας, που ισχύουν ήδη, θα εξαλείψει τους αρχικούς φόβους και θα δώσει τη δυνατότητα η πρωτοβουλία Kanban να έχει ευρύτερη υποστήριξη. Ίσως παρουσιάζοντας την Kanban ως μια εναλλακτική, σε μια πιο σαρωτική προσέγγιση που θα μπορούσε να οδηγήσει σε αλλαγές στους τίτλους, τους ρόλους, τις ευθύνες και ίσως και τη μαζική αφαίρεση ορισμένων θέσεων θα βοηθήσει τα άτομα να συνειδητοποιήσουν τα οφέλη της.

51 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 51 Αρχές της Διαδικασίας Kanban Οι πέντε βασικές αρχές, για την υιοθέτηση της μεθόδου είναι [David J. Anderson, 2010]: 1) Οπτικοποιήστε την ροή εργασίας Οι ομάδες Kanban θα πρέπει να χρησιμοποιούν έναν πίνακα για να οπτικοποιήσουν τη ροή των εργασιών τους. Συνήθως ο πίνακας αυτός είναι φυσικός είτε σε ηλεκτρονική μορφή, και θα εμφανίζει που βρίσκεται ένα κομμάτι της εργασίας κατά τη διάρκεια της διαδικασίας. Ο πίνακας συνήθως οργανώνεται σε στήλες, κάθε μία από τις οποίες αντιπροσωπεύει ένα στάδιο στη διαδικασία, και προαιρετικά σειρές οι οποίες διαχωρίζουν εργασίες που ανήκουν σε διαφορετικά προϊόντα. Κάθε κάρτα Kanban θα πρέπει να έχει επαρκείς πληροφορίες, όπως το όνομα, την ταυτότητα του αντικειμένου εργασίας και την ημερομηνία λήξης (αν υπάρχει), με σκοπό τη διαχείριση των εργασιών από την ομάδα χωρίς την καθοδήγηση του διευθυντή. Ο στόχος είναι να οπτικοποιηθούν αρκετές πληροφορίες για να καταστεί η διαδικασία αυτό-οργανωτική και αυτό-επιταχυνόμενη στο επίπεδο της ομάδας. Το διοικητικό συμβούλιο ενημερώνεται άμεσα από τα μέλη της ομάδας κατά τη διάρκεια της ημέρας, όσο προχωρούν οι εργασίες, και αντιμετωπίζει τα θέματα που προκύπτουν κατά τη διάρκεια της καθημερινής συνεδρίασης. 2) Περιορίστε την εργασία σε εξέλιξη (WIP) Ο περιορισμός των εργασιών σε εξέλιξη μειώνει τον μέσο χρόνο παράδοσης, ο οποίος με τη σειρά του βελτιώνει την ποιότητα του παραγόμενου έργου και ως εκ τούτου αυξάνει τη συνολική παραγωγικότητα της ομάδας. Η μείωση του χρόνου

52 52 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού παράδοσης αυξάνει επίσης την ικανότητα της ομάδας να παραδίδει συχνά λειτουργικά τμήματα του έργου, κάτι που βοηθά στην οικοδόμηση εμπιστοσύνης ανάμεσα στα εμπλεκόμενα μέλη. Για να περιοριστεί η εργασία σε εξέλιξη πρέπει να εντοπιστεί πού βρίσκονται τα ζητήματα που εμποδίζουν τη διαδικασία, και στη συνέχεια να αντιμετωπιστούν γρήγορα. Επειδή κάθε ομάδα ανάπτυξης είναι διαφορετική, τα όρια WIP δεν μπορούν να είναι ποτέ σταθερά, αλλά θα πρέπει να δοκιμάζονται αρχικά και στη συνέχεια να προσαρμοστούν, με βάση τα εμπειρικά αποτελέσματα από τον πειραματισμό. 3) Μετρήστε και διαχειριστείτε τη ροή εργασιών Οι ομάδες Kanban παράγουν πολύτιμες λύσεις για τις επιχειρήσεις σε μια σταθερή ροή. Μια πτυχή για να επιτευχθεί αυτό, είναι ότι θα πρέπει να κατανοήσουν το προφίλ της ζήτησης του οργανισμού, έτσι ώστε ο σχεδιασμός της διαδικασίας Kanban να μπορεί να αντανακλά τις διαφορετικές απαιτήσεις για διαφορετικούς τύπους εργασίας. Για παράδειγμα, υπάρχουν εποχιακές διαφορές στον τρόπο με τον οποίο φθάνουν αιτήσεις για νέα χαρακτηριστικά; Μήπως θα πρέπει να υποστηριχθούν οι θεσμοθετημένες απαιτήσεις; Είναι η ομάδα υπεύθυνη για την αντιμετώπιση των προβλημάτων της παραγωγής, μερικά από τα οποία μπορεί να είναι άμεσα; Μήπως θα πρέπει να υποστηριχθούν οι απαιτήσεις με σταθερές ημερομηνίες παράδοσης; Χρειάζεται να υποστηριχθούν απαιτήσεις που είναι πολύ υψηλής προτεραιότητας; Το συμπέρασμα είναι ότι ένα σύστημα Kanban μπορεί να χρειαστεί να υποστηρίξει αρκετές κατηγορίες υπηρεσιών για να είναι αποτελεσματικό.

53 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 53 4) Οι πολιτικές της διαδικασίας πρέπει να είναι ρητές Μια ομάδα Kanban καθορίζει τις πολιτικές που αφορούν τις εργασίες σε εξέλιξη, την ιεράρχηση (αναπλήρωση της ουράς εργασίας), τον ρυθμό παράδοσης, το χρόνο παράδοσης για τις κατηγορίες των υπηρεσιών, και το πώς τα ζητήματα θα πρέπει να αντιμετωπιστούν / κλιμακωθούν. Οι πολιτικές αυτές πρέπει να είναι ρητές και να αντικατοπτρίζουν την κατάσταση που αντιμετωπίζει η ομάδα. Επίσης πρέπει να είναι γνωστές τόσο στην ομάδα όσο και στους εμπλεκόμενους φορείς, και αρκετά εύπλαστες, έτσι ώστε να μπορούν να εξελιχθούν με την πάροδο του χρόνου. 5) Χρησιμοποιήστε μοντελοποιημένες διαδικασίες για την αναγνώριση ευκαιριών για βελτίωση Οι ομάδες Kanban θα πρέπει να πειραματιστούν και στη συνέχεια να βελτιώσουν τη διαδικασία που θα ακολουθηθεί. Μια κοινή τεχνική που διαδόθηκε στα βιβλία, σχετικά με την λιτή ανάπτυξη λογισμικού, που γράφτηκαν από τους Mary και Thomas Poppendieck, αποκαλείται «ρεύμα χαρτογραφημένης αξίας», μια τεχνική μοντελοποίησης των διαδικασιών ανάπτυξης, η οποία εστιάζει στον εντοπισμό και των δραστηριοτήτων με προστιθέμενη αξία και τον εντοπισμό του χρόνου αναμονής μεταξύ των εν λόγω δραστηριοτήτων. Αυτή η πολύ απλή τεχνική παρέχει τη δυνατότητα να εντοπιστούν οι προβληματικές πτυχές της διαδικασίας και ως εκ τούτου να τεθούν ως υποψήφιες για βελτίωση. Εκτός από τις πέντε αρχές, ο David J. Anderson περιγράφει αρκετές πολύ ενδιαφέρουσες φιλοσοφίες που είναι σημαντικές για την πραγματική κατανόηση της μεθόδου Kanban. Πρώτον, ο κύριος λόγος για να υιοθετήσει κανείς τη διαδικασία Kanban, είναι η βελτίωση των υφιστάμενων διαδικασιών παράδοσης λογισμικού. Στόχος βέβαια δεν είναι να αναμορφωθεί ολοκληρωτικά η διαδικασία, αλλά αντίθετα να τεθεί ως βάση το υφιστάμενο περιβάλλον, το οποίο ήδη

54 54 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού λειτουργεί (αν και όχι τέλεια) και στη συνέχεια να βελτιωθεί. Σε γενικές γραμμές υπάρχει η παραδοχή πως είναι καλύτερα να βελτιστοποιηθεί μια υπάρχουσα διαδικασία επειδή είναι ευκολότερο, ταχύτερο, και θα προκαλέσει λιγότερη αντίσταση σε σχέση με την εισαγωγή μιας «ριζοσπαστικής» αλλαγής. Δεύτερον, οι διαδικασίες πρέπει να προσαρμοστούν για κάθε συγκεκριμένη περίπτωση, επειδή οι άνθρωποι είναι μοναδικοί, οι ομάδες είναι μοναδικές, οι οργανώσεις είναι μοναδικές, και η κατάσταση στην οποία βρίσκεται μια ομάδα είναι μοναδική. Τρίτον, οι συχνές εκδόσεις παρέχουν την απαραίτητη ορατότητα στην πρόοδο της ομάδας και έτσι χτίζεται εμπιστοσύνη ανάμεσα στα ενδιαφερόμενα μέρη. Τέταρτον, η Kanban ζητά από τις επιχειρήσεις να συμμετάσχουν στην συνεργασία με τις ομάδες ανάπτυξης, με στόχο την ενεργή συμμετοχή των ενδιαφερόμενων φορέων, και όχι μόνο με ένα αντιπρόσωπο των ενδιαφερόμενων φορέων, όπως για παράδειγμα έναν αναλυτή επιχειρήσεων. Πέμπτον, οι ομάδες Kanban στοχεύουν σε μια μακροπρόθεσμη σχέση παροχής υπηρεσιών με την επιχείρηση. Μια ομάδα Kanban δεν δημιουργείται για ένα συγκεκριμένο έργο και στη συνέχεια διαλύεται, αλλά αντίθετα σκοπός είναι να δημιουργηθεί μια μακροχρόνια σχέση.. Έκτον, το αληθινό μέτρο της επιτυχίας είναι η επιχειρηματική αξία του προϊόντος που παραδίδεται και όχι απλώς η λειτουργικότητα του λογισμικού. Τα Βήματα της Διαδικασίας Kanban Στην Kanban όλη η ροή εργασιών βρίσκεται στον ίδιο πίνακα (Σχήμα 14). Αντίθετα στη Scrum ο πίνακας περιέχει τις εργασίες πού η ομάδα έχει δεσμευτεί να ολοκληρώσει.

55 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 55 Σχήμα 14: Παράδειγμα Πίνακα Kanban (Προέλευση εικόνας: [Kniberg, 2009]) Στο παραπάνω παράδειγμα στη στήλη Backlog παρουσιάζονται οι απαιτήσεις, χωρίς συγκεκριμένη σειρά. Στη στήλη Selected βρίσκονται οι εργασίες υψηλής προτεραιότητας, έχοντας ως όριο τον αριθμό 2. Οπότε, μπορούν να υπάρχουν μόνο δύο αντικείμενα υψηλής προτεραιότητας ανά πάσα στιγμή. Όποτε η ομάδα αποφασίζει να υλοποιήσει ένα νέο αντικείμενο, θα επιλέξει από τη στήλη Selected, την πρώτη σε σειρά εργασία. Ο product owner (εφόσον έχει οριστεί τέτοιος ρόλος) μπορεί να κάνει αλλαγές στις στήλες Backlog και Selected οποιαδήποτε στιγμή επιθυμεί, αλλά δεν μπορεί να επεξεργαστεί τις υπόλοιπες στήλες. Η στήλη Develop χωρίζεται σε δυο στήλες Ongoing και Done και περιέχει τις εργασίες που βρίσκονται σε εξέλιξη. Το όριο 3 στη στήλη Develop απευθύνεται στο σύνολο των εργασιών που είναι δυνατό να περιέχονται και στις δυο υπό-στήλες ταυτόχρονα. Συχενής ροή ή «άψογη ροή» Η συνεχής ή «άψογη» ροή είναι ένα ιδανικό σενάριο, όπου ένα αντικείμενο περνά από όλες τις καταστάσεις χωρίς καθυστερήσεις. Αυτό σημαίνει πως οποιαδήποτε

56 56 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού στιγμή, κάποιο μέλος της ομάδας εργάζεται για την ολοκλήρωση του αντικειμένου αυτού. «Η ιδανική διαδικασία διαχείρισης εργασιών θα πρέπει πάντα να παρέχει στην ομάδα ανάπτυξης το καλύτερο αντικείμενο για να εργαστεί στη συνέχεια, τίποτα παραπάνω τίποτα λιγότερο.» [Cory Ladas] Παράδειγμα χρήσης ενός πίνακα Kanban Παρακάτω παρατίθεται ένα αναλυτικό παράδειγμα χρήσης της Kanban και παρουσιάζεται η κίνηση που κάνουν τα αντικείμενα καθώς αλλάζουν κατάσταση (στήλη) στη ροή εργασιών. Να σημειωθεί ότι οι εικόνες που χρησιμοποιούνται στο παραπάνω παράδειγμα προέρχονται από το βιβλίο Kanban vs Scrum How to make the best of both [Kniberg, 2009]. Στην αρχή της διαδικασίας όλα τα αντικείμενα προς ανάπτυξη βρίσκονται στη στήλη Backlog.

57 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 57 Στη συνέχεια οι εργασίες Α και Β μετακινούνται στη στήλη Selected, γιατί αυτές έχουν την υψηλότερη προτεραιότητα. Δυο μέλη της ομάδας ανάπτυξης αναλαμβάνουν να υλοποιήσουν το αντικείμενο Α και δυο μέλη αναλαμβάνουν να υλοποιήσουν το αντικείμενο Β. Έτσι οι εργασίες αυτές περνου στη στήλη Ongoing. Τις δύο θέσεις που έμειναν κενές στη στήλη Selected έρχονται να καλύψουν τα αντικείμενα C και D.

58 58 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Μετά την ολοκλήρωση της εργασίας Α, αυτή περνάει στη στήλη Done. Ο product owner θέλει να ξεκινήσει η ανάπτυξη και των αντικειμένων J,K και L αλλά η στήλη Selected είναι κατηλημένη και δεν υπάρχουν κενές θέσεις. Για να ελευθερωθούν κενές θέσεις θα πρέπει η εργασία Α να μεταφερθεί στη στήλη Deploy η εργασία C να μεταφερθεί στη στήλη Ongoing. Στην περίπτωση που ένα αντικείμενο δεν μπορεί να μεταβεί από μια κατάσταση, τα μέλη της ομάδας που δεν έχουν κάποια εργασία να εκτελέσουν, βοηθούν στην επίλυση των προβλημάτων που έχουν προκύψει. Η διαδικασία θα πρέπει να συνεχιστεί μέχρι όλα τα αντικείμενα της στήλης Backlog να περάσουν από όλες τις καταστάσεις και να καταλήξουν στην στήλη Live. Όταν αυτό πραγματοποιηθεί, τότε το έργο θεωρείται ολοκληρωμένο. 9. Σύγκριση μεταξύ Scrum και Kanban Οι διαδικασίες Scrum και Kanban, που παρουσιάστηκαν αναλυτικά προηγουμένως, είναι οδηγοί που περιλαμβάνουν ένα σύνολο πρακτικών για να υποστηρίξουν τις ομάδες ανάπτυξης λογισμικού να εργάζονται πιο αποτελεσματικά, υποδεικνύοντας τους, έως ένα βαθμό, τι να κάνουν κατά την ανάπτυξη ενός συστήματος λογισμικού.

59 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 59 Όπως όμως όλες οι λύσεις, έτσι και οι διαδικασίες αυτές, δεν είναι τέλειες ούτε ολοκληρωμένες. Δεν υποδεικνύουν με ακρίβεια καθετί που πρέπει να γίνει, αλλά καθοδηγούν την ομάδα έργου παρέχοντάς της ορισμούς και οδηγίες. Για παράδειγμα, η Scrum απαιτεί την επανάληψη της διαδικασίας με ορισμένη χρονική διάρκεια και την ύπαρξη δια τμηματικών ομάδων, ενώ η Kanban απαιτεί τη χρήση οπτικών πινάκων και τον περιορισμό των εργασιών ανά στήλη. Παραδόξως, η αξία ενός εργαλείου είναι το γεγονός ότι περιορίζει τις διαθέσιμες επιλογές. Για το λόγο αυτό, ένα εργαλείο, το οποίο επιτρέπει να γίνονται τα πάντα (Do whatever), δεν είναι και πολύ χρήσιμο. Η χρήση των σωστών εργαλείων μπορεί να βοηθήσει μια ομάδα να πετύχει, χωρίς βέβαια να εγγυάται αυτομάτως την επιτυχία. Πολλές φορές είναι δύσκολο να διακριθεί πότε για μια επιτυχία/αποτυχία ευθύνεται το συνολικό έργο ή το εργαλείο που χρησιμοποιήθηκε. Μπορούμε να συγκρίνουμε διάφορες διαδικασίες (εργαλεία), εξετάζοντας πόσους κανόνες παρέχουν. Μια διαδικασία μπορεί να χαρακτηριστεί περιοριστική όταν παρέχει περισσότερους κανόνες και προσαρμοστική όταν οι κανόνες είναι λιγότεροι. Οι ευέλικτες διαδικασίες, όπως έχει αναφερθεί, αποκαλούνται ελαφριές διαδικασίες, ειδικά επειδή είναι λιγότερο περιοριστικές σε σχέση με τις παραδοσιακές διαδικασίες. Επειδή η επιτυχία ενός εργαλείου δεν είναι εγγυημένη, θα πρέπει η ομάδες ανάπτυξης να μην περιορίζονται στη χρήση ενός και μόνο εργαλείου. Αντίθετα, θα πρέπει να ενθαρρύνονται να συνδυάζουν τις καλές πρακτικές που προσφέρονται από τα διάφορα εργαλεία. Ένα παράδειγμα είναι η χρήση, από αρκετές ομάδες Kanban, καθημερινών συνεδριάσεων - μια πρακτική που χρησιμοποιείται στη Scrum, ενώ κάποιες ομάδες Scrum, περιορίζουν τον αριθμό τον αντικειμένων στις στήλες τους πρακτική της Kanban. Οπότε μια ομάδα ανάπτυξης θα πρέπει να χρησιμοποιεί τα εργαλεία που διευκολύνουν τον δικό της τρόπο εργασίας.

60 60 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Τέλος, θα πρέπει να επισημανθεί πως αν κατά το συνδυασμό διαφόρων εργαλείων, αφαιρεθεί κάποιο κύριο χαρακτηριστικό μιας μεθόδου (π.χ. oι ορισμένου χρόνου επαναλήψεις στη Scrum), τότε η διαδικασία αυτή θα πρέπει να αναφέρεται με άλλη ονομασία (π.χ. ως Scrum inspired ή κάτι παρόμοιο) και όχι όπως η αρχική διαδικασία. Ανασκόπηση Διαφορών και Ομοιοτήτων Παρακάτω παρουσιάζεται μια σύντομη ανασκόπηση των διαφορών και των ομοιοτήτων μεταξύ των δύο μεθόδων. Εκτενέστερη ανάλυση για τις βασικές ομοιότητες και διαφορές θα γίνει στη συνέχεια. α) Ομοιότητες Είναι λιτές (lean) και ευέλικτες (agile) Και οι δύο χρησιμοποιούν pull scheduling Περιορίζουν τις εργασίες σε εξέλιξη Βασίζονται στη διαφάνεια, με στόχο τη βελτίωση των διαδικασιών Εστιάζουν στη γρήγορη και συχνή παράδοση λογισμικού προς έκδοση Λειτουργούν με βάση ομάδες που αυτό-οργανώνονται Προϋποθέτουν τον καταμερισμό εργασιών Και στις δύο, το πλάνο βελτιώνεται διαρκώς βάσει εμπειρικών δεδομένων (velocity/lead time) Και οι δύο επιτρέπουν την εργασία σε πολλαπλά προϊόντα ταυτόχρονα β) Διαφορές Scrum Kanban

61 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 61 Απαραίτητες οι επαναλήψεις σε ίσα και ορισμένα χρονικά διαστήματα. Η ομάδα δεσμεύεται ότι θα εκτελέσει ένα συγκεκριμένο φόρτο εργασίας σε κάθε επανάληψη. Χρησιμοποιεί την ταχύτητα ανάπτυξης (velocity) ως προεπιλεγμένη μονάδα μέτρησης για τον προγραμματισμό και τη βελτίωση της διαδικασίας. Οι δια τμηματικές ομάδες είναι απαραίτητες. Οι επαναλήψεις σε ίσα και ορισμένα χρονικά διαστήματα είναι προαιρετικές. Μπορεί να οριστεί διαφορετικός ρυθμός για τον προγραμματισμό, την έκδοση και τη βελτίωση της διαδικασίας. Η διαδικασία μπορεί να οδηγείται από γεγονότα αντί από χρονικές περιόδους. Η δέσμευση είναι προαιρετική. Χρησιμοποιεί τον ρυθμό απόκρισης (lead time) ως προεπιλεγμένη μονάδα μέτρησης για τον προγραμματισμό και τη βελτίωση της διαδικασίας. Οι δια τμηματικές ομάδες είναι προαιρετικές, αλλά επιτρέπονται οι εξειδικευμένες ομάδες. Οι εργασίες πρέπει να διασπώνται σε μικρότερα τμήματα, με κύριο στόχο την ολοκλήρωσή τους σε μία επανάληψη (sprint). Απαραίτητο το διάγραμμα Burn down. Δεν υπάρχουν περιορισμοί στο μέγεθος των εργασιών. Δεν απαιτούνται διαγράμματα συγκεκριμένου τύπου. Οι εργασίες σε εξέλιξη περιορίζονται έμμεσα (ανά sprint). Οι υπό ανάπτυξη εργασίες περιορίζονται άμεσα (ανά κατάσταση/στήλη).

62 62 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Οι εκτιμήσεις είναι απαραίτητες. Οι εκτιμήσεις είναι προαιρετικές. Δεν επιτρέπεται η προσθήκη νέων εργασιών κατά τη διάρκεια μιας επανάληψης. Επιτρέπεται η προσθήκη νέων εργασιών. Ένα Sprint Backlog αντιστοιχεί σε μία συγκεκριμένη ομάδα. Προϋποθέτει τρεις ρόλους (PO/SM/Team) Ένας πίνακας Scrum επαναφέρεται μεταξύ δύο επαναλήψεων. Απαιτεί την ιεράρχηση των απαιτήσεων του προϊόντος (product backlog). Ένας πίνακας Kanban μπορεί να αντιστοιχεί σε πολλαπλές ομάδες ή άτομα. Δεν υπάρχουν προορισμένοι ρόλοι. Ένας πίνακας Kanban είναι μόνιμος. Η ιεράρχηση είναι προαιρετική. Βασικές Ομοιότητες α) Είναι λιτές (lean) και ευέλικτες (agile) Και οι δύο διαδικασίες είναι σύμφωνες με τις αρχές και τις αξίες του μανιφέστο των ευέλικτων διαδικασιών και του Lean Thinking. Για παράδειγμα: Η Scrum και η Kanban είναι συστήματα pull scheduling, το οποίο παραπέμπει σε μία από τις αρχές του Lean, το JIT(Just in time) inventory management. Αυτό σημαίνει ότι η ομάδα ανάπτυξης επιλέγει πότε και πόση εργασία θα διαθέσει, αντλεί φόρτο εργασίας όταν είναι έτοιμη, χωρίς να περιμένει να τις την αναθέσουν. Η Scrum και η Kanban βασίζονται στη συνεχή και εμπειρική βελτίωση της

63 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 63 διαδικασίας, κάτι που παραπέμπει σε άλλη μια αρχή του Lean. Η Scrum και η Kanban δίνουν έμφαση στην έγκαιρη ανταπόκριση στις αλλαγές και όχι στη τήρηση προσυμφωνημένων χρονοδιαγραμμάτων. Μια από τις τέσσερις βασικές αρχές του Agile Manifesto. Ορισμένοι πιστεύουν ότι η διαδικασία Scrum δεν είναι αρκετά Lean επειδή προϋποθέτει τον καταμερισμό των εργασιών σε επαναλήψεις ορισμένου χρόνου. Όμως αυτό εξαρτάται από τη διάρκεια της επανάληψης και από το ποιο είναι το μέτρο σύγκρισης. Αν, δηλαδή, συγκρίνουμε τη Scrum με μια πιο παραδοσιακή διαδικασία όπου η ενσωμάτωση στο προϊόν και η έκδοση συμβαίνουν 2-4 φορές το χρόνο, μία ομάδα Scrum που παραδίδει λειτουργικό λογισμικό κάθε δυο εβδομάδες είναι αρκετά lean. β) Βελτιώνονται διαρκώς βάσει εμπειρικών δεδομένων Και οι δύο διαδικασίες είναι εμπειρικές διαδικασίες, πράγμα που σημαίνει ότι πρέπει κανείς να πειραματιστεί με αυτές, να εξετάσει τα αποτελέσματά τους και να τις παραμετροποιήσει κατάλληλα ώστε να ανταποκρίνονται στο δικό του περιβάλλον. Για την ακρίβεια, οφείλει να πειραματιστεί κανείς με τη διαδικασία. Καμία από τις δύο διαδικασίες δεν παρέχει τις απαντήσεις σε όλα τα προβλήματα, αλλά προτείνουν μια σειρά βασικών περιορισμών με σκοπό την βελτίωση των διαδικασιών στο εκάστοτε περιβάλλον. Ας υποθέσουμε ότι μειώνουμε το όριο των επιτρεπόμενων εργασιών υπό ανάπτυξη, βασισμένοι στην υπόθεση ότι αυτό θα βελτιώσει την διαδικασία ανάπτυξης. Παρατηρούμε τότε, πως πράγματα όπως η ποιότητα, η προβλεψιμότητα κ.α., αλλάζουν. Από τα αποτελέσματα καταλήγουμε σε συμπεράσματα και αλλάζουμε κάποιες παραμέτρους, με κύριο στόχο τη συνεχή βελτίωση της διαδικασίας. Το πιο κρίσιμο σημείο κατά τη βελτίωση της διαδικασίας είναι ο κύκλος ανατροφοδότησης (feedback loop). Αλλαγή -> παρατηρήσεις -> συμπεράσματα -> αλλαγή. Σε γενικές γραμμές, θέλουμε ο κύκλος αυτός να είναι όσο πιο σύντομος γίνεται ώστε να επιτευχθεί γρήγορη προσαρμογή της διαδικασίας.

64 64 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Στη Scrum ο βασικός κύκλος ανατροφοδότησης είναι η επανάληψη (sprint). Υπάρχουν βέβαια περισσότεροι κύκλοι, ειδικά αν συνδυαστεί και με άλλες ευέλικτες διαδικασίες, όπως ο ακραίος προγραμματισμός. Εάν ο συνδυασμός γίνει σωστά, καταλήγουμε με μια πληθώρα χρήσιμων κύκλων ανατροφοδότησης. Το ίδιο βέβαια ισχύει και αν ο συνδυασμός γίνει με την Kanban. γ) Επιτρέπουν την εργασία σε πολλαπλά προϊόντα ταυτόχρονα Στη Scrum ο όρος Product Backlog είναι μάλλον ατυχής καθώς υπονοεί ότι όλες οι εργασίες ανήκουν στο ίδιο προϊόν. Παρακάτω μπορούμε να δούμε δύο προϊόντα, πράσινο (green) και κίτρινο (yellow), το καθένα με το δικό του Product Backlog και τη δική του ομάδα ανάπτυξης (Σχήμα 15): Σχήμα 15: Scrum Product Backlogs για δύο διαφορετικά προϊόντα (Προέλευση εικόνας: [Kniberg, 2009]) Τι γίνεται όμως αν έχουμε μια μόνο ομάδα; Στην περίπτωση αυτή θα πρέπει να φανταστούμε το Product Backlog περισσότερο ως Team Backlog. Εκεί θα περιέχονται, κατά προτεραιότητα, οι εργασίες για τις επερχόμενες επαναλήψεις που αντιστοιχούν σε μία συγκεκριμένη ομάδα. Αν όμως η ομάδα αυτή εργάζεται ταυτόχρονα σε περισσότερα από ένα προϊόντα, τότε οι εργασίες για όλα τα προϊόντα αυτά θα περιέχονται σε μία λίστα. Κάτι που αναγκάζει την ομάδα να θέσει προτεραιότητα ανάμεσα στα προϊόντα, πράγμα που είναι χρήσιμο σε ορισμένες

65 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 65 περιπτώσεις. Υπάρχουν αρκετοί τρόποι για να το εφαρμόσει κανείς. Μια από τις στρατηγικές που χρησιμοποιούνται για να δοθεί η προτεραιότητα αυτή είναι η ομάδα να εστιάσει σε ένα μόνο προϊόν κατά τη διάρκεια μιας επανάληψης. Ενώ μία άλλη προσέγγιση προτείνει η ομάδα να εργάζεται ταυτόχρονα και για τα δυο προϊόντα. Το ίδιο ισχύει και για την Kanban. Εργασίες που αφορούν διαφορετικά προϊόντα μπορούν να παρουσιαστούν στον ίδιο πίνακα. Για το διαχωρισμό τους γίνεται να χρησιμοποιηθούν κάρτες διαφορετικού χρώματος είτε οριζόντιες χρωματιστές διαχωριστικές περιοχές (Σχήμα 16). Σχήμα 16: Kanban Product Backlogs για δύο διαφορετικά προϊόντα (Προέλευση εικόνας: [Kniberg, 2009]) Βασικές Διαφορές α) Η Scrum απαιτεί οι επαναλήψεις να γίνονται σε ίσα και ορισμένα χρονικά διαστήματα Η Scrum βασίζεται σε χρονικά ορισμένες επαναλήψεις. Η διάρκεια της επανάληψης διαφέρει ανά περίπτωση, αλλά η βασική ιδέα είναι να παραμένει σταθερή για κάποιο διάστημα, ώστε να δοθεί η δυνατότητα στην ομάδα ανάπτυξης να σταθεροποιήσει το ρυθμό με τον οποίο εργάζεται.

66 66 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Κατά τη διάρκεια μιας επανάληψης στη διαδικασία Scrum, συνδυάζονται τρεις διαφορετικές δραστηριότητες: προγραμματισμός, βελτίωση της διαδικασίας και έκδοση ενός λειτουργικού τμήματος του προϊόντος. Στην Kanban δεν υπάρχουν προκαθορισμένες χρονικές επαναλήψεις, αλλά η ομάδα μπορεί να επιλέξει πότε θα προγραμματίσει, πότε θα κάνει βελτίωση της διαδικασίας και πότε θα εκδώσει το προϊόν ή επιμέρους τμήματά του. Οι δραστηριότητες αυτές μπορεί να επαναλαμβάνονται σε συχνή βάση π.χ. έκδοση κάθε Παρασκευή ή κατά βούληση π.χ. έκδοση όταν υπάρχει διαθέσιμο λειτουργικό μέρος του προϊόντος. β) Η Scrum θεωρεί απαραίτητη την εκτίμηση της ταχύτητας της ομάδας (velocity) Οι ομάδες Scrum πρέπει να εκτιμούν τον όγκο εργασίας που απαιτείται για να εκπονηθεί κάθε εργασία που αναλαμβάνουν να υλοποιήσουν. Προσθέτοντας τα μεγέθη των εργασιών που ολοκληρώνονται στο τέλος κάθε επανάληψης, έχουμε ως αποτέλεσμα την ταχύτητα της ομάδας (velocity). H velocity είναι μια μονάδα μέτρησης που δηλώνει την ποσότητα της εργασίας που μπορεί να εκπονήσει η ομάδα μέσα σε μια επανάληψη. Παρακάτω μπορούμε να δούμε το παράδειγμα μιας ομάδας με μέση ταχύτητα 8 (Σχήμα 17):

67 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 67 Σχήμα 17: Παράδειγμα υπολογισμού της Velocity (Προέλευση εικόνας: [Kniberg, 2009]) Η πληροφορία ότι η μέση ταχύτητα μιας ομάδας είναι 8 είναι πολύ σημαντική. Μας επιτρέπει να κάνουμε πιο ακριβείς εκτιμήσεις για το ποιες εργασίες μπορεί να ολοκληρώσει η ομάδα στις επόμενες επαναλήψεις και κατ' επέκταση πιο ακριβείς εκτιμήσεις για το πότε θα μπορέσει να εκδοθεί το προϊόν. Στην Kanban, εκτιμήσεις δεν ορίζονται, οπότε για να γίνει μια χρονική δέσμευση, θα πρέπει η ομάδα να αποφασίσει πώς θα αποκτήσει «προβλεψιμότητα». Κάποιες ομάδες επιλέγουν να κάνουν προβλέψεις και να μετρούν τη velocity, όπως ακριβώς και στη Scrum. Ενώ, άλλες ομάδες επιλέγουν να μην συμπεριλάβουν τις εκτιμήσεις, αλλά μετρούν τη velocity. Σε γενικές γραμμές, υπάρχουν πολλές και ενδιαφέρουσες τεχνικές για τον προγραμματισμό των εκδόσεων και τη διαχείριση, αλλά δεν ορίζεται καμία συγκεκριμένη τεχνική. γ) Οι δια-τμηματικές ομάδες είναι απαραίτητες στη Scrum

68 68 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού Ένας πίνακας Scrum ανήκει αποκλειστικά σε μια ομάδα. Η ομάδα αυτή είναι διατμηματική και τα μέλη που την απαρτίζουν διαθέτουν όλες τις τεχνικές ικανότητες που απαιτούνται για την ολοκλήρωση των εργασιών που περιλαμβάνει η εκάστοτε επανάληψη. Ο πίνακας αυτός είναι στη διάθεση οποιουδήποτε ενδιαφέρεται, αλλά αλλαγές σε αυτόν μπορούν να γίνουν μόνο από την ομάδα στην οποία ανήκει (Σχήμα 18). Σχήμα 18: Πίνακας Scrum (Προέλευση εικόνας: [Kniberg, 2009]) Στην Kanban οι δια τμηματικές ομάδες είναι προαιρετικές και ένας πίνακας δεν είναι απαραίτητο να ανήκει σε μια συγκεκριμένη ομάδα, αλλά συνδέεται με μια ροή εργασιών. Οπότε στην Kanban, θα πρέπει να οριστούν κάποιοι αρχικοί κανόνες που θα περιγράφουν το ποιος θα χρησιμοποιεί τον πίνακα και πώς και έπειτα να γίνει πειραματισμός με τους κανόνες με σκοπό τη βελτίωση της διαδικασίας. Στο Σχήμα 19 αναπαριστώνται δυο πίνακες Kanban. Στην πρώτη περίπτωση ο πίνακας ανήκει σε μια δια τμηματική ομάδα, όπως ακριβώς και στη Scrum, ενώ στη δεύτερη περίπτωση ο πίνακας ανήκει σε δυο ομάδες και στον product owner.

69 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού 69 Σχήμα 19: Πίνακες Kanban (Προέλευση εικόνας: [Kniberg, 2009]) δ) Οι εργασίες του Scrum Backlog πρέπει να ολοκληρώνονται σε μια επανάληψη Μια ομάδα Scrum φροντίζει να αναλάβει, από το product backlog, τις εργασίες για τις οποίες είναι σίγουρη ότι μπορεί να ολοκληρώσει (με κριτήριο το Definition of Done) κατά τη διάρκεια μιας επανάληψης. Στην περίπτωση που μια εργασία είναι πολύ μεγάλη για να χωρέσει σε μια επανάληψη, ο ομάδα Scrum και ο product owner αναζητούν τρόπους ώστε να διασπάσουν την εργασία σε μικρότερα κομμάτια για να χωρέσει σε μια επανάληψη. Η διάσπαση αυτή γίνεται γιατί αν υπάρχουν πολλές μεγάλες εργασίες τότε και οι επαναλήψεις θα είναι μεγαλύτερες σε διάρκεια. Οι ομάδες Kanaban χρησιμοποιούν διαφορετική προσέγγιση. Η στρατηγική τους είναι να μειώσουν τον ρυθμό απόκρισης και να ισορροπήσουν τη ροή των εργασιών. Η προσέγγιση αυτή βέβαια δημιουργεί την ανάγκη να χωριστούν οι εργασίες σε μικρότερα κομμάτια αλλά κάτι τέτοιο δεν ορίζεται από τη διαδικασία. Γι αυτό και σε

70 70 Ευέλικτες Διαδικασίες Ανάπτυξης Λογισμικού έναν πίνακα Kanban μπορούμε να συναντήσουμε εργασίες που διαρκούν ένα μήνα αλλά συγχρόνως και εργασίες που διαρκούν μόλις μια μέρα. ε) Η Kanban περιορίζει τις εργασίες σε εξέλιξη (WIP) ανά κατάσταση ενώ η Scrum περιορίζει τις εργασίες σε εξέλιξη (WIP) ανά επανάληψη Στη διαδικασία Scrum, όπως και στην Kanban η ροή των εργασιών αναπαριστάται σε έναν ορατό πίνακα. Με μια πρώτη ματιά οι πίνακες και των δύο μεθόδων φαίνονται ίδιοι αλλά υπάρχει μια ουσιαστική διαφορά (Σχήμα 20), η οποία αλλάζει και τον τρόπο με τον οποίο εκτελεί τις εργασίες μια ομάδα ανάπτυξης αλλά όπως έχει προαναφερθεί, παρά τις διαφορές τους, οι δυο διαδικασίες μπορούν να συνδυαστούν. Σχήμα 20: Πίνακες Scrum και Kanban (Προέλευση εικόνας: [Kniberg, 2009]) Και στους δύο πίνακες παρακολουθούμε ορισμένα αντικείμενα να ακολουθούν τη ροή εργασιών και τις καταστάσεις από τις οποίες περνούν. Η μόνη διαφορά που παρατηρούμε είναι ο αριθμός 2 κάτω από την στήλη Ongoing στον πίνακα Kanban. Ο αριθμός αυτός περιορίζει τα αντικείμενα τα οποία μπορούν να βρίσκονται σε αυτή την κατάσταση ανά πάσα στιγμή. Πράγμα που σημαίνει ότι στην Kanban ο αριθμός εργασιών ανά κατάσταση περιορίζεται άμεσα.