Σκραμ

Από τη Βικιπαίδεια, την ελεύθερη εγκυκλοπαίδεια

Σκραμ[1] είναι πλαίσιο επαναληπτικής και επαυξητικής ευέλικτης μεθοδολογίας ανάπτυξης λογισμικού για τη διαχείριση της ανάπτυξης ενός προϊόντος. Ορίζει μια ευέλικτη, ολιστική στρατηγική για την ανάπτυξη του προϊόντος, όπου μια ομάδα ανάπτυξης λειτουργεί ως μονάδα για την επίτευξη ενός κοινού στόχου και επιτρέπει στις ομάδες να αυτοοργανώνονται με την ενθάρρυνση της φυσικής συνεργασίας ή διαδικτυακής συνεργασίας όλων των μελών της ομάδας, καθώς και την καθημερινή πρόσωπο-με-πρόσωπο επικοινωνία μεταξύ όλων των μελών της ομάδας και κλάδων στο σχεδιασμό.

Η λέξη σκραμ προέρχεται από τη μέθοδο scrummage (στα Αγγλικά) του Ράγκμπι.

Η αρχή-κλειδί του σκραμ είναι η αναγνώριση του ότι κατά τη διάρκεια της διαδικασίας παραγωγής, οι πελάτες μπορούν να αλλάξουν γνώμη σχετικά με το τι θέλουν και χρειάζονται (συχνά αυτό αναφέρεται ως μεταβλητότητα αναγκών[2]), καθώς και ότι μη αναμενόμενες προκλήσεις δεν είναι εύκολα διαχειρίσιμες με έναν παραδοσιακό προγνωστικό ή σχεδιασμένο τρόπο. Το σκραμ υιοθετεί μία εμπειρική προσέγγιση αποδεχόμενο ότι το πρόβλημα δεν μπορεί να κατανοηθεί πλήρως ή να οριστεί, εστιάζοντας αντ' αυτού στην μεγιστοποίηση της ικανότητας της ομάδας να διανέμει γρήγορα, να αποκρίνεται σε αναδυόμενες απαιτήσεις και να προσαρμόζεται σε εξελισσόμενες τεχνολογίες και αλλαγές στην κατάσταση της αγοράς.

Ιστορία[Επεξεργασία | επεξεργασία κώδικα]

Το πλαίσιο σκραμ αρχικά ορίστηκε ως "μία ευέλικτη, ολιστική στρατηγική ανάπτυξης ενός προϊόντος όπου μία ομάδα ανάπτυξης εργάζεται ως μία μονάδα για την επίτευξη ενός κοινού στόχου", σε αντίθεση με την "παραδοσιακή, ακολουθιακή προσέγγιση", το 1986 από τον Χιροτάκα Τακεούτσι και τον Ικουζίρο Νονάκα στο άρθρο "New Product Development Game"[3]. Ο Τακεούτσι και ο Νονάκα αργότερα συζήτησαν στο βιβλίο "The Knowledge Creating Company" για το ότι είναι ένα σχήμα "οργανωτικής δημιουργίας γνώσης,[...] ιδιαίτερα καλή στο να επιφέρει διαρκή καινοτομία, σταδιακά και με επαυξητικό ρυθμό".

Οι συγγραφείς περιέγραψαν μία νέα προσέγγιση στον εμπορικό χώρο ανάπτυξης προϊόντος, η οποία θα αύξανε την ταχύτητα και την ευελιξία, βασιζόμενοι σε μελέτες περιπτώσεων από παραγωγές επιχειρήσεων στους τομείς της αυτοκινητιστικής, φωτοτυπικής και τυπογραφικής βιομηχανίας. Αυτό το ονόμασαν η ολιστική ή ράγκμπι στρατηγική, καθώς όλη η διαδικασία εκτελείται από μία διαλειτουργική ομάδα σε πολλαπλά επικαλυπτόμενα στάδια, όπου η ομάδα "προσπαθεί να διανύσει την απόσταση ως μία μονάδα, πετώντας την μπάλα μπροστά και πίσω". (Στο ράγκμπι, το σκραμ αναφέρεται σε έναν στενά συνδεδεμένο σχηματισμό των παικτών με τα κεφάλια τους κάτω, οι οποίοι προσπαθούν να αποκτήσουν την κατοχή της μπάλας.)

Στις αρχές του 1990, ο Ken Schwaber χρησιμοποιούσε στην εταιρία του, Advanced Development Methods, αυτό που αργότερα θα ονομαζόταν σκραμ και έπειτα ο Jeff Sutherland, μαζί με τον John Scumniotales και τον Jeff McKenna, ανέπτυξαν μία παρόμοια στρατηγική στην Easel Corporation, και ήταν οι πρώτοι που αναφέρθηκαν σε αυτήν με την λέξη σκραμ. Το 1995, ο Sutherland και ο Schwaber παρουσίασαν από κοινού ένα άρθρο περιγράφοντας το πλαίσιο σκραμ στο Business Object Design and Implementation Workshop ως μέρος του Object-Oriented Programming, Systems, Languages & Applications '95 (OOPSLA '95) στο Ώστιν του Τέξας το οποίο και αποτελεί την πρώτη δημόσια παρουσίαση του. Ο Schwaber και ο Sutherland συνεργάστηκαν στην πορεία των χρόνων για να συγχωνεύσουν τα προαναφερόμενα γραπτά, τις εμπειρίες τους και τις καλύτερες βιομηχανικές πρακτικές σε αυτό που σήμερα είναι γνωστό ως σκραμ.

Το 2001, ο Schwaber συνεργάστηκε με τον Mike Beedle για να περιγράψει την μέθοδο αυτή στο βιβλίο Agile Software Development with Scrum. Η προσέγγιση της μεθόδου για τον σχεδιασμό και τη διαχείριση των πρότζεκτ είναι να αποφέρει αρμοδιότητα για την λήψη αποφάσεων στο επίπεδο των λειτουργικών ιδιοτήτων και σιγουριά. Αν και η λέξη δεν αποτελεί ακρωνύμιο, ορισμένες εταιρίες που εφαρμόζουν την μέθοδο γράφουν την λέξη με κεφαλαία γράμματα, ΣΚΡΑΜ. Αυτό ίσως να οφείλεται στο γεγονός ότι ένα από τα αρχικά άρθρα του Schwaber, είχε την λέξη ΣΚΡΑΜ (SCRAM) με κεφαλαία γράμματα στον τίτλο του.

Αργότερα, ο Schwaber μαζί με άλλους, ίδρυσε την συμμαχία σκραμ (Scrum Alliance) και δημιούργησαν τα προγράμματα πιστοποίησης κατοχής του σκραμ (Certified Scrum Master) και τα παράγωγα τους. Ο Schwaber αποχώρησε από την συμμαχία σκραμ προς τα τέλη του 2009 και ίδρυσε το Scrum.org με τον Alex Armstrong.

Ρόλοι[Επεξεργασία | επεξεργασία κώδικα]

Υπάρχουν τρεις βασικοί ρόλοι στο πλαίσιο σκραμ. Αυτοί οι ρόλοι είναι αφοσιωμένοι στο πρότζεκτ με την μέθοδο σκραμ· είναι οι ρόλοι που παράγουν το προϊόν (τον στόχο του πρότζεκτ). Αντιπροσωπεύουν την ομάδα σκραμ. Αν και μπορεί να συναντηθούν και άλλοι ρόλοι σε πραγματικά πρότζεκτ, το σκραμ δεν ορίζει άλλους ομαδικούς ρόλους πέρα από αυτούς που θα περιγράψουμε παρακάτω.

Ιδιοκτήτης του προϊόντος[Επεξεργασία | επεξεργασία κώδικα]

