3 παγίδες του Scrum και πώς να τις διορθώσετε

Ας απαλλαγούμε από τις τρομερές συναντήσεις stand-up, εκτιμώντας την κόλαση και παρέχοντας αξία χρήστη και κατασκευάζοντας εξαιρετικά προϊόντα αντί.

Φωτογραφία από τον Randy Fath στο Unsplash

Κάθε φορά που περιηγείστε κενές θέσεις για μηχανικούς λογισμικού, υπάρχει σχεδόν πάντα μια καθολική ικανότητα που ένας υποψήφιος υποψήφιος θα πρέπει να κατέχει. Αυτή η δεξιότητα είναι "Scrum". Ανεξάρτητα από το αν ο Scrum είναι στην πραγματικότητα μια δεξιοτεχνία με τον ίδιο τρόπο που είναι η τοποθέτηση κλωστοϋφαντουργικών προϊόντων ή η σύνταξη κώδικα, πάντα έχω διαπιστώσει ενδιαφέρον ότι η μεγάλη πλειοψηφία των εταιρειών έχουν κάνει τον Scrum τον τρόπο που τους δουλεύει de facto.

Τα οφέλη της ευέλικτης εργασίας - που σχεδόν πάντα σημαίνει κάποια εφαρμογή του Scrum - είναι προφανή από διοικητική άποψη. Μπορείτε να αποφασίσετε τι είναι πολύτιμη δουλειά σε τακτά χρονικά διαστήματα και όχι να βάλτε τον εαυτό σας σε τριμηνιαίες οδικές χαρτογραφίες και το έργο χωρίζεται κατά τέτοιο τρόπο ώστε θεωρητικά, όλοι να μπορούν να το κάνουν.

Πίσω το 2018, έγραψα ένα άρθρο που περιγράφει αυτό που σκέφτηκα τότε ήταν η τιμή της χρήσης του Scrum για μηχανική λογισμικού. Αυτό το άρθρο έλαβε πολλά έπαινο από τους απογοητευμένους προγραμματιστές, καθώς και ένα δίκαιο ποσό κριτικής από εκείνους που επιμένουν αυτό που περιέγραψα ήταν faux Scrum.

Από τότε, πήγα σε ένα ταξίδι για να μάθω τι συνιστά αυτό το "κακό" Scrum. Αντί να αποσύρουν εξ ολοκλήρου το Scrum ως κάτι που δεν μπορεί να λειτουργήσει για την ανάπτυξη λογισμικού, επικεντρώθηκα στην επισήμανση των κακών στοιχείων και προσπάθησα να διατυπώσω τρόπους να τους μετατρέψω σε σημαντικά και παραγωγικά στοιχεία.

Σε αυτό το άρθρο, σκέφτομαι αυτό που έχω μάθει από τη συγγραφή του προηγούμενου άρθρου και πώς νομίζω ότι ο Scrum θα μπορούσε να σας βοηθήσει και την ομάδα σας να χτίσει καλύτερο λογισμικό.

Διεξαγωγή Χρήσιμων Καθημερινών Συναντήσεων Stand-up

Αυτό είναι ένα ενδιαφέρον θέμα. Οι Stand-up συναντήσεις αποτελούν έναν από τους ακρογωνιαίους λίθους του Scrum. Η ιδέα είναι ότι μια ομάδα έργου συναντά νωρίς το πρωί, σηκώνεται και ενημερώνει ο ένας τον άλλον σχετικά με την πρόοδό τους και τα εμπόδια με τα οποία θα μπορούσαν να βοηθήσουν. Αυτές οι συναντήσεις είναι μεγάλες θεωρητικά. Παίρνει ο καθένας στην ίδια σελίδα και από τότε που συμβαίνουν στην αρχή της ημέρας, όλοι μπορούν να περάσουν παραγωγικά τις μέρες τους.

Ωστόσο, αυτό που έχω διαπιστώσει είναι ότι αυτές οι συναντήσεις συχνά καταχρώνται από τα διευθυντικά στελέχη για να διαπιστωθεί αν όλοι κάνουν τη δουλειά τους σωστά και αν το έργο είναι ακόμα στο χρονοδιάγραμμα. Εάν δεν είστε σίγουροι αν αυτό συμβαίνει ή όχι στις στάσεις σας, μια καλή ένδειξη είναι να δείτε αν το πρόσωπο που μιλάει κάνει μια επαφή με τον μάνατζέρ του ή με έναν από τους συναδέλφους του. Εάν κατευθύνουν κυρίως τη συζήτησή τους στον διευθυντή τους, οι πιθανότητες είναι ότι πρόκειται για μια συνάντηση αναφοράς που έχει μεταμφιεστεί.

