Στις περισσότερες ομάδες που εφαρμόζουν SCRUM, το Backlog Refinement αντιμετωπίζεται ως μια δευτερεύουσα δραστηριότητα, σχεδόν βοηθητική. Δεν είναι επίσημο event, δεν έχει αυστηρή δομή και συχνά συμπιέζεται χρονικά ή παραλείπεται όταν «δεν υπάρχει χρόνος». Και όμως, στην πράξη, αποτελεί έναν από τους πιο καθοριστικούς παράγοντες επιτυχίας ή αποτυχίας ενός προϊόντος.
Το παράδοξο είναι ότι τα περισσότερα προβλήματα που εμφανίζονται μέσα σε ένα Sprint δεν δημιουργούνται κατά τη διάρκειά του. Έχουν ήδη «φυτευτεί» πολύ νωρίτερα, στο επίπεδο της κατανόησης και της ανάλυσης. Ένα ασαφές user story, μια ελλιπής επιχειρησιακή απαίτηση ή μια υποεκτιμημένη τεχνική εξάρτηση δεν διορθώνονται στο Daily Scrum ούτε στο Sprint Review. Απλώς εκδηλώνονται εκεί.
Έχω δει επανειλημμένα ομάδες να ξεκινούν Sprint Planning με backlog που θεωρητικά είναι «ready», μόνο και μόνο για να αφιερώσουν το μισό χρόνο σε διευκρινίσεις. Σε ένα έργο που σχετιζόταν με διαχείριση εταιρικών πράξεων, ένα user story για διανομή μερίσματος φαινόταν απλό. Κατά τη διάρκεια του Sprint, αποκαλύφθηκε ότι υπήρχαν διαφορετικοί κανόνες φορολόγησης ανά χώρα, ειδικές περιπτώσεις για nominee accounts και εξαρτήσεις από εξωτερικά αρχεία που δεν είχαν καν αναφερθεί. Το αποτέλεσμα δεν ήταν απλώς καθυστέρηση. Ήταν ανασχεδιασμός εν κινήσει.
Το Backlog Refinement, όταν γίνεται σωστά, δεν είναι grooming. Είναι διαδικασία σταδιακής αποκάλυψης της πολυπλοκότητας. Είναι το σημείο όπου το business αναγκάζεται να γίνει συγκεκριμένο και η τεχνολογία να γίνει ρεαλιστική. Είναι, με άλλα λόγια, ένας μηχανισμός μείωσης της αβεβαιότητας πριν αυτή μετατραπεί σε κόστος.
Στην πράξη, αυτό σημαίνει ότι ένα ώριμο refinement δεν περιορίζεται σε διατύπωση user stories. Περιλαμβάνει αποδόμηση απαιτήσεων, αναγνώριση edge cases, κατανόηση δεδομένων και συχνά μια πρώτη μορφή αρχιτεκτονικής σκέψης. Σε περιβάλλοντα με αυξημένες κανονιστικές απαιτήσεις, όπως χρηματοοικονομικά συστήματα ή εφαρμογές που διαχειρίζονται ευαίσθητα δεδομένα, η απουσία αυτής της διεργασίας οδηγεί σχεδόν με βεβαιότητα σε τεχνικό χρέος ή λειτουργικά σφάλματα.
Υπάρχει επίσης μια λιγότερο προφανής διάσταση. Το refinement λειτουργεί ως μηχανισμός ευθυγράμμισης. Όχι μόνο μεταξύ business και IT, αλλά και εντός της ίδιας της ομάδας. Όταν οι developers συμμετέχουν ενεργά, δεν «παραλαμβάνουν» απλώς δουλειά. Συνδιαμορφώνουν τη λύση. Αντίθετα, όταν το backlog ετοιμάζεται απομονωμένα από τον Product Owner, το Sprint μετατρέπεται σε εκτέλεση εντολών με περιορισμένη κατανόηση του σκοπού.
Συχνά ακούγεται ότι «δεν έχουμε χρόνο για refinement». Στην πραγματικότητα, αυτό που δεν υπάρχει είναι χρόνος για τα προβλήματα που δημιουργούνται όταν το refinement απουσιάζει. Οι ομάδες που επενδύουν συστηματικά εκεί, παρατηρούν λιγότερες εκπλήξεις, πιο σταθερή ταχύτητα και κυρίως υψηλότερη ποιότητα παραδοτέων. Όχι επειδή εργάζονται περισσότερο, αλλά επειδή εργάζονται με μεγαλύτερη σαφήνεια.
Το SCRUM δεν επιβάλλει το πώς θα γίνει το refinement. Και αυτό είναι ίσως το πιο παρεξηγημένο σημείο. Η ευθύνη μεταφέρεται στην ομάδα. Να αποφασίσει πόσο βαθιά θα πάει, πόσο χρόνο θα επενδύσει και πόσο σοβαρά θα αντιμετωπίσει την κατανόηση πριν την υλοποίηση. Εκεί ακριβώς διαφοροποιούνται οι ώριμες ομάδες από αυτές που απλώς ακολουθούν ένα framework.
Τελικά, το Backlog Refinement δεν είναι μια προπαρασκευαστική δραστηριότητα. Είναι το σημείο όπου χτίζεται, ή υπονομεύεται, η επιτυχία του Sprint. Και αν κάτι αξίζει να αντιμετωπίζεται ως στρατηγική επένδυση μέσα στο SCRUM, αυτό δεν είναι τα ceremonies, αλλά η ποιότητα της σκέψης που προηγείται της ανάπτυξης.
Βιβλιογραφία
- Schwaber, K., & Sutherland, J. (2020). The Scrum Guide.
- Pichler, R. (2010). Agile Product Management with Scrum.
- Cohn, M. (2004). User Stories Applied: For Agile Software Development.
- Leffingwell, D. (2018). SAFe 4.5 Reference Guide.
- Wiegers, K., & Beatty, J. (2013). Software Requirements.
Δεν υπάρχουν σχόλια:
Δημοσίευση σχολίου