Ο ιδιοκτήτης του προϊόντος αντιπροσωπεύει τους ενδιαφερόμενους και είναι η φωνή του πελάτη, είναι υπεύθυνος ώστε να εξασφαλίσει ότι η ομάδα θα επιφέρει κέρδη στην επιχείρηση. Ο ιδιοκτήτης του προϊόντος γράφει (ή βάζει την ομάδα να γράψει) πελατοκεντρικά στοιχεία (συνήθως ιστορίες χρήστη), τα αξιολογεί και τα τοποθετεί σε σειρά προτεραιότητας, και έπειτα τα προσθέτει στη λίστα εκκρεμοτήτων του προϊόντος. Οι ομάδες σκραμ πρέπει να έχουν έναν ιδιοκτήτη προϊόντος, αυτός ο ρόλος δεν πρέπει να συνδυάζεται με αυτόν του αρχηγού του σκραμ. Ο ιδιοκτήτης του προϊόντος πρέπει να είναι στην επιχειρησιακή πλευρά του πρότζεκτ και δεν πρέπει πότε να παρεμβαίνει ή να αλληλεπιδρά με μέλη ομάδας σχετικά με τεχνικές απόψεις στην εξέλιξη της εργασίας. Αυτός ο ρόλος είναι ισοδύναμος με τον ρόλο του αντιπρόσωπου του πελάτη σε κάποια άλλα πλαίσια ευελιξίας.

Ο ρόλος του στις επικοινωνιακές ανάγκες[Επεξεργασία | επεξεργασία κώδικα]

Η επικοινωνία είναι το βασικό καθήκον του ιδιοκτήτη του προϊόντος. Η ικανότητα του να μεταβιβάζει προτεραιότητες και να ταυτίζεται με τα μέλη της ομάδας και τους ενδιαφερόμενους είναι κρίσιμη στο να μπορέσει να κατευθύνει το πρότζεκτ προς την σωστή πορεία. Οι ιδιοκτήτες προϊόντος γεμίζουν το κενό της επικοινωνίας που υπάρχει μεταξύ της ομάδας και των ενδιαφερόμενων. Όπως δείχνει το σχήμα 1 Αρχειοθετήθηκε 2016-01-27 στο Wayback Machine., εκτελούν τα καθήκοντα ενός εξουσιοδοτημένου αντιπρόσωπου του ενδιαφερόμενου προς την ομάδα ανάπτυξης και ενός εκπρόσωπου της ομάδας του έργου προς το σύνολο της κοινότητας των ενδιαφερόμενων.

Τα παρακάτω περιλαμβάνουν κάποια από τα επικοινωνιακά καθήκοντα ενός ιδιοκτήτη προϊόντος προς τους ενδιαφερόμενους, ως του προσώπου της ομάδας στους ενδιαφερόμενους, :

  • να επιδεικνύει την λύση στους βασικούς ενδιαφερόμενους που δεν ήταν παρούσα σε μια κριτική ενός σπριντ·
  • να ορίζει και να ανακοινώνει εκδόσεις·
  • να εκφράζει την κατάσταση της ομάδας·
  • να οργανώνει σημαντικές κριτικές·
  • να ενημερώνει τους ενδιαφερόμενους σχετικά με τη διαδικασία ανάπτυξης·
  • να διαπραγματεύεται τις προτεραιότητες, το πεδίο εφαρμογής, τη χρηματοδότηση και το χρονοδιάγραμμα·
  • να διασφαλίζει ότι η λίστα με τις εκκρεμότητες του προϊόντος είναι ορατή, διαφανής και ξεκάθαρη·

Η κατανόηση είναι ένα βασικό χαρακτηριστικό για έναν ιδιοκτήτη προϊόντος-η ικανότητα να μπαίνει στα παπούτσια κάποιου άλλου. Ένας ιδιοκτήτης προϊόντος συνδιαλέγεται με διάφορους ενδιαφερόμενους για το πρότζεκτ, οι οποίοι έχουν μια ποικιλία υποβάθρων, εργασιακών ρόλων και στόχων. Ένας ιδιοκτήτης προϊόντος πρέπει να είναι ικανός να βλέπει από όλες αυτές τις διαφορετικές οπτικές. Για να είναι αποτελεσματικός, είναι συνετό για τον ιδιοκτήτη του προϊόντος να γνωρίζει τον βαθμό λεπτομέρειας που ζητάει το κοινό. Η ομάδα ανάπτυξης χρειάζεται διεξοδικές κριτικές και προδιαγραφές έτσι ώστε να μπορεί να κατασκευάσει ένα προϊόν βάση προσδοκιών, ενώ ένας χορηγός του έργου μπορεί να χρειαστεί μόνο περιλήψεις σχετικά με την πρόοδό του. Η παροχή περισσότερων πληροφοριών απ' όσες χρειάζονται μπορεί να έχει ως αποτέλεσμα ο ενδιαφερόμενος να χάσει το αρχικό του ενδιαφέρον και όλη η διαδικασία να αποτελέσει σπατάλη χρόνου. Επιπλέον υπάρχουν σημαντικά αποδεικτικά στοιχεία ότι η πρόσωπο-με-πρόσωπο επικοινωνία γύρω από ένα κοινόχρηστο πρόχειρο περιβάλλον είναι ο πιο αποδοτικός τρόπος για την επιτυχή μεταφορά πληροφοριών απ' ό,τι με τα έγγραφα. Ένας άμεσος τρόπος επικοινωνίας προτιμάται περισσότερο από πεπειραμένους ευέλικτους ιδιοκτήτες προϊόντων.

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

Ομάδα ανάπτυξης[Επεξεργασία | επεξεργασία κώδικα]

Η ομάδα ανάπτυξης είναι υπεύθυνη για τη διανομή δυνητικά παραδοτέων δόσεων (potentially shippable increments - PSIs) του προϊόντος στο τέλος κάθε σπριντ (ο στόχος του σπριντ). Μία ομάδα απαρτίζεται από 3-9 άτομα που κάνουν την πραγματική δουλειά (ανάλυση, σχεδιασμό, ανάπτυξη, έλεγχο, τεχνική επικοινωνία, καταγραφές, κ.ο.κ.). Οι ομάδες ανάπτυξης είναι διαλειτουργικές, έχοντας όλες τις ικανότητες ως ομάδα οι οποίες είναι απαραίτητες ώστε να δημιουργηθεί μία δόση του προϊόντος. Η ομάδα ανάπτυξης στο σκραμ αυτοοργανώνεται, παρόλο που μπορεί να υπάρχουν κάποια επίπεδα επικοινωνίας με τα γραφεία διαχείρισης του πρότζεκτ (project management offices - PMOs).

Αρχηγός του σκραμ[Επεξεργασία | επεξεργασία κώδικα]

Το σκραμ διευκολύνεται από έναν αρχηγό του σκραμ, ο οποίος είναι υπεύθυνος να αφαιρεί τα εμπόδια από την ικανότητα της ομάδας να ανταποκριθεί στους στόχους του προϊόντος και τα παραδοτέα. Ο αρχηγός του σκραμ δεν είναι ο παραδοσιακός αρχηγός μίας ομάδας ή ο μάνατζερ του προτζεκτ, αλλά δρα σαν "διαιτητής" μεταξύ της ομάδας και σε οτιδήποτε μπορεί να της αποσπάσει την προσοχή. Ο αρχηγός του σκραμ βοηθά στο να διασφαλιστεί ότι η ομάδα ακολουθεί τις συμφωνημένες μεθόδους του σκραμ, συχνά κάνει πιο εύκολες βασικές συνεδριάσεις και ενθαρρύνει τα μέλη της ομάδας να βελτιωθούν. Επιπλέον, ο ρόλος αυτός έχει αναφερθεί και ως διοργανωτής ομάδας και ως υπηρέτης-ηγέτης, κάτι που ενισχύει αυτές τις δύο αντιλήψεις.

Οι κύριες υποχρεώσεις του αρχηγού του σκραμ περιλαμβάνουν (αλλά δεν περιορίζονται σε):

  • Να βοηθάει τον ιδιοκτήτη προϊόντος στη διατήρηση των εκκρεμοτήτων του προϊόντος με τέτοιον τρόπο ώστε να εξασφαλίζεται ότι η απαιτούμενη δουλειά είναι σωστά αντιλήψιμη ώστε η ομάδα να προοδεύει διαρκώς.
  • Να βοηθάει την ομάδα στο να καθορίσει τον ορισμό του έτοιμου για το προϊόν, με την βοήθεια των βασικών ενδιαφερόμενων.
  • Να καθοδηγεί την ομάδα, βάσει των αρχών του σκραμ, με σκοπό να παραδώσουν υψηλής ποιότητας λειτουργίες για το προϊόν.
  • Να προωθεί την αυτοοργάνωση μέσα στην ομάδα.
  • Να βοηθάει την ομάδα του σκραμ να αποφύγει ή να αφαιρέσει εμπόδια, είτε εσωτερικά είτε εξωτερικά, που αφορούν την πρόοδο της.
  • Να διευκολύνει τις διοργανώσεις της ομάδας  ώστε να εξασφαλίζει τακτική πρόοδο.
  • Να ενημερώνει τους βασικούς ενδιαφερόμενους για το προϊόν σύμφωνα με τις αρχές του σκραμ.