Αν η στάση είναι προσανατολισμένη στον διευθυντή, τείνει να γίνει μια άσκηση στο να μιλώ, κανείς δεν ακούει. Όλοι κοιτάζουν απλά από μακριά, βαρεμένοι από το μυαλό τους και περιμένουν να τελειώσει η συνάντηση. Κατά ειρωνικό τρόπο, αυτός ο τύπος stand-up τείνει επίσης να περιλάβει περιττές λεπτομέρειες μόνο για να αναφέρει στον διαχειριστή, καθιστώντας αυτό να διαρκέσει πολύ περισσότερο από ό, τι πραγματικά έπρεπε.

Ευτυχώς, η λύση σε αυτό το είδος stand-up μπορεί να είναι απλή. Πρώτα απ 'όλα, αφαιρέστε τον διαχειριστή από την άκρη. Οι Δυνάμεις δουλεύουν, αλλά ίσως να τους πείσετε να το κάνουν, μιλώντας απλά μαζί τους. Υποθέτοντας ότι όλοι που παραμένουν στη συνάντηση εργάζονται για το ίδιο έργο, ο τόνος της συνάντησης θα αλλάξει μετά από λίγο.

Αντί της συνάντησης να αποδείξετε ότι έχετε κάνει σημαντικές εργασίες χθες και θα συνεχίσετε να το κάνετε σήμερα, η συνάντηση θα έχει περισσότερο πρόβλημα επίλυσης προβλημάτων. Θα αποφασίσετε επιτόπου ποιο έργο θα αντιμετωπίσετε στη συνέχεια και αν υπάρχει κάτι που εμποδίζει το μονοπάτι σας, μπορείτε να το αντιμετωπίσετε σωστά τότε και εκεί.

PS Εάν είστε ο διευθυντής αυτής της ιστορίας, ξέρω ότι είναι δύσκολο να κόψετε τον εαυτό σας από τη συνάντηση. Είναι ακόμα πιο δύσκολο για τα μέλη της ομάδας να ζητήσουν την απουσία σας. Ίσως να συζητάτε αυτό με την ομάδα σας και να δοκιμάζετε συνεδριάσεις χωρίς διευθυντή για μικρό χρονικό διάστημα μπορεί να είναι ένας καλός τρόπος για να μετρήσετε αν η σύσκεψη γίνεται πιο παραγωγική χωρίς εσάς.

Φωτογραφία από τον Rob Hampson στο Unsplash

Μην παρατηρείτε την αξία του χρήστη

Ένας από τους λόγους για τους οποίους οι εταιρείες εφαρμόζουν πλαίσια όπως το Scrum είναι επειδή θέλουν να προσφέρουν αξία στους τελικούς χρήστες τους, γρήγορα. Αυτά τα ζευγάρια ωραία με τη σύντομη διάρκεια των μεμονωμένων σπριντ, καθώς και με τη δυνατότητα να κάνουν προσαρμογές εστίαση μεταξύ τους.

Το μεγαλύτερο λάθος που μπορείτε να κάνετε εδώ είναι να μοιραστείτε την προσφορά αξίας μόνο στους τελικούς χρήστες σας. Ακριβώς όπως δεν έχει νόημα να προσθέσετε ένα επιπλέον πάτωμα σε ένα κτίριο με σάπια δοκάρια υποστήριξης, δεν έχει πολύ νόημα να προσθέσετε χαρακτηριστικά σε ένα έργο που καταρρέει με το δικό του βάρος.

Όπως το πώς το να οδηγείς ένα αυτοκίνητο δεν σημαίνει ότι κάποιος ξέρει πώς να κατασκευάσει ένα αυτοκίνητο, το άτομο που «οδηγεί» την ομάδα ανάπτυξης δεν γνωρίζει απαραίτητα τον καλύτερο τρόπο κατασκευής του λογισμικού. Εάν ο μηχανικός του αυτοκινήτου σας σας λέει ότι το αυτοκίνητό σας δεν είναι πλέον ασφαλές να οδηγείτε, γνωρίζετε ότι θα πάρετε τον τεράστιο κίνδυνο την επόμενη φορά που θα το πάρετε διακοπές. Πρέπει να λάβουμε την ίδια προφύλαξη όταν ένας έμπειρος μηχανικός μας λέει ότι η προσθήκη κάτι που ο χρήστης θέλει απελπισμένα έχει μεγάλο αντίκτυπο στην ποιότητα της βάσης κώδικα.

