Scrum Μέθοδος για τη Διαχείριση Έργων Λογισμικού Ενότητα 3- Scrum- εργαλεία Δρ. Δημήτριος Τσέλιος Καθηγητής Εφαρμογών Τμήμα Μηχανικών Πληροφορικής Τ.Ε.- ΤΕΙ Θεσσαλίας Μεταπτυχιακό Πρόγραμμα Μηχανική Λογισμικού για Διαδικτυακές & Φορητές Εφαρμογές 1
Σχεδιασμός του Scrum και συλλογική δέσμευση Πρακτικές των ομάδων Scrum σε σχέση με τον σχεδιασμό των sprints. User stories για την κατανόηση των αναγκών των χρηστών. Story points για τον υπολογισμό της ταχύτητας των έργων. Εργαλεία οπτικοποίησης όπως τα γραφήματα burndown και τα task boards. 2
Ιστορίες χρηστών, Ταχύτητα και Γενικά Αποδεκτές Πρακτικές Scrum Η ομάδα πρέπει να θέτει τις ορθές προσδοκίες στην αρχή του κάθε sprint. Κατά τη διάρκεια του sprint θα πρέπει να ενημερώνει τους πάντες για τις αλλαγές που προκύπτουν μέσα από τις Daily scrum συναντήσεις. Συνεπώς αν και δεν είναι υποχρεωτικό καλό είναι να συμμετέχουν σε αυτές τις συναντήσεις χρήστες και άλλοι stakeholders. 3
Κάνοντας το λογισμικό σας χρήσιμο (1) Συλλογική δέσμευση σημαίνει ότι όλοι ειλικρινώς προσπαθείτε να κάνετε το λογισμικό πιο χρήσιμο. Αυτό γίνεται όταν κατανοείτε το τι κάνουν οι χρήστες. Δεν αρκεί το λογισμικό απλώς να «τρέχει» αλλά θα πρέπει να βοηθάει του χρήστες στο να κάνουν τη δουλειά τους. Αυτό προκύπτει μέσω της συνεργασίας με τους πελάτες. 4
Κάνοντας το λογισμικό σας χρήσιμο (2) Σύμφωνα με μια αναφορά με τίτλο CHAOS της Standish Group, ένα μεγάλο μέρος των έργων λογισμικού στα τέλη του περασμένου αποτύγχαναν. Το 64% των χαρακτηριστικών του λογισμικού είτε δεν χρησιμοποιήθηκαν ποτέ είτε χρησιμοποιήθηκαν σπάνια. 5
Κάνοντας το λογισμικό σας χρήσιμο (3) Τότε οι περισσότερες εταιρείες ακολουθούσαν την τακτική του gold-plating. Δηλαδή, οι ομάδες πρόσθεταν επιπλέον features στο λογισμικό που δεν ήταν απαραίτητα για τον χρήστη. Ένας άλλος λόγος για αυτό το φαινόμενο είναι το γεγονός πως οι χρήστες είχαν λίγο χρόνο στην αρχή του έργου για να επικοινωνήσουν με την ομάδα ανάπτυξης και έτσι φόρτωναν το λογισμικό με πλήθος από features για να είναι σίγουροι. Οι Scrum ομάδες αποφεύγουν αυτό το φαινόμενο. 6
Τα User Stories βοηθούν στη δημιουργία features που θα χρησιμοποιηθούν από τους χρήστες (1) Το User Story είναι ένα πολύ απλό εργαλείο. Αποτελείται από μία έως τέσσερις προτάσεις και αποτυπώνεται σε κάρτες. Ένα συνηθισμένο format είναι το εξής: Ως <τύπος χρήστη>, θέλω να <κάνω συγκεκριμένη ενέργεια> έτσι ώστε <τι θέλω ως αποτέλεσμα>. 7
Τα User Stories βοηθούν στη δημιουργία features που θα χρησιμοποιηθούν από τους χρήστες (2) Ένα User Story γραμμένο σε μια κάρτα 8
Τα User Stories βοηθούν στη δημιουργία features που θα χρησιμοποιηθούν από τους χρήστες (3) Ένα User Story είναι αποτελεσματικό όταν κάνει τα εξής: Περιγράφει ποιος είναι ο χρήστης. Τι θέλει να κάνει ο χρήστης. Γιατί θέλει να αυτή την ενέργεια ο χρήστης. 9
Τα User Stories βοηθούν στη δημιουργία features που θα χρησιμοποιηθούν από τους χρήστες (4) Τα User Stories χρησιμοποιούνται από τον Product Owner για να δημιουργήσει το Product Backlog. Οι περισσότερες ομάδες έργου διασπούν τα User Stories σε tasks και τοποθετούνται στη στήλη To Do του task board. Όταν κάποιος αναλαμβάνει ένα task το μεταφέρει στη στήλη In Progress. 10
Συνθήκες ικανοποίησης ενός User Story (1) Λέγονται και κριτήρια αποδοχής. Οι συνθήκες αποδοχής όπως είναι γραμμένες στο πίσω μέρος της κάρτας του User Story. Δίνουν τον πλήρη ορισμό του «Done». Είναι ένας μη αμφισβητούμενος τρόπος καθορισμού το πότε ένα User Story είναι «Done». 11
Συνθήκες ικανοποίησης ενός User Story (2) Οι συνθήκες αποδοχής όπως είναι γραμμένες στο πίσω μέρος της κάρτας του User Story. 12
Story Points και Velocity (ταχύτητα) Τα Story Points είναι μια τεχνική που χρησιμοποιείται για την εκτίμηση της εργασίας που απαιτείται σε ένα sprint. Ο υπολογισμός των Story Points του κάθε User Story γίνεται συγκρίνοντας το με παλαιότερα User Stories. Συνηθισμένη είναι η κλίμακα των 5 σημείων (1-point, 3- points και 5-points). Χρησιμοποιούνται για τον υπολογισμό της ταχύτητας ενός sprint. Εάν η ομάδα ολοκληρώσει πχ. 25 σημεία κατά τη διάρκεια ενός sprint τότε το project velocity είναι ίσο με 25 σημεία. Συνήθως οι ομάδες αποκτούν σταθερή ταχύτητα μετά από αρκετά sprints. 13
Σχεδιασμός του sprint με βάση τα Story Points. Αρχίστε με τα πιο πολύτιμα User Stories από το Product backlog. Θεωρείστε το πιο μικρό User Story ως βάση για σύγκριση. Συζητείστε με την ομάδα αν η εκτίμηση είναι ασφαλής και αν χρειάζεται αναθεωρείστε τις βαθμολογίες. Συνεχίστε την επιλογή των User Stories μέχρι να γεμίσετε το sprint με τη συνήθη ταχύτητα. Μην υπερφορτώνετε το sprint backlog. Στην αρχή της εφαρμογής των Scrum η βαθμολόγηση των User Stories είναι δύσκολη και αυθαίρετη. 14
Γιατί τα User Stories δουλεύουν; Είναι απλά. Δεν υπολογίζονται με μαγικό τρόπο. Η ομάδα έργου έχει τον έλεγχο τους. Αναγκάζουν τα μέλη της ομάδας να μιλούν για εκτιμήσεις. Οι προγραμματιστές δεν τα φοβούνται. Βοηθούν την ομάδα να ανακαλύψει τι σημαίνει ένα User Story. Βοηθούν το κάθε μέλος της ομάδας να γίνει ειλικρινώς δεσμευμένο με το Scrum 15
Γραφήματα Burndown (1) Δείχνουν με ματιά το πως προοδεύει το sprint συγκρίνοντας το με την ιστορικά καταγεγραμμένη ταχύτητα (velocity). Βήμα 1: Ξεκινούμε με ένα άδειο γράφημα γραμμής. 16
Γραφήματα Burndown (2) Αρχικό γράφημα Burndown 17
Γραφήματα Burndown (3) Βήμα 2: Καθώς το πρώτο User Story τελειώνει τότε μετακινείται στη στήλη «Done» και έτσι γίνεται η πρώτη τελεία στο γράφημα. 18
Γραφήματα Burndown (4) Δύο ιστορίες αξίας 7 σημείων ολοκληρώθηκαν 19
Γραφήματα Burndown (5) Βήμα 3: Κατά τη διάρκεια του Daily Scrum μπορεί να διαπιστωθεί ότι απαιτείται πρόσθετη εργασία. 20
Γραφήματα Burndown (6) Ο Product Owner προσθέτει επιπλέον εργασία κατά τη διάρκεια του sprint. 21
Γραφήματα Burndown (7) Βήμα 4: Όσο το sprint πλησιάζει στο τέλος του όλο και περισσότερα σημεία «καίγονται». Θα πρέπει να ελέγχουμε το κενό μεταξύ της οδηγίας και του πραγματικού «καψίματος» 22
Γραφήματα Burndown (8) Ύπαρξη κενού 23
Χρησιμοποιώντας ένα Task Board για την εκτέλεση του sprint (1) Στο δεύτερο μισό του σχεδιασμού του sprint γίνεται η διάσπαση του User Story σε tasks. Τότε όλα τα tasks καταγράφονται στο task board και στη στήλη To Do. 24
Χρησιμοποιώντας ένα Task Board για την εκτέλεση του sprint (2) Εισαγωγή tasks στη στήλη To Do. Καθώς η ομάδα αρχίζει να εργάζεται με κάποια tasks αυτά μεταφέρονται στη στήλη In Progress. 25
Χρησιμοποιώντας ένα Task Board για την εκτέλεση του sprint (3) Κάθε μέλος της ομάδας δουλεύει με ένα task που μπαίνει στη στήλη In Progress. Κάποια από τα tasks ολοκληρώνονται και μπαίνουν στη στήλη Done. 26
Χρησιμοποιώντας ένα Task Board για την εκτέλεση του sprint (4) Κάθε task που ολοκληρώνεται μπαίνει στη στήλη Done. 27
Χρησιμοποιώντας ένα Task Board για την εκτέλεση του sprint (5) Κάποια στιγμή το timebox του sprint λήγει. Αυτό σημαίνει πως κάποια tasks ακόμη παραμένουν στις στήλες In Progress και To Do. Όλα αυτά τα tasks επιστρέφουν στο Product backlog. 28
Γενικώς αποδεκτές πρακτικές Scrum Πολλές ομάδες αναπτύσσουν και χρησιμοποιούν πρόσθετα εργαλεία και τεχνικές που ονομάζονται Γενικώς Αποδεκτές Πρακτικές Scrum 29
Είναι η εταιρική κουλτούρα συμβατή με τις αξίες του Scrum; (1) Για να δείτε αν είναι συμβατή σε σχέση με τη δέσμευση: Εμπιστεύεστε την ομάδα για να αποφασίζει τι θα παραδώσει. Δεν φτιάχνετε κάτι χωρίς να μιλήσετε με την υπόλοιπη ομάδα. Ακούτε τα σχόλια και την ανάδραση των υπολοίπων. Αναλαμβάνετε πρωτοβουλίες και υπευθυνότητες (όλοι!). 30
Είναι η εταιρική κουλτούρα συμβατή με τις αξίες του Scrum; (2) Για να δείτε αν είναι συμβατή σε σχέση με τον σεβασμό: Εμπιστεύεστε την ομάδα ότι θα κάνει το σωστό πράγμα ακόμη και αν το έργο καθυστερήσει. Δίνετε αρκετό χρόνο στην ομάδα για να εργαστεί. Εμπιστεύεστε την ομάδα να επιλέξει τα σωστά για αυτή tasks. 31
Είναι η εταιρική κουλτούρα συμβατή με τις αξίες του Scrum; (3) Για να δείτε αν είναι συμβατή σε σχέση με τον εστίαση: Δεν ρωτάτε κανέναν αν κάνει δουλειά εντός του sprint. Δεν ρωτάτε κανέναν αν κάνει δουλειά που δεν έχει συμφωνηθεί από την ομάδα. Δεν απαιτείτε από την ομάδα να εργάζεται με tasks που έχετε προαποφασίσει. 32
Είναι η εταιρική κουλτούρα συμβατή με τις αξίες του Scrum; (4) Για να δείτε αν είναι συμβατή σε σχέση με το κουράγιο: Δεν μπορείτε να κατηγορήσετε για έλλειψη σχεδιασμού τον διαχειριστή έργου. Δεν μπορείτε να κατηγορήσετε κανέναν για φτωχές προδιαγραφές. Δεν παίρνετε αρκετό χρόνο για να κατανοήσετε τι θέλουν οι χρήστες. Φτιάχνετε κάτι που δεν είναι τέλειο αλλά είναι αρκετά καλό για του χρήστες σας. 33
Πότε είναι χρήσιμο το Scrum και πότε δεν είναι; (1) Complex Domain Στα πολύπλοκα έργα, τα πράγματα είναι περισσότερο απρόβλεπτα. Είναι τα έργα που χαρακτηρίζονται από το νέο. Αυτά τα έργα παράγουν καινοτομικά προϊόντα. Το Scrum είναι ιδιαίτερα αποδοτικό σε αυτό το complex domain. Complicated Domain Τα περίπλοκα προβλήματα είναι το domain των καλών πρακτικών όπου κυριαρχούν οι ειδικοί (experts). Σε αυτά τα έργα το Scrum μπορεί να δουλέψει αλλά δεν είναι και η καλύτερη επιλογή. Simple Domain Στα απλά προβλήματα, ο καθένας μπορεί να δει την αιτία και το αποτέλεσμα. Σε αυτά χρησιμοποιούνται οι βέλτιστες πρακτικές γιατί οι λύσεις είναι γνωστές. Δεν έχει νόημα η χρήση του Scrum. 34
Πότε είναι χρήσιμο το Scrum και πότε δεν είναι; (2) Chaotic Domain Σε αυτά απαιτείται η άμεση ανταπόκριση. Το Scrum δεν είναι η καλύτερη λύση για αυτά. Κάποιος πρέπει να αναλάβει την ευθύνη να λύσει το πρόβλημα τη στιγμή που πρέπει. Disorder Domain Δεν γνωρίζουμε σε ποιο domain ανήκει το έργο μας. Συνήθως οι εργαζόμενοι σε τέτοιο έργο επιλέγουν μέθοδο με βάση τις προσωπικές προτιμήσεις τους. Η λύση είναι διάσπαση του έργου σε μικρότερα που ανήκουν σε γνωστά domains. Σίγουρα δεν αποτελεί λύση το Scrum. Interrupt- Driven Domain Το Scrum δεν είναι κατάλληλο για αυτά τα έργα. Είναι προτιμότερη μια εναλλακτική agile προσέγγιση, το Kanban. Αυτό είναι ιδιαίτερα χρήσιμο σε έργα υποστήριξης ή συντήρησης λογισμικού και συστημάτων πληροφορικής. 35
Βιβλιογραφία Learning Agile, Andrew Stellman & Jennifer Greene, O Reilly, 2015, σελίδες 137-174 Essential Scrum, Keneth S. Rubin, 2013, Pearson Education Inc., σελίδες 8-10 36