Ένας από τους τρόπους που ο ρόλος του αρχηγού του σκραμ διαφέρει από αυτόν του μάνατζερ του προτζεκτ είναι ότι ο μάνατζερ πιθανώς να έχει υπευθυνότητες σχετικά με τη διαχείριση του κοινού, ενώ ο αρχηγός του σκραμ δεν έχει. Το σκραμ δεν αναγνωρίζει επισήμως τον ρόλο του μάνατζερ του πρότζεκτ, καθώς παραδοσιακές μέθοδοι διοίκησης και ελέγχου θα προξενούσαν δυσκολίες.

Ροή εργασιών[Επεξεργασία | επεξεργασία κώδικα]

Το πλαίσιο σκραμ.
Η μέθοδος σκραμ.

To σπριντ είναι το βασικό στοιχείο ανάπτυξης στο σκραμ. Το σπριντ είναι μία χρονοπεριορισμένη προσπάθεια· περιορισμένη σε μία ακριβή διάρκεια. Η διάρκεια καθορίζεται εκ των προτέρων για κάθε σπριντ και είναι συνήθως μεταξύ μίας βδομάδας και ενός μήνα, με τις δύο βδομάδες να αποτελούν την πιο κοινή.

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

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

Σχεδιασμός[Επεξεργασία | επεξεργασία κώδικα]

Στην αρχή κάθε σπριντ, η ομάδα οργανώνει μία εκδήλωση σχεδιασμού σπριντ (sprint planning event) στην οποία:

  • Γνωστοποιείται το πιθανό εύρος δουλειάς για το σπριντ.
  • Επιλέγονται στοιχεία από τις εκκρεμότητες του προϊόντος που είναι πιθανό να ολοκληρωθούν.
  • Ετοιμάζονται οι εκκρεμότητες του σπριντ που περιγράφουν την απαιτούμενη δουλειά για την ολοκλήρωση των επιλεγόμενων εκκρεμοτήτων του προϊόντος.
  • Οργανώνεται μία εκδήλωση σχεδιασμού, με χρονική διάρκεια έως τέσσερις ώρες, για ένα σπριντ των δύο εβδομάδων (το χρονικό όριο ρυθμίζεται αναλόγως για σπριντ διαφορετικής διάρκειας).
    • Στο πρώτο μισό της εκδήλωσης, ολόκληρη η ομάδα (ομάδα ανάπτυξης, ο αρχηγός του σκραμ και ο ιδιοκτήτης προϊόντος) συμφωνεί στο ποιά στοιχεία από τις εκκρεμότητες του προϊόντος θα ληφθούν υπόψιν σε αυτό το σπριντ.
    • Στο δεύτερο μισό της εκδήλωσης, η ομάδα ανάπτυξης αναλύει τη δουλειά (εργασία) που απαιτείται για να ολοκληρώσουν αυτές τις εκκρεμότητες, οι οποίες και καταλήγουν στις εκκρεμότητες του σπριντ.

Όταν τα μέλη της ομάδας ανάπτυξης ετοιμάσουν την λίστα με τις εκκρεμότητες του σπριντ, δεσμεύοντα (συνήθως ψηφίζοντας) να φέρουν εις πέρας τις εργασίες μέσα στο όριο του σπριντ.

Καθημερινό σκραμ[Επεξεργασία | επεξεργασία κώδικα]

Καθημερινό σκραμ στο δωμάτιο υπολογιστών. Αυτή η κεντρική τοποθεσία βοηθάει την ομάδα να ξεκινήσει στην ώρα της.

Κάθε μέρα κατά τη διάρκεια του σπριντ, η ομάδα κάνει ένα καθημερινό σκραμ (ή stand-up) με συγκεκριμένες οδηγίες:

  • Όλα τα μέλη της ομάδας ανάπτυξης έρχονται προετοιμασμένα. Το καθημερινό σκραμ...
    • ...ξεκινάει ακριβώς στην ώρα του ακόμα και αν κάποια μέλη της ομάδας ανάπτυξης απουσιάζουν .
    • ...θα πρέπει να πραγματοποιείται την ίδια ώρα και στο ίδιο μέρος κάθε μέρα.
    • ...είναι περιορισμένο (χρονοπρογραμματισμένο) στα δεκαπέντε λεπτά.
  • Ο καθένας είναι ευπρόσδεκτος, παρόλο που κανονικά μόνο οι ρόλοι των ομάδων σκραμ συνεισφέρουν.
  • Κατά τη διάρκεια του καθημερινού σκραμ, κάθε μέλος της ομάδας απαντάει τρεις ερωτήσεις:
    • Τι έκανα χθες που βοήθησε την ομάδα ανάπτυξης να πλησιάσει την επίτευξη του στόχου του σπριντ;
    • Τι θα κάνω σήμερα ώστε να βοηθήσω την ομάδα ανάπτυξης να πλησιάσει την επίτευξη του στόχου του σπριντ;
    • Βλέπω κάποιο εμπόδιο που εμποδίζει εμένα ή την ομάδα στο να πλησιάσει την επίτευξη του στόχου του σπριντ; 

Οποιοδήποτε εμπόδιο (στο οποίο μπορεί να "σκοντάψει" κάποιος, το οποίο μπορεί να προκαλέσει κίνδυνο ή πρόβλημα) αναγνωρίζεται στο καθημερινό σκραμ, πρέπει να συλλαμβάνεται από τον αρχηγό του σκραμ και να αναρτάται στον πίνακα σκραμ της ομάδας, με ένα άτομο που επιλέγεται και έπειτα προορίζεται να δουλέψει στην εύρεση μίας λύσης πάνω στο θέμα (εκτός του καθημερινού σκραμ). Καμία λεπτομερής συζήτηση περί του θέματος δεν θα πρέπει να συμβαίνει κατά τη διάρκεια του καθημερινού σκραμ.

Επανεξέταση και αναδρομή[Επεξεργασία | επεξεργασία κώδικα]

Στο τέλος κάθε σπριντ, η ομάδα διεξάγει δύο εκδηλώσεις: την επανεξέταση του σπριντ και την αναδρομή του σπριντ.

Στην επανεξέταση του σπριντ, η ομάδα:

  • Κάνει μία ανασκόπηση της δουλειάς που ολοκληρώθηκε και των προγραμματισμένων εργασιών που δεν ολοκληρώθηκαν.
  • Παρουσιάζει την ολοκληρωμένη δουλειά στους ενδιαφερόμενους (γνωστό και ως το demo).

Οδηγίες για επανεξετάσεις σπριντ:

  • Μη ολοκληρωμένη δουλειά δεν μπορεί να παρουσιαστεί.
  • Η προτεινόμενη διάρκεια είναι δύο ώρες για ένα σπριντ δύο εβδομάδων (αντίστοιχα για σπριντ με διαφορετική διάρκεια)

Στην αναδρομή του σπριντ, η ομάδα:

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

Οδηγίες για την αναδρομή του σπριντ:

  • Δύο βασικές ερωτήσεις πρέπει να απαντηθούν κατά την αναδρομή του σπριντ: Τι πήγε καλά κατά τη διάρκεια του σπριντ; Τι θα μπορούσε να βελτιωθεί στο επόμενο σπριντ;
  • Η προτεινόμενη διάρκεια είναι μιάμιση ώρα για ένα σπριντ δύο εβδομάδων (αντίστοιχα για σπριντ με διαφορετική διάρκεια).
  • Η εκδήλωση αυτή διευκολύνεται από τον αρχηγό του σκραμ.

Επεκτάσεις[Επεξεργασία | επεξεργασία κώδικα]

Βελτίωση των εκκρεμοτήτων[Επεξεργασία | επεξεργασία κώδικα]