Οι μηχανικοί λογισμικού που εργάζονται σε βάση κώδικα κάθε μέρα είναι επίσης οι πιο εντατικοί χρήστες. Σε αντίθεση με τους συνηθισμένους χρήστες σας, δεν ακολουθούν απλώς την ευτυχισμένη πορεία. ακολουθούν κάθε πορεία. Εάν η υλοποίηση ενός προϊόντος γίνει συνωστισμένη, θα γίνει σταδιακά πιο δύσκολο για τους μηχανικούς να πραγματοποιήσουν οποιαδήποτε ουσιαστική δουλειά. Θα περάσουν ένα μεγάλο μέρος των ημερών τους που εργάζονται γύρω από τα πράγματα αντί να δουλεύουν πάνω σε πράγματα.

Ενώ υπάρχει αναμφίβολα αξία στη δημιουργία χαρακτηριστικών για τους τελικούς χρήστες μας, η κατοχή ενός προϊόντος που θα διατηρεί τόσο τους τελικούς χρήστες όσο και τους προγραμματιστές για μεγάλο χρονικό διάστημα είναι πολύ πιθανότερο να επιτύχει μακροπρόθεσμα. Αυτό σημαίνει ότι, μερικές φορές, μπορεί να είναι καλή ιδέα να σχεδιάσετε μεγάλο έργο refactoring ή γενική καθαριότητα σε σπριντ. Όχι ως εργασία δευτέρου επιπέδου, αλλά ως πρώτης τάξεως - την αντιμετωπίζουμε ως εργασία εξίσου σημαντική με τη δημιουργία νέων χαρακτηριστικών.

Μην λαμβάνετε εκτιμήσεις για το Ευαγγέλιο

Για να προσδιοριστεί το μέγεθος της εργασίας που μπορεί να γίνει σε ένα σπριντ, κάθε επιμέρους έργο στο backlog έχει προτεραιότητα και έχει εκτιμηθεί το έργο του. Μερικές φορές αυτό γίνεται με την εκτίμηση των πραγματικών ωρών που απαιτούνται για την ολοκλήρωση μιας εργασίας, άλλες φορές πιο ασαφείς υποκατάστατα όπως σημεία ή ακόμα και μεγέθη μπλουζών.

Η εκτίμηση του έργου που μπορεί να γίνει κατά τη διάρκεια ενός σπριντ είναι αναμφισβήτητα ένα από τα πιο περίπλοκα μέρη του Scrum. Οι προγραμματιστές ποτέ δεν φαίνεται να συμφωνούν σχετικά με το ποσό της προσπάθειας που αναλαμβάνει μια συγκεκριμένη εργασία, και αυτό υποθέτει ότι είναι ακόμη προφανές τι εκτιμάται να αρχίσει. Υπάρχουν διάφοροι λόγοι για τους οποίους οι εκτιμήσεις δεν είναι σχεδόν ακριβείς.

Ένας από τους λόγους αυτούς είναι η προηγούμενη εμπειρία. Αυτή μπορεί να είναι η προηγούμενη εμπειρία ενός ατόμου ή η ομάδα του, αλλά ποτέ δεν ισχύει για κάθε άτομο στην ομάδα. Ας υποθέσουμε ότι ένα μέλος της ομάδας έχει εκτεταμένη εμπειρία στην εφαρμογή μηχανισμών επαλήθευσης ταυτότητας, ακολουθώντας ένα συγκεκριμένο πρότυπο. Μπορεί να είναι διατεθειμένοι να εκτιμήσουν την εφαρμογή αυθεντικότητας ως πολύ λιγότερη "προσπάθεια" από κάποιον που είναι λιγότερο ενημερωμένος για το θέμα. Ωστόσο, η εκτίμηση πρέπει να είναι ακριβής για οποιονδήποτε στην ομάδα, ανεξάρτητα από το ποιος τελικά καταλήγει να κάνει το έργο.

