Στον κόσμο του Agile επικράτησε για χρόνια μια σχεδόν δογματική παραδοχή, ότι δηλαδή τα user stories αντικαθιστούν τις παραδοσιακές επιχειρησιακές απαιτήσεις και ότι αυτό από μόνο του συνιστά πρόοδο. Η ιδέα ήταν ελκυστική. Λιγότερη γραφειοκρατία, περισσότερη ευελιξία, μικρότερης αξίας increments. Στην πράξη όμως, ιδιαίτερα σε σύνθετα πληροφοριακά συστήματα, αυτή η μετάβαση συχνά παρήγαγε ένα χρόνιο misalignment ανάμεσα σε αυτό που χρειάζεται η επιχείρηση και σε αυτό που τελικά υλοποιείται.
Ωστόσο το πρόβλημα δεν είναι τα user stories. Το πρόβλημα είναι ότι αντιμετωπίζονται ως υποκατάστατο επιχειρησιακής ανάλυσης. Το κλασικό «As a user, I want… so that…» είναι εξαιρετικό εργαλείο συνομιλίας, αλλά κακό εργαλείο μοντελοποίησης της πολυπλοκότητας. Δεν περιγράφει κανόνες, δεν αποτυπώνει εξαιρέσεις, δεν χαρτογραφεί dependencies, δεν εκφράζει regulatory constraints. Και όμως, σε πολλά έργα χρησιμοποιήθηκε σαν να αρκεί.
Εκεί αρχίζει η απόκλιση. Το business συχνά σκέφτεται σε όρους outcomes, κανόνων, κινδύνων και λειτουργικών αλληλεξαρτήσεων. Οι ομάδες ανάπτυξης μεταφράζουν αυτά σε backlog items. Αν η μετάφραση αυτή γίνει πρόχειρα, η πληροφορία χάνεται. Και τότε εμφανίζεται ένα γνώριμο φαινόμενο. Το σύστημα “υλοποιεί τις απαιτήσεις”, αλλά δεν λύνει το επιχειρησιακό πρόβλημα.
Το έχω δει πολλές φορές σε enterprise περιβάλλοντα. Σε ένα σύστημα εταιρικών πράξεων, για παράδειγμα, ένα user story μπορεί να λέει «ως operator θέλω να εκτελώ distribution δικαιωμάτων». Ακούγεται επαρκές. Αλλά δεν είναι. Πού βρίσκονται οι κανόνες αποκοπής; Τι γίνεται με fractional entitlements; Πώς διαχειρίζονται exceptions, tax scenarios, reconciliation events; Αυτά δεν είναι “details”. Είναι η ίδια η επιχειρησιακή ουσία.
Εδώ κρύβεται και μια παρεξήγηση του Agile. Το Agile ποτέ δεν είπε να σταματήσει η ανάλυση. Είπε να σταματήσει η βαριά, στατική, upfront ανάλυση που παγώνει τη μάθηση. Άλλο αυτό και άλλο η απουσία σοβαρής requirements engineering. Πολλές ομάδες μπέρδεψαν την ελαφρότητα με την επιπολαιότητα.
Το παράδοξο είναι ότι όσο πιο ώριμες είναι οι Agile ομάδες, τόσο περισσότερο επενδύουν σε καλύτερη κατανόηση απαιτήσεων. Χρησιμοποιούν user stories, αλλά δεν περιορίζονται σε αυτά. Επιστρατεύουν domain models, event mapping, story mapping, acceptance criteria, examples, specification by example. Γιατί έχουν καταλάβει κάτι κρίσιμο, οτι δηλαδή τα user stories είναι interface συνεργασίας, όχι πλήρες γνωσιακό μοντέλο του προβλήματος.
Το misalignment γίνεται ακόμη μεγαλύτερο όταν το Product Ownership συγχέεται με το backlog administration. Product Owner δεν σημαίνει διαχειριστής tickets. Σημαίνει μεταφραστής επιχειρησιακής πρόθεσης σε προϊόν. Και αυτό επίσης συχνά είναι ένα σημείο στο οποίο χάνεται το παιχνίδι. Όχι επειδή λείπουν developers, αλλά επειδή λείπει δομημένη σκέψη γύρω από το τι πραγματικά πρέπει να λυθεί.
Υπάρχει κάτι βαθύτερο. Τα business requirements εκφράζουν σταθερότητα. Τα user stories εκφράζουν αλλαγή. Τα πληροφοριακά συστήματα όμως χρειάζονται και τα δύο. Ειδικά σε domains με κανονισμούς, χρηματοοικονομική ακρίβεια ή κρίσιμες συναλλαγές, η ιδέα ότι όλα μπορούν να διασπαστούν απλώς σε μικρά user stories είναι συχνά αφελής.
Tο πραγματικό ερώτημα λοιπόν δεν είναι “user stories ή business requirements”. Είναι πώς γεφυρώνουμε το χάσμα ανάμεσα στην επιχειρησιακή πρόθεση και στην τεχνολογική υλοποίηση. Γιατί εκεί τελικά κρίνονται τα συστήματα.
Πιστεύω ότι οι ώριμοι οργανισμοί θα πάψουν σιγά - σιγά να αντιμετωπίζουν το θέμα ως δίλημμα. Θα δουν τα user stories ως εργαλείο μέσα σε ένα ευρύτερο discipline requirements thinking. Και ίσως τότε σταματήσουμε να παραδίδουμε features που περνούν acceptance tests αλλά αποτυγχάνουν να δημιουργήσουν πραγματική επιχειρησιακή αξία.
Γιατί στο τέλος, το πρόβλημα δεν είναι αν γράψαμε σωστές ιστορίες. Είναι αν καταλάβαμε σωστά την ιστορία του ίδιου του business.
Βιβλιογραφία
- Schwaber, K. & Sutherland, J. — The Scrum Guide
- Cohn, M. — User Stories Applied
- Patton, J. — User Story Mapping
- Wiegers, K. & Beatty, J. — Software Requirements
- Poppendieck, M. & Poppendieck, T. — Lean Software Development
- Gojko Adzic — Specification by Example
- Evans, E. — Domain-Driven Design
Δεν υπάρχουν σχόλια:
Δημοσίευση σχολίου