Η βελτίωση των εκκρεμοτήτων (ενίοτε ονομαζόμενη και περιποίηση των εκκρεμοτήτων) είναι η εξελισσόμενη διεργασία ελέγχου των εκκρεμοτήτων του προϊόντος και επιβεβαίωσης ότι είναι αυτές κατάλληλα καθορισμένες βάσει προτεραιότητας και έτοιμες, με τέτοιο τρόπο ώστε να είναι κατανοητές και εκτελέσιμες για τις ομάδες, όταν αυτές ξεκινήσουν ένα σπριντ μέσω της δραστηριότητας σχεδιασμού σπριντ. Η λίστα των στοιχείων σε εκκρεμότητα μπορεί να διασπαστεί σε άλλες μικρότερες· κριτήρια αποδοχής μπορεί να διευκρινιστούν· και εξαρτήσεις, έρευνες και προπαρασκευαστικές εργασίες μπορεί επίσης να αναγνωριστούν και να συμφωνηθούν ως τεχνικές αιχμής.

Η βελτίωση των εκκρεμοτήτων δεν είναι μία από τις κύριες πρακτικές του σκραμ αλλά έχει υιοθετηθεί ως ένας τρόπος ελέγχου της ποιότητας των στοιχείων σε εκκρεμότητα τα οποία θα απασχολήσουν την ομάδα σε ένα σπριντ, με μία προτεινόμενη διάρκεια εως το 10% της διάρκειας του σπριντ.

Σκραμ των σκραμ[Επεξεργασία | επεξεργασία κώδικα]

Το σκραμ των σκραμ είναι μία τεχνική ώστε να αυξηθεί το σκραμ στις πολλαπλές ομάδες που δουλεύουν στο ίδιο προϊόν, επιτρέποντας στις ομάδες να συζητούν την πρόοδο των αλληλεξαρτήσεων τους, εστιάζοντας στο πώς να συντονίσουν την παράδοση λογισμικού, ειδικά στους τομείς της επικάλυψης και της ενοποίησης. Βασιζόμενο στον ρυθμό του σκραμ των σκραμ, το σχετικό καθημερινό σκραμ κάθε ομάδας κλείνει αναδεικνύοντας ένα άτομο ως πρεσβευτή ο οποίος θα πάρει μέρος στο σκραμ των σκραμ με τους άλλους πρεσβευτές των άλλων ομάδων. Ανάλογα με το περιεχόμενο, οι πρεσβευτές μπορεί να είναι τεχνικοί συνεισφέροντες ή ο αρχηγός του σκραμ της κάθε ομάδας.

Το σκραμ των σκραμ θα πρέπει να λειτουργεί παρόμοια με το καθημερινό σκραμ, όπου κάθε πρεσβευτής απαντάει στις ακόλουθες τέσσερις ερωτήσεις:

  • Τι έκανε η ομάδα σου από τότε που συναντηθήκαμε τελευταία φορά;
  • Τι θα κάνει η ομάδα σου πριν συναντηθούμε ξανά;
  • Υπάρχει κάτι που καθυστερεί ή εμποδίζει την ομάδα σου;
  • Πρόκειται να βάλεις κάτι στον δρόμο κάποιας άλλης ομάδας;

Η λύση των προβλημάτων αναμένεται να εστιάσει στις προκλήσεις σχετικά με την καθοδήγηση μεταξύ των ομάδων και ίσως προϋποθέσει την συμφωνία διασυνδέσεων μεταξύ των ομάδων, την διαπραγμάτευση των ορίων για τις υποχρεώσεις, κ.ο.κ.

Το σκραμ των σκραμ παρακολουθεί αυτά τα στοιχεία εργασίας μέσω μίας δικής του λίστας εκκρεμοτήτων, όπως ένας πίνακας ROAM, όπου κάθε στοιχείο συνεισφέρει στην βελτίωση την καθοδήγησης της διαλειτουργικής ομάδας.

Όπως είχε σχολιάσει και ο Jeff Sutherland,

Από τότε που είχα ορίσει αρχικά το σκραμ των σκραμ (ο Ken Schwaber ήταν στην IDX και δούλευε μαζί μου), μπορώ να πω με σιγουριά ότι το σκραμ των σκραμ δεν είναι μία δοκιμαστική έκδοση του σκραμ. Το σκραμ των σκραμ όπως το είχα ορίσει είναι υπεύθυνο για την διανομή του εκτελέσιμου λογισμικού όλων των ομάδων σύμφωνα με τον ορισμού του έτοιμου στο τέλος κάθε σπριντ ή για την διανομή εκδόσεων κατά τη διάρκεια του σπριντ. Η PatientKeeper διένειμε στην παραγωγή τέσσερεις φορές σε κάθε σπριντ. Η Ancestry.com διανέμει στην παραγωγή 220 φορές σε κάθε σπριντ διάρκειας δύο εβδομάδων. Ο αρχηγός του σκραμ των σκραμ φέρνει την ευθύνη για να γίνει εφικτό κάτι τέτοιο. Συνεπώς, το σκραμ των σκραμ είναι ένας λειτουργικός μηχανισμός παράδοσης.

Τεχνουργήματα[Επεξεργασία | επεξεργασία κώδικα]

Εκκρεμότητες προϊόντος[Επεξεργασία | επεξεργασία κώδικα]

Οι εκκρεμότητες του προϊόντος αποτελούν μία ταξινομημένη λίστα από ανάγκες την οποία μία ομάδα σκραμ συντηρεί για το προϊόν. Αποτελείται από λειτουργίες, διορθώσεις σφαλμάτων, μη λειτουργικών αναγκών κ.α. — γενικά από το οτιδήποτε πρέπει να γίνει για να παραδοθεί ένα βιώσιμο προϊόν. Ο ιδιοκτήτης του προϊόντος ταξινομεί τα εκκρεμή στοιχεία του προϊόντος βασιζόμενος σε παράγοντες όπως το ρίσκο, την επιχειρηματική αξία, τις εξαρτήσεις και τον χρόνο παράδοσης.

Τα στοιχεία που προστίθενται στη λίστα των εκκρεμοτήτων είναι συνήθως γραμμένα σε μορφή ιστορίας. Οι εκκρεμότητες του προϊόντος είναι αυτές που θα παραδοθούν, ταξινομημένες στην σειρά με την οποία πρέπει να παραδοθούν. Η λίστα είναι εμφανής σε όλους αλλά μπορεί να υποστεί επεξεργασία μόνο με την συγκατάθεση του ιδιοκτήτη του προϊόντος, ο οποίος είναι ο απόλυτα υπεύθυνος για την ταξινόμηση των εκκρεμοτήτων από τις οποίες θα κάνει επιλογή η ομάδα ανάπτυξης.

Η λίστα με τις εκκρεμότητες του προϊόντος περιέχει την αξιολόγηση του ιδιοκτήτη του προϊόντος σχετικά με την επιχειρηματική αξία και την αξιολόγηση της ομάδας σχετικά με την προσπάθεια ανάπτυξης που απαιτείται, που είναι συχνά, όχι όμως πάντα, δηλωμένες σε ιστορικές υποδείξεις με την χρήση μίας καμπυλωτής ακολουθίας Φιμπονάτσι. Αυτές οι εκτιμήσεις βοηθούν τον ιδιοκτήτη του προϊόντος να υπολογίσει την χρονική σειρά των γεγονότων και μπορεί να επιδράσουν στην ταξινόμηση των εκκρεμοτήτων· παραδείγματος χάριν, εάν οι λειτουργίες της "προσθήκης ορθογραφικού ελέγχου" και της "προσθήκης υποστήριξης πίνακα" έχουν την ίδια επιχειρηματική αξία, ο ιδιοκτήτης του προϊόντος μπορεί να προγραμματίσει πιο σύντομα την παράδοση για την λειτουργία που χρειάζεται την πιο ελάχιστη καταβολή προσπάθειας για την ανάπτυξη (διότι το κέρδος είναι υψηλότερο) ή για αυτή που χρειάζεται την περισσότερη καταβολή προσπάθειας για την ανάπτυξη (διότι είναι πιο πολύπλοκη και ριψοκίνδυνη και θέλει να την αποσύρει νωρίς)

Οι εκκρεμότητες προϊόντος και η επιχειρηματική αξία κάθε εκκρεμότητας είναι ευθύνη του ιδιοκτήτη του προϊόντος. Ωστόσο, το μέγεθος (δηλαδή η εκτιμώμενη πολυπλοκότητα και προσπάθεια) κάθε στοιχείου καθορίζεται από την ομάδα ανάπτυξης, η οποία συμβάλλει στο να μετράει το μέγεθος των στοιχείων, βάσει των σημειώσεων ή του εκτιμώμενου χρόνου.

