Release planning
Γενικά, εάν δεν υπάρχει η
απαίτηση ένα σύνολο λειτουργιών / χαρακτηριστικών να ενσωματωθεί στο προϊόν σε
ένα προ-ορισμένο χρονικό σημείο, τότε η ομάδα θα πρέπει απλώς να αρχίσει να
εργάζεται «τραβώντας» αντικείμενα από την κορυφή της λίστας ανεκτέλεστου
προϊόντος (product backlog).
Όταν ωστόσο απαιτείται η ομάδα να
προβλέψει χρονικά πότε θα έχει υλοποιηθεί ένα καθορισμένο σύνολο νέων λειτουργιών,
τότε θα πρέπει να γίνεται
προγραμματισμός των νέων εκδόσεων του προϊόντος.
Οι νέες εκδόσεις του προϊόντος θα
πρέπει να πραγματοποιούνται σε χρονικές στιγμές που έχουν προγραμματιστεί από
τον ιδιοκτήτη του προϊόντος, ο οποίος έχει αποφασίσει ότι ένα σύνολο
χαρακτηριστικών θα πρέπει να είναι διαθέσιμο στους πελάτες ή τους χρήστες. Ο
ιδιοκτήτης του προϊόντος, πιθανότατα, έχει μια ιδέα για τα κατάλληλα χρονικά
πλαίσια κυκλοφορίας νέων εκδόσεων πριν ξεκινήσει οποιαδήποτε εργασία. Υπάρχει δηλαδή
μια συχνότητα στην οποία οι πελάτες ή οι χρήστες θα ήθελαν να βλέπουν νέες
δυνατότητες και είναι ευθύνη του ιδιοκτήτη του προϊόντος να καθορίσει αυτόν τον
ρυθμό.
Είναι απαραίτητο ο ιδιοκτήτης του
προϊόντος να μπορεί να κοινοποιεί το πλάνο των νέων εκδόσεων και σε άλλες
ομάδες εντός της επιχείρησης. Για παράδειγμα, οι ομάδες μάρκετινγκ και πωλήσεων
σε πολλές εταιρείες πρέπει να επικοινωνούν στην αγορά τα σχετικά με την
κυοφορούμενη νέα κυκλοφορία εκ των προτέρων, προκειμένου να προκαλέσουν θόρυβο
και ενδιαφέρον στην αγορά, και άρα είναι σημαντικό από επιχειρηματική άποψη να
ενημερώνονται αυτές τις ομάδες έγκαιρα για το τι έχει σχεδιαστεί να παραχθεί.
Οι περισσότεροι οργανισμοί αρχίζουν να πωλούν λειτουργικότητα πριν καν
ολοκληρωθεί η τοποθέτηση σε παραγωγή των νέων χαρακτηριστικών. Ανεξάρτητα πάντως
από το πότε και τον τρόπο δημιουργίας του πλάνου παραγωγής νέων εκδόσεων, ο ιδιοκτήτης
του προϊόντος και η ομάδα θα πρέπει να επανεξετάσουν τον σχεδιασμό καθ' όλη τη
διάρκεια του έργου, καθώς οι συνθήκες συχνά αλλάζουν.
Tα μέλη της ομάδας πρέπει να
ενσωματώνουν εγκαίρως τα νέα παραγόμενα χαρακτηριστικά και λειτουργίες στην επόμενη
νέα έκδοση του προϊόντος. Πολλοί προγραμματιστές αναβάλλουν τη συγχώνευση της
δουλειάς τους επειδή δεν θέλουν να αντιμετωπίσουν τα προβλήματα που προκύπτουν
από την ενοποίηση. Ο ScrumMaster, πρέπει να υπενθυμίζει στα μέλη της ομάδας ότι
οι εργασίες ενός sprint δεν ολοκληρώνονται έως ότου ο κώδικας κάθε μέλους της
ομάδας συνεργαστεί με τον κώδικα όλων των άλλων και ότι όλοι οι έλεγχοι περιπτώσεων
πρέπει να περάσουν επιτυχώς τον ποιοτικό έλεγχο. Μπορεί να είναι δύσκολο για
την ομάδα να φτάσει σε αυτό το επίπεδο κατά τα πρώτα sprint για πολλούς και διάφορους λόγους,
όπως παρωχημένες πρακτικές κατασκευής, παλιά εργαλεία κ.λπ.—αλλά πρέπει τελικά η
ομάδα να αναπτύξει την ικανότητα να ενσωματώνει τα επιμέρους παραχθέντα
χαρακτηριστικά το ενιαίο προϊόν σε συνεχή βάση. Η μη επίτευξη αυτού του στόχου θα
εμποδίσει την ικανότητα του οργανισμού να ανταποκριθεί στις πιο πιεστικές
ανάγκες των πελατών. Ο ScrumMaster, πρέπει
να βεβαιωθεί ότι η ομάδα συζητά και αντιμετωπίζει ζητήματα όπως η ενσωμάτωση
και ότι οι δοκιμές και ο ποιοτικός έλεγχος των παραδοτέων ικανοποιούν πλήρως
τις προδιαγραφές (Definition of Done)
που έχουν τεθεί.
O ScrumMaster θα πρέπει να ενθαρρύνει
την ομάδα να επικοινωνεί ρεαλιστικές εκτιμήσεις και να προσθέτει buffer όταν η
αβεβαιότητα είναι ιδιαίτερα υψηλή. Η επιλογή να δώσει μια σύντομη εκτίμηση, να
πει δηλαδή στον ιδιοκτήτη του προϊόντος ό,τι θέλει να ακούσει και να τον ικανοποιήσει
βραχυπρόθεσμα δεν πρέπει να επικροτείται. Η ομάδα επίσης θα πρέπει να επικαιροποιεί
τις εκτιμήσεις ώστε να αντισταθμιστεί η αβεβαιότητα και να κοινοποιεί τακτικά
τις ανησυχίες και τους φόβους της, τόσο στον ScrumMaster, όσο και στον
ιδιοκτήτη του προϊόντος. Γενικά, είναι πάντα καλύτερο για την ομάδα να έχει υπερεκτιμήσει
λίγο τον φόρτο των εργασιών, παρά να αποτύχει στον χρονικό σχεδιασμό της. Στην
πρώτη περίπτωση, μπορεί απλώς να «τραβήξει» και νέες προδιαγραφές από το product Backlog, τις οποίες θα
συμπεριλάβει στην επερχόμενη έκδοση. Είναι σίγουρα προτιμότερο η ομάδα να βάλει
και νέα χαρακτηριστικά στην νέα έκδοση παρά να χρειαστεί να κόψει προσχεδιασμένη
λειτουργικότητα από τη νέα κυκλοφορία.
Ο σχεδιασμός νέων εκδόσεων θα
πρέπει να είναι μια ουσιαστική συζήτηση μεταξύ της ομάδας και του ιδιοκτήτη του
προϊόντος σχετικά με το τι είναι ρεαλιστικό. Μερικές φορές αυτό σημαίνει λήψη
σκληρών αποφάσεων και συμβιβασμούς. Ο ιδιοκτήτης προϊόντος πρέπει να γνωρίζει
τις ανησυχίες και τους κινδύνους το συντομότερο δυνατό, ώστε να έχει χρόνο να
λάβει τις κατάλληλες αποφάσεις. Το buffering βοηθά τις ομάδες να κάνουν
ρεαλιστικές εκτιμήσεις και να έχουν περισσότερες πιθανότητες να ανταποκριθούν
στις δεσμεύσεις τους προς τον κάτοχο του προϊόντος.
Ο ScrumMaster πρέπει να κάνει ορατά τα buffer σε
όλους τους ενδιαφερόμενους. Στην πραγματικότητα, εφόσον ο πελάτης ή ο ιδιοκτήτης
του προϊόντος παρευρίσκονται στη συνάντηση προγραμματισμού νέων εκδόσεων, θα
κατανοούσαν τους λόγους πίσω από το buffering, απλά και μόνο επειδή συμμετείχε σε έναν εμπεριστατωμένο
διάλογο. Οι περισσότεροι άνθρωποι αναγνωρίζουν το buffering ως καλή πρακτική
μετριασμού του κινδύνου. Γενικά, όσο πιο αβέβαιοι είναι η ομάδα και ο
ιδιοκτήτης του προϊόντος για την μελλοντική εξέλιξη του έργου, τόσο περισσότερο
χρόνο απόσβεσης (buffer)
θα πρέπει να δεσμεύουν.
Ο σωστός σχεδιασμός των νέων
εκδόσεων είναι τελικά εξαιρετικής σημασίας λειτουργία. Πρέπει να γίνεται και με
συνεργασία του πελάτη, ώστε να αποτυπωθούν τα επιθυμητά χαρακτηριστικά, το αποδεκτό επίπεδο ποιότητας, το αποδεκτό
χρονικό διάστημα, ενώ παράλληλα γίνεται ορατή η αβεβαιότητα και το εκτιμώμενο
κόστος, ώστε ο πελάτης να μην εκπλήσσεται. Ομοίως, δεν πρέπει να περιμένουμε
από τους πελάτες μας να γνωρίζουν τα πάντα για το τι θέλουν σήμερα, γιατί απλά
δεν μπορούν.
Ο προγραμματισμός των νέων
εκδόσεων δεν είναι υποχρεωτικό γεγονός στο Scrum. Οι προδιαγραφές του Scrum δεν το αναφέρουν καν. Τα
τελευταία χρόνια το πλαίσιο Scrum επεκτάθηκε για να αναγνωρίσει τον
προγραμματισμό έκδοσης ως μια καλή (αλλά προαιρετική) πρακτική συνάντηση Scrum.
Ίσως χρειαστεί να αναρωτηθείτε εάν η ομάδα σας χρειάζεται εξαρχής σχεδιασμό
κυκλοφορίας.