Ένας άλλος λόγος είναι ότι το έργο που εκτιμάται είναι σχεδόν καθόλου σαφές. Για ένα αρτοποιείο, είναι αρκετά απλό να υπολογίσουμε πόσο χρόνο θα τους πάρει για να ψήσουν εκατό ψωμιά. Ξέρουν πόσο καιρό παίρνει κάποιος, πόσοι μπορούν να ψήσουν σε μια στιγμή, και τότε κάνεις απλά κάποια απλά μαθηματικά.

Όπως κάθε μηχανικός λογισμικού θα γνωρίζει, δεν λειτουργεί με αυτόν τον τρόπο όταν πρόκειται για κώδικα. Κάθε φορά που βυθίζεστε σε ένα συγκεκριμένο κομμάτι κώδικα, πρέπει όχι μόνο να το αναλύσετε και να το καταλάβετε, αλλά να κατανοήσετε και να αναλύσετε τις αλλαγές που πρόκειται να κάνετε και τις πιθανές συνέπειές του. Αυτό είναι εξαιρετικά δύσκολο να το κάνετε, πόσο μάλλον να εκτιμήσετε.

Μπορείτε πιθανώς να καταλήξετε σε μια δέσμη περισσότερων λόγων για τους οποίους η εκτίμηση εργασίας είναι δύσκολη, αλλά το θέμα είναι ότι δεν πρέπει να λάβετε καμία εκτίμηση ως ευαγγέλιο. Ας υποθέσουμε ότι η ομάδα κάνει μια εκπαιδευμένη εικασία στην καλύτερη περίπτωση, με τους ανθρώπους που έχουν εκείνη την στιγμή.

Ενώ οι ομάδες βελτιώνουν την εκτίμηση της εργασίας με την πάροδο του χρόνου, πάντα να έχετε κατά νου ότι το μικρότερο από τα πράγματα μπορεί να πετάξει εντελώς την εκτίμηση. Η πραγματική αξία είναι στην πραγματική εργασία, όχι στο εάν η εκτίμηση ήταν σωστή.

συμπέρασμα

Είναι προφανές ότι ο Scrum είναι περισσότερο από το άθροισμα των τμημάτων του. Χειρουργικά εφαρμόζοντας τις τελετές και αποκαλώντας το Scrum θα σας αφήσει απλά μια δέσμη τελετών που πρέπει να παρακολουθήσετε ξαφνικά, αλλά δεν θα κάνει απαραίτητα την ανάπτυξη της διαδικασίας σας πιο αποτελεσματική ή ακόμα πιο ευκίνητη.

Η εφαρμογή Scrum πρέπει να αποτελεί αντικείμενο συνεχούς βελτίωσης. Αν κάτι δεν λειτουργεί για την ομάδα σας. προσαρμόστε το. Το Scrum δεν πρέπει να είναι ένα αμετάβλητο σύνολο τελετών και συναντήσεων - θα πρέπει να είναι ένα ρευστό πράγμα που αναπτύσσεται στην ομάδα σας και σας δίνει ένα σύνολο οδηγιών που σας βοηθούν να γίνετε πιο παραγωγικοί και αποτελεσματικοί.

Δεν είμαι σε καμία περίπτωση ένας άπληστος ευκίνητος ενθουσιώδης, και μάλλον δεν θα είμαι ποτέ. Αλλά σε αντίθεση με το άρθρο που έγραψα το 2018 ίσως μίλησε, δεν νομίζω ότι το Scrum ως θεσμός είναι εγγενώς κακό πράγμα για τις ομάδες ανάπτυξης λογισμικού.

Αν Scrum δεν αισθάνεται ότι είναι η κατάλληλη για εσάς ομάδα, ανοίξτε τη συζήτηση. Δείτε αν άλλοι άνθρωποι στην ομάδα σας αισθάνονται τον ίδιο τρόπο και, αν το κάνουν, προσπαθήστε να εντοπίσετε τι ακριβώς αισθάνεται μη παραγωγικό και να κάνετε σταδιακές αλλαγές μαζί.

Ο καλύτερος τρόπος για την ανάπτυξη λογισμικού είναι ο τρόπος που εργάζεται για την ομάδα σας. Επικεντρωθείτε σε αυτό. Ξεχάστε τα υπόλοιπα.