Υπάρχει μία συχνή παρεξήγηση:ότι μόνο οι ιστορίες χρήστη επιτρέπεται να είναι στις εκκρεμότητες του προϊόντος. Ωστόσο, το σκραμ είναι ουδέτερο σε τεχνικές απαιτήσεις. Όπως διατυπώνει το εγχειρίδιο του σκραμ,

Τα εκκρεμή στοιχεία του προϊόντος είναι αρθρωτά με τέτοιο τρόπο ώστε να είναι κατανοητά και βιώσιμα. Σε αντίθεση με την κοινή παρεξήγηση, οι εκκρεμότητες του προϊόντος δεν περιέχουν "ιστορίες χρήστη"· περιέχουν απλά στοιχεία. Αυτά τα στοιχεία μπορούν να εκφραστούν ως ιστορίες χρήστη, περιπτώσεις χρήσης, ή ως οποιαδήποτε άλλη προσέγγιση την οποία η ομάδα βρίσκει χρήσιμη.Όμως οποιαδήποτε και να είναι αυτή η προσέγγιση, τα περισσότερα στοιχεία θα πρέπει να εστιάζουν στην παράδοση αξίας στους πελάτες.

Το σκραμ συνιστά την ανάθεση του ρόλου του ιδιοκτήτη προϊόντος. Ο ιδιοκτήτης προϊόντος είναι υπεύθυνος για την μεγιστοποίηση της αξίας του προϊόντος. Ο ιδιοκτήτης του προϊόντος συλλέγει ιδέες και δέχεται γνώμες από αρκετούς ανθρώπους, από τους οποίους και πιέζεται, αλλά κυρίως αποφασίζει το τι θα φτιαχτεί.

Οι εκκρεμότητες του προϊόντος:

  • Συλλέγουν αιτήματα σχετικά με την επεξεργασία του προϊόντος - καθώς και νέες λειτουργίες, αντικαθιστώντας λειτουργίες, καταργώντας λειτουργίες και διορθώνοντας λάθη.
  • Βεβαιώνουν τον ιδιοκτήτη προϊόντος ότι η ομάδα ανάπτυξης κάνει δουλειά η οποία μεγιστοποιεί τα κέρδη της επιχείρησης.

Γενικά, ο ιδιοκτήτης του προϊόντος μαζί με την ομάδα του σκραμ ενώνονται και σημειώνουν οτιδήποτε πρέπει να μπει σε προτεραιότητα, και αυτό γίνεται το περιεχόμενο του πρώτου σπριντ, όπου είναι ένα κομμάτι χρόνου αφοσιωμένης δουλειάς σε επιλεγμένα στοιχεία που μπορούν να επιτευχθούν μέσα στα όρια του σπριντ. Οι εκκρεμότητες προϊόντος μπορούν να αυξηθούν καθώς νέες πληροφορίες έρχονται στην επιφάνεια σχετικά με το προϊόν και τους πελάτες, έχοντας ως αποτέλεσμα τα επερχόμενα σπριντ να πρέπει να αναλάβουν την νέα δουλειά.

Τα ακόλουθα στοιχεία συνήθως αποτελούν τις εκκρεμότητες ενός σκραμ: λειτουργίες, σφάλματα, τεχνική εργασία και η απόκτηση γνώσης. Η ανάπτυξη ιστοσελίδας μπορεί να επιφέρει σύγχυση σχετικά με την διαφορά μεταξύ μιας λειτουργίας και ενός σφάλματος: τεχνικά μία λειτουργία είναι "επιθυμητή", ενώ ένα σφάλμα είναι μία λειτουργία "αθέλητη" ή "ανεπιθύμητη" (αλλά μπορεί να μην είναι απαραίτητα κάτι το προβληματικό). Ένα παράδειγμα τεχνικής εργασίας θα ήταν: "τρέξτε έναν έλεγχο για ιούς σε όλους τους σταθμούς εργασίας των προγραμματιστών". Ένα παράδειγμα απόκτησης γνώσης θα μπορούσε να είναι ένα στοιχείο εκκρεμότητας του σκραμ σχετικά με την αναζήτηση βιβλιοθηκών επεκτάσεων του Wordpress και έπειτα μία επιλογή μεταξύ αυτών.

Διαχείριση[Επεξεργασία | επεξεργασία κώδικα]

Οι εκκρεμότητες, στην πιο απλή τους μορφή, είναι απλώς μία λίστα από στοιχεία για δουλειά. Η ύπαρξη καλά καθορισμένων κανόνων για το πώς η δουλειά προστίθεται, αφαιρείται και ταξινομείται, βοηθάει ολόκληρη την ομάδα να λάβει καλύτερες αποφάσεις για το πώς να αλλάξει το προϊόν.

Ο ιδιοκτήτης του προϊόντος καθορίζει τις προτεραιότητες σχετικά με το ποια εκκρεμή στοιχεία του προϊόντος είναι τα πιο απαραίτητα. Η ομάδα έπειτα διαλέγει ποια στοιχεία μπορούν να ολοκληρώσουν τα μέλη της στο επερχόμενο σπριντ. Στον πίνακα σκραμ, η ομάδα μετακινεί στοιχεία από τις εκκρεμότητες του προϊόντος στις εκκρεμότητες του σκραμ, οι οποίες αποτελούν και την λίστα των στοιχείων που θα φτιάξουν. Κατά προτίμηση, είναι ιδανικό για την ομάδα να επιλέγει μόνο αυτά που θεωρεί ότι μπορεί να επιτύχει από την κορυφή της λίστας, αλλά δεν είναι ασυνήθιστο για τις ομάδες να είναι σε θέση να παίρνουν στοιχεία χαμηλής προτεραιότητας από την λίστα μαζί με στοιχεία υψηλής προτεραιότητας. Αυτό συνήθως συμβαίνει διότι υπάρχει ελεύθερος χρόνος κατά τη διάρκεια του σπριντ για την ομάδα να μεριμνήσει για περισσότερη δουλειά. Στοιχεία υψηλής προτεραιότητας, τα στοιχεία που πρώτα θα πρέπει να διασπαστούν σε ιστορίες που είναι κατάλληλες για την ομάδα ανάπτυξης να τα δουλέψει. Όσο πιο κάτω πάει η λίστα, τόσο λιγότερο εξευγενισμένα θα πρέπει να είναι τα στοιχεία. Όπως το έθεσε ο Schwaber και ο Beedle: "Όσο πιο χαμηλή η προτεραιότητα, τόσο πιο χαμηλή και η λεπτομέρεια, μέχρι να μην μπορείς να διακρίνεις τα εκκρεμή στοιχεία".

Καθώς η ομάδα εργάζεται με τις εκκρεμότητες, πρέπει να υπάρχει η υπόθεση ότι "αλλαγές στον κόσμο μπορούν να συμβούν" — η ομάδα μπορεί να μάθει για νέες ευκαιρίες της αγοράς που μπορεί να εκμεταλλευτεί, αναδυόμενες απειλές από ανταγωνιστές και κριτικές από πελάτες που μπορούν να αλλάξουν τον τρόπο με τον οποίο το προϊόν ήταν σχεδιασμένο να δουλέψει. Όλες αυτές οι καινούργιες ιδέες τείνουν να πυροδοτούν την ομάδα στο να προσαρμόσει τις εκκρεμότητες της με τις συμπεριλαμβανόμενες νέες γνώσεις. Αυτό είναι το κομμάτι της θεμελιώδους νοοτροπίας μιας ευέλικτης ομάδας: ο κόσμος αλλάζει, οι εκκρεμότητες δεν τελειώνουν ποτέ.

Εκκρεμότητες σπριντ[Επεξεργασία | επεξεργασία κώδικα]

Ένας πίνακας εργασιών σκραμ

