Φανταστείτε τη σκηνή: Ένα σκοτεινό γραφείο, managers πηγαινοέρχονται μουρμουρίζοντας, άυπνοι προγραμματιστές σε πρόθυρα νευρικού κλονισμού σκυμμένοι στις οθόνες τους πληκτρολογούν μανιωδώς, τριγύρω τσαλακωμένα post-its, στοίβες χαρτιών και άδεια ποτήρια καφέ. Η ένταση είναι αισθητή στην ατμόσφαιρα, υπάρχουν διαφωνίες αλλά όχι οδηγίες και πρότυπα, όλοι δουλεύουν μόνοι τους και κανείς δεν ξέρει πώς και πότε τελειώνει η δουλειά. Μια ειδοποίηση για bug εμφανίζεται ξαφνικά σε μια οθόνη, κάποιος χτυπάει το ένα χέρι στο μέτωπο και το άλλο στο γραφείο, κι ένας άλλ ος παραδίπλα φωνάζει: «Ναι, το παλεύω ώρες! Τέλος πάντων, [ο πελάτης] θέλει κάτι άλλο τώρα».
Οκ, ίσως τα πράγματα να μην είναι τόσο…κινηματογραφικά δραματικά. Αλλά για όποιον έζησε τις πρώτες εποχές του software development, είναι μια σκηνή μάλλον οικεία.
Ευτυχώς πολλά έχουν βελτιωθεί από τότε. Μια εφεύρεση που βοήθησε να μπει τάξη σε αυτό το χάος και έκανε τις ζωές των προγραμματιστών (και των πελατών) καλύτερες, είναι η τυποποιημένη αντίληψη του "Definition of Done" - το γνωστό DoD.
Πώς προέκυψε το DoD;
Η έννοια του Definition of Done (DoD) προέρχεται από την Agile μεθοδολογία ανάπτυξης λογισμικού που πρωτοεμφανίστηκε στις αρχές της δεκαετίας του 2000. Στο επίκεντρό της – όπως τονίζει και το Agile Manifesto
– βρίσκεται η συχνή παράδοση λειτουργικού software με έμφαση στη συνεργασία, την ευελιξία και την ικανοποίηση των πελατών. Το DoD, λοιπόν, δημιουργήθηκε για να διασφαλίζει ότι όλα τα μέλη της ομάδας έχουν κοινή αντίληψη του τι σημαίνει η ολοκλήρωση ενός user story ή feature.
Είναι στην ουσία ένα κοινός «Ορισμός του Έτοιμου», ώστε όλοι να έχουν την ίδια, σαφή εικόνα, για το τι ακριβώς περιμένουν από ένα ολοκληρωμένο user story ή feature.
Agile, DevOps και CI/CD για απλοποιημένο, καλύτερο delivery.
Ένα από τα βασικά οφέλη ενός καλού DoD είναι ότι προσφέρει τη δυνατότητα για άμεσο deployment ενός user story ή feature στην παραγωγή, χωρίς περιττές καθυστερήσεις. Αυτή η προσέγγιση συμβαδίζει επίσης με τη χρήση Continuous Integration and Continuous Deployment (CI/CD) όπως και με τις αρχές του DevOps, και με αυτοματοποίηση της διαδικασίας testing & deployment μας επιτρέπει να παραδίδουμε νέα features και updates στους πελάτες μας ευκολότερα και γρήγορα.
Έχοντας ένα καλά καθορισμένο DoD λοιπόν, εξασφαλίζουμε την τήρηση των απαραίτητων προτύπων ποιότητας για κάθε feature, ελαχιστοποιώντας έτσι τον κίνδυνο εμφάνισης errors ή bugs στο περιβάλλον παραγωγής.
Διαβάστε επίσης:
Case Studies:
Τι είναι το DoD στην πράξη;
Αν και, όπως είπαμε, το DoD είναι μια κοινή κατανόηση μεταξύ των μελών της ομάδας για το τι σημαίνει να ολοκληρωθεί ένα user story ή feature με το απαιτούμενο πρότυπο, η μορφή που παίρνει στην πράξη το DoD μπορεί να ποικίλλει ανάλογα με τη φύση του έργου. Το DoD καθορίζει τα κριτήρια που πρέπει να πληρούνται ώστε η δουλειά να θεωρηθεί ολοκληρωμένη, λειτουργώντας ως εργαλείο για την εγγύηση της συνέπειας και της ποιότητας κατά τις 3 διακριτές φάσεις του coding, του testing και του user acceptance.
Τυπικά περιλαμβάνει μια λίστα (checklist) με συγκεκριμένα tasks ή δρ αστηριοτήτες που πρέπει να ολοκληρωθούν (όπως coding, testing, documentation, deployment), ενώ μπορεί να καθορίζει και τα πρότυπα ποιότητας των εργασιών όπως είναι η τήρηση των συμβάσεων κώδικα ή η συμμόρφωση με νομικές απαιτήσεις. Τέλος, το DoD μπορεί επίσης να θέτει τα κριτήρια για το user acceptance testing και να ορίζει τι ακριβώς σημαίνει «ολοκληρωμένο» για ένα συγκεκριμένο product increment.
Πώς διαμορφώνεται η λίστα για το DoD;
Μια «γενική ιδέα» του τι πρέπει να γίνει δεν είναι αρκετή. Το κλειδί για αποτελεσματικό project management είναι ηδημιουργία μιας αναλυτικής λίστας με καταγραφή των απαιτούμενων items με σαφήνεια και ακρίβεια.
Παρομοίως, δεν αρκεί απλά το να γνωρίζετε τι χρειάζεστε εσείς. Είναι απαραίτητο να κατανοήσετε και να τεκμηριώσετε τι χρειάζονται και οι άλλοι, και οι ανάγκες και οι απαιτήσεις όλων να επικοινωνούνται μέσα στην ομάδα με οργανωμένο και μεθοδικό τρόπο.
Τα κύρια βήματα αυτής της διαδικασίας είναι τα εξής:
- Προσδιορίστε ποιοι είναι οι ενδιαφερόμενοι (stakeholders): Αφορά όλους όσους συμβάλλουν στη δημιουργία και την έγκριση του DoD, συμπεριλαμβανομένων των developers, testers, product owners, project managers και άλλων εμπλεκόμενων μελών της ομάδας.
- Κάντε brainstorm για τα checklist items: Στο στάδιο αυτό γίνεται μία συνάντηση όπου όλοι οι ενδιαφερόμενοι προτείνουν στοιχεία (items), χρησιμοποιώντας τεχνικές όπως το mind mapping ή το affinity diagramming.
- Κατηγοριοποιήστε & θέστε προτεραιότητες: Στη συνέχεια, τα items ταξινομούνται με βάση την ποιότητα του κώδικα, τις δοκιμές και την τεκμηρίωση (code quality, testing and documentation) και ιεραρχούνται με βάση το πόσο σημαντικά είναι.
- Αναπροσαρμόστε & Οριστικοποιήστε: Η λίστα τροποποιείται και βελτιώνεται σύμφωνα με το feedback και εγκρίνεται από όλους τους ενδιαφερόμενους.
- Επικοινωνία & Εφαρμογή: Μετά την έγκριση, το DoD κοινοποιείται σε όλα τα μέλη της ομάδας και η εφαρμογή του παρακολουθείται μέσω τακτικών reviews.
- Εξέλιξη & Βελτίωση: Στα πλαίσια της γενικότερης φιλοσοφίας της Agile μεθοδολογίας, το DoD δεν είναι στατικό. Με την πάροδο του χρόνου και καθώς η ομάδα μαθαίνει και βελτιώνεται, το DoD μπορεί και αυτό να εξελίσσεται και να χρησιμεύει ως εργαλείο για συνεχόμενη πρόοδο, ενισχύοντας παράλληλα και τις άλλες πτυχές της agile διαδικασίας.
Πέρα από τις τεχνικές απαιτήσεις
Για κάποιον με τεχνικό υπόβαθρο, π.χ. έναν προγραμματιστή, είναι μάλλον εύκολο να πέσει στην παγίδα του να πιστέψει ότι τα κριτήρια ολοκλήρωσης του project είναι κυρίως τεχνικής φύσης, για παράδειγμα:
- Ο κώδικας έχει περάσει από review και έχει δοκιμαστεί
- Όλα τα αυτοποιημένα tests έχουν γίνει επιτυχώς
- Ο κώδικας έχει ενσωματωθεί στο κύριο codebase
- Η τεκμηρίωση έχει ενημερωθεί
Οι μη-τεχνικές απαιτήσεις όμως είναι εξίσου σημαντικές, ειδικά για τους πελάτες. Αυτές περιλαμβάνουν πράγματα όπως:
- Το feature έχει εγκριθεί από τον product owner
- Το user acceptance testing έχει ολοκληρωθεί
- Όλοι οι ενδιαφερόμενοι έχουν εξοικειωθεί με το feature
Τα ακριβή κριτήρια που περιλαμβάνονται στο DoD μπορεί να διαφέρουν από ομάδα σε ομάδα και από project σε project. Γι' αυτό είναι πρωταρχικής σημασίας το να αναγνωριστούν εξαρχής οι κατάλληλοι ενδιαφερόμενοι και να εμπλακούν σωστά στη φάση της δημιουργίας του checklist. Το να έχουν επίσης κοινή αντίληψη του τι σημαίνει να είναι «έτοιμο» ένα feature, βοηθά στην αποφυγή παρεξηγήσεων και καθυστερήσεων καθώς το project προχωράει.
Οφέλη για πελάτες και end-users
Εκτός από τη βελτίωση της επικοινωνίας εντός της ομάδας development, ένα DoD checklist φτιαγμένο προσεκτικά με τις παραπάνω διαδικασίες μπορεί να προσφέρει σημαντικά οφέλη σε ολόκληρη την επιχείρησή σας, όπως:
- Καλύτερη ποιότητα: Το DoD σας βοηθά να διασφαλίζετε πως κάθε feature δοκιμάζεται διεξοδικά και πληροί τα απαραίτητα πρότυπα ποιότητας. Αυτό σημαίνει ότι οι πελάτες και οι end-users θα λάβουν ένα πιο αξιόπιστο και σταθερό προϊόν, με λιγότερες πιθανότητες να έχει bugs ή άλλα προβλήματα.
- Μεγαλύτερη διαφάνεια: Το DoD εδραιώνει μια κοινή αντίληψη στην ομάδα σχετικά με το τι σημαίνει για ένα feature να είναι «έτοιμο». Αυτή η διαφάνεια βοηθά στο χτίσιμο εμπιστοσύνης και εξασφαλίζει πως όλοι κινούνται στο ίδιο μήκος κύματος όσον αφορά στην πρόοδο και τις προσδοκίες από το project.
- Ταχύτερη Διάθεση στην Αγορά: Έχοντας έναν σαφή ορισμό για το τι σημαίνει η ολοκλήρωση ενός feature, οι devs αποφεύγουν καθυστερήσεις και μειώνουν τον χρόνο για δοκιμές και debugging. Αυτό σημαίνει ότι μπορούν να παραδίδουν νέα features και updates πιο γρήγορα σε πελάτες και end-users.
- Καλύτερη Επικοινωνία: Το DoD προάγει τη συνεχή επικοινωνία μεταξύ της ομάδας development και όλων των ενδιαφερόμενων, διευκολύνοντας έτσι όλα τα εμπλεκόμενα μέρη να μένουν συντονισμένα και να έχουν κοινούς στόχους. Η αρμονική συνεργασία βοηθάει επίσης στον έγκαιρο εντοπισμό προβλημάτων ή εμποδίων, συνεπώς στην πρόληψη και την ταχύτερη επίλυσή τους και, τελικά, στην ομαλ ότερη διαδικασία ανάπτυξης.
Είναι το DoD ένας απόλυτος ορισμός; Τι να προσέξετε.
Όπως κάθε εργαλείο, το DoD έχει περιορισμούς και είναι σημαντικό να τους γνωρίζουμε για να το χρησιμοποιούμε αποτελεσματικά.
- Ένα καλό DoD απαιτεί χρόνο: Αυτό ενδέχεται να δώσει την αίσθηση σε κάποια μέλη της ομάδας ότι «χάνεται» χρόνος από το development.
- Η ευελιξία έχει όρια: Μερικές φορές οι γρήγορα μεταβαλλόμενες απαιτήσεις ή άλλες απροσδόκητες συνθήκες, μπορεί να καταστήσουν δύσκολη τη συμφωνία σχετικά με το ποια είναι τα σταθερά καλά κριτήρια, δηλαδή εκείνα που παραμένουν επίκαιρα για αρκετό χρόνο ώστε να είναι χρήσιμα.
- Ψευδαίσθηση ολοκλήρωσης: Όταν τα κριτήρια δεν είναι αρκετά σαφή, είναι εύκολο για μια ομάδα να πιστέψει ότι κάτι έχει ολοκληρωθεί ενώ δεν είναι ακόμα έτοιμο.
- Πρέπει να ξέρετε τι θέλετε: Σε κάποιους ακούγεται παράδοξο αλλά ορισμένα είδη projects στην ανάπτυξη software ωφελούνται από την έλλειψη προβλεψιμότητας (π.χ. τα R&D ή τα πειραματικά projects). Σε κάποιες από αυτές τις περιπτώσεις η DoD προσέγγιση μπορεί να μην είναι ιδανική.
- Απαιτείται συναίνεση & κατανόηση από όλα τα μέρη: Εάν το DoD δεν κοινοποιηθεί με σαφήνεια ή δεν συμφωνηθεί από όλους τους εμπλεκόμενους, ενδέχεται να μην καθοδηγήσει αποτελεσματικά τις προσπάθειες ανάπτυξης.
DoD: Ένα checklist για επιτυχία
Σε τελική ανάλυση, το DoD είναι σαφέστατα ένα χρήσιμο εργαλείο και βασικός πυλώνας του Agile software development στο cloud. Oι περιορισμοί δεν θα έπρεπε να σας αποθαρρύνουν, αφού όταν λαμβάνονται υπόψη οι επιπλοκές μπορούν να αποφεύγονται. Όταν τα DoD χρησιμοποιούνται σωστά, όταν δηλαδή καθορίζουν ένα σαφές και πλήρες σύνολο απαιτήσεων που πρέπει να πληρούνται για να μπορούμε να μιλάμε για «έτοιμο», συμβάλλουν αποφασιστικά στη διασφάλιση όχι μόνο της ολοκλήρωσης αλλά και της ποιότητας ενός project.
Ακολουθώντας λοιπόν αυτές τις κατευθυντήριες γραμμές, μπορείτε να είστε σίγουροι ότι κινείστε ήδη προς την επιτυχία.
Επιδιώξτε υψηλότερα πρότυπα.
Είστε έτοιμοι να ξεκινήσετε; Αφήστε τους ειδικούς μας να αναλάβουν τις λύσεις σας για να μπορέσετε να εστιάσετε στους επιχειρηματικούς σας στόχους. Επικοινωνήστε μαζί μας σήμερα για μια πρώτη συζήτηση!