Στο προηγούμενο άρθρο μου, ξεκίνησα τη συζήτηση σχετικά με τις κακώς αναπτυγμένες συνήθειες μέσα σε μια ομάδα scrum που τελικά θα οδηγήσει (αργά ή γρήγορα) σε αποτυχία στην παράδοση. Σε αυτό το άρθρο, θα ήθελα να επεκτείνω αυτό το θέμα για άλλη μια φορά και να επικεντρωθώ τώρα στις λειτουργικές διαδικασίες μέσα στην ομάδα.
Αυτά είναι εξίσου σημαντικά με την τεχνική υπεροχή της ομάδας. Ακόμα κι αν οι άνθρωποι μέσα είναι εξαιρετικά ικανοί για τη δουλειά που πρόκειται να προσφέρουν, εξακολουθούν να υπάρχουν τομείς που μπορούν να καταστρέψουν την προσπάθειά τους για τελειότητα. Και δεν θα φταίνε τόσο πολύ όσο θα είναι η άμεση ευθύνη των αποφάσεων διαχείρισης έργου και η ικανότητά τους να εξυπηρετούν την ομάδα με διαδικασίες κατάλληλες για το σκοπό για να υποστηρίξουν την ομάδα με σαφείς προθέσεις και προβλέψιμες δραστηριότητες.
Πίνακας περιεχομένων
Ιδιαίτερα διαχωρισμένη ομάδα με ξεχωριστές δεξιότητες
Φανταστείτε ότι η ομάδα έχει εξειδικευμένους προγραμματιστές, απόλυτα ανεξάρτητους και με την ικανότητα να τηρούν τις υποσχέσεις τους και να παρέχουν το συμφωνημένο περιεχόμενο σπριντ ακριβώς έγκαιρα πριν από το τέλος του σπριντ. Ακόμη και σε ένα τόσο τέλειο σενάριο (το οποίο είναι πολύ απίθανο να συμβεί ούτως ή άλλως), η ομάδα θα έχει προβλήματα να συμβαδίσει με τα (διαρκώς αυξανόμενα) χαρακτηριστικά ανεκτέλεστου αν οι δεξιότητες είναι αυστηρά διαχωρισμένες μεταξύ των μελών της ομάδας.
Λίγα Παραδείγματα
- Η ομάδα έχει 1 ή 2 μηχανικούς DevOps ικανούς να κάνουν οποιεσδήποτε αλλαγές στους αυτοματοποιημένους αγωγούς ή να φροντίζουν τις υπηρεσίες εντός της πλατφόρμας, αλλά η υπόλοιπη ομάδα δεν έχει ιδέα για τέτοια πράγματα. Στη συνέχεια, η συζήτηση αυτών των ιστοριών σε τελετές scrum, όπως οι βελτιώσεις, θα οδηγήσει σε χαμένο χρόνο για την πλειοψηφία της ομάδας με το να μένει στη σύσκεψη χωρίς καμία συμμετοχή και αντίστροφα – ο προγραμματιστής του DevOps δεν θα ενδιαφέρεται για τις υπόλοιπες ιστορίες που προσανατολίζονται στη λειτουργικότητα και Ο χρόνος στη συνάντηση θα χαθεί κυρίως.
- Υπάρχει ένας μόνο εμπειρογνώμονας βάσης δεδομένων για όλη την ομάδα. Ανάλογα με την πολυπλοκότητα και τη χρήση των λύσεων δεδομένων στο σύστημα που αναπτύσσει η ομάδα, αυτό το άτομο μπορεί να είναι συνεχώς υπερφορτωμένο με ιστορίες που δεν έχουν την ευκαιρία να ολοκληρώσουν αρκετά σύντομα, ειδικά όταν συνυπολογίζουν τις προτεραιότητές τους. Ακόμη χειρότερα, άλλες ιστορίες θα πρέπει επίσης να περιμένουν, καθώς αυτές εξαρτώνται από την πηγή δεδομένων που παρέχονται από τις ιστορίες της βάσης δεδομένων.
- Όταν ένα συγκεκριμένο προϊόν έχει ως επί το πλείστον προσανατολισμό προς την ανάπτυξη backend, ο μόνος προγραμματιστής front-end είναι εκεί για κάθε ενδεχόμενο (γιατί κατά καιρούς, ούτως ή άλλως απαιτείται κάποια μικρή αλλαγή ακόμη και στην εφαρμογή UI). Σε αυτήν την περίπτωση, πάλι, οι περισσότερες από τις τελετές scrum είναι χάσιμο χρόνου για αυτό το μέλος της ομάδας, καθώς οι γνώσεις τους περιορίζονται μόνο στο front end και τίποτα άλλο δεν έχει σημασία.
Όπου καταλήγει
Σε οποιαδήποτε από τις παραπάνω περιπτώσεις, το αποτέλεσμα είναι ότι οι άνθρωποι είτε χάνουν τον χρόνο τους είτε, εναλλακτικά, δεν μπορούν να καλύψουν τη ζήτηση. Εμποδίζουν την υπόλοιπη ομάδα να ξεκινήσει τη δουλειά στις επόμενες ιστορίες ή ουσιαστικά μειώνουν τη συνολική αποτελεσματικότητα της ομάδας scrum επειδή υπάρχει πάρα πολύς χρόνος που δεν χρησιμοποιείται στο σπριντ.
Η ομάδα, ωστόσο, εξακολουθεί να έχει αυτόν τον αριθμό προγραμματιστών. Από έξω, δεν είναι ορατό (ακόμα και χωρίς να θέλουν να εκτεθούν) ότι οι άνθρωποι μέσα στην ομάδα δεν είναι σε θέση να αναλάβουν κάποιες ιστορίες μόνο και μόνο επειδή είναι πολύ προσανατολισμένοι σε κάποιο συγκεκριμένο σύνολο δεξιοτήτων. Έτσι, δεν μπορούν να βοηθήσουν τα άλλα μέλη της ομάδας με τις ιστορίες, ακόμα κι αν η ικανότητά τους το επέτρεπε, και οι προτεραιότητες για τις ιστορίες θα το ευνοούσαν επίσης.
Είναι ακόμη δύσκολο για τον κάτοχο του προϊόντος να συνθέσει κάποιο ουσιαστικό περιεχόμενο σπριντ για την ομάδα, καθώς ο κάτοχος του προϊόντος πρέπει πάντα να λαμβάνει υπόψη του πόσα άτομα μπορούν να εργαστούν σε κάθε ιστορία και εάν περισσότερες παρόμοιες ιστορίες παρουσιάζονται στο σπριντ ταυτόχρονα , τελικά η ικανότητα της ομάδας ξεχειλίζει, ακόμα κι αν στην πραγματικότητα υπάρχουν άνθρωποι που θα μπορούσαν ενδεχομένως να δουλέψουν σε αυτές τις ιστορίες, αλλά δεν έχουν την ικανότητα να ξεκινήσουν με αυτές.
Επίλυση του Διλήμματος
Είναι ένα δίλημμα που πρέπει να λυθεί και οι διαχειριστές έργων πρέπει να γνωρίζουν τη διαδρομή που θα επιλέξουν. Συγκεκριμένα, η επιλογή μεταξύ:
- Έχοντας πολλούς προγραμματιστές full-stack ικανούς να εργαστούν σε ευρύτερο περιεχόμενο, αλλά όχι πραγματικά ειδικούς σε πολλά θέματα. Έτσι μπορούν να πάνε πλατιά αλλά όχι βαθιά. Τότε η παράδοση μπορεί να προχωρήσει γρήγορα, αλλά η ποιότητα μπορεί να υποφέρει.
- Έχοντας αφοσιωμένους ειδικούς για κάθε τεχνολογία, αλλά στη συνέχεια αποδέχεστε τον περιορισμό και εργάζεστε σκληρότερα για καλύτερα προσαρμοσμένο περιεχόμενο εκτύπωσης. Στη συνέχεια, οι άνθρωποι μπορούν να εμβαθύνουν και να οικοδομήσουν υπέροχες ιστορίες, αλλά οι ιστορίες θα πρέπει να προσεγγιστούν διαδοχικά, οπότε χρειάζεται περισσότερος χρόνος για να παραδοθούν.
Αδύναμος ιδιοκτήτης προϊόντος
Αυτό δεν είναι απαραιτήτως ένα «θέμα διαδικασίας» εξ ορισμού, αλλά το αντιμετωπίζω έτσι μόνο και μόνο επειδή η δημιουργία στερεών ιστοριών μπορεί να γίνει κατανοητή ως μια διαδικασία που η ομάδα θα πρέπει να θέλει να είναι σταθερή και συμβατή με την ομάδα ανάπτυξης.
Αυτό που εννοώ με τον όρο αδύναμο δεν χρειάζεται να αναφέρεται στην ιδιότητα γνώσης ενός ατόμου, αλλά μάλλον στην ικανότητα του κατόχου του προϊόντος να υπηρετεί τις ιστορίες της ομάδας που μπορούν να κατανοήσουν οι προγραμματιστές και οι οποίες έχουν κάποιο σαφές νόημα από την προοπτική του οδικού χάρτη προϊόντος. Και τα δύο είναι πολύ σημαντικά για μια επιτυχημένη ομάδα scrum.
Εάν στις ιστορίες λείπουν λεπτομέρειες ώστε οι προγραμματιστές να είναι σε θέση να κατανοήσουν ξεκάθαρα τον σκοπό, τη λειτουργική αξία ή τις τεχνικές προσδοκίες, τότε βασικά μπορούν να συμβούν δύο σενάρια:
- Οι προγραμματιστές θα δημιουργήσουν κάτι διαφορετικό από αυτό που πραγματικά ήθελε ο ιδιοκτήτης του προϊόντος. Είναι ακόμη δύσκολο να το πιάσεις κατά τη διάρκεια του ίδιου του σπριντ, επειδή κυρίως ο ιδιοκτήτης του προϊόντος δεν είχε τη δυνατότητα να παρακολουθεί την πρόοδο των ιστοριών σε τόσο λεπτομερές επίπεδο, και ως επί το πλείστον ο PO θα περιμένει απλώς ότι το πράγμα θα συμβεί (μαγικά).
- Οι προγραμματιστές θα ξοδέψουν πάρα πολύ χρόνο για να ξεκαθαρίσουν τις ιστορίες και να τις συζητήσουν ξανά και ξανά αντί να αρχίσουν να τις δημιουργούν. Αυτό περιλαμβάνει πολλές πρόσθετες κλήσεις, επαναλαμβανόμενες συμφωνίες και αναβολή της εργασίας στην όψιμη φάση του σπριντ. Φτάνει σε ένα σημείο όπου οι αρχικές εκτιμήσεις για τις ιστορίες δεν μπορούν πλέον να θεωρηθούν ακριβείς και οι ιστορίες δεν είναι δυνατό να κλείσουν εντός του σπριντ και κυλιούνται στα επόμενα σπριντ. Στη χειρότερη περίπτωση, η κατάσταση επαναλαμβάνεται στη συνέχεια στα επόμενα σπριντ.
Ώρα για Αυτοστοχασμό
Συνήθως είναι δύσκολο να το παραδεχτεί κανείς, αλλά ο ιδιοκτήτης του προϊόντος θα πρέπει να βρει τον χρόνο να σκεφτεί, να εξετάσει τις εκκρεμείς ιστορίες που δημιουργήθηκαν και τελικά να το συγκρίνει με το όραμα του οδικού χάρτη του προϊόντος, εάν εξακολουθεί να υπάρχει κάποια λογική σχέση μεταξύ αυτών των δύο – εάν υπάρχει κάποιος οδικός χάρτης καθόλου. Αν όχι, αυτό είναι το πρώτο πράγμα που πρέπει να λυθεί. Μερικές φορές, η λύση είναι να παραδεχτείτε ότι ο ιδιοκτήτης του προϊόντος είναι πολύ μακριά από την ομάδα και πολύ μακριά από τον δικό του στόχο.
Σε μια τέτοια περίπτωση, πρέπει να λυθεί το τμήμα του ιδιοκτήτη προϊόντος της ομάδας. Αν μη τι άλλο, το να φέρουμε στην ομάδα έναν σταθερό επιχειρηματικό αναλυτή που προσανατολίζεται περισσότερο στο περιεχόμενο της ομάδας και όχι στο επιχειρηματικό περιεχόμενο (για αυτό, έχουμε ήδη έναν ιδιοκτήτη προϊόντος σε αυτήν την περίπτωση) θα μπορούσε να είναι μια έγκυρη επιλογή, ακόμη και για την τιμή του αυξημένο συνολικό κόστος της ομάδας.
Διαδικασίες δοκιμής χωρίς σταθερό χρονοδιάγραμμα
Τι γίνεται αν οι δραστηριότητες δοκιμών δεν είναι αυστηρές σε ένα συγκεκριμένο χρονοδιάγραμμα μέσα σε ένα scrum sprint;
Εκ πρώτης όψεως, αυτό μπορεί να μοιάζει με κάτι καλό που θέλουμε για μια ευέλικτη / ομάδα scrum. Η ευελιξία είναι πάντα ευπρόσδεκτη και ακούγεται καλά όταν παρουσιάζεται έξω.
Η εμπειρία μου δείχνει ότι το αποτέλεσμα αυτής της ελευθερίας είναι περισσότερο χάος παρά ευελιξία. Δεν σημαίνει ότι η λύση σε αυτό θα πρέπει να είναι η δημιουργία «καταρρακτών εντός σπριντ» με αποκλειστικές φάσεις δοκιμών που ακολουθούνται αμέσως μετά την ολοκλήρωση της ανάπτυξης. Αυτή δεν είναι σε καμία περίπτωση η σωστή προσέγγιση σε αυτή την περίπτωση. Μπορείτε να διαβάσετε περισσότερα σχετικά με αυτό στις αναρτήσεις μου σχετικά με τη στρατηγική δοκιμών scrum και τον κύκλο ζωής ευέλικτων δοκιμών.
Μπορούμε ακόμα να επιτρέψουμε κάποια ευελιξία και να επιλέξουμε το χρονοδιάγραμμα δοκιμών καθώς φαίνεται πιο κατάλληλο για την τρέχουσα ομάδα ανάπτυξης και τις συγκεκριμένες ιδιότητες προϊόντος που παρέχει η ομάδα. Υπάρχουν, ωστόσο, δύο κύριοι στόχοι που πρέπει να επιτευχθούν με αυτήν την επιλογή:
Εάν πληρούνται αυτές οι προϋποθέσεις, η ομάδα φυσικά θα προσαρμοστεί στη διαδικασία τοποθέτησης και το χρονοδιάγραμμα παράδοσης δεν θα επηρεαστεί από απρογραμμάτιστες παρατεταμένες δραστηριότητες δοκιμών.
Τελικά, αυτό που έχει μεγαλύτερη σημασία είναι η αξιόπιστη και προβλέψιμη κυκλοφορία του sprint, που με οδηγεί στο τελευταίο σημείο αυτού του blog.
Απροσδιόριστη Διαδικασία Έκδοσης
Τώρα, αυτό είναι τόσο προφανές για κάθε ομάδα scrum. Ωστόσο, περιέργως, είναι επίσης συνήθως μια από τις πιο υποτιμημένες διαδικασίες.
Πολύ συχνά, μια ομάδα scrum θα πει απλώς ότι η κυκλοφορία θα γίνεται μετά από κάθε σπριντ, αλλά δεν υποστηρίζεται από μια σταθερή διαδικασία. Αυτό που συμβαίνει τότε, στην πραγματικότητα, είναι ότι θα προκύψουν πολλές χαοτικές, απρόβλεπτες δραστηριότητες κατά τη διάρκεια της κυκλοφορίας. Ξαφνικά όλοι οι άνθρωποι απασχολούνται με «καθήκοντα απελευθέρωσης» και κανείς δεν μπορεί να επικεντρωθεί στο να συνεχίσει να αναπτύσσει νέες ιστορίες σπριντ. Οι μετρήσεις Sprint είναι απενεργοποιημένες και η κυκλοφορία μοιάζει με τυχαία, απρόβλεπτη δραστηριότητα από την άποψη του τρίτου ατόμου (συνήθως του πελάτη).
Οι άνθρωποι είναι τόσο επικεντρωμένοι στο ανεκτέλεστο, το περιεχόμενο σπριντ, την ανάπτυξη, τις δοκιμές και τελικά την επίδειξη των αποτελεσμάτων που ξεχνούν ότι μόλις τελειώσουν με όλα αυτά, το επόμενο σπριντ είναι ήδη σε εξέλιξη και ήδη χάνουν χρόνο.
Ψάχνετε για μια καλή στιγμή για κυκλοφορία
Πότε ακριβώς πρέπει η ομάδα να κάνει την πραγματική κυκλοφορία στην παραγωγή; Το μόνο σημαντικό πράγμα που έχει σημασία στο τέλος.
Η απάντηση σε αυτή την ερώτηση βρίσκεται στη διαδικασία, υποθέτοντας ότι έχετε μία. Εξαρτάται από:
- την πολυπλοκότητα του περιεχομένου που παράγει η ομάδα στα σπριντ,
- διάρκεια ενός σπριντ,
- αριθμός των επηρεαζόμενων στοιχείων στο σύστημα
- τον αριθμό των ατόμων που χρησιμοποιούν και ζητούν τις αλλαγές,
θα πρέπει να καθιερωθεί μια διαδικασία επαναλαμβανόμενης απελευθέρωσης και να ακολουθηθεί στο εξής. Οι ακριβείς κανόνες της διαδικασίας μπορούν και πάλι να είναι ευέλικτοι στον καθορισμό. Αλλά όπως συμβαίνει με τις δραστηριότητες δοκιμών, καθιστώντας το μια σταθερή συνήθεια που είναι προβλέψιμη και προγραμματισμένη για συγκεκριμένες μέρες στο μέλλον, το κάνει κάτι στο οποίο πρέπει να βασιστείτε και να αναφερθείτε.
Επιλογές προς επιλογή
Οι πιθανές μορφές μιας τέτοιας διαδικασίας μπορεί να είναι οποιαδήποτε από τις ακόλουθες ή άλλες:
- Ολοκληρώστε τη δοκιμή των χαρακτηριστικών από το τρέχον σπριντ κατά τη διάρκεια του επόμενου σπριντ και αφήστε το περιεχόμενο στο τέλος αυτού του σπριντ (όταν ολοκληρωθεί η δοκιμή). Αυτό σημαίνει ότι κάθε κυκλοφορία δεν θα έχει περιεχόμενο από το τελευταίο σπριντ, αλλά θα περιέχει ιστορίες από τα 2 προηγούμενα σπριντ.
- Το τελευταίο σπριντ πριν από την κυκλοφορία είναι πάντα αφιερωμένο στη δοκιμή του περιεχομένου από τα δύο προηγούμενα σπριντ.
- Αυτό δεν σημαίνει ότι θα σταματήσει η ανάπτυξη κατά τη διάρκεια του «δοκιμαστικού σπριντ». Λέει μόνο ότι το περιεχόμενο που αναπτύχθηκε σε αυτό το δοκιμαστικό σπριντ δεν θα συμπεριληφθεί ακόμα στην επόμενη έκδοση.
- Εάν υπάρχουν ήδη αρκετές αυτοματοποιημένες δραστηριότητες δοκιμών, προσπαθήστε να κάνετε την κυκλοφορία μετά το τέλος κάθε σπριντ. Τότε αυτή πρέπει να είναι μια πολύ αυστηρή διαδικασία με αφοσιωμένους ανθρώπους να επικεντρώνονται σε αυτές τις λίγες ημέρες για 100%. Δεν θα πρέπει να επηρεάσει με κανέναν τρόπο την υπόλοιπη ομάδα ανάπτυξης.
- Μπορείτε επίσης να επιλέξετε να κυκλοφορείτε μία φορά το μήνα ή μία φορά ανά N μήνες, κυρίως εάν αυτό είναι καλό από την πλευρά των τελικών χρηστών. Αυτό θα αυξήσει την προσπάθεια από την πλευρά των δοκιμών για κάθε σπριντ (καθώς το περιεχόμενο θα είναι μεγαλύτερο για κάθε κυκλοφορία). Αλλά από την άλλη, θα σημαίνει μικρότερο αριθμό επαναλαμβανόμενων δραστηριοτήτων με την πάροδο του χρόνου, κάτι που σε αυτή την περίπτωση μπορεί να έχει οφέλη για την ομάδα. Ως αποτέλεσμα, μπορεί να επιτρέψει στην ομάδα να δημιουργήσει περισσότερα νέα χαρακτηριστικά μεταξύ των κυκλοφοριών, παρά το γεγονός ότι τα χαρακτηριστικά θα έρθουν στην παραγωγή με πιο αργό ρυθμό.
Αλλά όπως αναφέρθηκε ήδη μερικές φορές στο παρελθόν, δεν είναι τόσο σημαντικό ποια από αυτές τις διαδικασίες θα επιλεγεί. Είναι πολύ πιο σημαντικό το πόσο καλά θα τηρήσει η ομάδα στη συνέχεια αυτή τη διαδικασία και θα την κάνει μια σκληρή συνήθεια.
Μπορείτε επίσης να διαβάσετε αυτόν τον οδηγό για τη διαδικασία και τις πρακτικές διαχείρισης εκδόσεων.