Οι εκκρεμότητες του σπριντ είναι η λίστα της δουλειάς που πρέπει να κάνει η ομάδα ανάπτυξης στο επερχόμενο σπριντ. Η λίστα παραδίδεται από την ομάδα του σκραμ με επιλεγμένα στοιχεία από τις εκκρεμότητες του προϊόντος, από την κορυφή της λίστας έως ότου η ομάδα αισθανθεί ότι έχει αρκετή δουλειά ώστε να πληροί το όριο του σπριντ. Αυτό γίνεται από την ομάδα ανάπτυξης η οποία ρωτάει "Μπορούμε να κάνουμε και αυτό;" και προσθέτοντας τα εκκρεμή στοιχεία του προϊόντος στις εκκρεμότητες του σκραμ. Η ομάδα ανάπτυξης θα πρέπει να έχει στο μυαλό της την προηγούμενη απόδοση της, αξιολογώντας την ικανότητα της για το επερχόμενο σπριντ και χρησιμοποιώντας αυτό σαν καθοδηγητή για το πόση "προσπάθεια" μπορούν να καταβάλλουν.

Τα στοιχεία των εκκρεμοτήτων του προϊόντος μπορεί να διασπαστούν σε μικρότερες εργασίες από την ομάδα ανάπτυξης. Οι εργασίες δεν κατανέμονται ποτέ στις εκκρεμότητες του σπριντ· κατά προτίμηση, οι εργασίες αναθέτονται από τα μέλη της ομάδας βάση του βαθμού προτεραιότητας και των ικανοτήτων των μελών της ομάδας ανάπτυξης. Αυτό ενισχύει την αυτοοργάνωση της ομάδας ανάπτυξης.

Οι εκκρεμότητες του σπριντ είναι ιδιοκτησία της ομάδας ανάπτυξης και όλες οι περιλαμβανόμενες εκτιμήσεις δίνονται από την ομάδα ανάπτυξης. Συχνά χρησιμοποιείται ένας συνοδευτικός πίνακας εργασιών για να παρακολουθούν και να αλλάζουν την κατάσταση των εργασιών για το τρέχων σπριντ, όπως: "να γίνει", "σε εξέλιξη" και "έτοιμο".

Όταν οι εκκρεμότητες του σπριντ δεσμευτούν, δεν μπορεί καμία επιπλέον εργασία να προστεθεί στις εκκρεμότητες του σπριντ εκτός της ομάδας. Μόλις ένα σπριντ τελειώσει, αναλύονται οι εκκρεμότητες προϊόντος και ξαναμπαίνουν σε σειρά προτεραιότητας αν είναι απαραίτητο και επιλέγεται το επόμενο σύνολο στοιχείων για το επόμενο σπριντ.

Δόση προϊόντος[Επεξεργασία | επεξεργασία κώδικα]

Η δόση (ή η δυνητικά παραδοτέα δόση - potentially shippable increment, PSI) είναι το άθροισμα όλων των στοιχείων από τις εκκρεμότητες του προϊόντος που ολοκληρώθηκαν κατά την διάρκεια ενός σπριντ και όλων των περασμένων σπριντ. Στο τέλος ενός σπριντ, η δόση πρέπει να είναι έτοιμη, σύμφωνα με τον ορισμό του έτοιμου (Definition of Done - DoD) της ομάδας του σκραμ και σε μία χρήσιμη κατάσταση ασχέτως αν ο ιδιοκτήτης προϊόντος αποφασίσει να το εκδώσει ή όχι.

Διάγραμμα burn-down σπριντ[Επεξεργασία | επεξεργασία κώδικα]

Ένα παράδειγμα διαγράμματος burn-down σπριντ για μία πλήρη επανάληψη, παρουσιάζοντας την υπολειπόμενη προσπάθεια και εργασίες για κάθε μία από τις 21 εργάσιμες μέρες ενός σπριντ με διάρκεια 1 μήνα.

Το διάγραμμα burn-down σπριντ είναι ένα δημόσιο διάγραμμα που παρουσιάζει την υπολειπόμενη δουλειά για τις εκκρεμότητες του σπριντ. Ενημερώνεται καθημερινά, δίνοντας μία απλή εκτίμηση για την πρόοδο του σπριντ. Επιπλέον, παρέχει έτοιμες απεικονίσεις για καταγραφή. Κατά την διάρκεια του σχεδιασμού του σπριντ το ιδανικό διάγραμμα σχεδιάζεται. Έπειτα, κατά την διάρκεια του σπριντ, κάθε μέλος αναλαμβάνει καθήκοντα από τις εκκρεμότητες του σπριντ και δουλεύει σε αυτά. Στο τέλος της ημέρας, ενημερώνει τις υπολειπόμενες ώρες έως την ολοκλήρωση των εργασιών. Με αυτόν τον τρόπο, το τρέχον διάγραμμα ενημερώνεται καθημερινά.

Αυτό το διάγραμμα δεν θα πρέπει να συγχέεται με το διάγραμμα κερδισμένης αξίας.

Διάγραμμα burn-down έκδοσης[Επεξεργασία | επεξεργασία κώδικα]

Το διάγραμμα burn-down της έκδοσης είναι ο τρόπος με τον οποίο η ομάδα παρακολουθεί την πρόοδο και της παρέχει οπτικοποίηση του ρυθμού εξέλιξης. Το διάγραμμα εργασίας-χρόνου έκδοσης ενημερώνεται στο τέλος κάθε σπριντ από τον αρχηγό του σκραμ. Ο οριζόντιος άξονας του διαγράμματος δείχνει τα σπριντ· ο κατακόρυφος άξονας δείχνει το σύνολο της υπολειπόμενης δουλειά για την αρχή του κάθε σπριντ. Το διάγραμμα διευκολύνει την επισκόπηση ενός σπριντ και να κατανοήσει κανείς ποια είναι η υπολειπόμενη δουλειά, τι έχει προστεθεί, ποια δουλειά έχει ολοκληρωθεί και το ποια δουλειά πρέπει να ολοκληρωθεί. Μπορεί να δει κάποιος τι έχει ολοκληρώσει η ομάδα καθώς και πως έχει αλλάξει το πεδίο εφαρμογής.

Ορολογία[Επεξεργασία | επεξεργασία κώδικα]

Οι ακόλουθοι όροι χρησιμοποιούνται συχνά στην μέθοδο σκραμ.

Ομάδα σκραμ (Scrum team)

Ο ιδιοκτήτης του προϊόντος, ο αρχηγός του σκραμ και η ομάδα ανάπτυξης

Ιδιοκτήτης προϊόντος (Product owner)

Είναι το άτομο που είναι υπεύθυνο για την συντήρηση των εκκρεμοτήτων του προϊόντος με το να εκπροσωπεί το συμφέρον των ενδιαφερόμενων και εξασφαλίζοντας την αξία της δουλειάς που κάνει η ομάδα ανάπτυξης.

Αρχηγός του σκραμ (Scrum master)

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

Ομάδα ανάπτυξης (Development team)

Είναι μία διαλειτουργική ομάδα ατόμων υπεύθυνων να έχουν έτοιμες δυνητικά παραδοτέες δόσεις του προϊόντος στο τέλος κάθε σπριντ.

Διάγραμμα burn-down σπριντ (Sprint burn-down chart)

Είναι ένα διάγραμμα των εργασιών σύμφωνα με τον υπολείποντα χρόνο. Παρουσιάζει την καθημερινή πρόοδο για ένα σπριντ κατά την διάρκεια του.

Διάγραμμα burn-down έκδοσης (Release burn-down chart)

Παρουσιάζει το επίπεδο προόδου των ολοκληρωμένων στοιχείων σε εκκρεμότητα του προϊόντος.

Λίστα εκκρεμοτήτων προϊόντος (Product backlog List - PBL)

Μία λίστα προτεραιοτήτων υψηλού επιπέδου αναγκών.

Λίστα εκκρεμοτήτων σπριντ (Sprint backlog List -  SBL)

Μία λίστα προτεραιοτήτων με εργασίες που πρέπει να ολοκληρωθούν κατά τη διάρκεια του σπριντ.

Σπριντ (Sprint)

Μία χρονική περίοδος (συνήθως 1-4 εμβομάδες) στην οποία η ανάπτυξη προκύπτει από το σύνολο των στοιχείων που βρίσκονται σε εκκρεμότητα και στα οποία έχει δεσμευτεί να ολοκληρώσει η ομάδα—συχνά αναφέρεται ως χρονοπεριορισμός ή δόση.

Αιχμή (Spike)

Μία χρονοπεριορισμένη περίοδος που χρησιμοποιείται για την έρευνα μίας ιδέας ή την δημιουργία ενός απλού πρωτοτύπου. Οι αιχμές μπορούν να προγραμματιστούν να συμβούν ενδιάμεσα των σπριντ ή, όταν υπάρχουν μεγαλύτερες ομάδες, μία αιχμή μπορεί να γίνει αποδεκτή ως ένας από τους πολλούς στόχους παράδοσης του σπριντ. Οι αιχμές συνήθως παρουσιάζονται πριν την παράδοση μεγάλων ή πολύπλοκων εκκρεμών στοιχείων του προϊόντος προκειμένου να διασφαλιστεί ο προϋπολογισμός, να επεκταθεί η γνώση ή να παράγουν μία δοκιμαστική έκδοση της ιδέας. Η διάρκεια και οι στόχοι της συμφωνούνται από τον ιδιοκτήτη του προϊόντος και την ομάδα ανάπτυξης πριν την αρχή της. Σε αντίθεση με τις δεσμεύσεις του σπριντ, οι αιχμές μπορεί παραδόσουν (μπορεί και όχι) απτή, δυνητικά παραδόσιμη, σημαντική λειτουργικότητα. Για παράδειγμα, ο στόχος μίας αιχμής μπορεί να είναι η επιτυχής λήψη μίας απόφασης για μία πορεία δράσης. Η αιχμή τελειώνει όταν τελειώσει και ο χρόνος της, όχι απαραίτητα όταν ο στόχος έχει παραδοθεί.

Ανιχνευτής σφαιρών (Tracer bullet)

Ο ανιχνευτής σφαιρών είναι μία αιχμή με την τρέχουσα αρχιτεκτονική, με το τρέχον σύνολο τεχνολογίας και το τρέχον σύνολο των καλύτερων πρακτικών που οδηγούν στην παραγωγή ποιοτικού κώδικα. Μπορεί να είναι απλώς μία αρκετά περιορισμένη υλοποίηση της λειτουργικότητας αλλά δεν είναι άχρηστος κώδικας. Είναι παραγωγικής ποιότητας και οι υπόλοιπες δόσεις μπορούν να χτιστούν πάνω σε αυτόν τον κώδικα. Η ονομασία έχει στρατιωτική προέλευση ως ένα πυρομαχικό που κάνει την διαδρομή της σφαίρας ορατή, επιτρέποντας διορθώσεις. Συχνά αυτές οι υλοποιήσεις είναι μία "γρήγορη ματιά" σε όλα τα επίπεδα μίας εφαρμογής.

Εργασίες (Tasks)

Είναι τα στοιχεία εργασίας που προσθέτονται στην λίστα εκκρεμοτήτων του σπριντ στην αρχή του και διαχωρίζονται σε χρονικές περιόδους. Κάθε εργασία δεν πρέπει να ξεπερνάει τις 12 ώρες (ή τις δύο μέρες), αλλά είναι συχνό για τις ομάδες να επιμένουν ότι μία εργασία δεν παίρνει πάνω από μία μέρα για να ολοκληρωθεί.

Ορισμός του έτοιμου (Definition of done - DoD)

Είναι το κριτήριο εξόδου για να καθοριστεί αν ένα στοίχειο από την λίστα των εκκρεμοτήτων έχει ολοκληρωθεί. Σε αρκετές περιπτώσεις ο ορισμός του έτοιμου απαιτεί ότι όλες οι δοκιμές αναδρομής είναι επιτυχείς. Ο ορισμός για το αν κάτι είναι έτοιμο μπορεί να διαφέρει μεταξύ διάφορων ομάδων του σκραμ, αλλά πρέπει να είναι συνεπής μεταξύ μίας ομάδας.

Ταχύτητα (Velocity)

Είναι η συνολική προσπάθεια που μία ομάδα είναι σε θέση να καταβάλλει σε ένα σπριντ. Ο αριθμός προκύπτει με την αξιολόγηση της δουλειάς που ολοκληρώθηκε από το προηγούμενο σπριντ. Η συλλογή ιστορικών στοιχείων σχετικά με την ταχύτητα είναι ένας οδηγός για την ομάδα βοηθώντας την να καταλάβει πόση δουλειά μπορεί να καταφέρει σε ένα μελλοντικό σπριντ.

Εμπόδιο (Impediment)

Είναι οτιδήποτε το οποίο εμποδίζει ένα μέλος της ομάδας να εκτελέσει τη δουλειά του όσο πιο αποτελεσματικά γίνεται.

Σασίμι (Sashimi)

Είναι ένας όρος που χρησιμοποιείται για να περιγράψει μία ή περισσότερες ιστορίες χρήστη, υποδεικνύοντας ότι είναι κομμάτια μίας λειτουργίας ή ικανότητας του προϊόντος.

Μη φυσιολογικός τερματισμός (Abnormal termination)

Ο ιδιοκτήτης του προϊόντος μπορεί να ακυρώσει ένα σπριντ αν είναι απαραίτητο. Ο ιδιοκτήτης του προϊόντος μπορεί να το κάνει με την υπόδειξη της ομάδας, του αρχηγού του σκραμ ή της διεύθυνσης. Για παράδειγμα, η διεύθυνση μπορεί να επιθυμεί να ακυρωθεί το σπριντ, αν εξωτερικοί παράγοντες ανατρέψουν την αξία του στόχου ενός σπριντ.

ScrumBut

Το ScrumBut (ή Scrum But) είναι ένας όρος ο οποίος περιγράφει την προσέγγιση μίας ομάδας η οποία έχει προσαρμόσει την μέθοδο σκραμ στις δικές της ανάγκες με τρόπο αντικρουόμενο στο γνήσιο σκραμ.

Περιορισμοί[Επεξεργασία | επεξεργασία κώδικα]

Το σκραμ δεν δουλεύει τόσο καλά στις ακόλουθες περιπτώσεις:

  • Ως κανόνας, η προσέγγιση του σκραμ απαιτεί στενή αλληλεπίδραση μεταξύ των προγραμματιστών. Ιδανικά οι προγραμματιστές εργάζονται μαζί στον ίδιο όροφο τις περισσότερες φορές. Πρότζεκτ όπου οι προγραμματιστές έχουν γεωγραφική απόσταση μεταξύ τους μειώνουν την προσέγγιση του σκραμ. Για παρόμοιους λόγους, πρότζεκτ με αρκετούς απασχολούμενους δεν ταιριάζουν στην προσέγγιση του σκραμ.
  • Οι προγραμματιστές πρέπει να είναι ικανοί να αναλάβουν εργασίες και να δουλεύουν σε εργασίες και των άλλων μελών της ομάδας. Συνεπώς, πρότζεκτ όπου οι προγραμματιστές κατέχουν διαφορετικές και πιο ειδικευμένες δεξιότητες είναι λιγότερο κατάλληλοι για την προσέγγιση του σκραμ.
  • Το να διαχωρίζεται ένα πρότζεκτ σε άλλα μικρότερα σπριντ κάποιες φορές απαιτεί προσεχτικό σχεδιασμό. Εξωτερικές εξαρτήσεις, όπου παραλαβές λογισμικού από άλλα πρότζεκτ, μπορούν να καταστρέψουν τον σχεδιασμό των μεμονωμένων σπριντ. Συνεπώς η προσέγγιση του σκραμ είναι λιγότερο κατάλληλη για πρότζεκτ με αρκετές εξωτερικές εξαρτήσεις.
  • Οι εκδόσεις των πρότζεκτ με μεγάλο ιστορικό τείνουν να χρειάζονται περισσότερες αναδρομικές δοκιμές. Αυτό κάνει τα μικρά σπριντ λιγότερο αποτελεσματικά σε σύγκριση με τις μεγαλύτερες σε διάρκεια συσσωρευμένες εκδόσεις. Συνεπώς η προσέγγιση του σκραμ δεν είναι τόσο κατάλληλη για πρότζεκτ με μεγάλο ιστορικό.
  • Πρότζεκτ τα οποία απαιτούν υψηλής ποιότητας κώδικα, απαιτούν και καλή ποιότητα ελέγχου. Συχνά παραδείγματα είναι τα λογισμικά για ιατρικές συσκευές ή για αυτοκίνητα. Επειδή τα σπριντ του σκραμ είναι μικρής διάρκεις, δεν υπάρχει αρκετός χρόνος για έλεγχο, έχοντας ως αποτέλεσμα κώδικα χαμηλότερης ποιότητας. Επιπροσθέτως, λόγω της ευελιξίας της προσέγγισης του σκραμ, ειδικευμένες αποφάσεις λαμβάνονται εύκολα. Αυτό μπορεί επίσης να μειώσει την ποιότητα του κώδικα.

Σκραμ-μπαν (Scrum-ban)[Επεξεργασία | επεξεργασία κώδικα]

Το σκραμ-μπαν είναι ένα μοντέλο παραγωγής λογισμικού βασισμένο στο σκραμ και το κανμπαν. Το σκραμ-μπαν είναι ειδικά χρήσιμο για πρότζεκτ συντήρησης ή πρότζεκτ (συστήματος) με συχνά και απρόσμενα αντικείμενα εργασίας ή προγραμματιστικά σφάλματα. Σε τέτοιες περιπτώσεις τα χρονοπεριορισμένα σπριντ του μοντέλου σκραμ δεν έχουν σημαντική χρησιμότητα, αλλά οι καθημερινές εκδηλώσεις του σκραμ και άλλες πρακτικές μπορούν να εφαρμοστούν, βάση της ομάδας και της τρέχουσας κατάστασης. Η απεικόνιση των σταδίων εργασίας και οι περιορισμοί για ταυτόχρονη ημιτελή δουλειά και ελαττώματα είναι γνωστά από το μοντέλο κανμπαν. Χρησιμοποιώντας αυτές τις μεθόδους, η ροή εργασίας της ομάδας καθοδηγείται με τέτοιον τρόπο ώστε να επιτρέπει την ολοκλήρωση κάθε αντικειμένου εργασίας και προγραμματιστικού σφάλματος σε λιγότερο χρόνο, καθώς παράλληλα επιβεβαιώνει ότι κάθε μέλος της ομάδας είναι διαρκώς απασχολημένο.

Για να απεικονιστεί κάθε στάδιο της εργασίας, οι ομάδες που δουλεύουν στον ίδιο χώρο συνήθως χρησιμοποιούν χαρτάκια σημειώσεων ή έναν μεγάλο πίνακα. Στην περίπτωση των αποκεντρωμένων ομάδων, η απεικόνιση σταδίων γίνεται με λογισμικά όπως το Assembla, TargetProcess, Eylean Board, JIRA ή το Agilo for Trac.

Γενικά, τα καθήκοντα κατηγοριοποιούνται στα εξής στάδια εργασίας:

  • Δεν έχουν ξεκινήσει
  • Σε εξέλιξη
  • Ολοκληρωμένα

Εαν οι ομάδες επιθυμούν μπορούν να προσθέσουν και άλλα στάδια εργασίας (όπως "ορισμένα", "σχεδιασμένα", "δοκιμασμένα" ή "διανεμημένα"). Αυτά τα επιπλέον στάδια μπορεί να βρεθούν χρήσιμα αν κάποιο συγκεκριμένο κομμάτι της εργασίας δημιουργήσει "μποτιλιάρισμα" στην ανάπτυξη και οι περιοριστικές εκτιμήσεις της ημιτελούς δουλειάς δεν μπορούν να αυξηθούν. Επίσης, μια πιο ειδικευμένη τμηματοποίηση καθηκόντων δίνει την δυνατότητα στους εργαζόμενους να εξειδικευτούν σε ένα συγκεκριμένο στάδιο της εργασίας.

Δεν υπάρχουν καθορισμένοι περιορισμοί εκτίμησης για ημιτελή δουλειά. Αντιθέτως, κάθε ομάδα πρέπει να τις ορίσει ξεχωριστά βάση των δοκιμών και των σφαλμάτων· χαμηλές εκτιμήσεις έχουν ως αποτέλεσμα την αδράνεια των εργαζομένων λόγω της έλλειψης δουλειάς, ενώ υψηλές εκτιμήσεις τείνουν να συγκεντρώνουν μεγάλα ποσοστά ημιτελούς δουλειάς, επιβραδύνοντας τους χρόνους ολοκλήρωσης. Ένας εμπειρικός κανόνας που αξίζει να έχει κάποιος υπόψην είναι ότι κανένα μέλος της ομάδας δεν πρέπει να έχει πάνω από δύο παράλληλα επιλεγόμενα καθήκοντα και από την άλλη μεριά ότι δεν μπορούν όλα τα μέλη της ομάδας να έχουν δύο παράλληλα καθήκοντα.

Οι κύριες διαφορές μεταξύ του σκραμ και του κανμπαν προέρχονται από το γεγονός ότι, στο σκραμ η δουλειά χωρίζεται σε σπριντ που διαρκούν μία συγκεκριμένη χρονική περίοδο, σε αντίθεση με την ροή εργασίας του κανμπαν που είναι διαρκής. Αυτό είναι εμφανές στους πίνακες των σταδίων εργασίας, οι οποίοι στο σκραμ αδειάζονται στο τέλος κάθε σπριντ. Στο κανμπαν όλα τα καθήκοντα σημειώνονται στον ίδιο πίνακα. Το σκραμ επικεντρώνεται στις ομάδες με πολυεπίπεδες τεχνογνωσίες, ενώ το κανμπαν κάνει εφικτές τις εξειδικευμένες, λειτουργικές ομάδες.

Καθώς το σκραμ-μπαν είναι ένα σχετικά νέο μοντέλο ανάπτυξης, δεν υπάρχει αρκετό υλικό για αναφορά. Το κανμπαν από την άλλη, έχει εφαρμοστεί από την Microsoft και την Corbis.

Εργαλεία εφαρμογής[Επεξεργασία | επεξεργασία κώδικα]

Όπως και άλλες μεθοδολογίες ευελιξίας, το σκραμ μπορεί να υλοποιηθεί μέσα από μία ευρεία γκάμα εργαλείων.

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

Τροποποιήσεις[Επεξεργασία | επεξεργασία κώδικα]

Η υβριδοποίηση του σκραμ με άλλες μεθοδολογίες ανάπτυξης λογισμικού είναι συχνή καθώς το σκραμ δεν καλύπτει όλο τον κύκλο της ανάπτυξης προϊόντος· συνεπώς, οι οργανισμοί βρίσκουν την ανάγκη να προσθέσουν επιπλέον μεθόδους ώστε να δημιουργήσουν μία πιο γενική υλοποίηση. Για παράδειγμα, στην αρχή του πρότζεκτ, οι οργανισμοί συνήθως προσθέτουν μεθόδους καθοδήγησης σχετικά με την συλλογή αναγκών και προτεραιοτήτων, τον αρχικό σχεδιασμό υψηλού επιπέδου και  την πρόβλεψη του προϋπολογισμού και του προγράμματος.

Διάφοροι δημιουργοί και κοινότητες ατόμων που χρησιμοποιούν το σκραμ έχουν επίσης προτείνει πιο λεπτομερείς τεχνικές σχετικά με το πως να εφαρμοστεί ή να προσαρμοστεί το σκραμ σε συγκεκριμένα προβλήματα ή οργανώσεις. Αρκετοί αναφέρονται σε αυτές τις μεθοδολογικές τεχνικές ως "πρότυπα" - σε αναλογία με τα σχεδιαστικά πρότυπα στην αρχιτεκτονική και το λογισμικό. Τέτοια πρότυπα έχουν επεκτείνει το σκραμ και εκτός του τομέα ανάπτυξης λογισμικού, όπως στην βιομηχανία, στην οικονομία και στους ανθρώπινους πόρους.

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

Παραπομπές[Επεξεργασία | επεξεργασία κώδικα]

  1. Sutherland, Jeff (2014). «Scrum The Art of Doing Twice The Work In Half the Time». Crown Business. 
  2. J. Henry and S. Henry. Quantitative assessment of the software maintenance process and requirements volatility. In Proc. of the ACM Conference on Computer Science, pages 346–351, 1993.
  3. «NEW NEW PRODUCT DEVELOPMENT GAME». Harvard Business Review 86116:137–146, 1986. January 1, 1986. Retrieved March 12, 2013. Ανακτήθηκε στις 11 Φεβρουαρίου 2016. 

Περαιτέρω ανάγνωση[Επεξεργασία | επεξεργασία κώδικα]

  • Jeff Sutherland· Ken Schwaber (2013). «Scrum Guides». ScrumGuides.org. Ανακτήθηκε στις 22 Μαρτίου 2015. 

Εξωτερικοί σύνδεσμοι[Επεξεργασία | επεξεργασία κώδικα]